Understanding View Controller Nesting in iOS
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.
This is definitively possible in IOS 4 :
You have a view controller "A" with its view :
- Alloc init the view controller "B" you want to had on your view controller "A"
- Call (void)addSubview:(UIView *)view on the view of the view controller "A" with the view of the view controller "B" as parameter
- The frame of the view of the view controller "B" is set to fullscreen because of addSubView, so change it to put the view where you want on the view of view controller "A".
- Add some UIView animations when you change the frame to have a good display.
On IOS5 just use the method on your view controller "A" :
- (void)addChildViewController:(UIViewController *)childController
The View Controller Programming Guide covers this pretty well.
A view controller manages a set of views. You can have content view controllers and container/navigation view controllers which manage the hierarchy of view controllers (example: navigation view controller can manage a listview controller and a detail controller).
It's covered in more detail here:
A view controller manages a discrete portion of your application’s user interface. Upon request, it provides a view that can be displayed or interacted with. Often, this view is the root view for a more complex hierarchy of views — buttons, switches, and other user interface elements with existing implementations in iOS. The view controller acts as the central coordinating agent for this view hierarchy, handling exchanges between the views and any relevant controller or data objects.
Multiple view controllers coordinate their efforts to present a single unified user interface.