Являются ли они все еще действительными негативами против использования раскадровки в разработке приложений iOS 6?

Использование раскадровки вместо традиционной стратегии .xib - это то, над чем я все еще борюсь, поскольку есть нерешительность в отношении принятия чего-то, что делает так много под обложками, не понимая, что он делает, и какой контроль я "Я действительно проигрываю".

Книга программирования BNR iOS выделяет несколько "минусов" для использования раскадровки. Я перечислил их ниже, и мой вопрос: Являются ли эти негативы действительными с iOS 6?

Раскадранты с трудом работают в команде.
Раскалывание управления версиями версии
Раскалывание нарушает поток программирования
Кампании жертвуют гибкостью и контролем за простоту использования.
Раскадровки всегда создают новые экземпляры контроллера просмотра.

Я ищу ответы от ребята, которые на самом деле строят, и, желательно, развертывают настоящие приложения для iOS и борется с самими "раскадными файлами против .xib".

Спасибо

Ответ 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 попробовать и сообщите свой собственный опыт. Удачи!

Ответ 2

Я вообще согласен с jbbenni. Единственная "действительная" критика, которую я вижу в ваших точках, заключалась в том, что "Раскалы всегда создают новый экземпляр". В принципе, это означало, что, хотя вы можете подключить кнопку, чтобы нажать контроллер представления в стеке, вы не смогли бы подключить кнопку, чтобы пополнить резервную копию стека без дополнительного кода. Это было разрешено в Xcode 4.5 с "exit segues", что позволяет указать, что вы хотите вернуться к предыдущему контроллеру, а не создавать новый экземпляр.

Другое ограничение раскадровки, на которое многие жаловались, заключалось в том, что вы не могли встроить контроллеры детского представления в раскадровку. Это также было рассмотрено в Xcode 4.5.

Раскадровки являются значительным шагом вперед для разработки iOS. Жалобы, такие как "это затрудняет слияние", необоснованны; раскадровки не сложнее слить, чем другой код; вам просто нужно потратить время, чтобы на самом деле прочитать diff вместо того, чтобы замаскировать его как "не Obj-C, не может читать".

Я использовал раскадровки успешно в команде с момента их появления. Не позволяйте неосведомленным пугать вас. Они великолепны.