What is the difference between UIViewController and UITableViewController

Question

Sometimes I want to subclass UIViewController for some app wide customizations. Eg. something that all view controllers should perform during viewDidLoad or viewWillAppear or so.

Naturally I subclass UIViewController and go from there and all view controllers inherit from that. But some of the controllers run tables. And there is UITableViewController designed for that purpose.

So I subclass UITableViewController too and just do the same things there. Which does not seem to be the smartest thing in OOP terms. And there is no multiple inheritance etc.

And as UITableViewController inherits from UIViewController ...

Now I am asking myself why I don't just create my own table view controller that inherits from my very own view controller subclass and adds all the table stuff. But what is "all the table stuff"?

• There is the skeleton code that xcode adds to every new table view controller. Quite handy but that can be easily moved to code snippets.
• There is the declaration of the protocols UITableViewDelegate and UITableViewDataSource. Easy going. The implementation of those methods has to follow in each subclass of UITableViewController anyway.
• There are probably reasonable default implementations of all those mandatory methods in the protocol. Such as returning 0 for numberOfSectionsInTableView: or nil for titleForHeaderInSection or 44.0f for heightForRowAtIndexPath: (Bad example though. Could be smarter not implementing that at all)

So despite the obvious stuff, are there any miracles that UITableViewController takes care of?

Answer 1

I believe all of the behavior UITableViewController adds is well defined in the class documentation: https://developer.apple.com/documentation/uikit/uitableviewcontroller?language=objc

The UITableViewController class creates a controller object that manages a table view. It implements the following behavior:

• If a nib file is specified via the initWithNibName:bundle: method (which is declared by the superclass UIViewController), UITableViewController loads the table view archived in the nib file. Otherwise, it creates an unconfigured UITableView object with the correct dimensions and autoresize mask. You can access this view through the tableView property.

• If a nib file containing the table view is loaded, the data source and delegate become those objects defined in the nib file (if any). If no nib file is specified or if the nib file defines no data source or delegate, UITableViewController sets the data source and the delegate of the table view to self.

• When the table view is about to appear the first time it’s loaded, the table-view controller reloads the table view’s data. It also clears its selection (with or without animation, depending on the request) every time the table view is displayed. The UITableViewController class implements this in the superclass method viewWillAppear:. You can disable this behavior by changing the value in the clearsSelectionOnViewWillAppear property.

• When the table view has appeared, the controller flashes the table view’s scroll indicators. The UITableViewController class implements this in the superclass method viewDidAppear:.

• It implements the superclass method setEditing:animated: so that if a user taps an Edit|Done button in the navigation bar, the controller toggles the edit mode of the table.

All of these are behaviors which should be easy to re-implement if they apply to your specific controller and table view.

In general I have found it preferable to implement these behaviors myself in order to allow for alternate inheritance hierarchies as you noted and because I usually consider setting both the delagate and datasource of a table view to be a view controller a design smell. Those are independent concerns which usually can and should be handled by some other class (e.g. a dedicated data source for a particular model class) rather than bloating a view controller.