What's the best way to organize multiple subviews?

Question

As someone who is fairly new to iPhone development, I've been trying to find good design patterns for managing multiple subviews, specifically where the subviews need the same type of delegate methods to be defined.

For example, I have a view where I need to swap between 2 UITableViews based on user actions. Both UITableViews need a UITableViewControllerDelegate object defined to populate the rows, etc.

Do you more experienced iPhone devs find that overloading the main view controller as the delegate for both subviews is the right way to do things? Currently I have 2 objects defined that each act as a delegate for each UITableView to try to keep things more organized. It accomplishes what I need it to, but is this a good pattern to follow?

I would assume there are some best practices out there to avoid various pitfalls with memory management and fun things like that. Thanks in advance!

Answer 1

That's how I would handle the situation myself. One controller and delegate per UITableView. The datasource can be reused, if that makes sense (i.e. the same data is displayed in both UITableViews) Otherwise you would have lots of ifs in you're delegate methods, checking which tableview send the message.

Switching UITableViews sounds like job for UINavigationController to me. Usually on the iphone, you don't just rearrange your controls. You create complete screens (in code or as .nib via InterfaceBuilder), switching between them using UINavigationController or a UITabBar.

Answer 2

If there was only a small difference between the two—for example, if table cells are laid out the same way but use slightly different data—I might use if statements, but otherwise I'd go with separate delegate objects of some sort. Separation of concerns is the key here: if you're writing one method that does two vastly different things, that's a sign that your code is not organized well enough to be readable, maintainable, or flexible.

Also, don't forget that view controllers don't have to be magical objects that you can only use with Apple-approved tab bar and navigation controllers. It's perfectly legitimate to write your own "switching view controller" that takes two view controllers and toggles between them. You'll need to do some testing, though, to determine whether you need to call -viewWillAppear: and its ilk manually or not—there's some magic machinery that may or may not do it for you, depending on where you add your view controller in the hierarchy.

Answer 3

You can use views as containers to hold the elements like tables. So in the case you outline, you'd have one container view and swap UITableViews in and out of it...

A good approach would be to have seperate view controllers for each table. Otherwise it just gets too messy trying to keep track of which data set you are supporting across the various table view delegate methods, and makes it harder to do lots of customization to one table that may not apply to another.

The main thing to be aware of when using composed view controllers is the "self.navigationController" and related calls will not return anything (since they are not really children of your navigation controller) so you'll need to pass along that reference or otherwise handle that somewhat differently in the table view controllers.