How to choose what code to put in a View vs. a ViewController?

Question

In Xcode, the Utility Application template makes a project with:

MainView, MainViewController

and

FlipsideView, FlipsideViewController

In my app, the two views correspond to the main UI and a preferences screen. Obviously I want the prefs to be reflected in the main UI and persisted to disk to remember settings. I know how to do that part.

The issue is, while looking at sample code of similar apps, I see that some put most of the active code in a View, leaving the ViewController little more than a stub, yet some others do it the other way around.

Is there a rule of thumb to go by when deciding where to put the bulk of my functionality?

Answer 1

If you want to be a MVC purist, things like view-switching and event handling should go in the controller, and the view-building code in the view.

But it's ok to put some app logic in the view, if you are consistent across the whole app.

Answer 2

One way to decide: if your app gets a low-memory warning, the default behavior is that any view that isn't currently visible may be destroyed. This means that if you have any state information that you can't easily re-create, you'd better not keep it in your view.

So it depends what the bulk of your functionality is doing: if it's maintaining information that the user created, it needs to be in the view controller.

Answer 3

There's already several questions at StackOverflow covering model-view-controller. For instance, see http://stackoverflow.com/questions/1015813/what-goes-into-the-controller-in-mvc.

In your specific scenario, the preferences themselves are a kind of model that keeps track of user's preferences. Saving and loading those preferences is the duty of the controller. Displaying those preferences and giving the user a way to change them is the duty of the view. And finally, when a user changes those preferences the view reports this to the controller, which makes the appropriate changes to the model.