Using Custom View Controllers to manage different portions of the same view hierarchy

The View controller programming guide states this regarding view controller's usage:

Each custom view controller object you create is responsible for managing all of the views in a single view hierarchy. In iPhone applications, the views in a view hierarchy traditionally cover the entire screen, but in iPad applications they may cover only a portion of the screen. The one-to-one correspondence between a view controller and the views in its view hierarchy is the key design consideration. You should not use multiple custom view controllers to manage different portions of the same view hierarchy. Similarly, you should not use a single custom view controller object to manage multiple screens worth of content.

I understand that if we use multiple custom view controller's to control the parts of a view (i.e. a view controller to manage subViews of a main view which in turn is managed by a view controller) the default methods like:

didReceiveMemoryWarnings
viewWillAppear
viewWillDisappear
viewDidUnload

etc. etc. will not be called.

Apart from this, is there any other solid reason why we should not be using multiple view controllers to manage the respective subviews of a view?

The documentation also provide an alternative solution which reads as:

Note: If you want to divide a view hierarchy into multiple subareas and manage each one separately, use generic controller objects (custom objects descending from NSObject) instead of view controller objects to manage each subarea. Then use a single view controller object to manage the generic controller objects.

But there is no mention as to why multiple view controllers should not be preferred. My question is:

Why should not we prefer it this way?

I am concerned because I prefer using UIViewController's subclass t开发者_高级运维o manage my views since I load them from nib each time and I segregate nibs for each view controllers. It becomes easy to cater the changes in later stages of the project. Is this wrong? Should I necessarily change my programming style, or is it ok if I go ahead with this approach?

Thanks,

Raj

Well, I'd say "as long as it works", you can keep on doing like you do ! But to keep things "cleaner", I'd use my own objects. Since ViewControllers are designed with other general features in mind (like working with navigation controllers and tab bar controllers), which makes it a bit "heavy" for a simple usage, like you do. Plus, like you mentioned, some events are only called when the viewController's view is added to the main window.

Can't you use your own objects with Interface Builder ? If you create one (or several) UIView IBOutlet(s), it should work the same.

I have an app that does use two UIViewControllers on a single screen. The child is a UITableViewController. I don't rely on any of the UIViewController behavior of the child -- only the UITableViewController methods. This is convenient because there are other cases where the child UITableViewController does manage the whole screen. And in that case, it does use the UIViewController methods. Questionable design? Maybe. It has worked fine for two years now. But I'm not sure I would recommend the pattern.