Question

I have a re-usable UITableViewController sub-class, call it “tableVC”. Selecting a table row pushes that detail view controller onto the nav stack. The tableVC instance only has a valid navController when it has been pushed itself. So far so good.

I need to embed the tableVC’s view inside another view whose viewController has been pushed. Since that superview’s viewController has been pushed, it has a valid navCon. I can’t get at that navCon from the tableVC because tableVC has not been pushed, and so the otherwise perfectly re-usable tableVC cannot push details.
Is there a clean way to reference that navCon, other than hacking in a special UINavigationController variable, and if self.navigationController is nil, then access the hack? Seems like a common enough situation that there should be a best practice.
Any insights are much appreciated.
-Mike

Answer 1

The short answer AFAIK is no, that there is no other way to get at the navigation controller you are after.

The medium answer is that you could override your table view controller’s navigationController property to make it writable:

@interface myTableViewController : UITableViewController {
  UINavigationController *navigationController;
}
@property (nonatomic, retain) UINavigationController *navigationController;

That would allow you to set it to the pushed VC’s navigation controller when you add its view as a subview. It will also still work as promised when you push it onto a navigation controller stack normally.

The long answer is that Apple discourages what you are doing. From “About Custom View Controllers” in the View Controller Programming Guide:

Note: If you want to divide a single
screen into multiple areas and manage
each one separately, use generic
controller objects (custom objects
descending from NSObject) instead of
view controller objects to manage each
subsection of the screen. Then use a
single view controller object to
manage the generic controller objects.
The view controller coordinates the
overall screen interactions but
forwards messages as needed to the
generic controller objects it manages.

I have run into the problem you are describing and ended up taking an approach first suggested by Matt Gallagher on Cocoa with Love: Create a separate controller class that inherits from NSObject (instead of UIViewController) and implements UITableViewDelegate and UITableViewDataSource to manage the table view. He has sample code with his post that is extremely useful if you decide to go down this road. When I did this it largely amounted to simply changing the inheritance declaration in my custom UITableViewController subclass.