Должна ли логика представления идти в UIView или (если применимо) в его UIViewController? - PullRequest
6 голосов
/ 11 сентября 2010

Я недавно обнаружил, что UIView с должны иметь UIViewController с, только когда они заполняют все окно (или управляются другим UIViewController, таким как UINavigationController или UISplitViewController).Это предложение взято из документации для UIViewController :

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

Обычно я помещаю логику своего представления в UIView, даже когда оно управляетсяUIViewController, но мне часто приходится обращаться к свойствам UIViewController, таким как его свойство navigationController.Тем не менее, UIViews не должны знать о своем UIViewController.

Мой вывод заключается в том, что логика представления должна идти в UIViewController UIView, когда он существует, и в самом UIView в противном случае.лучше практиковать создание класса контроллера для представления, которое не является подклассом UIViewController?UIPopoverController (подкласс NSObject), по-видимому, следует этому шаблону, хотя в большинстве случаев (UIButton и т. Д.) Представления, по-видимому, не имеют выделенных классов контроллера.

Ответы [ 2 ]

3 голосов
/ 13 сентября 2010

Я пришел из мира Win32 + .NET + Java Swing GUI, и я делал то же самое. Но потом я исправил свои злые пути. Теперь единственный раз, когда я помещаю код в UIView, это если я хочу настроить VIEW ITSELF (например, рисунок OpenGL).

Контроллеры устанавливают состояние просмотра. Представление отображает свое состояние.

2 голосов
/ 11 сентября 2010

Логика приложения никогда не должна идти в UIView.Период.Цель UIViewController - управлять представлением и его подпредставлениями и, в большинстве случаев, является подходящим местом для логики.UIKit придерживается парадигмы Model-View-Controller.Модели хранят данные, представления отображают их и принимают ввод, а контроллеры управляют взаимодействием между двумя другими слоями.Вот почему контроллер является логическим местом для логики приложения.В iOS UIViewController и его подклассы являются обычными классами контроллеров.Я бы предложил прочитать руководство Apple , чтобы лучше понять этот шаблон и то, как он используется в iOS.

Цитата из документации Apple говорит вам, что вы не создаете UIViewController для каждой метки или кнопки.Вы создаете по одному для каждой «страницы» или «экрана» вашего приложения и используете его для управления элементами управления в этом представлении.Обратите внимание, что в UIKit есть классы для управления табличными представлениями, представлениями вкладок и представлениями навигации.Это уровень объекта, которым вы будете управлять UIViewController.

Я бы порекомендовал просмотреть примеры iOS, включенные в SDK.Они должны дать вам хорошее представление о том, как фреймворк ожидает структурирование приложений.

...