Когда создавать подкласс UIViewController для пользовательского подпредставления? - PullRequest
7 голосов
/ 27 марта 2011

Я видел пользовательские подпредставления, реализованные как подкласс UIViewController, но, возможно, их можно было бы реализовать как подкласс UIView.

Когда мне следует создавать подкласс UIViewController вместо UIView для подпредставления? Есть ли недостатки у подклассов UIViewController?

Ответы [ 4 ]

6 голосов
/ 27 марта 2011

Лично, когда мне нужна какая-то существенная логика, я делаю это с подклассом UIViewController. Кроме того, если я ищу поведение, которое вы получаете от UIViewController, например представляя его модально или в навигационном контроллере.

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

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

4 голосов
/ 03 апреля 2011

Посмотрите, что Apple говорит о объектах контроллера и шаблон проектирования MVC

В контроллере iOS обычно ожидается выполнение хотя бы одной из следующих ролей:

  1. Координирующие контроллеры обеспечивают логику для конкретного приложения. Они отвечают на сообщения делегатов, уведомления и IBActions. Координирующие контроллеры также устанавливают связи между другими объектами и часто управляют созданием и уничтожением этих объектов.

  2. Контроллеры представления, в частности UIViewControllers, управляют отображением контента на один «экран» и инициируют переходы на следующий «экран». Они отвечают на предупреждения памяти и события вращения.

  3. Контроллеры-посредники существуют в OS X, но их роль обычно выполняют контроллеры представления в iOS. Они выступают в качестве посредника между взглядами и моделями; Обновление моделей при получении входных данных и обновление представлений при изменении моделей.

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

2 голосов
/ 27 марта 2011

Вы бы также создали подкласс UIViewController, если собираетесь использовать AdBannerView в своем «представлении».Для работы AdBannerView необходим UIViewController.

1 голос
/ 17 июля 2011

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

...