Как вы знаете, в Xcode 6 и iOS 8 SDK Apple добавила возможность рендеринга кастомных компонентов и редактирования их свойств прямо в стандартном Interface Builder (здесь должно быть едкое упоминание о том, что это было еще в Delphi древних версий).
Для начала нам понадобится какой-то самодельный наследник UIView, чтобы заставить Xcode рендерить его в Interface Builder. Для этого его нужно пометить атрибутом IB_DESIGNABLE (технически в Objective-C это макрос, ну раз Apple называет это атрибутом, и в Swift это атрибут, так тому и быть):
Теперь можно создать storyboard (или xib) и разместить там наш view, и Xcode должен будет его успешно отобразить (предварительно собрав проект):
Теперь было бы здорово редактировать свойства компонента, влияющие на его внешний вид, прямо из IB. Для этого нужно пометить соответствующие свойства атрибутом IBInspectable. Вот результат:
Все редактируемые в Assistant Editor свойства дублируются в Runtime Attributes:
Поддерживаемые на данный момент типы свойств:
Типы NSNumber, UIEdgeInsets, NSRange, а также типы-перечисления (пока?) не поддерживаются. Runtime Attributes поддерживают NSRange, некоторые системные компоненты позволяют редактировать UIEdgeInsets- и enum-свойства, поэтому есть надежда на их поддержку в будущем. NSNumber также можно задать через Runtime Attributes (см. скриншот выше, свойство price задано именно так).
В идеальном мире описанных действий быть достаточно для добавления поддержки live rendering. В реальном же мире могут возникнуть некоторые неочевидные сложности.
В ранних бета-версиях Xcode 6 для live rendering наследник UIView должен был находиться в отдельном модуле (фреймворке). Позже это ограничение убрали, однако для понимания процесса взаимодействия Xcode, iOS Simulator и вашего приложения в ходе live rendering это полезно знать.
Суть такова: Xcode собирает ваше приложение с указанием специальных дефайнов, симулятор загружает приложение как динамическую библиотеку и инстанциирует ваш наследник UIView, чтобы его отрендерить, и передает результаты обратно в Xcode через XPC.
Важно! Точка входа вашего приложения не вызывается, соответственно не создается и application delegate. Так что если там у вас расположен какой-то важный код (например, настройка UIAppearance), имейте это в виду.
В части «загружает приложение как динамическую библиотеку» и кроется дьявол: бандл вашего приложения более не является главным бандлом, и вызов +[NSBundle mainBundle] вернёт не его, а что-то вроде:
А теперь представьте, в скольких местах +mainBundle используется неявно? Да в любом месте, где в качестве аргумента bundle можно указать nil.
Решение такое: делаем глобальную функцию XXXApplicationBundle (или категорию NSBundle с методом), где используем +[NSBundle bundleForClass:<какой-нибудь класс, который гарантированно в вашем бандле>], и используем ее вместо +mainBundle или nil.
Но этой проблеме подвержен не только ваш код, но и код используемых библиотек. Например, libPhoneNumber-iOS обращается к своим ресурсам именно через +mainBundle. Упс, никакого live rendering для нашего наследника UILabel, форматирующего телефонные номера.
Нет, не тяните руки к Objective-C runtime, не надо swizzle'ить +mainBundle, неизвестно, что при этом поломается. Да и CoreFoundation API для доступа к бандлам нам не подменить при всём желании.
Наивный iOS-разработчик может подумать, что создаваться view должен с помощью -initWithCoder:, он же в xib! Но не всё так просто, Apple решили не связываться с частичным инстанциированием nib (там помимо вашего view еще много всего может быть), и инстанс создается через -initWithFrame:. Для view, которые свёрстаны в xib, -initWithFrame: часто не реализуется, или реализуется и состоит из какого-нибудь assert, чтоб уронить программу и напомнить незадачливому пользователю, что view предназначен исключительно для загрузки из xib. На самом же деле ничего не мешает нам реализовать -initWithFrame: в таких случаях «как надо», и просто грузить view из xib и возвращать:
Думаю, категория для загрузки view из xib есть у многих, поэтому в подробности реализации +xxx_viewFromNib вдаваться не буду (не забываем указывать правильный bundle). Должен заметить, что в Swift такой трюк не пройдёт (так как там initializers похожи на конструкторы в Java или C++, то есть не могут подменить инициализируемый объект другим).
После инстанциирования у view будет вызван метод -prepareForIntefaceBuilder (если таковой реализован). В нём можно задать значения свойств, чтоб по умолчанию ваш компонент выглядел осмысленно. Загружая картинки и другие ресурсы в этом методе не забывайте про правильный bundle.
Если ваш view создается из xib и помечен как IB_DESIGNABLE, он будет рендериться даже при редактировании его собственного xib. Вот такая вот рекурсия. Даже не знаю, баг ли это.
Иногда live rendering просто не будет работать, выдавая сообщение о том, что «ibtool crashed» без особых подробностей. Столкнулся с подобным, отлаживая упомянутую проблему с загрузкой ресурсов из неправильного бандла: код регистрации шрифта просто падал, роняя вместе с собой симулятор. Но узнал я это только изучив логи в Console.app, и обнаружив крэшлог симулятора с вменяемым стектрейсом.
Поэтому в любой непонятной ситуации следуйте в Console.app и ищите крэшлог.
Несмотря на описанные подводные камни, считаю live rendering отличным способом ускорения прототипирования, разработки и отладки кастомных view. Особенно круто, что при live rendering учитываются layout constraints и intrinsic content size вашего view, поэтому autolayout работает по-честному, без констрейнтов-заглушек.
Бонус: редактирование свойств через Assistant Editor работает и для невизуальных объектов (то есть произвольных объектов, добавленных в xib или storyboard), просто используйте IBInspectable без IB_DESIGNABLE: www.merowing.info/2014/06/behaviours-and-xcode-6.
Надеюсь, что мой опыт будет кому-то полезен и сэкономит некоторое количество времени при реализации live rendering для ваших view.
Полезные ссылки:
Основы
Для начала нам понадобится какой-то самодельный наследник UIView, чтобы заставить Xcode рендерить его в Interface Builder. Для этого его нужно пометить атрибутом IB_DESIGNABLE (технически в Objective-C это макрос, ну раз Apple называет это атрибутом, и в Swift это атрибут, так тому и быть):
IB_DESIGNABLE
@interface XXXStaticPriceView : UIView
@property (nonatomic, copy) IBInspectable NSNumber *price;
@property (nonatomic) IBInspectable NSUInteger amount;
@property (nonatomic) IBInspectable NSNumberFormatterRoundingMode roundingMode;
@property (nonatomic, getter = isHighlighted) IBInspectable BOOL highlighted;
@property (nonatomic, copy) IBInspectable UIColor *textColor;
@property (nonatomic, copy) IBInspectable UIColor *outlineColor;
@end
Теперь можно создать storyboard (или xib) и разместить там наш view, и Xcode должен будет его успешно отобразить (предварительно собрав проект):
Теперь было бы здорово редактировать свойства компонента, влияющие на его внешний вид, прямо из IB. Для этого нужно пометить соответствующие свойства атрибутом IBInspectable. Вот результат:
Все редактируемые в Assistant Editor свойства дублируются в Runtime Attributes:
Поддерживаемые на данный момент типы свойств:
- целочисленные типы (кроме enum)
- float/double/CGFloat (Float/Double/CGFloat в Swift)
- NSString (Strnig в Swift)
- BOOL (Bool в Swift)
- CGPoint
- CGSize
- CGRect
- UIColor
- UIImage
Типы NSNumber, UIEdgeInsets, NSRange, а также типы-перечисления (пока?) не поддерживаются. Runtime Attributes поддерживают NSRange, некоторые системные компоненты позволяют редактировать UIEdgeInsets- и enum-свойства, поэтому есть надежда на их поддержку в будущем. NSNumber также можно задать через Runtime Attributes (см. скриншот выше, свойство price задано именно так).
Проблемы
В идеальном мире описанных действий быть достаточно для добавления поддержки live rendering. В реальном же мире могут возникнуть некоторые неочевидные сложности.
Доступ к application bundle
В ранних бета-версиях Xcode 6 для live rendering наследник UIView должен был находиться в отдельном модуле (фреймворке). Позже это ограничение убрали, однако для понимания процесса взаимодействия Xcode, iOS Simulator и вашего приложения в ходе live rendering это полезно знать.
Суть такова: Xcode собирает ваше приложение с указанием специальных дефайнов, симулятор загружает приложение как динамическую библиотеку и инстанциирует ваш наследник UIView, чтобы его отрендерить, и передает результаты обратно в Xcode через XPC.
Важно! Точка входа вашего приложения не вызывается, соответственно не создается и application delegate. Так что если там у вас расположен какой-то важный код (например, настройка UIAppearance), имейте это в виду.
В части «загружает приложение как динамическую библиотеку» и кроется дьявол: бандл вашего приложения более не является главным бандлом, и вызов +[NSBundle mainBundle] вернёт не его, а что-то вроде:
po [NSBundle mainBundle]
NSBundle </Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/Library/Xcode/Overlays> (loaded)
А теперь представьте, в скольких местах +mainBundle используется неявно? Да в любом месте, где в качестве аргумента bundle можно указать nil.
Решение такое: делаем глобальную функцию XXXApplicationBundle (или категорию NSBundle с методом), где используем +[NSBundle bundleForClass:<какой-нибудь класс, который гарантированно в вашем бандле>], и используем ее вместо +mainBundle или nil.
Но этой проблеме подвержен не только ваш код, но и код используемых библиотек. Например, libPhoneNumber-iOS обращается к своим ресурсам именно через +mainBundle. Упс, никакого live rendering для нашего наследника UILabel, форматирующего телефонные номера.
Нет, не тяните руки к Objective-C runtime, не надо swizzle'ить +mainBundle, неизвестно, что при этом поломается. Да и CoreFoundation API для доступа к бандлам нам не подменить при всём желании.
Особенности жизненного цикла view при live rendering
Наивный iOS-разработчик может подумать, что создаваться view должен с помощью -initWithCoder:, он же в xib! Но не всё так просто, Apple решили не связываться с частичным инстанциированием nib (там помимо вашего view еще много всего может быть), и инстанс создается через -initWithFrame:. Для view, которые свёрстаны в xib, -initWithFrame: часто не реализуется, или реализуется и состоит из какого-нибудь assert, чтоб уронить программу и напомнить незадачливому пользователю, что view предназначен исключительно для загрузки из xib. На самом же деле ничего не мешает нам реализовать -initWithFrame: в таких случаях «как надо», и просто грузить view из xib и возвращать:
- (instancetype)initWithFrame:(CGRect)frame
{
self = [self.class xxx_viewFromNib];
self.frame = frame;
return self;
}
Думаю, категория для загрузки view из xib есть у многих, поэтому в подробности реализации +xxx_viewFromNib вдаваться не буду (не забываем указывать правильный bundle). Должен заметить, что в Swift такой трюк не пройдёт (так как там initializers похожи на конструкторы в Java или C++, то есть не могут подменить инициализируемый объект другим).
После инстанциирования у view будет вызван метод -prepareForIntefaceBuilder (если таковой реализован). В нём можно задать значения свойств, чтоб по умолчанию ваш компонент выглядел осмысленно. Загружая картинки и другие ресурсы в этом методе не забывайте про правильный bundle.
Yo dawg, we heard u like live rendering
Если ваш view создается из xib и помечен как IB_DESIGNABLE, он будет рендериться даже при редактировании его собственного xib. Вот такая вот рекурсия. Даже не знаю, баг ли это.
Диагностика проблем
Иногда live rendering просто не будет работать, выдавая сообщение о том, что «ibtool crashed» без особых подробностей. Столкнулся с подобным, отлаживая упомянутую проблему с загрузкой ресурсов из неправильного бандла: код регистрации шрифта просто падал, роняя вместе с собой симулятор. Но узнал я это только изучив логи в Console.app, и обнаружив крэшлог симулятора с вменяемым стектрейсом.
stacktrace
Application Specific Information:
*** CFRelease() called with NULL ***
Thread 0 Crashed:
0 com.apple.CoreFoundation 0x0000000112f0ef6f CFRelease + 1183
1 com.company.XXXCoreTestHost 0x000000021e206dd7 LoadFonts + 455 (XXXCore.m:38)
2 dyld_sim 0x000000010f8a9867 ImageLoaderMachO::doModInitFunctions(ImageLoader::LinkContext const&) + 265
3 dyld_sim 0x000000010f8a99f4 ImageLoaderMachO::doInitialization(ImageLoader::LinkContext const&) + 40
4 dyld_sim 0x000000010f8a65a5 ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned int, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&) + 305
5 dyld_sim 0x000000010f8a642c ImageLoader::processInitializers(ImageLoader::LinkContext const&, unsigned int, ImageLoader::InitializerTimingList&, ImageLoader::UninitedUpwards&) + 138
6 dyld_sim 0x000000010f8a669d ImageLoader::runInitializers(ImageLoader::LinkContext const&, ImageLoader::InitializerTimingList&) + 75
7 dyld_sim 0x000000010f89e352 dyld::runInitializers(ImageLoader*) + 89
8 dyld_sim 0x000000010f8a2be7 dlopen + 951
9 libdyld.dylib 0x000000011666d3df dlopen + 59
10 com.apple.dt.IBFoundation 0x00000001115419a3 -[IBAbstractInterfaceBuilderTool _resultByLoadingUnloadedBundleInstance:] + 154
11 com.apple.dt.IBFoundation 0x0000000111541f6e -[IBAbstractInterfaceBuilderTool loadBuiltLiveViewBundleInstances:] + 607
12 com.apple.dt.IBFoundation 0x0000000111540e42 __80-[IBMessageReceiveChannel deliverMessage:toTarget:withArguments:context:result:]_block_invoke + 278
13 com.apple.dt.IBFoundation 0x0000000111540c66 -[IBMessageReceiveChannel deliverMessage:toTarget:withArguments:context:result:] + 441
14 com.apple.dt.IBFoundation 0x0000000111540930 __88-[IBMessageReceiveChannel runBlockingReceiveLoopNotifyingQueue:notifyingTarget:context:]_block_invoke + 97
15 libdispatch.dylib 0x000000011663daf4 _dispatch_client_callout + 8
16 libdispatch.dylib 0x000000011662aeb2 _dispatch_barrier_sync_f_slow_invoke + 51
17 libdispatch.dylib 0x000000011663daf4 _dispatch_client_callout + 8
18 libdispatch.dylib 0x00000001166292e9 _dispatch_main_queue_callback_4CF + 490
19 com.apple.CoreFoundation 0x0000000112f9f569 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 9
20 com.apple.CoreFoundation 0x0000000112f6246b __CFRunLoopRun + 2043
21 com.apple.CoreFoundation 0x0000000112f61a06 CFRunLoopRunSpecific + 470
22 com.apple.Foundation 0x00000001118dd862 -[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 275
23 com.apple.dt.IBFoundation 0x0000000111520745 -[IBAbstractPlatformTool startServingReceiveChannel:] + 322
24 com.apple.dt.IBFoundation 0x000000011152081f -[IBAbstractPlatformTool startServingSocket:] + 106
25 com.apple.dt.IBFoundation 0x0000000111520ae2 +[IBAbstractPlatformTool main] + 220
26 IBDesignablesAgentCocoaTouch 0x000000010f7eafe0 main + 34
27 libdyld.dylib 0x000000011666e145 start + 1
Поэтому в любой непонятной ситуации следуйте в Console.app и ищите крэшлог.
Конец
Несмотря на описанные подводные камни, считаю live rendering отличным способом ускорения прототипирования, разработки и отладки кастомных view. Особенно круто, что при live rendering учитываются layout constraints и intrinsic content size вашего view, поэтому autolayout работает по-честному, без констрейнтов-заглушек.
Бонус: редактирование свойств через Assistant Editor работает и для невизуальных объектов (то есть произвольных объектов, добавленных в xib или storyboard), просто используйте IBInspectable без IB_DESIGNABLE: www.merowing.info/2014/06/behaviours-and-xcode-6.
Надеюсь, что мой опыт будет кому-то полезен и сэкономит некоторое количество времени при реализации live rendering для ваших view.
Полезные ссылки:
