Это нормально для подкласса контроллера представления?

Question

Я относительный Noob Objective-C, поэтому, пожалуйста, потерпите меня.В документации Apple говорится, что не рекомендуется использовать два контроллера представления для управления одним представлением.

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

Answer 1

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

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

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

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

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

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

Помещая всю сложную логику игры в модель данных, вы облегчаете смену пар «вид-контроллер / вид» и добавляете, удаляете или изменяете множество различных видов. Например, у вас может быть одна и та же игра на iPhone, iPad и Mac. Большая часть кода будет одинаковой на всех трех платформах, но каждая из них будет иметь собственные пары view-controller / view.

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

Answer 2

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

Один из способов представить этомикс состоит в том, чтобы использовать один контроллер представления (подкласс из UIViewController) для управления всеми представлениями.Это совершенно законно.Таким образом, ваш контроллер одного представления отвечает за ваш основной вид (лабиринт) и подвиды (символы).

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

Answer 3

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

Answer 4

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

Answer 5

Ваши подпредставления должны быть не UIViewController, а UIView.