Пользовательский UIView из интерфейса Builder

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

Я знаю, как его создать программно - вы создаете подкласс UIView, реализуете метод drawRect, поместите пустой UIView в Interface Builder и получите шанс Класс мой пользовательский класс. Моя проблема в том, что я хочу создать этот пользовательский вид в построителе интерфейса, а не программно.

До сих пор я создал контроллер UIViewController с XIB файлом и в методе диспетчера вида viewDidLoad из шаблона создаю этот экземпляр настраиваемого контроллера представления и добавлю его в качестве подзадача этого пустого UIView, добавленного в Interface Builder (то же самое вы бы изменили в программном подходе класса).

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

Ответ 1

Чтобы это работало, вы должны создать плагин для Interface Builder, который использует ваш собственный класс управления. Как только вы создадите и установите свой плагин, вы сможете добавлять и перетаскивать экземпляры своего представления в другое окно или представление в Интерфейсном Разработчике. Чтобы узнать о создании плагинов IB, см. Руководство по программированию плагинов Interface Builder и главу по созданию собственных элементов управления палитрой IB из книги Аарона Хиллегаса " Программирование cocoa для Mac OS X".

Вот ссылка на оригинального автора принятого ответа на аналогичный вопрос.

Ответ 2

Это был изначально комментарий в потоке Ratinho, но он стал слишком большим.

Хотя мой собственный опыт согласуется со всем, что упоминается здесь и выше, есть некоторые вещи, которые могут облегчить вашу боль, или, по крайней мере, заставить вещи чувствовать себя немного менее взломанными.

Вывести все пользовательские классы UIView из общего класса, например EmbeddableView. Заверните всю логику initWithCoder в этом базовом классе, используя идентификатор Class (или перегружаемый метод), чтобы определить NIB для инициализации. Это все еще хак, но, по крайней мере, формализация правил интерфейса и скрытие машин.

Кроме того, вы можете еще больше улучшить свой интерфейс Builder, используя классы "микроконтроллера", которые сочетаются с вашими пользовательскими представлениями, чтобы обрабатывать их методы делегирования/действия и преодолевать разрыв с основным UIViewController через собственный протокол делегирования. Все это можно связать с помощью соединителей в Interface Builder.

Подлежащий UIViewController должен только реализовать достаточную функциональность, чтобы удовлетворить шаблон делегирования "микроконтроллера".

У вас уже есть сведения о добавлении пользовательских представлений путем изменения имени класса и обработки загрузки nib. "Микроконтроллеры" (если они используются) могут быть просто производными классами NSObject добавлены в NIB, как предлагается здесь.

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

Ответ 3

Возможно, я не понял, что вы? у вас есть библиотека в построителе интерфейса, и вы можете перемещать каждый компонент u и размещать его на вашем представлении. (u может добавить другое представление, добавив UIView и изменив его имя класса на четвертой вкладке).
то u объявляет vars с IBOutlet и связывает их со второй вкладкой владельцев файлов ur с их компонентами... другой вопрос?

Ответ 4

К сожалению, вы не можете делать то, что хотите делать с UIKit. Плагины IB работают только для OS X, и Apple явно не разрешает их использовать с разработкой iOS. Кое-что делать с ними не являясь статическими библиотеками. Кто знает, они могут когда-нибудь изменить это, но я бы не задерживал дыхание.