Коли використовувати Storyboard та коли використовувати XIB

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

Поруч, як я можу сказати, що це не так просто використовувати розгортки розкадровки, коли у вас є контролери подання, що підштовхуються динамічними елементами інтерфейсу користувача (як шпильки карт).

Я широко використовував XIB і завершив два проекти, використовуючи Storyboards. Моє навчання:

• Дошка розкадрувань приємна для додатків із невеликою та середньою кількістю екранів та відносно простою навігацією між переглядами.
• Якщо у вас багато переглядів і багато перехресної навігації між ними, перегляд розгортки стає заплутаним і занадто багато роботи, щоб підтримувати чистоту.
• Для великого проекту з декількома розробниками я б не використовував Storyboards, оскільки у вас є один файл для вашого інтерфейсу, і ви не можете легко працювати паралельно.
• Можливо, варто, щоб великі програми розділилися на кілька файлів розкадровки, але я цього не пробував. Ця відповідь показує, як робити сеги між раскадровками.
• Вам все ще потрібні XIB: В обох моїх проектах Storyboard мені довелося використовувати XIB для користувацьких комірок таблиці.

Я думаю, що Розгорнуті дошки - це крок у правильному напрямку для впровадження інтерфейсу, і сподіваюся, що Apple поширить їх у майбутніх версіях iOS. Їм потрібно вирішити проблему "єдиного файлу", інакше вони не будуть привабливими для великих проектів.

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

Оновлення 12.01.2016 : 2016 рік, і я все ще вважаю за краще розміщувати свої інтерфейси користувача у коді, а не в дошках розповідей. Коли це було сказано, Дошки розповідей пройшли довгий шлях. Я зняв усі пункти з цієї публікації, які просто більше не застосовуються у 2016 році.

Оновлення 24.04.2015 : Цікаво, що Apple навіть не використовує дошки розкад у своїх нещодавно відкритих джерелах ResearchKit, як зауважив Пітер Штейнбергер (у підрубриці "Builder інтерфейсу").

Оновлення 6.10.2014 : Як і очікувалося, Apple продовжує вдосконалювати дошки розкад та Xcode. Деякі моменти, застосовані до iOS 7 і нижче, вже не стосуються iOS 8 (і тепер позначені як такі). Тож, хоча споріднені дошки по суті все ще мають недоліки, я переглядаю свої поради від використання не вибіркового використання там, де це має сенс .

Навіть зараз, коли iOS 9 не працює, я б порадив протибудьте обережні при вирішенні питання про те, чи використовувати Стілборди. Ось мої причини:

• Не вдалося виконати рекламні дошки під час виконання, а не під час компіляції . У вас є помилка друку в назві Segue або неправильно пов’язано його у своїй дошці розкадрувань? Він підірветься під час виконання. Ви використовуєте спеціальний підклас UIViewController, який більше не існує у вашій дошці? Він підірветься під час виконання. Якщо ви робите такі речі в коді, ви їх будете ловити на початку, під час компіляції. Оновлення : мій новий інструмент StoryboardLint в основному вирішує цю проблему.

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

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

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

• Дошка розгортання перешкоджає повторному використанню коду . У своїх проектах iOS я зазвичай створюю клас, який містить усі кольори та шрифти та поля та вставки, які я використовую в додатку, щоб надати йому послідовний вигляд і відчуття: це зміна одного рядка, якщо мені доведеться відрегулюйте будь-яке з цих значень для всього додатка. Якщо ви встановите такі значення в дошці розкадрувань, ви дублюєте їх і потрібно буде знайти кожне виникнення, коли потрібно змінити їх. Висока ймовірність того, що ви пропустите його, оскільки в пошукових скриньках немає пошуку та заміни.

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

• Дошка розкадрувань важко переробити : Коли ви перефактуруєте код, ви повинні переконатися, що він все ще відповідає тому, що очікує ваша розкадровка. Коли ви переміщуєте речі на своїй раскадровці, під час виконання роботи ви дізнаєтесь лише, якщо вона все ще працює з вашим кодом. Мені здається, ніби мені доводиться синхронізувати два світи. Це відчуває крихкість і відлякує зміни в моїй скромній думці.

• Рекламні дошки менш гнучкі : в коді ви в основному можете робити все, що завгодно! За допомогою розповідей ви обмежені підмножиною того, що ви можете зробити в коді. Особливо, коли ви хочете зробити якісь передові речі з анімацією та переходами, ви опинитеся на тому, що ви "бороєтесь із розкладовою", щоб змусити її працювати.

• Рекламні дошки не дозволяють вам змінити тип спеціальних контролерів перегляду : Ви хочете змінити " UITableViewControllera" UICollectionViewController? Або на рівнину UIViewController? Неможливо на Дошці розкадрувань. Потрібно видалити старий контролер перегляду та створити новий і знову підключити всі сайти. Набагато простіше зробити таку зміну коду.

• Дошки оголошень додають до вашого проекту два додаткових зобов’язання : (1) Інструмент "Редактор розгортки", який генерує XML раскадровки та (2) компонент часу виконання, який розбирає XML і створює з нього об'єкти інтерфейсу та контролера. В обох частинах можуть бути помилки, які ви не можете виправити.

• Рекламні дошки не дозволяють додавати підвідмову доUIImageView : Хто знає чому.

• Дошки розгортання не дозволяють вам вмикати автоматичний макет для окремих переглядів (-контролера) : Перевіряючи / знімаючи прапорець параметр Автоматичний макет на Дошці розкад, зміна застосовується до ВСІХ контролерів на Розгортці. (Дякую Саві Мазаре за цей момент!)

• Дошки розгортання мають більший ризик порушення сумісності назад : Xcode іноді змінює формат файлу Storyboard і жодним чином не гарантує, що ви зможете відкривати файли Storyboard, які ви створюєте сьогодні, через кілька років або навіть місяців. (Завдяки хочамзначенням цього пункту. Дивіться оригінальний коментар )

• Рекламні дошки можуть зробити ваш код складнішим : Коли ви створюєте свої контролери подання в коді, ви можете створювати власні initметоди, наприклад initWithCustomer:. Таким чином, ви можете зробити customerвнутрішню частину контролера перегляду непорушною і переконатися, що цей контролер подання не може бути створений без customerоб'єкта. Це неможливо при використанні дощок. Вам доведеться почекати виклику prepareForSegue:sender:методу, і тоді вам доведеться встановити customerвластивість на контролері перегляду, а це означає, що ви повинні зробити цю властивість зміною, і вам доведеться дозволити створення контролера перегляду без customerоб'єкта . На мій досвід, це може значно ускладнити ваш код і ускладнити міркування про потік вашої програми. Оновлення 9.9.16: Кріс Джомбак написав чудову статтю про цю проблему .

• Це Макдональдс : сказати це словами Стіва Джобса про Microsoft: це Макдональдс (відео) !

Це мої причини, чому мені дуже не подобається працювати з розповідями. Деякі з цих причин стосуються і XIB. Щодо проектів на основі розповідей, над якими я працював, вони коштували мені набагато більше часу, ніж заощадили, і вони ускладнювали речі, а не легші.

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

Однак я погоджуюся з тим, що розміщення всього вашого інтерфейсу в коді може не бути рішенням одного розміру для кожного проекту. Якщо ваш інтерфейс iPad в певних місцях сильно відрізняється від інтерфейсу вашого iPhone, може бути доцільним створити XIB лише для цих областей.

Багато проблем, викладених вище, можуть виправити Apple, і я сподіваюся, що саме це і зробить.

Всього два мої центи.

Оновлення : У Xcode 5 Apple відібрала можливість створити проект без дошки сповіщення. Я написав невеликий сценарій, який переносить шаблони Xcode 4 (з опцією відмови від розгортки) на Xcode 5: https://github.com/jfahrenkrug/Xcode4templates

Дошки розгортання були створені, щоб допомогти розробникам візуалізувати їх додаток та потік програми. Це багато, як мати купу xib, але в одному файлі.

Існує питання, подібне до цього, що знаходиться. Чим відрізняється файл .xib від .storyboard? .

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

ПРО:

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

Мінуси:

• Працює лише з iOS 5+. Не працює з iOS4.
• Можна легко захаращувати, якщо у вас дуже інтенсивне застосування.

Насправді не правильно / неправильно, коли використовувати ту чи іншу, це лише питання переваги та те, які версії iOS ви хочете використовувати.

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

1. Apple ВЕЛИКО покращила роботу з Storyboards. І вони заохочують вас працювати з ними. Це означає, що вони не порушують ваші існуючі проекти оновленнями, вони гарантують, що дошки розкадрування - це майбутній доказ нових версій XCode / iOS.
2. Більш помітні результати за менший час для власників продуктів та менеджерів, навіть на етапі створення. Ви навіть можете використовувати саму раскадровку як схему потоку екрану та обговорювати її на зустрічах.
3. Навіть після того, як додаток буде зроблено (і це взагалі починається його життєвий цикл) - в майбутньому застосувати невеликі коригування буде швидше і простіше . І це може дуже добре змінити декілька аспектів вашого макета одночасно, що ви, мабуть, хочете побачити WYSIWYG. Альтернативою може бути рукописний зміна коду в інтерфейсі та переключення між IDE та тренажером для перевірки його, щоразу очікуючи на компіляцію та збірку.
4. Не розробників можна навчити налаштовувати макети на дошках розповідей та створювати необхідні гачки для розробників (IBOutlets та IBActions). Це дуже великий плюс, оскільки він дозволяє розробникам зосередитись на логіці, а дизайнери UX застосовують свої зміни візуально, без того, щоб взагалі писати будь-який код.

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

Я не думаю, що на ваше запитання є правильна відповідь, це лише питання особистого досвіду і те, що вам здається комфортнішим.

На мою думку, Розкадровки - це чудова річ. Це правда, насправді важко з’ясувати, чому ваш додаток таємно виходить з ладу під час виконання, але через деякий час і досвід ви зрозумієте, що це завжди пов’язано з тим, що десь відсутній IBOutlet, і ви зможете це легко виправити.

Єдине справжнє питання - це робота в команді під контролем версій з раскадровками, на ранніх стадіях розробки це може бути справжній безлад. Але після цього першого етапу оновлення інтерфейсу користувача, які повністю змінюють дошку розгортки, дуже рідкісні, і в більшості випадків ви стикаєтеся з конфліктами в останніх частинах xml, які є відомими посиланнями, які зазвичай автоматично виправляються під час повторного відкриття дошки. . У нашій командній роботі ми вважали за краще розібратися з цим замість важких контролерів перегляду з тоннами коду перегляду.

Я прочитав багато коментарів Againts авто-макет. З XCode5 він справді покращився, він справді хороший навіть для макетів з автоматичним поворотом. У деяких випадках вам доведеться щось зробити в коді, але ви можете просто викреслити обмеження, які потрібно відредагувати, і в цей момент зробити все, що вам потрібно в своєму коді. Навіть оживляти їх.

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

Я не використовую StoryBoard або XIB в будь-якому додатку .., але створюю все програмно.

∆ Переваги:

√ Ви можете створити будь-який складний тип інтерфейсу користувача або перехідні анімації для UIViews.

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

√ * Ваш додаток підтримує всі пристрої iPhone / iPod / iPad у межах вашого коду.

√ Ви завжди оновлюєтесь, оскільки знаєте код, який завжди працюватиме.

√ * Працює на будь-якому (новому) пристрої, запущеному - Не потрібно змінювати код.

√ Все залежить від вас. У певному місці ви хочете щось змінити - Не потрібно заглядати в раскадровку чи xib. Просто шукайте його в конкретному класі.

√ Останнє, але не список - Ви ніколи цього не забудете, як все керувати програмно. Це найкраще, тому що ви знаєте контроль дуже глибокий, ніж будь-хто.

_{Я ніколи не знаходжу проблем, не використовуючи SB або XIB, оскільки я добре в цьому.}

_{* якщо ви встановили об'єктні кадри UIKit відповідно до розміру екрана.}

_{PS Якщо ви ще цього не робили - ви можете зіткнутися з труднощами (або вам може бути нудно), але як тільки ви ознайомитесь з цим - це справді Цукерка для вас.}

Якщо ви збираєтеся піклуватися про ефективність дошки, перегляньте WWDC 2015 Session 407

Час побудови

Коли розробник інтерфейсів збирає дошку розкадрувань, він спочатку робить дві речі, він намагається досягти максимальної продуктивності вашої програми, а по-друге, це також мінімізує кількість створених файлів ніб.

Якщо у мене є контролер перегляду з видом і купою під-поглядів, конструктор інтерфейсів, час збирання створить файл nib для контролера перегляду та створить файл nib для подання.

Маючи окремі файли нібеля і для контролера перегляду, і для перегляду, це означає, що ієрархія перегляду може завантажуватися на вимогу.

Час виконання

Коли ви виділяєте екземпляр раскадровки за допомогою інтерфейсу розширення інтерфейсу інтерфейсу, API, спочатку все, для чого ви виділяєте пам'ять, - це самий екземпляр розкадри інтерфейсу користувача.

Контролерів перегляду ще немає переглядів

Коли ви інстанціюєте свій початковий контролер перегляду, він завантажить ручку для цього початкового контролера перегляду, але, знову ж таки, ще не завантажена ієрархія перегляду, поки хтось насправді не попросить цього.

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

1. Інтерфейс користувача весь в одному файлі. Навіть якщо ви створюєте декілька дощок, все ще є багато сцен / екранів у кожній дошці. Це проблема в середніх великих командах.

2. По-друге, вони не грають добре з користувацькими контролерами контейнерів, які вбудовують інші контролери контейнерів тощо. Ми використовуємо MFSlideMenu в додатку Tabbed, і сцена має таблицю. Це майже неможливо зробити із раскадровкой. Провівши дні, я вдався зробити XIB способом там, де є повний контроль.

3. IDE не дозволяє вибирати елементи керування у зменшеному стані. Отже, у великому проекті зменшення масштабу полягає в основному для отримання високого рівня перегляду і нічого більше.

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

Якщо ви хочете повторно використовувати деякий інтерфейс користувача у кількох контролерах перегляду, то вам слід використовувати XIB