Should view logic go in a UIView or (when applicable) its UIViewController?

Question

I recently discovered that UIViews should only have UIViewControllers 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.

Answer 1

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.

Answer 2

I came from the Win32 + .NET + Java Swing GUI world and I used to do the same thing. But then I fixed my evil ways. Now the only time I put code in UIView is if I wish to customize the VIEW ITSELF (OpenGL drawing, for example).

Controllers set the state of the view. The view renders its state.