Wednesday, September 30, 2009

More iPhone 3 Development Update

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.



11 comments:

sserye said...

Thanks for the information.

One question, are you considering avoiding interface builder generated code in this book?
I assume this book is not for beginners, and sometimes, using interface builder code is really annoying, but, i know is a matter of choice.

All the best,

Jeff LaMarche said...

No, I would never even consider or recommend "avoiding" interface builder. If Interface Builder is suitable for a purpose, I always use it and honestly, I think anyone who avoids Interface Builder is foolish and doesn't fully understand its power.

That being said, we don't use Interface Builder much in the Core Data chapters because the views we're building are all table-based views and there's no point in creating a nib with just a single instance of UITableView in it, since UITableViewController will create the table view instance automatically.

After Chapter 7, most of the remaining chapters are likely to use IB. I don't really see it as a matter of choice, to be perfectly honest. I see it as an indication of whether you fully understand the tool and the architecture. I don't know an experienced, long-term Cocoa developer who avoids IB.

sserye said...

I am one of that foolish who doesn't understand IB power :-)

It was difficult for me trying to debug code when i was using IB, but you are right, it depends how you understand a tool in order to use it.

Thanks for your feedback,

Looking forward to buy your next book,

Timos said...

You just sold one more copy of your book. I have totally avoided using the table view framework because I find it much to confusing to use. I look forward to your book!

dcardella said...

Looking forward to the new book. Any way to get a look at beta material?

Jeff LaMarche said...

sserye:

I didn't mean for that to come across sounding so personal. There are a lot of people who have problems with it at first, but it's really a wonderful thing. I've got some slides from my workshop maybe I'll post later that may help explain why I discourage people from avoiding IB.

Gargs said...

This is a pretty interesting discussion. Even I have always wondered whether using the IB was the best way to learn the subtleties of iPhone UI development. At least the sample Apple code/projects seem to rely on doing everything programmatically.

That said, I am looking forward to this book. The first book is an excellent way to get started with iPhone development. To this day, it remains the only book I have purchased, yet, to learn development. And I consider myself an intermediate developer. Thanks Jeff!

sserye said...

Hi Jeff,

I didn't take this as personal at all.

Your help and advices about IB are really welcome.

Looking forward for your post about your workshop.

All the best,

Deans said...

You've probably covered this before (if so, sorry), but what's the ETA for the new book. I can't wait!

Subkey said...

I'm excited to hear you're writing another book! Looking forward to it!

h4ns said...

I was very encouraged to find this site. I wanted to thank you for this special read. I definitely savored every little bit of it and I have you bookmarked to check out new stuff you post.

AC Milan vs Lazio Live Streaming
West Bromwich Albion vs Wigan Athletic Live Streaming
Manchester United vs Aston Villa Live Streaming
Sunderland vs Chelsea Live Streaming
Arsenal vs Everton Live Streaming
Augsburg vs Bochum Live Streaming
Racing Santander vs Valencia Live Streaming
Frosinone vs Atalanta Live Streaming
AC Milan vs Lazio Live Streaming
West Bromwich Albion vs Wigan Athletic Live Streaming
Manchester United vs Aston Villa Live Streaming
Sunderland vs Chelsea Live Streaming
Arsenal vs Everton Live Streaming
Augsburg vs Bochum Live Streaming
Racing Santander vs Valencia Live Streaming
Frosinone vs Atalanta Live Streaming
Technology News | Hot News Today | Live Stream