Вот как я решаю похожую проблему: я хотел:
создание многократно используемых автономных «классов модулей виджетов», реализующих сложное представление, построенное из нескольких компонентов UIKit (и других вложенных классов модулей виджетов!). Клиентские классы более высокого уровня этих классов виджетов не заботятся о том, что такое UILabel, о том, что такое UIImageView внутри виджета, а клиенты заботятся только о «отображении счета» или «показе логотипа команды».
внутри класса модуля виджета, выложите пользовательский интерфейс для виджета и точек подключения с помощью построителя интерфейса
для пользователей виджетов более высокого уровня, я хотел бы иметь возможность размещать рамку виджета в поле зрения клиента в конструкторе интерфейсов без необходимости разработки пользовательских плагинов для IB и т. Д.
Эти виджеты не являются контроллерами верхнего уровня: поэтому для них нет смысла быть подклассами UIViewController. Также есть совет от Apple, чтобы на одном экране не было более одного ВК. Кроме того, есть много советов и мнений, таких как «MVC! MVC! Вы должны разделить свой View и свой контроль! MVC!» что людям так настоятельно не рекомендуется создавать подклассы UIView или размещать логику приложения в классе UIView.
Но я все равно решил это сделать (подкласс UIView). Я бывал в этом районе несколько раз (но все еще новичок в iPhone SDK / UIKit), и я очень чувствителен к уродливому дизайну, который может вызвать проблемы, и, честно говоря, не вижу проблемы с подклассами UIView здесь. На самом деле есть много преимуществ сделать ваш повторно используемый виджет подклассом UIView, а не на основе UIViewController:
Вы можете поместить прямой экземпляр класса виджета в компоновщик построителя интерфейса представления клиента, и фрейм UIView представления виджета будет правильно инициализирован при загрузке класса клиента из xib. Для меня это намного чище, чем поместить «представление заполнителя» в клиента, затем создать экземпляр модуля виджета программно, установить рамку виджета в соответствии с заполнителем, а затем поменять представление заполнителя для представления виджета.
Вы можете создать чистый и простой xib-файл для размещения компонентов виджета в конструкторе интерфейса. Файл пера содержит другой UIView, в котором расположен весь графический интерфейс пользователя, а затем в функции виджета awakeFromNib: этот вид пера добавляется в сам виджет в качестве подпредставления. Любые корректировки размера кадра могут быть обработаны здесь, полностью в коде виджета, если таковые необходимы.
Виджет самостоятельно инициализирует свой пользовательский интерфейс, используя метод loadNibNamed: owner: options NSBundle в своем собственном методе awakeFromNib, поэтому интеграция виджета в классы клиента является чистой: просто поместите UIView в представление клиента в IB измените класс UIView на MyWidgetView, а в init или viewDidLoad клиента установите любые значения по умолчанию на дисплее виджета, используя API виджета, который вы пишете сами (setScore: setTeamImage: и т. д.)
Мне кажется, что между подклассами UIView таким образом, чтобы создать повторно используемый «виджет», и использованием UIViewController очень и очень мало различий. В обоих случаях .h файл виджета полон членов, выходов, объявлений действий и специальных объявлений API. В обоих случаях .m файл виджета полон реализаций действий и специальной реализации API. И представление отделено от элемента управления - представление находится в xib-файле!
Итак, вот что я делаю для упаковки сложных многократно используемых виджетов:
- Сделать класс виджета подклассом UIView
- Создавайте виджет где угодно, в других представлениях вашего приложения в IB напрямую.
- Разработка интерфейса вашего виджета в IB.
в классе awakeFromNib: метода класса виджета, загрузите пользовательский интерфейс виджета из xib и выполните[self addSubview:theXibView]
Кодируйте виджет так же, как и в UIViewController: торговые точки, действия, специальные API
Мне было бы интересно услышатьо других структурных системах для создания многократно используемых виджетов и о преимуществах этого подхода.
edit: забыл упомянуть, если виджет должен сообщать о событиях классу клиента, просто используйте протокол делегата, где клиентустанавливает делегата виджета на себя.