Когда использовать раскадровку и когда использовать XIB

Question

Существуют ли какие-либо рекомендации относительно того, когда использовать раскадровки в проекте iOS и когда использовать XIB? Каковы плюсы и минусы каждого из них и какие ситуации им подходят?

Насколько я могу судить, использование сегментированных раскадровок не так уж и чисто, когда контроллеры представления выталкиваются динамическими элементами пользовательского интерфейса (например, выводами карты).

Answer 1

Обновление 1/12/2016 : сейчас 2016 год, и я все еще предпочитаю размещать свои интерфейсы в коде, а не в раскадровке.При этом раскадровки прошли долгий путь.Я удалил все пункты из этого поста, которые просто больше не применяются в 2016 году.

Обновление 4/24/2015 : Интересно, что Apple даже не использует раскадровки в своих недавно открытыхИсточник ResearchKit as Питер Штейнбергер заметил (в подзаголовке «Интерфейсный конструктор»).

Обновление 6/10 / 2014 : Как и ожидалось, Apple продолжает улучшать раскадровки иXcode.Некоторые из пунктов, которые применяются к iOS 7 и ниже, больше не применяются к iOS 8 (и теперь помечены как таковые).Таким образом, хотя раскадровки по-прежнему имеют недостатки, я пересматриваю свой совет с не использовать до выборочно использовать там, где это имеет смысл .

Даже сейчас, когда iOS 9 вышла, я бы посоветовал против проявлять осторожность при принятии решения о том, использовать ли раскадровки.Вот мои причины:

• Раскадровки дают сбой во время выполнения, а не во время компиляции : У вас есть опечатка в имени segue или вы неправильно ее связали в вашей раскадровке?Это взорвется во время выполнения.Вы используете пользовательский подкласс UIViewController, которого больше нет в вашей раскадровке?Это взорвется во время выполнения.Если вы делаете такие вещи в коде, вы поймаете их на раннем этапе, во время компиляции. Обновление : Мой новый инструмент StoryboardLint в основном решает эту проблему.

• Раскадровки быстро сбивают с толку : с ростом вашего проекта навигация по раскадровке становится все более сложной.Кроме того, если несколько контроллеров представления имеют несколько переходов к нескольким другим контроллерам представления, ваша раскадровка быстро начинает выглядеть как чаша спагетти, и вы обнаружите, что увеличиваете и уменьшаете масштаб и прокручиваете всюду, чтобы найти контроллер представления, который вы ищетедля и выяснить, что Segue указывает, где. Обновление : эту проблему в основном можно решить, разбив раскадровку на несколько раскадровок, как описано в этой статье Пилки и этой статье РобертаКоричневый .

• Раскадровки усложняют работу в команде : поскольку у вас обычно есть только один огромный файл раскадровки для вашего проекта, когда несколько разработчиков регулярно вносят измененияодин файл может быть головной болью: необходимо объединить изменения и разрешить конфликты.Когда возникает конфликт, трудно сказать, как его разрешить: Xcode генерирует XML-файл раскадровки, и он на самом деле не был разработан с той целью, чтобы человеку пришлось читать, не говоря уже о его редактировании.

• Раскадровки делают проверки кода трудными или почти невозможными : Проверки кода коллег - отличная вещь для вашей команды.Однако, когда вы вносите изменения в раскадровку, практически невозможно просмотреть эти изменения у другого разработчика.Все, что вы можете получить - это разбор огромного XML-файла.Расшифровка того, что действительно изменилось, и если эти изменения верны или что-то сломали, действительно сложно.

• Раскадровки мешают повторному использованию кода : В моих проектах iOS я обычно создаюкласс, который содержит все цвета, шрифты, поля и вставки, которые я использую в приложении для придания ему единообразного внешнего вида: изменение в одну строку, если мне нужно настроить любое из этих значений для всего приложения.Если вы устанавливаете такие значения в раскадровке, вы дублируете их, и вам нужно будет найти каждый случай, когда вы захотите изменить их.Скорее всего, вы пропустите один, потому что в раскадровке нет поиска и замены.

• Раскадровки требуют постоянных переключателей контекста : я работаю и ориентируюсь в коде гораздо быстрее, чем в раскадровках.Когда ваше приложение использует раскадровки, вы постоянно переключаете свой контекст: «О, я хочу нажать на эту ячейку табличного представления, чтобы загрузить другой контроллер представления. Теперь мне нужно открыть раскадровку, найти правильный контроллер представления, создать новый переход».другому контроллеру представления (который я также должен найти), дайте имя segue, запомните это имя (я не могу использовать константы или переменные в раскадровках), переключитесь обратно на код и надеюсь, что я не опечатал имячто за мой метод prepareForSegue. Как бы я хотел, чтобы я мог просто набрать эти 3 строки кода прямо здесь, где я нахожусь! "Нет, это не весело.Переключение между кодом и раскадровкой (а также между клавиатурой и мышью) устареет и замедляет работу.

• Раскадровки трудно реорганизовать : Когда вы реорганизуете код,Вы должны убедиться, что он по-прежнему соответствует тому, что ожидает ваша раскадровка.Когда вы перемещаете вещи в своей раскадровке, вы только узнаете во время выполнения, работает ли он с вашим кодом.Мне кажется, что мне нужно синхронизировать два мира.Это кажется хрупким и мешает измениться по моему скромному мнению.

• Раскадровки менее гибкие : В коде вы можете делать все, что захотите!С раскадровками вы ограничены подмножеством того, что вы можете делать в коде.Особенно, если вы захотите сделать некоторые сложные вещи с анимацией и переходами, вы обнаружите, что «боретесь с раскадровкой», чтобы заставить ее работать.

• Раскадровки не позволяют вам менятьтип специальных контроллеров представления : вы хотите изменить UITableViewController на UICollectionViewController?Или в простой UIViewController?Невозможно в раскадровке.Вы должны удалить старый контроллер представления и создать новый и повторно соединить все переходы.Гораздо проще сделать такое изменение в коде.

• Раскадровки добавляют к вашему проекту два дополнительных обязательства : (1) Инструмент редактора раскадровки, который генерирует XML раскадровкии (2) компонент времени выполнения, который анализирует XML и создает из него объекты пользовательского интерфейса и контроллера.Обе части могут иметь ошибки, которые вы не можете исправить.

• Раскадровки не позволяют добавить подпредставление к UIImageView: Кто знает, почему.

• Раскадровки не позволяют включать автоматическое расположение для отдельного представления (-Controller). S : установив / сняв флажок «Автоматическое расположение в раскадровке», изменение применяется ко ВСЕМ контроллерам в раскадровке.(Спасибо Сава Мазаре за этот пункт!)

• Раскадровки имеют более высокий риск нарушения обратной совместимости : Xcode иногда меняет формат файла раскадровки и не гарантируетлюбым способом, которым вы сможете открывать файлы Storyboard, которые вы создаете сегодня, через несколько лет или даже месяцев.(Спасибо за достижения в этом вопросе. См. Оригинальный комментарий )

• Раскадровки могут сделать ваш код более сложным : при создании представленияКонтроллеры в коде, вы можете создавать собственные init методы, например initWithCustomer:.Таким образом, вы можете сделать customer внутри вашего контроллера представления неизменным и убедиться, что этот контроллер представления не может быть создан без объекта customer.Это невозможно при использовании раскадровок.Вам нужно будет дождаться вызова метода prepareForSegue:sender:, а затем вам нужно будет установить свойство customer на вашем контроллере представления, что означает, что вы должны сделать это свойство изменяемым, и вы должны будете разрешить контроллер представлениябыть созданным без объекта customer.По моему опыту, это может значительно усложнить ваш код и усложнить процесс рассмотрения вашего приложения. Обновление 9/9/16 : Крис Джомбак написал отличную статью об этой проблеме .

• Это McDonald's : Скажу это словами Стива Джобса о Microsoft: Это McDonald's (видео) !

Вот мои причины, почему мне действительно не нравится работать с раскадровками. Некоторые из этих причин также относятся к XIB. В проектах, основанных на раскадровке, над которыми я работал, они стоили мне гораздо больше времени, чем они экономили, и они усложняли, а не упрощали вещи.

Когда я создаю свой пользовательский интерфейс и поток приложений в коде, я гораздо больше контролирую происходящее, легче отлаживать, легче обнаружить ошибки на ранних этапах, легче объяснить мои изменения другим разработчики и проще поддерживать iPhone и iPad.

Тем не менее, я согласен, что размещение всего вашего пользовательского интерфейса в коде может не быть универсальным решением для всех проектов. Если пользовательский интерфейс iPad в некоторых местах сильно отличается от пользовательского интерфейса iPhone, возможно, имеет смысл создать XIB только для этих областей.

Многие из вышеперечисленных проблем могут быть устранены Apple, и я надеюсь, что именно так они и будут.

Только мои два цента.

Обновление : В Xcode 5 Apple убрала возможность создания проекта без раскадровки. Я написал небольшой скрипт, который переносит шаблоны Xcode 4 (с опцией Storyboard-opt-out) в Xcode 5: https://github.com/jfahrenkrug/Xcode4templates

Answer 2

Я широко использовал XIB и завершил два проекта, используя раскадровки.Мои уроки:

• Раскадровки хороши для приложений с небольшим или средним количеством экранов и относительно простой навигацией между представлениями.
• Если у вас много просмотров и много перекрестныхпри переходе между ними представление «Раскадровка» становится запутанным и слишком трудоемким, чтобы его поддерживать в чистоте.
• Для большого проекта с несколькими разработчиками я бы не стал использовать раскадровки, поскольку у вас есть один файл для пользовательского интерфейса и вы не можете легко работать параллельно.
• Возможно, стоит разбить большие приложения на несколько файлов раскадровки, но я этого не пробовал. Этот ответ показывает, как выполнять переходы между раскадровками.
• Вам по-прежнему нужны XIB: в обоих моих проектах раскадровки мне приходилось использовать XIB для пользовательских ячеек таблицы.

Я думаю, что раскадровки - это шаг в правильном направлении для реализации пользовательского интерфейса, и надеюсь, что Apple расширит их в будущих версиях iOS.Тем не менее, они должны решить проблему «одного файла», иначе они не будут привлекательны для крупных проектов.

Если бы я запустил приложение небольшого размера и мог позволить себе совместимость только с iOS5, я бы использовал раскадровки.Во всех остальных случаях я придерживаюсь XIB.

Answer 3

Раскадровки были созданы, чтобы помочь разработчикам визуализировать свое приложение и поток приложения. Это очень похоже на кучу xib, но в одном файле.

Есть вопрос, похожий на этот В чем разница между файлом .xib и раскадровкой? .

Вы также можете создавать собственные переходы с помощью кода, который будет динамически изменяться при необходимости, так же, как вы можете с .xibs.

ПЛЮСЫ:

• Вы можете смоделировать поток приложения, не написав много, если есть код.
• Намного легче увидеть ваши переходы между экранами и потоком ваших приложений.
• Может также использовать .xibs при необходимости с раскадровками.

МИНУСЫ:

• Работает только с iOS 5+. Не работает с iOS4.
• Может легко загромождаться, если у вас очень интенсивное представление.

На самом деле нет правильного / неправильного в использовании того или иного, это просто вопрос предпочтений и версий iOS, которые вы хотите использовать.

Answer 4

Я просто укажу 4 простых причины , почему вы должны использовать раскадровки, особенно в продуктивной среде, где вам приходится работать в команде владельцев продуктов, менеджеров по продуктам, дизайнеров UXи т. д.

1. Apple значительно улучшила работу со раскадровками. И они поощряют вас работать с ними.Это означает, что они не будут ломать ваши существующие проекты обновлениями, они обеспечат, что раскадровки будут ориентированы на будущее для новых версий XCode / iOS.
2. Более видимые результаты в меньше времени для владельцев и менеджеров продукта, даже на этапе создания.Вы даже можете использовать саму раскадровку как диаграмму последовательности действий и обсуждать ее на собраниях.
3. Даже после того, как приложение готово (и это, как правило, там начинается его жизненный цикл) - в будущем будет быстрее и проще применять небольшие корректировки *1023*.И это вполне может изменить несколько аспектов вашего макета одновременно, что вы, вероятно, захотите увидеть в виде WYSIWYG.Альтернативой может быть написание изменений пользовательского интерфейса в коде и переключение туда-обратно между IDE и симулятором для его тестирования, каждый раз в ожидании компиляции и сборки.
4. Можно научить не-разработчиков для настройки макетов в раскадровках и создания необходимых хуков для разработчиков (IBOutlets и IBActions).Это очень большой плюс, потому что позволяет разработчикам сосредоточиться на логике, а дизайнеры UX применяют свои изменения визуально, без необходимости писать какой-либо код вообще.

Я не буду писатьлюбые недостатки, так как Йоханнес уже перечислил, вероятно, все жизнеспособные из них в своем ответе.И большинство из них определенно нежизнеспособны, особенно если не учитывать значительные улучшения XCode6.

Answer 5

Я не думаю, что есть правильный ответ на ваш вопрос, это просто вопрос личного опыта и того, с чем вы чувствуете себя более комфортно.

На мой взгляд, раскадровки - отличная вещь.Это правда, действительно трудно понять, почему ваше приложение таинственно падает во время выполнения, но через некоторое время и опыт вы поймете, что это всегда связано с отсутствием какого-либо IBOutlet, и вы легко сможете это исправить.

Единственная реальная проблема - это работа в команде под контролем версий с раскадровками, на ранних стадиях разработки это может быть настоящей неразберихой.Но после этого первого этапа обновления пользовательского интерфейса, которые полностью изменяют раскадровку, очень редки, и в большинстве случаев вы сталкиваетесь с конфликтами в самых последних частях xml, которые являются переходными ссылками, которые обычно автоматически исправляются при повторном открытии раскадровки,В нашей командной работе мы предпочитали иметь дело с этим вместо тяжелых контроллеров представления с тоннами кода представления.

Я прочитал много комментариев против автоматического макета.С XCode5 он действительно улучшился, он действительно хорош даже для автоматического размещения макетов.В некоторых случаях вам придется что-то делать в коде, но вы можете просто вывести ограничение, которое нужно отредактировать, и в этот момент делать то, что вам нужно в вашем коде.Даже анимировать их.

Я также думаю, что большинство людей, которым не нравятся раскадровки, не пытались полностью понять всю мощь пользовательского перехода, где вы можете полностью настроить (в одном файле) способ, которым выпереходить от способа к другому, а также (с некоторыми хитростями) даже повторно использовать ранее загруженный контроллер представления, просто обновляя его содержимое представления вместо полной перезагрузки всего объекта.В конце вы действительно можете сделать то же самое, что и в коде, но я думаю, что у вас есть лучшее разделение проблем с раскадровками, но я согласен, что во многих случаях им не хватает функций (шрифты, изображение в качестве цветного фона, ecc ...).

Answer 6

Если вы хотите повторно использовать некоторый интерфейс в контроллерах с несколькими представлениями, вам следует использовать XIB

Answer 7

Я работал над проектом разумного размера (> 20 сцен на языке раскадровки), и столкнулся со многими ограничениями, и мне приходится неоднократно переходить к документации и поиску в Google, чтобы что-то делать.

1. Пользовательский интерфейс находится в одном файле.Даже если вы создаете несколько раскадровок, у вас все равно есть много сцен / экранов в каждой раскадровке.Это проблема в средних и больших командах.

2. Во-вторых, они не очень хорошо работают с пользовательскими контроллерами контейнеров, которые встраивают другие контроллеры контейнеров и т. Д. Мы используем MFSlideMenu в приложении с вкладками иу сцены есть стол.Это почти невозможно сделать с раскадровкой.Потратив дни, я прибег к способу XIB, где есть полный контроль.

3. Среда IDE не позволяет выбирать элементы управления в уменьшенном состоянии.Таким образом, в большом проекте, масштабирование в основном для того, чтобы получить представление высокого уровня и ничего более.

Я бы использовал раскадровки для небольших приложений с небольшими размерами команды и использовал подход XIBдля средних и больших команд / проектов.

Answer 8

Если вы хотите позаботиться о производительности раскадровки, посмотрите WWDC 2015 Session 407

Время сборки

Когда конструктор интерфейса компилирует раскадровку, он делает две вещи Во-первых, он пытается максимизировать производительность вашего приложения и во-вторых, это также минимизирует количество созданных nib-файлов.

Если у меня есть контроллер представления с представлением и несколько вложенных представлений, конструктор интерфейса, время сборки собирается создать файл пера для контроллер представления и создайте файл пера для представления.

Наличие отдельных файлов пера как для контроллера вида, так и для view, это означает, что иерархия представления может быть загружена по требованию.

Время выполнения

Когда вы выделяете экземпляр раскадровки, используя раскадровку пользовательского интерфейса, API, Первоначально все, что вы выделяете память для раскадровки пользовательского интерфейса Сам экземпляр.

Нет контроллеров представления пока нет просмотра.

Когда вы создаете исходный контроллер вида, он загружает перо для этого начального контроллера представления, но, опять же, ни одна иерархия представления не имеет был загружен еще, пока кто-то на самом деле не просит об этом.

Answer 9

Я не использую StoryBoard или XIB в своих приложениях, но создаю все программно.

∆ Преимущества:

√ Вы можете создавать любые сложные виды пользовательского интерфейса или анимации перехода для UIView.

√ Поддержка всех версий iOS.Не нужно беспокоиться о

√ * Ваше приложение будет поддерживать все устройства iPhone / iPod / iPad в вашем коде.

√ Вы всегда обновляетесь, поскольку знаете код, который всегда будет работать.

√ * Будет работать на любом запущенном (новом) устройстве - нет необходимости изменять код.

√ Все зависит от вас.В определенном месте вы хотите что-то изменить - не нужно заглядывать в раскадровку или xib.Просто найдите его в определенном классе.

√ Последний, но не список - вы никогда не забудете этого, как управлять всем программно.Это лучшая вещь, потому что вы знаете элемент управления очень глубокий, чем кто-либо другой.

_{Я никогда не сталкивался с проблемой, не используя SB или XIB, так как я хорошо с этим справился.}

_{*, если вы установили рамки объектов UIKit в соответствии с размером экрана.}

_{PS Если вы еще этого не сделали - вы можете столкнуться с трудностями (илиможет показаться скучным) но как только вы познакомитесь с этим - это действительно Candy для вас.}