Как Apple заставляет свои контроллеры содержать другие контроллеры?

Question

Документация Apple содержит следующее предупреждение относительно использования View Controllers для управления частью экрана.

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

Теперь странно то, что Apple нарушает этот совет. UITabBarController , UINavigationController , UISplitViewController все идут против этого совета. На форумах Apple 1016 * обсуждается, что может пойти не так, если вы проигнорируете этот совет.

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

Итак, вопрос в том, какой метод Apple использует для своих собственных контроллеров?

Answer 1

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

Answer 2

Apple написала UIKit, чтобы они могли делать то, что им нравится.

Под капотом происходит много всего:

• вид {Will, Оказалась} {Появляются, Исчезают}
• Просмотр поворотов (тьфу, головная боль)
• UIViewControllerWrapperView, который иногда является родителем UIViewController.view. Или что-то.
• UIViewController.navigationController / tabBarController / parentViewController / modalViewController
• Поповы странные. Я не уверен, как они вписываются.

Если вы пишете свои собственные представления, вы, вероятно, можете избежать использования UIViewController для управления ими , но не ожидайте, что все магические действия, которые UIKit придает «правильному» контроллеру представления.

РЕДАКТИРОВАТЬ: Мне, вероятно, не следует StackOverflow, когда уже поздно. Я действительно имею в виду что-то вроде этого:

Если представление управляется UIViewController, контроллер представления должен существовать в иерархии контроллера представления (т.е. функционировать как presentModalViewController:animated:). Это позволяет UIKit обрабатывать сложные биты.

Когда вы используете что-то вроде [fooSubview addSubview:viewController.view], UIKit может не делать все то, что он должен делать. Что сохраняет viewController? Что произойдет, если появится предупреждение о том, что fooSubview выгружен?

Если вы установите что-то вроде viewController.view.frame = (CGRect){{0,0},{320,480}}, вы тоже напрашиваетесь на неприятности: UIViewController устанавливает фрейм в зависимости от текущего состояния / панели навигации / вкладки / и т. Д. Он может переустанавливать его или использовать фрейм, чтобы решить, как расположить контроллеры представления, которые вы нажимаете сверху (я заметил это поведение, оно грязное). Если вы измените viewController.view.transform, при поворотах вида могут произойти странные вещи, поскольку преобразование вида - это то, что UIViewController использует для ориентации (вместе со строкой состояния и кучей других вещей).

Есть только одно хорошо поддерживаемое исключение, о котором я знаю:

[window addSubview:viewController.view];
[window makeKeyAndVisible];

(На самом деле, вы можете вставить viewController.view в полноэкранное представление внутри окна; я не уверен, как это работает.)

Я думаю, что в OS 4.0+ вместо этого вы должны установить window.rootViewController = viewController.