Today, I teased my Twitter followers with this and this. I thought it would only be fair to elucidate a little bit.
The first half of More iPhone 3 Development has been a struggle to write. In the first half of the book, we create a navigation-based application using Core Data. Although the chapters are primarily intended to teach different aspects of Core Data, I also wanted to set a good example design-wise. If you've ever written a table-based detail editing view, you know that's a challenge. Even Apple's sample code uses kludgey, hard-to-maintain techniques because the table view architecture simply wasn't designed primarily for creating this type of view; it was designed to display values from a collection or list not for displaying or editing different attributes of a single object.
My early thought was to create a generic framework of controllers that could handle editing any Core Data object just by creating property lists. This approach, although I think it has great merit for use in development, made the book too hard to write. All the code that I needed to show was getting squirreled away in these generic classes, and I was having to spend a lot of time explaining the architecture rather than the important Core Data concepts that I needed to get across.
After a lot of struggling, and writing probably twenty-five different prototypes, I finally hit on a solution that I liked. It was a maintainable design that borrowed a lot from the property list prototype, but kept everything in the places where people are used to seeing it. Instead of property lists, we store the structure of the table view in arrays, but we start simple enough that the concepts don't become too overwhelming. Or at least I hope they don't.
As I started working on the Chapter 7 version of the application, which is the first time that we need to add another detail editing controller, I realized that in just a few short pages, we could refactor the controller class written over the previous six chapters to be completely generic and totally reusable, meaning we wouldn't need to write any more substantive code for editing or displaying data once the refactoring is done. We can add drill down into an infinite number of controllers, traversing relationships or fetched properties, and never have to add more code than what's needed to create a couple of arrays that define the object and attributes we want to let the user see or edit.
It's so far been a somewhat difficult chapter to write, but it's incredibly edifying to get here and realize that the attention to design has paid off. The end-result of Chapter 7 is basically an extensible infrastructure for creating navigation-based Core-Data applications. Hopefully, the reader will also have taken away a strong understanding of Core Data, but even if not, you'll have a starting point to work from that will save you a lot of development time. You just create your model, and set the controller instance's arrays to reflect the objects and data to be displayed or edited in your application. All the really hard stuff is done and can be leveraged over and over again.
Thanks for your patience. Once Chapter 7 is done, I should be able to make much faster progress.