iPhone UIKit prevents custom view controller hierarchies?

Question

Can anyone explain why it's not possible to create your own view controller hierarchies using UIKit on the iPhone?

Let me explain: when creating applications using a complex view hierarchy and navigation logic, it's a good idea to have certain views controlled by a dedicated view controller. These controllers can have their own subcontrollers, and so on. All standard stuff really.

So why is the parentViewController property readonly? It's used by UINavigationController and UITabBarController, and many other properties rely on it (for example the navigationController property).

I've seen many people telling us to create our own property for managing view controller hierarchies, but that's a little silly when Apple's own framework uses its own private "you can't touch it" hierarchy model.

Answer 1

Your question is more of a rant than a question.

parentViewController is only really used in modal view controller presentations, as indicated by being in the "Presenting Modal Views" section of the documentation. The navigation and tab bar controllers each have their own property (navigationController and tabBarController respectively.) for accessing them as parent view controllers, so what's the big deal in adding your own?

If you want custom behavior, you'll need to add custom code.

Answer 2

Readonly properties are usually properties that an instance must have set all the time to avoid serious problems.

In this case of a navigable hierarchy, child controllers must be able to have access to the parent controller at all times. (This is trait defines the actual navigation hierarchy i.e. you can back out of subviews.) If the property is readwrite it might not be set,might not be set correctly or might suddenly change all of which would orphan the controller. That is unacceptable in the API upon which the entire platform depends.

Why risk making the API more fragile just to handle a rare design case? It's easy enough to roll your own for the rare circumstance in which you want a flexible hierarchy.

Answer 3

Totally agree with Ben. Try asking the opposite question. Why did Apple create a tabBarController and navigationController property in a UIViewController. This could've easily, well not easily, be accomplished with some hacking around of the parentViewController property. Something like this to find the tab view controller would be common across all apps:

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

Yes, it probably goes against intuition as a navigation, or a tab bar controller, is most likely also a parent view controller.

There is no harm in using the parentViewController property actually. To get past the warning, checkout this thread.

But once you expose any data/behavior in the hierarchy's parent view controller, these isKindOfClass checks would become far too common.

Answer 4

Explain what you mean by "complex", that you cannot do with the system as it exists.

Controllers can have subcontrollers... you can either compose subcontrollers/views and delegate work, or have complex inheritance hierarchies of controllers to manage behavior.

I would love to see a concrete example of what it is you think you cannot do.