Архитектура иерархии представлений - iPhone

Question

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

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

a) Мой корневой класс является контроллером uiview, и он добавляет / удаляетподпредставления при вызове методов делегата.

b) Мой корневой класс - это подкласс NSObject, и он изменяет окно rootViewControoler, когда это необходимо.

c) Контроллер навигации без панели навигации.Но как мне управлять видением hiearchy?

Какая логика лучше подходит для управления иерархией моего вида?Любая другая идея, кроме а и б?

Answer 1

Либо а), либо б) будет работать.Выбор будет зависеть от таких факторов, как степень, в которой уровень модели используется для определения последовательности представления видов.Если последовательность представления является динамической, то дизайн вспомогательного класса (ваш вариант b) может быть более чистым с точки зрения разделения MVC.В конечном счете, решение зависит от деталей и сложности вашего приложения.

В общем, некоторые вопросы, которые я задаю при принятии проектных решений, такие как:

• Как это влияет управление памятью ?
• Как дизайн повлияет на производительность ?
• Соответствует ли дизайн отдельным проблемам ?
• Является ли конструкция гибкой ? минимизирует зависимости ?
• Использует ли дизайн преимущества структуры / платформы шаблонов проектирования ?

Answer 2

Из представленных вами вариантов мне нравится c) лучший.

Опция a) не дотягивает, потому что игнорирует основную роль контроллеров представления - для управления просмотром содержимого на всю страницу.Использование addSubview в таких ситуациях, как ваша, требует, чтобы вы перепрыгнули через кучу препятствий, чтобы управлять памятью всех этих объектов в иерархии представлений, и вам бы просто пришлось заново изобретать колесо UIViewController.

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

варианту в).UINavigationController запрограммирован для выполнения работы, требуемой в вашей конкретной ситуации.Вы можете управлять иерархией, используя UINavigationController - (void)setViewControllers:(NSArray *)viewControllers animated:(BOOL)animated.Вы можете сделать обычный толчок, но это будет держать предыдущий VC в памяти, в то время как ваш основной VC игры находится впереди и требует ресурсов от системы.Короче говоря, я думаю, что ваш в) прост и эффективен.

Как и в случае с пост-сценарием, помните, что есть и другие варианты, кроме вашего a, b, c.Вы можете обойтись с помощью UIPageViewController , хотя я не рекомендую его.iOS 5 представила UIStoryboard как метод для управления пользовательским интерфейсом вашего приложения и UIStoryboardSegue для управления переходами.Посмотрите документы, если вы ориентируетесь на iOS 5, они также могут вам помочь.Но, похоже, вам подойдет простой навигационный контроллер.