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

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

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

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

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

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

[[UIApplication sharedApplication] delegate]

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

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

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

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

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

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

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