Идеальное руководство для написания родительских контроллеров представления

Question

Короткая версия

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

Например: отправитьviewWillAppear: и т. Д.

Длинная версия

Фон

Некоторое время назад я ответил на следующий вопрос:
Переключение между UIViewControllers с помощью UISegmentedControl

Со следующим ответом:

Правильный способ сделать это - заставить контроллер, обрабатывающий UISegmentedControl, добавить представления контроллеров как подпредставления.

[self.view addSubview:controller.view];

Вы несете ответственность за отправку viewWillAppear: и т. Д.

Однако, тк.отметил, что это не так тривиально, как кажется:

Нет.Контроллеры представления не предназначены для такого использования - контроллер упустит большую часть магии UIViewController, которая считается само собой разумеющейся (а именно -view {Will, Did} {Appear, Disappear}: и -shouldRotateToViewOritentation:).

Под "магией" я имею в виду все, что UIKit делает за сценой.Вы также забыли -parentViewController (что важно для таких вещей, как контроллеры модального представления).Кроме того, где-то в глубине UIKit, он автоматически вызывает -viewSomethingSomething: для вас, так что вы можете получить -viewDidDisappear: дважды!(Я не могу вспомнить точные детали, но есть другой пользователь, сообщающий, что все, что вам нужно сделать, это вызвать -viewWillAppear: и три других метода происходят автоматически.) Ключевая проблема заключается в том, что Apple не документирует «магию» иликак это меняется между обновлениями ОС.

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

Я написал несколько таких контроллеров, и все они, кажется, работают, но я не могу не задаться вопросом, не упускаю ли я важную магию контроллера вида.

Answer 1

Я думаю, что лучшее решение - «не делай этого». Вместо того, чтобы надеяться, что вы сможете продублировать все поведение UIViewController, не отклоняясь при использовании вызовов частного API, почему бы не создать объекты-контроллеры не-UIViewController для управления вашими подвидами? «Контроллер» не обязательно является UIViewController.

Как минимум вам нужно переопределить или смешать в заменяющих геттерах для parentViewController, splitViewController, navigationController, tabBarController и interfaceOrientation (и, вероятно, также modalViewController). Для каждого свойства вам необходимо убедиться, что любой частный установщик, вызываемый UIKit, по-прежнему работает должным образом, и любые изменения этих значений, сделанные путем непосредственного изменения иваров UIViewController, также правильно отражаются в ваших реализациях.

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

Вам также придется надеяться, что вы только что создали ситуацию, которая не поддерживается ни одним из классов контроллеров представления Apple. Например, кто-нибудь из них сломается, если у них есть parentViewController, но их navigationController, tabBarController и splitViewController равны нулю?

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