it-swarm.com.ru

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

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

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

194
Affian

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

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

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

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

174
henning77

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

Обновление 24.04.2015 : Интересно, что Apple даже не использует раскадровки в своем недавно открытом исследовательском наборе ResearchKit как Заметил Питер Штейнбергер (под заголовком "Интерфейсный конструктор").

Обновление 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) : установив/сняв флажок с параметром Автоматическая компоновка в раскадровке, изменение применяется ко ВСЕМ контроллерам в раскадровке. (Спасибо Сава Мазаре за этот пункт!)

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

  • Раскадровки могут сделать ваш код более сложным : когда вы создаете свои контроллеры представления в коде, вы можете создавать собственные методы 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

221
Johannes Fahrenkrug

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

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

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

ПЛЮСЫ:

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

МИНУСЫ:

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

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

17
Bot

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

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

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

12
thgc

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

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

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

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

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

4
Stefano Mondino

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

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

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

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

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

0
Krishna Vedula

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

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

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

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

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

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

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

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

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

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

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

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

0
Hemang

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

enter image description here

Время сборки

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

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

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

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

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

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

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

0
onmyway133

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

0
Bibin Jaimon