iPhone UIKit запрещает настраивать просмотр иерархий контроллеров?

Question

Может кто-нибудь объяснить, почему невозможно создать собственные иерархии контроллера представления с помощью UIKit на iPhone?

Позвольте мне объяснить: при создании приложений, использующих сложную иерархию представлений и логику навигации, было бы неплохо иметь определенные представления, управляемые выделенным контроллером представлений. Эти контроллеры могут иметь свои собственные субконтроллеры и так далее. Все стандартные вещи на самом деле.

Так почему же свойство parentViewController доступно только для чтения? Он используется UINavigationController и UITabBarController , и многие другие свойства зависят от него (например, свойство navigationController ).

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

Answer 1

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

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

Зачем рисковать делать API более хрупким, чтобы справиться с редким дизайном? Достаточно легко свернуть свое собственное для тех редких обстоятельств, в которых вы хотите гибкую иерархию.

Answer 2

Ваш вопрос скорее напыщенный, чем вопрос.

parentViewController действительно используется только в представлениях контроллера модального представления, как указано в разделе «Представление модальных представлений» документации. Каждый из контроллеров панели навигации и панели вкладок имеет свое собственное свойство (navigationController и tabBarController соответственно.) Для доступа к ним как к родительским контроллерам представления, так что же такого в добавлении собственного?

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

Answer 3

Объясните, что вы подразумеваете под «сложным», что вы не можете делать с системой, как она существует.

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

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

Answer 4

Полностью согласен с Беном. Попробуйте задать противоположный вопрос. Почему Apple создала свойства tabBarController и navigationController в UIViewController. Этого можно было бы, а может быть, и нелегко, осуществить, взломав свойство parentViewController. Примерно так, чтобы найти контроллер представления вкладок, было бы распространено во всех приложениях:

UIViewController *current = ...;
while([current parentViewController] != nil) {
    current = [current parentViewController];
    if([current isKindOfClass:[UITabViewController class]]) {
        // do something
    }
}

Да, это, вероятно, идет вразрез с интуицией, поскольку навигация или контроллер панели вкладок, скорее всего, также является родительским контроллером представления.

Нет никакого вреда при использовании свойства parentViewController. Чтобы пройти предупреждение, закажите в этой теме .

Но как только вы выставите какие-либо данные / поведение в родительском контроллере представления иерархии, эти проверки isKindOfClass станут слишком распространенными.