views:

358

answers:

1

I have a UIViewController that should be capable of displaying tableViews with multiple data sources. The UITableView spans about half the size of the screen, and there is and up and down button that allows you to go through different data. Everytime the up and down button is hit, I'd like to ultimately use UIViewAnimationTransitionCurlDown or something similar to display the next UITableView.

The question is: do I need multiple UIViewControllers to do this, with a tableView embedded in each one? Should I just create one instance of UITableView and change its data source when an up or down button is hit? If it's only one instance of UITableView, how do I manage to get a curl transition over the portion of the screen it takes up to make it look like a new tableView is coming in?

+4  A: 

Why not have each table view belong to its own UITableViewController, and nest these within the current screen's view controller? This way the screen's view controller is responsible for swapping out its subviews, each of which have a table view controller containing the necessary logic to show their data.

In the end, it comes down to what your functionality and data sets look like. It may end up being easier to implement the table view datasource & delegate code once, injecting an actual data source into this class - or it may be easier to write custom datasource code for each table view.

pix0r
How would you 'nest' one view controller with another? I understand adding subviews and all, but a uitableviewcontroller?
randombits
Your "parent" view controller would be responsible for creating the appropriate table view controllers and displaying their views. There's no reason you can't have several views on the screen simultaneously, controlled by separate view controllers.
pix0r
Yea, basically your viewDidLoad method can simply do something like topTableController = [[MyTopTableController alloc] init]; topTableController.view = self.topTableView; topTableController.delegate = self; (or do something similar in a nib file) ... Having looked at this already it seems like it's just easier to use one controller per table rather than try to use one controller as a delegate/ds for multiple tables. You can do it because the delegate methods pass in a pointer to the UITableView which you can if() or switch() on, but it may be a cleaner design to use multiple "subcontrollers"
Nimrod