Ответ 1
Я не думаю, что iOS 6 исправляет любую из этих ситуаций. Более того, xcode 4.5 не исправляет их и даже не пытается сделать это. Перечисленные проблемы, похоже, отражают мнения или стилистические предпочтения и, возможно, некоторые дезинформации. Это не та вещь, которая МОЖЕТ быть зафиксирована в коде.
Я использую раскадровки для существенного приложения, и я нахожу их настоящим бонусом в производительности. Я призываю вас попробовать их, чтобы убедиться, что вы не согласны.
Несколько комментариев по списку проблем:
- Я не знаю никаких проблем с командами и SB, но если 2 были правдой (что это не так), что объясняет эту проблему. Я думаю, это заблуждение, основанное на 2.
- Не верно. Я использую Git религиозно и часто совершаю. Без проблем. Во время коммитов SB отображаются в форме исходного кода (XML). Различия отлично работают и фактически дают некоторое представление о том, как SBs реализованы. Это уменьшает ощущение таинственного поведения "под покровом", которое становится неконкурентоспособным со знакомством.
- Не согласен. Они не нарушают поток, они предлагают другой поток - именно там они получают свою силу. Многие программисты находят ценность в разделении, налагаемом дисциплиной MVC. SBs вводят разделение между размещением элементов пользовательского интерфейса и поддерживающим кодом. Это естественный раскол и устраняет тонну бессмысленного кода (что исключает возможность опечаток и "де-загромождает" код REAL, который остается).
- Отчасти согласен - они определенно улучшают простоту использования. Но я вообще не нахожу жертву. Даже при использовании SB вы всегда можете вернуться к кодированию любых объектов, если вам нужно. Там нет жертвы гибкости или контроля.
- Не уверен, что это значит, и почему это может быть проблемой. Конечно, мы создаем разные VC для разных сцен - это естественно. Но, безусловно, можно повторно использовать классы VC в SB. Этот элемент может быть неправильным представлением о том, как установить класс для объекта SB. Легко забыть сделать этот шаг, и иногда он озадачивает начинающих. Но это тривиально, чтобы исправить, и установка класса быстро становится привычкой.
Для меня настоящие проблемы:
- Использование SB требует много экранной недвижимости для разработки. Использование SB может быть разочаровывающим на небольшом дисплее.
- Очень сложные пользовательские интерфейсы со многими сценами должны быть разделены на несколько SB. Множественные SB полностью поддерживаются, но легко выполнить это. (Это похоже на рефакторинг метода, который становится слишком большим. Обычно я замечаю, что мне нужен код рефрактора ПОСЛЕ того, что что-то уже запуталось.)
Удобство SB во время компоновки и устранение большого количества кода шаблона, который загромождает объекты VC, является огромным преимуществом. (Каждая строка кода, которую я исключаю, это строка, которую я не могу испортить, и строку, которая не может скрыть реальный код, который остается.)
Короче говоря, я не могу представить себе возвращение к жизни без SB. Да, это изменение. Но я не нашел серьезного серьезного недостатка. Особенно важно помнить, что даже при использовании SB все методы работы, отличные от SB, все еще работают. Попросите SB попробовать и сообщите свой собственный опыт. Удачи!