Что нужно для подкласса UIView вместо написания всего в ViewController

Question

Я прошел множество подобных вопросов, но до сих пор не понял этого.

С точки зрения лучшего дизайна - правильный путь - создание всех UIButtons, UILabels и т. Д. В самом контроллере представления, а затем добавление их в виде подзонов или создание пользовательского представления (@interface MyView: UIView) со всеми требуемые кнопки/метки и т. д., а затем назначить это представление свойству view контроллера View? Я не использую конструктор интерфейса.

Есть ли настоящая необходимость/преимущество создания пользовательского представления, подобного этому, или добавить все, что есть в самом контроллере, должно быть хорошо/хорошая идея? Извините, я очень новичок в разработке приложений для iOS :-)

Если бы кто-нибудь мог объяснить это мне, было бы очень полезно.

Answer 1

Некоторые преимущества подклассов вид являются: разделение

1. код. Если у вас сложный вид и вы хотите, чтобы ваш viewcontroller был чистым, подклассом и отделил его.
2. Повторное использование. Если вы повторно используете представление в любом месте, это возможно с минимальными усилиями, когда представление является его собственным классом.
3. Вы можете выбрать, какие настройки и методы, чтобы выставить настройки

Некоторые недостатки подклассов вид не являются:

1. Посмотреть больше не будет иметь доступ к просмотру Ивар контроллера.
2. Просмотреть диспетчер больше не будет иметь прямой манипуляции на вид
3. Вы ограничены тем, что публично раскрывает представление с точки зрения настройки и конфигурации (может быть, это хорошо).

В целом, нет единственного лучшего ответа, все зависит от вашей настройки и того, как вы хотите организовать свой проект.

Answer 2

Мой не-ответ: ответ лежит в промежутке между этими 2 противоположными сторонами:

• положить verything в View Controller, используя только основные взгляды
• , используя очень сложные виды, абстрагироваться от некоторых утомительных графических работ ,

Чтобы получить представление о том, что я говорю: один может реализовать UITableView поведения непосредственно в UIViewController с только UIScrollView и обрабатывать все вычисления indexPath (в зависимости от количества прокрутки), просмотры рециркуляции , и т. д. в этом режиме viewController.

Но, поскольку списки - это общий способ визуального отображения информации, все это «вид переработки», «настройка содержимого для отображаемых в настоящее время ячеек» было перенесено в пользовательский класс представления: UITableView, а шаблоны делегирования и источника данных были чтобы сделать это поведение класса легко настраиваемым.

Создание абстракций имеет свои преимущества и недостатки. Я стараюсь делать вещи постепенно:

• держать наиболее вы можете в ViewController
• когда код становится слишком сложным, или если вы видите себя needind такой же «компоненты» в другом месте: Создать настраиваемое представление и попытаться определить его API (какие свойства он обнажает, какую реализацию он скрывает)

Answer 3

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

Устранение правильного баланса зависит от ряда локализованных факторов. Представление, которое содержит метку и изображение (например, ячейку), может, безусловно, «владеть» своими подзонами и отображаться контроллеру как один контейнерный блок. Но обратите внимание, что в этом случае субподзоры также поддерживают ввод/вывод блока «cell».

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