Understanding View Controller Nesting in iOS

Question

Ive been tearing my hair out over the last couple of days trying to understand this one seemingly basic concept of iOS development:

• If I want to have two or mor

Answer 1

The answer depends on whether you need to support iOS 4 or not. If yes, the answer is:

Answer number 1 - With the exception of Apple's own container controllers, notably UITabBarController, UINavigationController, UISplitViewController, UIPageViewController and UIPopoverController (did I miss any?) there is no properly supported way to have multiple view controllers active on the same screen, managing different portions of the view. View controller methods such as presentModalViewController, etc all work on the assumption that there is a single "frontmost" view controller that owns the whole screen, and if you try to have multiple view controllers manage different parts of the view, all kinds of things will break, such as forwarding of screen rotation events and resizing/positioning of views after a page transition.

However if you only need to support iOS 5, the answer is:

Answer number 2 - No problem! Just make sure that all your sub-page-view controllers are correctly hooked up to a master view controller that manages the whole page. That means that in addition to the controllers' views being subviews of a common parent view, the controllers themselves should be child-controllers of a common parent controller. As long as the controller's parentViewController properties are all set correctly, you should be able to manage this kind of composite interface without too much hassle.

Unfortunately, Apple only added public setters for childViewControllers and parentViewControllers in iOS5. In iOS4 and earlier you're limited to Apple's own container controller arrangements and cannot create your own (at least, not without event forwarding issues).

So assuming you need to support iOS4 for now, answer number 3 seems like your best bet: Build your interface using multiple views but a single controller. This isn't too bad though. You can create custom view subclasses that manage heir own subviews (for example there's no rule that says a tableViewDataSource or delegate has to be a UIViewController subclass, or that a button IBAction has to be a method on a view controller instead of another view).

You'll actually find that most of the functionality you normally build into a view controller can be built into a "smart" container view instead, allowing you to split your screen into multiple standalone "controller-views" that manage their own contents.

The only bit that's tricky is doing stuff like transitions between one view and the next. For this you won't be able to use the standard presentModalViewController or pushViewController methods, you'll have to do the animations yourself using CATransitions or UIView animations.