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


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

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


Answers


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

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

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

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




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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Раскадровки не позволяют включать автоматическую компоновку для отдельного вида (-контроль) . С помощью проверки / снятия флажка с опцией автоматического макета в раскадровке это изменение применяется ко всем контроллерам в раскадровке. (Спасибо Саве Мазэре за это!)

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

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

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

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

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

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

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

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

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




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

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

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

ПЛЮСЫ:

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

МИНУСЫ:

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

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




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

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

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




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

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

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

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

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




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

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

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

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

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

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

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

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

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

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

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

PS Если вы еще не сделали этого - вы можете столкнуться с трудностями (или можете чувствовать себя скучно), но как только вы узнаете об этом - это действительно конфета для вас.




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

Время сборки

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

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

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

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

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

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

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




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

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

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

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

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