How to avoid big and clumpsy UITableViewController on iOS?
- by Johan Karlsson
I have a problem when implementing the MVC-pattern on iOS. I have searched the Internet but seems not to find any nice solution to this problem.
Many UITableViewController implementations seems to be rather big. Most example I have seen lets the UITableViewController implement UITableViewDelegate and UITableViewDataSource. These implementations are a big reason why UITableViewControlleris getting big. One solution would be to create separate classes that implements UITableViewDelegate and UITableViewDataSource. Of course these classes would have to have a reference to the UITableViewController. Are there any drawbacks using this solution? In general I think you should delegate the functionality to other "Helper" classes or similar, using the delegate pattern. Are there any well established ways of solving this problem?
I do not want the model to contain to much functionality, nor the view. A believe that the logic should really be in the controller class, since this is one of the cornerstones of the MVC-pattern. But the big question is;
How should you divide the controller of a MVC-implementation into smaller manageable pieces? (Applies to MVC in iOS in this case)
There might be a general pattern for solving this, although I am specifically looking for a solution for iOS. Please give an example of a good pattern for solving this issue. Also an argument why this solution is awesome.
