I recently discovered that UIView
s should only have UIViewController
s when they fill the entire window (or are managed by another UIViewController
such as a UINavigationController
or UISplitViewController
). This quotation is from the documentation for UIViewController:
You should not use view controllers to manage views that fill only a part of their window—that is, only part of the area defined by the application content rectangle. If you want to have an interface composed of several smaller views, embed them all in a single root view and manage that view with your view controller.
I usually put my view logic in the UIView even when it is managed by a UIViewController, yet I often find myself needing to access properties of the UIViewController such as its navigationController property. However, UIViews are not supposed to be aware of their UIViewController.
My conclusion is that view logic should go in a UIView's UIViewController when one exists, and in the UIView itself otherwise.
Alternatively, is it better practice to create a controller class for a view which is not a subclass of UIViewController? UIPopoverController (an NSObject subclass) appears to follow this pattern, although in most cases (UIButton, etc.) views do not seem to have dedicated controller classes.
A UIView is part of the UIViewController see the view property of UIViewController for this. As you pointed out correctly UIViewController manages a complete screen and there should be only one visible UIViewController at a time.
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.
To create a new view controller, select File->New->File and select a Cocoa Touch Class. Choose whether to create it with Swift or Objective-C and inherit from UIViewController . Don't create it with a xib (a separate Interface Builder file), as you will most likely add it to an existing storyboard.
Application logic should never go in a UIView
. Period. The purpose of a UIViewController
is to manage a view and its subviews and, under most circumstances, is the appropriate place for the logic. UIKit adheres to the Model-View-Controller paradigm. Models hold the data, views display it and accept input, and controllers manage the interaction between the other two layers. That's why the controller is the logical place for application logic. In iOS, UIViewController
and its subclasses are the usual controller classes. I'd suggest reading up on Apple's guidance to better understand this pattern and how it's used in iOS.
The quote from Apple's documentation is telling you that you don't create a UIViewController
for each label or button. You create one for each "page" or "screen" of your application and you use it to manage the controls in that view. Notice that UIKit has classes to manage table views, tab views and navigation views. That's the level of object that you would use UIViewController
to manage.
I'd recommend browsing through the iOS examples included with the SDK. They should give you a good idea of how the framework expects applications to be structured.
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