Menu
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)
353
The UIViewController class defines the shared behavior that's common to all view controllers. You rarely create instances of the UIViewController class directly. Instead, you subclass UIViewController and add the methods and properties needed to manage the view controller's view hierarchy.
The delegation pattern in your link is the correct way to do it, and it works just fine when you use ViewControllers.
The difference between viewDidAppear and viewDidLoad is that viewDidAppear is called every time you land on the screen while viewDidLoad is only called once which is when the app loads.
The view controller lifecycle can be divided into two big phases: the view loading and the view lifecycle. The view controller creates its view the first time the view is accessed, loading it with all the data it requires. This process is the view loading.
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.
158
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
