Подтвердить что ты не робот

Когда использовать UIView против UIViewController на iPhone?

Я всегда удивлялся, когда следует использовать UIView против UIViewController на iPhone.

Я понимаю, что вы не должны использовать UIViewController, если только это не полноэкранное представление, но какие существуют другие рекомендации?

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

4b9b3361

Ответ 1

От Apple Просмотр руководства по программированию контроллера для iOS:

"Самая важная роль контроллера представления - управлять иерархией представлений. Каждый контроллер представления имеет одно корневое представление, которое охватывает все содержимое контроллеров. В это корневое представление вы добавляете просмотры, которые нужно отображать ваш контент."

также:

"Существует два типа контроллеров:

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

Большинство приложений представляют собой смесь обоих типов контроллеров представлений.

Ответ 2

Это отличный вопрос.

Мое основное правило. Разве что каждая главная "страница" приложения получает свой собственный контроллер вида. Я имею в виду, что во время этапа проектирования проводки проектирования приложений все, что существует как его собственная сущность, в конечном итоге будет управляться собственным контроллером View. Если есть модальный экран, который скользит по существующему экрану, я буду считать это отдельной "страницей" и дать ему свой собственный контроллер представлений. Если есть представление, что наложения и существующая страница (например, экран загрузки или всплывающее окно справки), я бы рассматривал их по-разному, реализовывал их как подклассы UIView и сохранял логику в этом контроллере представлений "страниц". У этого всплывающего окна есть поведение. Я вернусь к этим страницам View Controller, используя шаблон делегирования.

Надеюсь, это поможет. Это очень философский и архитектурный вопрос, о котором многое можно было бы написать.

Ответ 3

Я использую UIViewController всякий раз, когда представление полноэкранное, и у него есть выходы/действия и/или субвью.

Ответ 4

У меня несколько иной подход:

Переопределите UIView, если вы планируете выполнять пользовательский чертеж в drawRect. В противном случае, подкласс UIViewController и используйте [self.view addSubview: blah], чтобы добавить компоненты страницы.

Есть несколько других особых случаев, но это занимает около 95% ситуаций.

(Вам по-прежнему часто нужен UIViewController с пользовательским UIView. Но обычно имеет пользовательский UIViewController без соответствующего пользовательского UIView.)

Ответ 5

Это то, что скользит в автономном экране? Я имею в виду, он напрямую взаимодействует с родителем? Если да, сделайте это UIView, если нет, вероятно, рекомендуем UIViewController.

Ответ 6

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

Пример, который вы дали, будет правильным использованием в большинстве случаев. Как вы могли заметить, вы получите много функциональности при подклассификации UIViewController. Анимировать внешний вид и увольнение UIViewController было бы одним из них.

Как указывалось в marcc, если вещь, которую вы хотите вставить, не является автономным экраном, вам было бы лучше использовать UIView.

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

В классе itunes U Standford есть замечательная лекция о UIViewControllers, которую я бы порекомендовал, наблюдая за ней, потому что у нее есть много информации о UIViewControllers в целом.

Ответ 7

Если вы знакомы с шаблоном MVC, вы должны понимать разницу между UIVIew и UIViewController. Чтобы сделать простой оператор, UIView предназначен для отображения элементов пользовательского интерфейса на экране. UIView является суперклассом почти всех элементов Cocoa Touch UI. Эти элементы не знают, какую информацию они должны отображать, что они должны делать, когда пользователь нажимает кнопку, что происходит, когда асинхронный сетевой запрос завершен и так далее. UIViewController для всего этого и более. Контроллер представления отвечает за размещение элементов пользовательского интерфейса в правильных местах на экране, настройку содержимого элементов пользовательского интерфейса, нажатия кнопок управления и других пользовательских входов, обновление модели при необходимости и т.д.

Концептуально, один UIViewController контролирует содержимое всего экрана в приложении для iPhone, и поэтому часто бывает легко думать о вещах с точки зрения контроллеров. Если вам нужно представление, в котором пользователь может выбрать ингредиенты для рецепта пищи, для этого вам понадобится UIViewController. Я сделал это различие для себя, потому что, исходя из фона Java, я не был использован для среды MVC. Из-за этого я бы подумал о вещах с точки зрения UIViews и начал их реализовывать, а затем столкнулся со всеми неприятностями. Если вы собираетесь придерживаться UIKit для своего приложения, то рабочий процесс, который Apple сделал для вас, - это: для каждого отдельного представления в вашем приложении создайте подкласс UIViewController, а затем используйте Interface Builder для размещения элементов пользовательского интерфейса и для создания соединений для кнопок и т.д. Он творит чудеса, экономит массу времени и позволяет вам сосредоточиться на том, чтобы сделать приложение хорошо.

Ответ 8

Поместите все на экран в UIViewController, пока контроллер представления не начнет иметь слишком много кода, а затем вырвет экран на несколько UIViewControllers, содержащий один главный контроллер представления...

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