2009-11-06 2 views
53

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

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

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

ответ

38

От компании Apple View Controller Programming Guide for iOS:

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

также:

«Есть два типа контроллеров отображения:.

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

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

+1

Просто обновите ссылку на руководство Apple: http://goo.gl/KF2wg –

+1

Этот ответ нужно изменить, поскольку он очень устарел и его вводят в заблуждение МНОГО людей, включая меня. Этот ответ почти заставил меня изменить тонну вещей в моем приложении, пока я не понял, что ни одно из них не применяется, если вы работаете в iOS5 или новее. VC больше не считаются «экраном с UIViews внутри». VC теперь могут содержать другие VC в ContainerViews и называются дочерними VC или контейнерами VC. Добавление дочернего VC к родительскому VC НЕ испортит вращение. Он по-прежнему будет вращаться с точки зрения родительского VC. – lespommes

0

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

+0

В этом случае наложение является частью приложения Lite. Когда пользователь пытается выполнить ограниченную активность, модальный оверлей появляется и предупреждает об этом. Он будет использоваться через несколько контроллеров представлений, но он будет говорить разные сообщения в зависимости от того, какое действие попытается предпринять пользователь. Наложение в основном имеет сообщение и небольшой UIWebView, чтобы показывать объявление с возможностью клика, которое выводит их в полную версию в магазине приложений. –

+0

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

+0

Я сделал это в своем приложении: пользователь достиг уровня 3, и я поднял представление, в котором говорилось: «Вы достигли последнего уровня. Пожалуйста, нажмите здесь, чтобы перейти в магазин приложений и купить полную версию». Apple отказалась от этого. – mahboudz

11

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

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

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

4

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

0

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

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

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

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

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

-1

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

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

+0

Упрощенный, так как это было неоправданно уменьшено до -5. Предложение Кендалла является одним из вариантов, в духе рефакторинга, когда это необходимо, вместо того, чтобы пытаться предвидеть все заранее. –

+0

Спасибо, я думаю, что люди, возможно, неправильно поняли мой ответ, поэтому я обновил его для ясности. Или, может быть, люди просто любят предварительную оптимизацию ... –

+0

, хотя этот ответ не удивительный и, возможно, немного косвенный, я согласен, что его слишком наказывают, поэтому я дал +1. Это похоже на приличное стартовое место, если вы действительно потеряли, когда начинаете разрастать свои венчурные капиталисты. – bitwit

1

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

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

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

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

0

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

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

0
  1. Я использую UIViewController для отображения вида на весь экран.

  2. Для лучшего контроля над пользовательским представлением я предпочитаю подкласс UIViewController вместо UIView, ранее я использовал UIView для создания пользовательского подкласса.

Смежные вопросы