Должны ли контроллеры uiview всегда быть частью иерархии viewcontroller?

Question

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

Мне кажется, что основная задача создания подклассов заключается в возможности переопределить методы, которые автоматически вызываются в течение жизненного цикла контроллера: viewDidAppear, viewWillAppear, willRotateToInterfaceOrientation и т. Д. Похоже, что эти методывызывается только если UIViewController (или подкласс) является частью иерархии UIViewController.Поэтому нет смысла создавать подклассы UIViewController, если я не собираюсь использовать одно из стандартных средств создания иерархии viewcontroller, то есть UINavigationController, [UIViewController presentModalViewController] и т. Д.

Я опасаюсь использования стиля Какаосредства добавления контроллеров представления в иерархию, потому что все они кажутся очень строгими.Например, я мог бы отобразить мой экран настроек, используя [UIViewController presentModalViewController], но я не хочу, чтобы он затенял весь экран.Есть фоновая анимация, с которой я хочу, чтобы пользователь мог взаимодействовать, даже когда экран настроек виден.

Вот мои вопросы:

1) Глупо ли создавать подкласс UIViewController, если я не 'собираюсь добавить его в иерархию viewController с помощью одного из методов Apple?

2) Правильно ли я полагаю, что встроенные средства отображения новых представлений слишком ограничительны для меня, и чтобыУ меня есть гибкость, которую я хочу, мне нужно будет просто загрузить представления через [view addSubview]

3) Если это правда, что подкласс UIViewController не имеет смысла для моих представлений меню и настроек, как я должен избегатьВесь мой код в одном подклассе UIViewController монстра.Должен ли я просто создать подкласс NSObject, добавить соответствующие IBOutlets и IBActions и передать их в качестве владельца файла при загрузке пера с помощью [NSBundle loadNibNamed]?

Answer 1

Хороший вопрос. Во-первых, для ясности: то, что вы называете «одним из методов Apple», упоминается в UIViewController Руководство по программированию как «косвенное представление» и включает в себя такие вещи, как модальное представление, выдвигаемое на навигацию. стек, представление поповерного контроллера и т. д. В основном все эти методы контроллера представления считаются «косвенными» методами представления, в то время как использование -addSubview: (что-то вроде [someView addSubview:myViewController.view]) считается «прямым» представлением.

Из упомянутого руководства по программированию: (Giant Block Quote ...)

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

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

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

1) Я не решаюсь сделать общее заявление и сказать: «Да, во всех случаях глупо создавать подкласс UIViewController, если вы не представляете его косвенно». Я уверен, что где-то есть что-то хорошее для этого. Я позволю себе сказать, что лично я никогда не делал этого.

2) Безусловно, я бы не использовал здесь подкласс UIViewController.

3) Позвольте мне обратить ваше внимание на другую область Руководства по программированию:

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

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