I avoid using UITableViewController
, as it puts lots of responsibilities into a single object. Therefore I separate the UIViewController
subclass from the data source and delegate. The view controller's responsibility is to prepare the table view, create a data source with data, and hook those things together. Changing the way the tableview is represented can be done without changing the view controller, and indeed the same view controller can be used for multiple data sources that all follow this pattern. Similarly, changing the app workflow means changes to the view controller without worrying about what happens to the table.
I've tried separating the UITableViewDataSource
and UITableViewDelegate
protocols into different objects, but that usually ends up being a false split as almost every method on the delegate needs to dig into the datasource (e.g. on selection, the delegate needs to know what object is represented by the selected row). So I end up with a single object that's both the datasource and delegate. This object always provides a method -(id)tableView: (UITableView *)tableView representedObjectAtIndexPath: (NSIndexPath *)indexPath
which both the data source and delegate aspects need to know what they're working on.
That's my "level 0" separation of concerns. Level 1 gets engaged if I have to represent objects of different kinds in the same table view. As an example, imagine that you had to write the Contacts app—for a single contact, you might have rows representing phone numbers, other rows representing addresses, others representing email addresses, and so on. I want to avoid this approach:
- (UITableViewCell *)tableView: (UITableView *)tableView cellForRowAtIndexPath: (NSIndexPath *)indexPath {
id object = [self tableView: tableView representedObjectAtIndexPath: indexPath];
if ([object isKindOfClass: [PhoneNumber class]]) {
//configure phone number cell
}
else if …
}
Two solutions have presented themselves so far. One is to dynamically construct a selector:
- (UITableViewCell *)tableView: (UITableView *)tableView cellForRowAtIndexPath: (NSIndexPath *)indexPath {
id object = [self tableView: tableView representedObjectAtIndexPath: indexPath];
NSString *cellSelectorName = [NSString stringWithFormat: @"tableView:cellFor%@AtIndexPath:", [object class]];
SEL cellSelector = NSSelectorFromString(cellSelectorName);
return [self performSelector: cellSelector withObject: tableView withObject: object];
}
- (UITableViewCell *)tableView: (UITableView *)tableView cellForPhoneNumberAtIndexPath: (NSIndexPath *)indexPath {
// configure phone number cell
}
In this approach, you don't need to edit the epic if()
tree to support a new type - just add the method that supports the new class. This is a great approach if this table view is the only one that needs to represent these objects, or needs to present them in a special way. If the same objects will be represented in different tables with different data sources, this approach breaks down as the cell creation methods need sharing across the data sources—you could define a common superclass that provides these methods, or you could do this:
@interface PhoneNumber (TableViewRepresentation)
- (UITableViewCell *)tableView: (UITableView *)tableView representationAsCellForRowAtIndexPath: (NSIndexPath *)indexPath;
@end
@interface Address (TableViewRepresentation)
//more of the same…
@end
Then in your data source class:
- (UITableViewCell *)tableView: (UITableView *)tableView cellForRowAtIndexPath: (NSIndexPath *)indexPath {
id object = [self tableView: tableView representedObjectAtIndexPath: indexPath];
return [object tableView: tableView representationAsCellForRowAtIndexPath: indexPath];
}
This means that any data source that needs to display phone numbers, addresses etc. can just ask whatever object is represented for a table view cell. The data source itself no longer needs to know anything about the object being displayed.
"But wait," I hear a hypothetical interlocutor interject, "doesn't that break MVC? Aren't you putting view details into a model class?"
No, it doesn't break MVC. You can think of the categories in this case as being an implementation of Decorator; so PhoneNumber
is a model class but PhoneNumber(TableViewRepresentation)
is a view category. The data source (a controller object) mediates between the model and the view, so the MVC architecture still holds.
You can see this use of categories as decoration in Apple's frameworks, too. NSAttributedString
is a model class, holding some text and attributes. AppKit provides NSAttributedString(AppKitAdditions)
and UIKit provides NSAttributedString(NSStringDrawing)
, decorator categories that add drawing behaviour to these model classes.
Best Answer
Might not be the best analogy but, think about the controller the same way as you would think about a spider's web. Its sole job is to catch flies (requests) for the spider (underlying layers) to digest. The web can catch and hold smaller or larger flies (models). A spider's web role is not to digest the prey, although it can be used in this purpose. The thinner and cleaner the web, the easier for the spider to make a living.
You could apply somewhat the same logic to your MVC application. The huge and nasty functions you describe are most likely behavior of the model and they should belong in the model (note that the model is not only the object that's being displayed in the view). If the behavior of the model changes it's the model that should be changed and not the controller that handles it.
Also, keeping them as private methods in the controller would only clutter it and make it hard to maintain. It also makes way for a bad habit, since other people that are involved in development would be tempted to do the same, since they've seen it done before in the project.