Wrapping the tableView in a custom view in UITableViewController
Ever wanted to add a different view north of your table view without making it the tableHeaderView?
Here’s what you need:
@property (nonatomic, retain) UITableView *internalTableView;
- (void)loadView;
{
[super loadView];
self.internalTableView = self.tableView;
self.view = [[[UIView alloc] initWithFrame:self.view.frame] autorelease];
[self.view addSubview:self.tableView];
self.tableView.frame = self.view.bounds;
}
- (void)viewDidUnload;
{
self.internalTableView = nil;
[super viewDidUnload];
}
- (void)dealloc;
{
internalTableView = nil;
[super dealloc];
}
// here's the finesse
- (UITableView *)tableView;
{
if (!self.internalTableView) {
return [super tableView];
}
return self.internalTableView;
}
Jörg 18:36 on 16. July 2012 Permalink
I’ve done this a few times, too but since came to the conclusion that it’s not a good idea to fiddle with UITableViewController. The alternative really is to use
UIViewController
and add a property
@property (weak, nonatomic) UITableView * tableView;
Then you build loadView like you did and assign the container view to self.view and the table view to self.tableView and all of a sudden you have all flexibility to put your table view wherever you like.
That way you are safe against implementation details in the UITableViewController which really assumes it owns the whole space of a container view and sometimes resizes the TableView. It’s especially an issue if you want to throw the whole thing into a NavigationController or if you have views to the left and right of the TableView. Except for that it’s really the same thing, everything you want to do to a TableViewController will work with this fake one, too.
Jörg 18:38 on 16. July 2012 Permalink
OK, what’s the syntax of this blog? The “UIViewController” thing was supposed to have protocols for UITableViewDataSource, UITableViewDelegate and UIScrollViewDelegat but the site did eat the stuff in between the brackets. Is this BBCode or something?
Ullrich 18:55 on 16. July 2012 Permalink
@Jörg: Comments are not yet optimized for code, sorry.
About implementing the UITableViewController functionality yourself: We went down that road & ended up in problems with keyboard support & contentInset in table views. Keeping as much functionality of the original UITableViewController never caused us any trouble.
Jörg 19:24 on 16. July 2012 Permalink
Surprises me, I’m using both, too, no trouble. There’s also nothing really you need to implement yourself, only the delegate protocols but that’s what you have to do for a TableView anyway.
The important part is to also support the UIScrollViewDelegate protocol for keyboards and insets but that’s also the same with UITableViewController, I believe (not sure).
I don’t remember when exactly it happens but there are cases where with a TableViewController the TableView will be resized to fill the whole container again and hide/clutter your top view. Probablyrelated to rotations or Navigation controllers.