1

I'm particularly interested in how to follow Apple's standards with respect to a good MVC pattern design. Let me illustrate my question with an example.

Lets say I have a number of fairly complicated UI elements on screen such as UITableView. Basically these elements require a datasource and a delegate to handle interaction.

There are two approaches to working with this.

I can have the same subclass of UITableViewController handling all of the elements and dynamically handling things based on the requesting UITableView.

Second approach would be to have "lightweight" controllers that would manage each individual view. In iOS 4.x you're not allowed to have multiple UIViewControllers, so these controllers would be more for managing state and interaction.

I don't like the first approach because it doesn't scale and seems to combine things. What if I have multiple complex objects of dissimilar type?

The second approach seems better. Objects are encapsulated better - separation of concerns. The only downside seems to be increased complexity of communication. Lightweight controllers would have to either delegate back to the real view controllers or they'd have to have a handle to something to perform real actions.

What is your experience with either of these approaches? Is there a better solution for decomposing a complicated interface?

Thanks

EightyEight
  • 3,430
  • 4
  • 36
  • 67

1 Answers1

1

You can always re-assign the delegate and datasource of a UITableView to something else. It does not have to be a UITableViewController. As long as it fulfills 1 of the protocol methods for the delegate and datasource.

So you may have a UIViewController (controller) that is powered by a nib/xib (view created by Interface Builder). In that interface you've added a tableview and set it's delegate and datasource to the file owner (back to the controller).

Then the UIViewController may communicate to Core Data (model) to retrieve related objects in response to the UITableView delegate messages.

Or, the UIViewController can re-assign the delegate/data-source to a lightweight provider that fulfills the protocols to make it more encapsulated.

This is the style of MVC Apple is suggesting.

Taylor Dondich
  • 628
  • 4
  • 9
  • But what if I have multiple Tableviews, all linking back to the same ViewController? What if each table view needs to retrieve data from various points, not just CoreData? Then said view controller needs to handle each tableview individually. Wouldn't it be cleaner to have an individual controller object within the larger UIViewController? – EightyEight Mar 22 '12 at 19:28
  • No. Not really. Remember, you can specify the datasource/delegate to be something else. So just assign it to another object which is responsible for managing those tableviews. No need to "nest" UIViewControllers. – Taylor Dondich Mar 22 '12 at 20:20