Should the View in MVC have its own class?

Question

I'm a bit confused about the MVC paradigm in relation to iPhone development. Currently, I'm splitting the app into:

1. Model (FooModel.h, FooModel.m)

2. View (FooView.xib)

3. Controller (FooController.h, FooController.m)

But should I instead use for the View a subclass of UIView (FooView.h, FooView.m)..?

It's just a simple game app.

Answer 1

This should help you with understanding MVC as implemented in iphone developemnt:

Understanding View Controllers in Cocoa Touch

Answer 2

NIBs are neither the controller nor the view; the NIB is referenced by the controller (UIViewController.nibName) and used to instantiate the controller's view. The default nib name is the name of your controller class (i.e. if you don't set a nib name, it will automatically look for "MyViewController.nib").

If you need to write code that's entirely self-contained UI, it should be in a view. This is probably going to be a custom control, or set of controls (e.g. a colour picker view).

You might add FooView.m if you need to implement anything Foo-specific in the UI, like custom drawing/touch handling. Additionally, if you need to access FooView's subviews, it may be easier to set them as outlets on FooView (instead of FooController); this means you don't need to unset them in viewDidUnload.

The standard naming convention is to call it "FooViewController", because it's pretty tightly coupled to the UIView hierarchy (and you might have an additional FooController which solely manages the model; and maybe a FooWebController for a web interface to the same model).

Ultimately, do whatever's easiest in the long term. Personally, I don't add extra classes until it's obvious that they become necessary, but I try to structure my code such that it's easy to refactor out bits. Once I've written more code, I have a better idea of how it ought to be structured, and also a better idea of how much more work is required. This might mean I spend more time refactoring, but it also means I spend less time doing a (wrong) design, or writing classes which are only ever used once because of some architectural change down the line.

Hopefully, it also means that releases get out the door sooner. This is important. UI requirements change too fast to spend a lot of time on it; we're about to do a complete UI overhaul for one of our apps to better support the iPad and multitasking.