What's the difference between a UIClass and UIClassController?

Question

Im starting iPhone developpement on Xcode and I don't get what the difference between a View and a View Controller is or between a Table View and a Table View Controller. Does anyone have a simple explanation?

Answer 1

The difference between a view and its controller can be properly framed in the context of the Model-View-Controller pattern (also have a look at this post):

A view is a (visual) representation of its model. It would ordinarily highlight certain attributes of the model and suppress others. It is thus acting as a presentation filter.

A view is attached to its model (or model part) and gets the data necessary for the presentation from the model by asking questions. It may also update the model by sending appropriate messages. All these questions and messages have to be in the terminology of the model, the view will therefore have to know the semantics of the attributes of the model it represents.

A controller is the link between a user and the system. It provides the user with input by arranging for relevant views to present themselves in appropriate places on the screen. It provides means for user output by presenting the user with menus or other means of giving commands and data. The controller receives such user output, translates it into the appropriate messages and pass these messages on to one or more of the views.

The idea is that the view is responsible for the visual representation of the data contained in the model; the controller is responsible for the user interaction and communication between the view and the model, roughly speaking.

This applies to the relationship between UIView and UIViewController, as well as to the relationship between UITableView and UITableViewController, etc. Also to be noted that while UIView/UIViewController has no provision for a model class (since they are very broad classes, so the model could be anything), UITableView/UITableViewController do define a model in the form of the table data source and it UITableViewDataSource.

Answer 2

A View Controller is as the name implies, an entity that controls the "views" that it manages. So you don't render the view controller to the screen. You just render views. A view can be rendered to the screen. It can accept touch events, gestures etc. It can contain many other subviews or it may be a subview to another view. But take this entire picture. What manages all these views (and the subviews) with their mechanisms? That is the view controller. A View Controller is an object that contains a composition of views and it manages how those views work.

Answer 3

Lets get to the UIView and the UIViewController class first

UIViewController is a Cocoa Touch class built for the purpose of managing UIViews. It expects to have a view hierarchy, but you don't "automatically" get a view (this is slightly inaccurate; see edit below). Usually you will obtain views by calling initWithNibName on your view controller.

There is some built-in magic in Interface Builder which knows that if File's Owner is a UIViewController (or subclass), there is a property called view. That's about it.

Once you have linked a view controller and a view, the view controller does a fair amount of work for you: it registers as a responder for view touch events, registers for device rotation notifications (and handles them automatically, if you wish), helps you take care of some of the details of animation, and handles low-memory conditions semi-automatically.

If you don't call initWithNibName or set the view property manually, the view property getter will invoke loadView if view is nil. The default implementation of loadView will see if you've set nibBundle and nibName and attempt to load the view from there (which is why you don't have to call initWithNibName, most of the time), but if those properties aren't set, it will instantiate a UIView object with default values. So technically, yes, it does automatically come with its own UIView, but most of the time that's of little value.

Now coming to the TableView and the UITableViewController class

A TableViewController is a ViewController with a TableView built in. This will have the delegate methods needed already declared and setup. This VC is already a TableView delegate and datasource. It cannot be resized. Upside is ease of use, downside is very limited flexibility.

A TableView is just that a TableView (subclass of UIView). It can be added to a ViewController and resized, used alongside another view based object, etc. The upside is the flexibility, the downside is that you have to setup the delegate and datasource methods yourself (in my opinion, well worth the time to get the flexibility).

One other note is that when using the new Static TableView cells (part of iOS5), you have to use a TableViewController.

Also please check the following links for a detailed explanation of the methods.

view and viewcontroller

What are controller classes?

What is the difference between UIView and UIViewController?

What's the difference between the RootViewController, AppDelegate and the View Controller classes that I may create?