Are there any advantages to using a UITableViewController over a UIViewController that implements tableview delegate and datasource methods?

Question

In Xcode when I create a new view controller to contain a tableview I have two options

1. Create a new UITableViewController
2. Create a new UIViewController that implements the UITableViewDelegate and UITableViewDataSource protocols

Assuming I properly implement all of the required and optional methods for the protocols, is there any advantage (besides not having to write the method stubs) to using the UITableViewController? means, is there anything (memory management, caching, etc.) implemented behind the scenes in the UITableViewController class that makes option 1 a better choice than option 2?

Answer 1

You have to write the delegate and protocol methods regardless of which of the two approaches you take.

There are only two possible reasons you should choose to use UIViewController over UITableViewController when you need a view controller with a table view:

1. You need the table view to be smaller than the view controller's view.
2. You need to add additional views to the view controller that don't scroll with the table view (though there are ways to solve this with UITableViewController).

Here are all of the things that UITableViewController does for you that you would need to replicate:

1. Defines and setups up the UITableView.
2. Sets itself as the table view's dataSource and delegate.
3. Overrides the setEditing:animated: method to also set the editing property of the table view.
4. Deselects the last selected row in the viewWillAppear: method depending on the clearsSelectionOnViewWillAppear property.
5. Flashes the table view's scrollbars in the viewDidAppear: method.
6. Hooks up the refresh control (as of iOS 6).
7. Reloads the table view the first time it will appear.
8. Adjusts the table view's contentInset (as of iOS 7).
9. Scrolls the table view as needed when the keyboard appears.

Answer 2

The Keyboard Advantage with 0 Lines of Code

UITableViewController provides automatic scrolling when an on-screen keyboard appears, while regular UIViewController doesn't.

A UITableViewController reliably moves the edited area within view, without the need to fiddle with keyboard notifications. It has done so since the dawn of iOS, while the keyboard notifications have changed, rarely providing backwards compatibility.

Whenever a view requires editing (like a login screen), consider using UITableViewController and capitalize on this unique feature with exactly 0 lines of code.

Unfortunately, a regular UIViewController adopting the UITableViewDelegate protocol does not offer that functionality.

Works from the dawn of iPhone OS to today.

► Find this solution on GitHub and additional details on Swift Recipes.

Answer 3

UITableViewController allows to have static table on iOS5

Answer 4

The only thing a UITableViewController has/does that a regular UIViewController doesn't, is a tableView property and it conforms to the UITableViewDelegate and UITableViewDataSource protocols. Ad RolandasR points out, setting a view controller to be a (descendant of) UITableViewController also lets you use static table cells.

Answer 5

The main advantage of using the UITableViewDelegate is the simplicity. However, there are advantages to creating your own TableViewController that doesn't assume the view is a table:

1) You can add other elements and have the table take up a smaller part of the screen. 2) You can add a whole bunch of helper methods that are accessible to all VC that derive from your controller. I implement helper methods to automatically return row height when I have different UITableViewCell types and also auto-register the various cells, methods to get cell reference from a CGPoint in the table, pull-to-refresh callbacks, etc.

While you can always derive from UITableViewController and add helper methods, I think the main advantage is not having the table take up the whole view.