Question

According to the Model-View-Controller pattern, applied heavily in Cocoa Touch, UIViewControllers should always handle the logic behind how a concrete UIView in the scene behaves.

I am curious as to how Apple implements it’s UITableView class while keeping in line with this philosophy. Especially since UITableView inherits from UIScrollView and UIView in turn.

When you add a UITableView to one of your classes, does it have a UIViewController handling the way it behaves in the background? I know that a UITableViewDelegate is in charge of telling the table how many rows it should have, etc. But what about it’s inner workings?

Answer 1

I’m gonna take a wild shot here, because I’m not sure I really follow your question. When you add a UITableView, you HAVE to have a controller associated to it to control how it handles and renders. Either a UITableViewController or a UIViewController that implements UITableViewDelegate and UITableViewDatasource. If you don’t there’s no way you can control what it does.