Почему Apple не разрешает подкласс UINavigationController? И каковы мои альтернативы подклассу?

Question

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

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

Спасибо!

Answer 1

Для справки обратите внимание, что с iOS 6 UINavigationController может быть подклассифицирован юридически.

Этот класс обычно используется как есть, но может быть подклассифицирован в iOS 6 и более поздних версиях. UINavigationController Class Reference

Конечно, это не означает, что вы всегда должны. Но вы можете.

Answer 2

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

Answer 3

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

Answer 4

Как я понимаю, подкласс не поощряется, поскольку Objective C позволяет подклассу слишком много доступа к внутренним работам своего суперкласса.

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

Answer 5

Если доступная контрольная иерархия не удовлетворяет вашим потребностям с точки зрения обработки данных (мое предположение, поскольку мы не знаем, почему вы хотите, чтобы один объект был источником данных для нескольких видов), вы всегда можете создавать дополнительные данные и/или классов контроллера (как минимум, подклассы NSObject).

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

[[UIApplication sharedApplication] delegate] 

Используйте это экономно, поскольку он по существу создавая глобал.

(2) Вы можете передавать данные или другие объекты от контроллера к контроллеру, когда вы нажимаете подклассы контроллера представления или выносите их внутри вкладок.

(3) Основные данные - это еще один способ, но для вашего пояса требуется много какао, и вам все равно нужно управлять экземплярами контекста.

Answer 6

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

В принципе нет причин, по которым вы не можете подклассифицировать контроллер UINavigation, чтобы добавить на него полностью ортогональный слой данных, поскольку он не имеет ничего общего с пользовательским интерфейсом или поведением, которым управляет UINavigationController (что касается Apple, с). Для тех, кто не согласен с этой идеей, подумайте об этом как о хранилище данных для каждой вкладки, чтобы все страницы на вкладке могли получить доступ, а не каждую страницу в системе, которая должна перейти в AppDelegate, или иметь кучу синглетов. Ну, в основном это одноэлементный, но по крайней мере один, который уже существует, и автоматически передает ссылку.

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