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

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.