Comments 11
Справедливости ради, стоит упомянуть, что ошибка в xib-файле с IBAction или Outlet тоже может привести к падению. Например, объявили в коде:
@IBOutlet weak var someView: UIView!Если забыли привязать в Interface Builder этот outlet — во время выполнения приложение упадёт, когда дойдёт до использования этого UIView.
И не очень понятно, почему среди слабых мест указано:
Использование подкласса UIView, которого уже не существует.
Разве это не приведёт к ошибке уже на этапе компиляции?
Один из классных, на мой взгляд, плюсов Storyboard — возможность прототипировать кастомные UITableViewCell прямо в Interface Builder внутри UITableView — если таблица использует несколько разных ячеек, удобно иметь их в одном месте, а не в отдельных xib-файлах.
Справедливости ради, стоит упомянуть, что ошибка в xib-файле с IBAction или Outlet тоже может привести к падению.
Конечно, если рассматривать недостатки Xib-файлов, то некоторые перечисленные здесь будут применимы и к ним.
Разве это не приведёт к ошибке уже на этапе компиляции?
Нет, Xcode только выдаст предупреждение. На самом деле, не менее распространенным случаем является несоответствие имени класса UIView в коде и в Storyboard. Тогда Xcode вообще молчит, и приложение может упасть, например, при вызове несуществующего метода.
Так же хотел бы отметить, что работать с trait variations можно и в коде. Так что в целом это не является преимуществом сторибордов.
Все указанные преимущества (в финальной таблице) относятся и к xib'ам. Так какой смысл использовать сториборды?
Xibs — замечательный инструмент, без которого лично я не представляю использование Storyboards. Storyboards мне нравятся тем, что они расширяют возможности Xibs. Иногда полезно объединить 2-3 экрана в одном месте и настроить между ними простую навигацию. Может быть, добавив еще storyboard reference на другой похожий модуль. Также Storyboards позволяют более гибко работать с таблицами, особенно когда речь идет о статических.
В конце концов, все зависит от конкретной ситуации: в каких-то удобно использовать Storyboard, а в каких-то можно ограничиться лишь Xib.
Так же хотел бы отметить, что работать с trait variations можно и в коде. Так что в целом это не является преимуществом сторибордов.
Безусловно, с trait variations можно взаимодействовать и в коде. Однако я посчитал необходимым включить size classes в список преимуществ Storyboards, так как Interface Builder упрощает с ними работу за счет предварительного просмотра любого size class и функции Vary for Traits.
Лично не сторонник сторибордов: предпочитаю xib, но исходя из контекста кажется, что вы имеете в виду "верстку в Storyboard и Xib" против "верстки в коде", по названию же кажется что речь исключительно про Storyboard.
Вынужден не согласиться с некоторыми вашими утверждениями:
Если стоит задача создать сложный экран с анимацией и эффектами, с которыми Storyboard не справится, то нужно использовать код!
Очень категорично сказано. На мой взгляд это зависит от ситуации. Вам ведь ничего не мешает декомпозировать экран, верстая и реализуя составные части в отдельных нибах или в коде.
Storyboards мешают повторному использованию кода
Ниже вы сами же верно пишете про декомпозицию экрана на xib'ы, что решает проблему. Почему же тогда это мешает повторному использованию?
Нельзя использовать кастомные инициализаторы для UIViewControllers, созданных в Storyboard
Вы правы. Но с iOS13 это возможно.
Тяжело править конфликты.
Под капотом там действительно XML, и если разработчики работают в двух разных экранах — конфликтов возникнуть не должно. Если же они работают над одним — конфликты появятся и в xib файле. Вы правы, если сравнение идет в отношении верстки в коде и storyboard, но не соглашусь если речь про xib и storyboard
Ниже вы сами же верно пишете про декомпозицию экрана на xib'ы, что решает проблему. Почему же тогда это мешает повторному использованию?
Как вы могли заметить, в итоге из 10 недостатков я вынес лишь 4. Но вы правы, из статьи это может быть не совсем понятно. Внес правку в тексте перед разделом о недостатках.
Вы правы. Но с iOS13 это возможно.
Пока необходима поддержка более старых версий, эта проблема все же сохраняет актуальность.
Вы правы, если сравнение идет в отношении верстки в коде и storyboard, но не соглашусь если речь про xib и storyboard
Неприятные конфликты могут иметь место и в xib-файлах, на мой взгляд. Зависит от его размера. В коде их править гораздо удобнее, чем в xml-файле.
3. Нельзя использовать кастомные инициализаторы для UIViewControllers, созданных в Storyboard
Да, одно из многих гореваний после андроида. Там есть хорошая идея Intent'ов. По сути объект, содержащий в себе информацию о вызывающей активности (здесь контроллере), вызываемой и набором данных-полей.
При вызове новой активности (контроллера), исходная кладет в объект набор данных, а также свой экземпляр. Некоторую похожую вещь пришлось здесь и сделать.
Правда, выше говорят что в 13 iOS'е что-то для этого есть, надо почитать
Как я понял, вы смогли это реализовать в случае со storyboards?
Да. Создал класс, в нем поля — исходный view controller, словарь данных и название нового контроллера. Также функция непосредственно запуска нового контроллера.
Новый контроллер при запуске ищет в общем списке последних 10 объектов этого класса, и находя себя по имени, заносит в найденый обьект себя, а это дает доступ к словарю данных.
При завершении вью-контроллер удаляет запись о переходе
Зачастую, когда создается кастомная вьюшка, то нам приходится использовать две точки входа в UI, UIView и Storyboard, а иногда даже UIViewController. И в таком случае у нас может появиться больше одного источника правды о состоянии UI. Для решения этой проблемы мы использовали Xibы исключительно как абстракцию лейаута, но вся кастомизация уже была кодом. Это был компромисс между разработчиками, но однако UIView мы хорошенько разгрузили от тонны лейаутного кода.
iOS Storyboards: анализ плюсов и минусов, best practices