When do you need to use a view controller?_问答_开发者

I'm diving into iPhone development and one of the core concepts im trying to get my head around is view controllers. If you look at the GLPaint example on the apple dev site, you'll see a project that has...

An app delegate class
A uiwindow subclass
And a uiview subclass

And the uiview subclass implements all the core graphics painting logic and handles the touch events. My questions are...

why is there no view controller implemented to handle that view logic?
Could you 开发者_如何学运维use a view controller to implement that logic or does it have to be implemented in the uiview subclass?
And last, when should you use a view controller to implement the view logic code?

Thanks so much in advance for your help!

A view knows how to interact with the user. It knows how to display some data, how to handle events, and how to give feedback to the user.

A view controller knows what but now how. It knows what data to display, and what to do in response to a user action.

A UIButton knows how to display a title and image, and how to track a click, but not what the title should be or what to do once clicked.

A UITableView knows how to display data in cells and how to handle editing, but it does not know what data to display or what to do when a cell is deleted. For that it uses a delegate and data source which will often be a view controller.

This division between what and how simplifies design and maintenance. You could make a subclass of tableview for every type of table logic, but then you cannot also control other views. A view controller can control several views and coordinate between them.

Edit:

So you should use a view controller any time you need to:

coordinate between multiple views.
coordinate between model data and views.
respond to user interaction with a view.
unload and reload views.

Note that a view controller is not strictly a UIViewController. You might have a view controller that is owned by a UIViewController and handles some views, but is derived from NSObject or whatever. The view controller manages some part of the view hierarchy rooted in the UIViewController and is owned by that UIViewController. The UIViewController can in turn be part of a hierarchy rooted at the application delegate and might be owned by a navigation, tab or other meta controller.

So the application delegate owns zero or more meta controllers such as UINavigationController. Each meta controller owns one or more UIViewControllers. Each of those owns a view hierarchy and may own several simple view controllers that help manage parts of the view hierarchy. If there is no need for a meta controller, then the application delegate could own or be a UIViewController.

If you need features in a view controller which is not found in a view (or vice versa), you'd know which to use. For your question 2, as an example, the drawRect callback is available in UIView but not in a UIViewController.

So far, I will use a UIViewController as long as there is a .xib is involved.

And I love to put initialization and clean up code (e.g. a NSTimer) in those viewWillAppear viewDidAppear viewWillDisapper and viewDidAppear methods. It's especially convenient in teams of single entry/exit point, when dealing with many modal popup and multiple view controllers.

View controllers are mainly suited for a full screen part of your app, that you can layout in interface builder. Every view controller has a view property, that points to a UIView or one of its subclasses, but they manage more than that. A View controller is always full screen, so it can implement stuff like shouldRotateToInterfaceOrientation: whereas there might be 5 UIViews on a screen, there can only be one view controller.

It is also a vital part of MVC (model-view-controller).

The view controller connects the view and the model. The model should, in theory, do mathematical stuff, and store data, and other non-UI at all stuff. The view should draw and manage. It should not store the content, and it should not do anything else, really. The view controller connects the two together. It can look up data from the model, and give it to the view. This way, less code is application specific. You can reuse the model, and the view, but most of the time it's hard to reuse the controller without modification.

I am no expert, so for clarification, please comment.