-
« Home
Pages
-
Categories
-
Archives
- May 2011
- April 2011
- March 2011
- February 2011
- January 2011
- December 2010
- November 2010
- October 2010
- September 2010
- August 2010
- July 2010
- June 2010
- May 2010
- April 2010
- March 2010
- February 2010
- January 2010
- December 2009
- November 2009
- October 2009
- September 2009
- August 2009
- July 2009
- June 2009
- May 2009
- November 2008
- September 2008
- August 2008
- July 2008
- June 2008
- May 2008
- April 2008
- March 2008
- February 2008
- January 2008
- December 2007
- September 2007
- August 2007
Monthly Archives: February 2011
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: https://github.com/csm/CustomNavigationController. 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.

