views:

70

answers:

2

I've been looking at the API for IOS Programming, and have been reading about view controllers and UIViews. It looks like UIViewController subclasses are really useful for Modal navigation and custom animation, but I can't see any other uses than that.

What is the benefit to using a UIViewController subclasses rather than a normal NSObject subclass?

Why

@interface MyViewController : UIViewController {
}

-(void)handleEvent;

@end

Instead of just

@interface MyViewController : NSObject {
    UIView* view;
}

@property(retain) UIView* view;
-(void)handleEvent;

@end

Don't you just end up adding just the view to the window, not the actual viewController itself? For most purposes, isnt all of the functionality you need encapsulated within the UIView object? You just end up adding it like this:

[window addSubview:myViewControllerInstance.view]

Is there a use for UIViewController other than built in functionality like Modal Navigation?

Thanks.

(Sorry if this is a stupid question, I've been learning this for 2 days now)

A: 

Take a look at the properties and instance methods of the UIViewController Class, which you would not get for free if you just subclassed NSObject. There is a lot of stuff in there that you will use in all of your applications.

Jules
+1  A: 

Cocoa on Mac OS and iOS make heavy use of the Model-View-Controller (MVC) pattern. Following the MVC model, UIViewController is a Controller class. Its job is to coordinate interactions between your user interface (View objects) and your application data (Model objects). More basically, the Controller is primarily where you place your application's logic. It handles events and calls upon the view and model accordingly.

See the UIViewController reference, which has a nice overview on the class.

By deriving from UIViewController, you get a bunch of Controller functionality for free, such as loading views from a Nib file (initWithNibName:bundle:) and responding to view-related events (viewWillAppear:, viewWillDisappear:). Additionally, UIViewController is itself a subclass of UIResponder, which contains functionality for handling touch events (touchesBegan:withEvent, touchesMoved:withEvent, touchesEnded:withEvent).

Basically, there's no reason NOT to use UIViewController with all the functionality it provides. Even if you could manage to to do so, it would be way more work, for no real benefit.

zpasternack
The thing is, in most Model-View-Controller architectures I've used or developed, the controller is completely independent from the view. These "View Controllers" encourage such tight coupling between the view and the controller - should I make a larger controller classes for communicating between individual view controllers and the model?