views:

3421

answers:

3

I'm writing a Navigation-Based iPhone app, and I'd like to have a UIToolBar docked at the bottom of my screen, with a UITableView scrolling between the tool bar and the navigation bar.

I've seen a couple of forums where it's been suggested that the View Controller handling this view should be a standard UIViewController rather than a UITableViewController. The view controller would have to implement the UITableView delegate and data source methods in addition to all of the standard UIViewController overrides. What (if any) built-in functionality do I need to recreate in this view controller subclass other than the aforementioned protocols to have it act like a UITableViewController? Is there anything I'm losing by going this route?

Or would it be better to nest a UITableViewController inside of a standard UIViewController?

A: 

All you need do is implement the UITableViewDelegate and UITableViewDatasource methods required for the level of table view functionality you require. These methods can be in any class(es) though said classes should conform to the relevant protocols. The delegate and datasource should be set on the UITableView instance - either programatically or with Interface Builder. According to the docs you will lose some functionality - see the overview section.

Personally I find that many developers seem to be obsessed with providing all of this functionality in a single monolithic view controller class, and that because they have a table view in their view then a subclass of UITableViewController must be used. However, I like to consider the Single Responsibility Principle and will often break the datasource and delegate into separate classes when the complexity is anything other than simple. The code is also then not tied to a specific UIViewController implementation.

In situations where I have separate datasource/delegate classes I often construct and wire them up to the table view using Interface Builder and not in code. This approach (to me at least) is in the spirit of Dependency Injection and saves writing some boiler-plate code, and provides some level of decoupling.

These choices of course are influenced by the complexity of the functionality that you are trying to achieve - for simple implementations I might find myself using UITableViewController.

teabot
+10  A: 

As of OS 3.0 the Navigation Controller has a tool bar built in. To make it appear:

[self.navigationController setToolbarHidden:NO];

By implmenting:

- (void)setToolbarItems:(NSArray *)toolbarItems animated:(BOOL)animated

in your view controller, you can configure the items of the tool bar.

So you no longer have to worry about where the tool bar is located in your hierarchy.

(corrected typo)

Corey Floyd
+1  A: 

Corey Floyd is mostly correct, except that

[self.navigationController setToolBarHidden:NO];

should be

[self.navigationController setToolbarHidden:NO];

That is, the "b" in "setToolbarHidden" must be lowercase. Also, method name listed in the iPhone OS Reference is actually

- (void)setToolbarHidden:(BOOL)hidden animated:(BOOL)animated

though it seems that omitting the animated parameter works too.

Vic
oops, corrected.
Corey Floyd