Понимание того, как делегаты приложения и контроллеры представления связаны друг с другом

Question

Я пытаюсь понять основы дизайна Какао (Iphone) MVC, но это довольно сложно. Я наткнулся на несколько примеров приложений из Интернета, книг ... но я не нашел ничего связанного с тем, что я ищу, так как большинство примеров представляют собой простое приложение (т.е. viewcontroller с перевернутым viewcontr и немного больше ..). Итак, давайте посмотрим, не желает ли кто-нибудь помочь мне указать мне правильное направление:

• Моя цель - создать довольно сложное приложение. Я хотел бы иметь следующее отношение взглядов:

  1. Представление презентации (в котором контроллер загружал бы несколько переменных, интенсивно использующих память)

  2. Вид главного меню: различные опции, которые могут привести к совершенно новым сложным видам. Например, опция Begin для запуска того, что приложение разрешает делать; второй вариант для выполнения другой сложной задачи с различными представлениями и действиями внутри нее, параметр «Параметры» для настройки параметров; опция справки, опция о, и так далее ..

• В первом подходе я попытался встроить несколько закругленных кнопок в представление под пером MainWindow со связанным делегатом приложения. Этот подход, однако, поставил вопрос о том, как мне удается переключаться между представлениями / viewcontrollers. После того, как у меня возникли непонятные исключения, потому что я, вероятно, не совсем понимаю основы, я попытался перейти к более «простым» вещам.

• Затем я наткнулся на контроллеры какао по умолчанию для Navigation и Tabbar. Я не хочу вкладку, хотя она может хорошо подойти для других частей этого приложения. Тогда навигационный контроллер - это то, что я считаю наиболее подходящим для этого случая.

• Таким образом, я в правильном месте, если я создаю иерархическое приложение, где его корнем является контроллер навигации? Я видел, что могу настроить основной вид для отображения настраиваемой таблицы, где каждая ячейка может выступать в качестве кнопки для создания своего соответствующего view + viewcontroller. Отсюда я могу продолжать строить «конечные узлы» этой иерархии представлений / контроллеров представления, верно? Даже если мне не нравится анимация, которая по умолчанию предоставляет контроллер навигации, я полагаю, что могу избавиться от нее ..

• Итак, подведем итоги по-простому: я хотел бы получить меню, подобное тем, которые обычно можно увидеть в приложениях Cocos2d.

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

Спасибо за любые ответы заранее и извините за этот длинный пост.

Answer 1

Таким образом, я на правильном месте, если я построить иерархическое приложение, где его root - это навигационный контроллер?

Почти. Контроллер навигации (несмотря на то, что он является подклассом UIViewController) не контролирует представления, а скорее контроллеры представления. Контроллер nav выдает и отображает контроллеры представлений, что, в свою очередь, приводит к загрузке и отображению соответствующих представлений контроллера.

Следовательно, «корневое представление» - это фактически представление, управляемое контроллером представления, который находится в свойстве контроллера nav topViewController.

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

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

И вы не должны смущаться, находя это в замешательстве. 90% вводной / учебной информации, в том числе книги и ресурсы Apple, посвящены особенностям интерфейса, а также практически ничего не рассказывают о реальном дизайне приложения или о том, как все части концептуально сочетаются друг с другом.

Answer 2

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

Видео с Itunes dev отлично подходят для изучения теории UIviews с использованием push и pop стека. Я обнаружил, что они двигались немного быстро, но после просмотра их рук имело больше смысла. Я заставлял себя смотреть их все и очень хорошо чувствовать происходящее. Надеюсь, скоро появится хорошее приложение.