Recently I’ve been working on an iPad-native interface for WOD. I did it the straightforward-ish way: make it a split view, with the source lists and navigation on the left (or in a popover in portrait mode) and put the detail view on the right. It was, overall, pretty simple to do, but I ran into some issues that I thought I’d write about.

The first issue was odd: occasionally, the navigation views on the left would get wonky; the color scheme is such that it’s white text on a dark background (the built-in, dark textured background), but occasionally these views would switch to a white background, and some of the views wouldn’t get populated with data anymore. This happened when memory pressure started hitting, and views needed to be unloaded.

I spent a long time trying to figure this out; I thought the problem might have been with UINavigationController, which people say is really only meant for full-screen views, or as the “root” view controller of a split view.

So, I spent some time reimplementing UINavigationController from scratch, and produced this: This is also nice, because it supports custom animation directions.

This wasn’t the problem, though; the problem was that I was subclassing UITableViewController in each of the content views, but wasn’t setting the view property to a table view: instead, it was a container view that held the table view. Well, it seems that if a UITableViewController gets unloaded, it doesn’t seem to re-load this correctly from the nib: instead, it was creating a brand-new UITableView that had the default settings and occasionally, didn’t have the delegate or dataSource properties set properly. So the solution was actually simple: just subclass UIViewController and implement the appropriate protocols. UITableViewController seems really optimized for just handling a single table view, so it’s better to just ignore UITableViewController if you’re doing anything fancy.

But anyway. I made something neat out of the process.