Экраны, Windows и представления создают визуальные интерфейсы

Рисунок 1-1 показывает простой интерфейс. Слева, Вы видите объекты, составляющие этот интерфейс и понимающие, как они подключены друг к другу.

Существует три главных объекта на работе здесь:

• A UIScreen объект, идентифицирующий физический экран, подключенный к устройству.

• A UIWindow объект, предоставляющий поддержку получения для экрана.

• Ряд UIView объекты выполнить получение. Эти объекты присоединены к окну и рисуют их содержание, когда окно спрашивает их к.

Рисунок 1-2 показывает, как эти классы (и связал важные классы) определяются в UIKit.

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

• Представление представляет элемент пользовательского интерфейса. Каждое представление покрывает определенную область. В той области это выводит на экран содержание или реагирует на пользовательские события.

• Представления могут быть вложены в иерархии представления. Подпредставления расположены и нарисованы относительно их суперпредставления. Таким образом, когда суперпредставление перемещается, его перемещение подпредставлений с ним. Эта иерархия упрощает собирать группу связанных представлений путем размещения их в общее суперпредставление.

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

  Анимация критически важна для разработки приложения для iOS. Поскольку большинство приложений выводит на экран только часть своего содержания когда-то, анимация позволяет пользователю видеть, когда переход произошел и куда новое содержание прибыло из. Мгновенный переход мог бы смутить пользователя.

• Представления редко понимают роль, которую они играют в Вашем приложении. Например, рисунок 1-1 показывает кнопку (названный Привет), который является специальным видом представления, известного как управление. Средства управления знают, как реагировать на взаимодействие с пользователем в их области, но они не знают то, чем они управляют. Вместо этого когда пользователь взаимодействует с управлением, оно отправляет сообщения в другие объекты в Вашем приложении. Эта гибкость позволяет единый класс (UIButton) обеспечить реализацию для многократных кнопок, каждый сконфигурированный для инициирования различного действия.

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

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

Каждый контроллер представления организует и управляет представлением; это представление часто является корневым представлением иерархии представления. Контроллеры представления являются объектами контроллера в образце MVC, но контроллер представления также имеет определенные задачи, которые iOS ожидает, что он выполнит. Эти задачи определяются UIViewController класс, от которого наследовались все контроллеры представления. Все контроллеры представления выполняют задачи представления и управления ресурсами; другая ответственность зависит от того, как используется контроллер представления.

Рисунок 1-3 показывает интерфейс от рисунка 1-1, но обновленный здесь для использования контроллера представления. Вы никогда непосредственно присваиваете представления окну. Вместо этого Вы присваиваете контроллер представления окну, и контроллер представления автоматически добавляет свое представление к окну.

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

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

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

Рисунок 1-4 показывает пример приложения, управляющего рецептами. Это отображения приложения три связанных, но отличных представления. Первое представление перечисляет рецепты, которыми управляет приложение. Ответвление рецепта показывает второе представление, описывающее рецепт. Ответвление изображения рецепта в подробном представлении показывает третье представление, увеличенную версию фотографии. Каждым представлением управляет отличный объект контроллера представления, задание которого должно представить надлежащее представление, заполнить подпредставления с данными и реагировать на взаимодействие с пользователем в иерархии представления.

Этот пример демонстрирует несколько факторов, распространенных для просмотра контроллеров:

• Каждым представлением управляет только один контроллер представления. Когда представление присваивается контроллеру представления view свойство, контроллеру представления принадлежит он. Если представление является подпредставлением, им могли бы управлять тот же контроллер представления или контроллер другого представления. Вы узнаете больше, как использовать многократные контроллеры представления для организации единственной иерархии представления, когда Вы узнаете о контейнерных контроллерах представления.

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

• Поскольку каждый контроллер представления обеспечивает только подмножество пользовательского опыта, контроллеры представления должны связаться друг с другом для создания этого опыта бесшовным. Они могут также связаться с другими контроллерами, такими как контроллеры данных или объекты документа.

Таксономия контроллеров представления

Рисунок 1-5 показывает классы контроллера представления, доступные в платформе UIKit вместе с другими классами, важными для просмотра контроллеров. Например, UITabBarController объект управляет a UITabBar объект, фактически выводящий на экран вкладки, связанные с интерфейсом панели вкладок. Другие платформы определяют дополнительные классы контроллера представления, не показанные в этом числе.

Контроллеры представления, и предоставленные iOS и те, которых Вы определяете, могут быть разделены на две общих категории — контроллеры представления содержания и контейнерные контроллеры представления — которые отражают роль игры контроллера представления в приложении.

Довольный содержание дисплея контроллеров представления

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

Вот типичные примеры, где Ваше приложение использует контроллеры представления содержания:

• Показать данные пользователю

• Собрать данные от пользователя

• Выполнять определенную задачу

• Для навигации между рядом доступных команд или опций, такой как на запуске экранируют на игру

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

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

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

О контроллерах табличного представления

Много приложений выводят на экран табличные данные. Поэтому iOS обеспечивает встроенный подкласс UIViewController класс, специально разработанный для управления табличными данными. Этот класс, UITableViewController, управляет табличным представлением и добавляет поддержку многих стандартных связанных с таблицей способов поведения, таких как управление выбором, редактирование строки и табличная конфигурация. Эта дополнительная поддержка должна там минимизировать объем кода, который необходимо записать, чтобы создать и инициализировать основанный на таблице интерфейс. Можно также разделить на подклассы UITableViewController добавить другие пользовательские способы поведения.

Рисунок 1-6 показывает пример с помощью контроллера табличного представления. Поскольку это - подкласс UIViewController класс, контроллер табличного представления все еще имеет указатель на корневое представление интерфейса (через view свойство), но это также имеет отдельный указатель на табличное представление, выведенное на экран в том интерфейсе.

Для получения дополнительной информации о табличных представлениях, см. Руководство по программированию Табличного представления для iOS.

Контейнерное содержание расположения контроллеров представления других контроллеров представления

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

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

• Контейнер обеспечивает свой собственный API для управления его дочерними элементами.

• Контейнер решает, есть ли у дочерних элементов отношение между ними и каково то отношение.

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

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

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

О контроллерах навигации

Контроллер навигации представляет данные, которые организованы иерархически и являются экземпляром UINavigationController класс. Методы этого класса предоставляют поддержку для управления стековым набором довольных контроллеры представления. Этот штабель представляет путь, взятый пользователем через иерархические данные с нижней частью штабеля, отражающего начальную точку и вершину штабеля, отражающего текущую позицию пользователя в данных.

Рисунок 1-7 показывает, скрывает из приложения Контактов, использующего контроллер навигации для представления контактной информации пользователю. Панель навигации наверху каждой страницы принадлежит контроллеру навигации. Остальной частью каждого экрана, выведенного на экран пользователю, управляют довольным контроллер представления, представляющий информацию на том определенном уровне иерархии данных. Поскольку пользователь взаимодействует со средствами управления в интерфейсе, те средства управления говорят контроллеру навигации отображать следующий контроллер представления в последовательности или отклонять контроллер текущего представления.

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

Для получения информации о том, как сконфигурировать и использовать объекты контроллера навигации, видит Контроллеры Навигации.

О контроллерах панели вкладок

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

Рисунок 1-8 показывает несколько режимов приложения Часов вместе с отношениями между соответствующими контроллерами представления. Каждый режим имеет довольное контроллер представления для управления областью основного содержания. В случае приложения Часов контроллеры представления Clock и Alarm оба выводят на экран интерфейс стиля навигации для размещения некоторых дополнительных средств управления вдоль вершины экрана. Другие режимы используют контроллеры представления содержания для представления единственного экрана.

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

Для получения информации о том, как сконфигурировать и использовать контроллер панели вкладок, видит Контроллеры Панели вкладок.

О контроллерах представления разделения

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

Рисунок 1-9 показывает интерфейс представления разделения из демонстрационного приложения MultipleDetailViews. В режиме портрета только выведено на экран подробное представление. Представление списка сделано доступным использованием легкой сдобы. Однако, когда выведено на экран в альбомном режиме, контроллер представления разделения выводит на экран содержание обоих дочерних элементов рядом.

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

Для получения информации о том, как сконфигурировать и использовать контроллер представления разделения, видит Легкую сдобу.

О контроллерах легкой сдобы

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

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

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

О контроллерах просмотра

Контроллер просмотра является контейнерным контроллером представления, используемым для реализации макета страницы. То расположение позволяет пользователям зеркально отражать между дискретными страницами содержания, как будто это была книга. Контроллер просмотра является экземпляром UIPageViewController класс. Каждая страница содержания предоставлена довольным контроллер представления. Контроллер просмотра управляет переходами между страницами. Когда новые страницы требуются, контроллер просмотра вызывает связанный источник данных для получения контроллера представления для следующей страницы.

Для получения информации о том, как сконфигурировать и использовать контроллер просмотра, видит Контроллеры Просмотра.

Содержание контроллера представления может быть выведено на экран во многих отношениях

Для представления содержание контроллера, чтобы быть видимым пользователю, это должно быть связано с окном. Существует много способов, которыми можно сделать это в приложении:

• Сделайте контроллер представления корневым контроллером представления окна.

• Сделайте контроллер представления дочерним элементом контейнера.

• Покажите контроллер представления в управлении легкой сдобой.

• Представьте его от другого контроллера представления.

Рисунок 1-10 показывает пример из приложения Контактов. Когда пользователь щелкает плюс кнопка для добавления нового контакта, контроллер представления Contacts представляет контроллер представления New Contact. Экран New Contact остается видимым, пока пользователь не отменяет работу или предоставляет достаточно информации о контакте, что это может быть сохранено к базе данных контактов. В той точке информация передается к контроллеру представления Contacts, тогда отклоняющему контроллер, который это представило.

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

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

Стоит отметить, что представленный контроллер представления может самостоятельно представить другой контроллер представления. Когда необходимо выполнить несколько модальных действий последовательно, эта возможность объединить контроллеры представления в цепочку вместе может быть полезной. Например, если пользователь касается кнопки Add Photo на экране New Contact на рисунке 1-10 и хочет выбрать существующее изображение, контроллер представления New Contact представляет интерфейс средства выбора изображения. Пользователь должен отклонить экран средства выбора изображения и затем отклонить экран New Contact отдельно для возврата к списку контактов.

При представлении контроллера представления один контроллер представления определяет, сколько из экрана используется для представления контроллера представления. Часть экрана вызывают контекстом представления По умолчанию, контекст представления определяется для покрытия окна.

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

Контроллеры представления сотрудничают для создания интерфейса приложения

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

Отношения отцов и детей представляют включение

Иерархия контроллера представления запускается с родителя-одиночки, корневого контроллера представления окна. Если тот контроллер представления является контейнером, он может иметь дочерние элементы, обеспечивающие содержание. Те контроллеры, в свою очередь, могут также быть контейнеры с собственными дочерними элементами. Рисунок 1-11 показывает пример иерархии контроллера представления. Корневой контроллер представления является контроллером представления вкладки с четырьмя вкладками. Первая вкладка использует контроллер навигации с собственными дочерними элементами, и другими тремя вкладками управляют довольным контроллеры представления без дочерних элементов.

Область, которую заполняет каждый контроллер представления, определяется его родителем. Корневая область контроллера представления определяется окном. На рисунке 1-11 контроллер представления вкладки получает свой размер от окна. Это резервирует пространство для своей панели вкладок и дает остаток от пространства его дочерним элементам. Если контроллер навигации был управлением, выведенным на экран прямо сейчас, это резервирует пространство для своей панели навигации и вручает остальным его контроллеру содержания. На каждом шаге дочернее представление контроллера представления изменено родителем и помещено в иерархию представления родителя.

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

Одноуровневые отношения представляют коллеги в контейнере

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

• В контроллере представления вкладки вкладки представляют отличные экраны содержания; контроллеры панели вкладок не определяют отношение между его дочерними элементами, несмотря на то, что Ваше приложение может принять решение сделать так.

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

Рисунок 1-12 показывает общую конфигурацию контроллеров представления, связанных с контроллером навигации. Первый дочерний элемент, ведущее устройство, показывает доступное содержание, не показывая все подробные данные. Когда элемент выбран, он продвигает новый одноуровневый элемент на контроллер навигации так, чтобы пользователь видел дополнительные подробные данные. Точно так же, если пользователь должен видеть больше подробных данных, этот одноуровневый элемент может продвинуть другой контроллер представления, показывающий самое подробное доступное содержание. Когда одноуровневые элементы имеют четко определенное отношение как в этом примере, они часто координируют друг с другом, или непосредственно или через контейнерный контроллер. Посмотрите рисунок 1-15.

Представление представляет переходный дисплей другого интерфейса

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

На рисунке 1-13 довольное просматривает контроллер, присоединенный к подаркам представления вкладки контроллер представления для выполнения задачи. Контроллер содержания является контроллером представления представления, и модальный контроллер представления является представленным контроллером представления.

Когда контроллер представления представлен, часть экрана, который это покрывает, определяется контекстом представления, предоставленным для него другим контроллером представления. Контроллер представления, обеспечивающий контекст представления, не должен быть тем же контроллером представления, представившим его. Рисунок 1-14 показывает ту же иерархию контроллера представления, представленную на рисунке 1-13. Вы видите, что довольное, представление представило контроллер представления, но это не обеспечивало контекст представления. Вместо этого контроллер представления был представлен контроллером вкладки. Из-за этого, даже при том, что контроллер представления представления только покрывает часть экрана, предоставленного для него контроллером представления вкладки, представленный контроллер представления использует всю область, принадлежавшую контроллеру представления вкладки.

Поток управления представляет полную координацию между контроллерами содержания

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

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

Рисунок 1-15 показывает наиболее распространенные примеры этих отношений.

В числе:

• Дочерний элемент контроллера навигации продвигает другой дочерний элемент на штабель навигации.

• Контроллер представления представляет другой контроллер представления.

• Контроллер представления выводит на экран другой контроллер представления в легкой сдобе.

Каждый контроллер сконфигурирован тем, предшествующим ему. Когда многократные контроллеры сотрудничают, они устанавливают коммуникационную цепочку всюду по приложению.

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

• Целевой контроллер представления обеспечивает, свойства раньше конфигурировали его данные и представление.

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

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

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

Справка раскадровок Вы разрабатываете свой пользовательский интерфейс

При реализации приложения с помощью раскадровок Вы используете Интерфейсного Разработчика для организации контроллеров представления приложения и любых связанных представлений. Рисунок 1-16 показывает расположение интерфейса в качестве примера от Интерфейсного Разработчика. Визуальная разметка Интерфейсного Разработчика позволяет Вам понимать поток через свое приложение сразу. Вы видите, какие контроллеры представления инстанцируют Ваше приложение и их порядок инстанцирования. Но больше, чем который, можно сконфигурировать сложные наборы представлений и других объектов в раскадровке. Получающаяся раскадровка сохранена как файл в Вашем проекте. Когда Вы разрабатываете свой проект, раскадровки в Вашем проекте обрабатываются и копируются в комплект приложений, где они загружаются Вашим приложением во время выполнения.

Часто, iOS может автоматически инстанцировать контроллеров представления в Вашей раскадровке в данный момент, они необходимы. Точно так же иерархия представления, связанная с каждым контроллером, автоматически загружается, когда это должно быть выведено на экран. Оба контроллера представления и представления инстанцируют с теми же атрибутами, которые Вы сконфигурировали в Интерфейсном Разработчике. Поскольку большая часть этого поведения автоматизирована для Вас, оно значительно упрощает работу, требуемую использовать контроллеры представления в Вашем приложении.

Полное изложение создания раскадровок описано в Обзоре XCode. На данный момент необходимо знать часть существенной терминологии, используемой при реализации раскадровок в приложении.

Сцена представляет экранную предметную область, которой управляет контроллер представления. Можно думать о сцене как о контроллере представления и его связанной иерархии представления.

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

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

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

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

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

  Различные виды переходов обеспечивают общие переходы, необходимые между двумя контроллерами другого представления:

  • Переход нажатия продвигает целевой контроллер представления на штабель контроллера навигации.

  • Модальный переход представляет целевой контроллер представления.

  • Переход легкой сдобы выводит на экран целевой контроллер представления в легкой сдобе.

  • Пользовательский переход позволяет Вам разрабатывать свой собственный переход для отображения целевого контроллера представления.

  Переходы совместно используют общую модель программирования. В этой модели контроллер назначения инстанцирует автоматически iOS, и затем исходный контроллер представления вызывают для конфигурирования его. Это поведение соответствует, модель потока управления, описанная в Потоке управления, Представляет Полную Координацию Между Контроллерами Содержания.

Можно также создать соединения между контроллером представления и объектами, хранившими в той же сцене. Эти выходы и действия позволяют Вам тщательно определить отношения между контроллером представления и его связанными объектами. Соединения не обычно видимы в самой раскадровке, но могут быть просмотрены в Инспекторе Соединений Интерфейсного Разработчика.