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


Answers

Обновление 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

Question

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

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




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

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

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

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

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




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

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

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

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

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

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

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

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

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

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

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

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




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

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

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