Сложный вид настройки в UIVIew или UIViewController? (Дизайнерское решение)

Question

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

• В контроллере представлений управляйте всеми представлениями (это контроллер представлений!)
• Создайте пользовательский подкласс UIView и просто подключите его к контроллеру

Я знаю, что оба будут работать, но в каких ситуациях вы бы выбрали, какое решение?

Также дляВ первом варианте можно выполнить настройку в viewDidLoad и добавить представления в self.view или создать контейнерное представление и добавить все представления в loadView.Любой хороший совет здесь также будет оценен.

Второй вариант близок к использованию пера, когда вы устанавливаете полное представление как представление диспетчера.

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

Answer 1

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

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

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

Если набор представлений не может представить API, работающий с одной концепцией, например, если иерархия представлений существует только для правильной установки z-индекса представлений, и эти представления имеют дело с отображением несвязанных данных, то я бы снова создал их в контроллере. Подкласс UIView должен отвечать за отображение только одного связного набора данных или согласованно управлять набором подвигов.

Если представления должны быть расположены относительно представлений вне их иерархии, я бы снова высказался за их определение в контроллере.

Answer 2

Подумайте MVC (Modal, View, Controller) в этом случае.

Хороший выбор - создать отдельный класс UIView и установить для него представление UIViewController (или добавить его в качестве подпредставления к представлению контроллера).), затем используйте методы делегата для любого взаимодействия пользователя от вашего подкласса UIView с контроллером.

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