Подкласс или нет, UITabBarController

Question

Итак, как и многие люди, с которыми я сталкиваюсь с UITabBarController, он не предназначен для подклассов , а должен быть корневым контроллером вида особенностей.

Мне нужно управлять поведением всех подпредставлений и естественным способом сделать это, кажется, иметь контроллер корневого представления, которому они сообщают и который передает сообщения между ними. В моей текущей установке у меня есть PBModalRootViewController, который создает экземпляр UITabBarController и устанавливает его как подпредставление. PBModalRootViewController управляет подпредставлениями и отвечает за отклонение модального представления. вроде так http://p.twimg.com/Abu0iWDCMAAwhuy.jpg:large

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

1. Подкласс UITabBarController и устранение возможных последствий позже.

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

3. Просто измените архитектуру оригинальным способом, который был бы великолепен, любые идеи ...

4. Все то, о чем я не думал ...

5. Я все делаю не так, и меня надо шлепнуть форелью!

6. Используйте NSNotificationCentre, возможно, это немного запутано с сохранением, отклонением и т. Д., Но все равно нужно где-то управлять логикой отклонения.

7. Категория на UITabBarController? Полагаю, это было бы способом обходить подклассы.

Answer 1

Я думаю, что установка объекта супервизора - определенно правильный путь.Это зависит от того, какой тип информации вам нужно отслеживать между различными контроллерами представления.Если это данные, о которых каждый контроллер должен знать и / или отображать, эти данные необходимо отделить, и объект обработки данных не должен обрабатывать представления напрямую, поэтому он не должен быть контроллером представления.