Alrighty, for those of you on the edge of your seats, here’s the rest of the story (see Part I here):
After doing a quick brush up on Objective-C (a la Apple Documentation, etc), the first thing I did was purchase a copy of the Big Nerd Ranch Guide to iPhone Programming. I am a huge fan of programming books that teach by allowing you to work through a single project over multiple chapters, because they really helps to see how each of the concepts/features you learn might fit into a larger whole. Years ago, I had purchased a number of books from the Head First series (specifically, Java and HTML/CSS), and I found them to be phenomenal, particularly as someone who at the time had no prior coding experience. Some might find the books a bit “immature,” and indeed, they are no replacement for a reference books or a more heavyweight books such as Steven Prata’s C++ Primer Plus, but for someone just starting out, they would definitely be at the top of my list.
Back to my project. After working through the first 10 chapters or so, I switched to skimming the parts that would be relevant to my app, and skipping those that weren’t (e.g. iPhone compatibility, accelerometer, location services, etc). Then, I hit the drawing board. My contact at the YDN had given me a few general functional specs, but the implementation was up to me. After drawing out a few diagrams under the Model-View-Controller paradigm, I was ready to go. Basically, I needed the following:
- An XML parser – complements of TBXML
- A list of articles – and new story object
- A list of favorites – and corresponding singleton object
- An interface
I chose to implement the XML parsing using a DOM-based parser – which, rather than notifying the program when it finds a new XML tag, creates a sort of “document map” that allows you to search for items based on various tags. Not only does TBXML store item tags, it also saves the attributes of each xml tag — so, for example, I needed to get the link for an image, I could ask for the src attribute of the image tag.
The list of articles and favorites were pretty easy to implement. The natural way to store all of the articles was in a dynamic array, which, in the case of Objective-C means an NSMutableArray. In the first go around, I had them written as separate classes, because the while they are similar in concept – presenting a view based on articles, the implementations were very different. Eventually, I decided to superclass them (I know, this is supposed to happen the other way; first make a class, then subclass it) with what amounts to an abstract base class in Java or simply a normal base class in C++/Objective-C. Actually writing my own class structure helped me understand inheritance in a way that I had previously not. The key lessons here are:
- figuring out which methods would be identical among subclasses
- figuring out how to write code that could be extended
- learning when to declare [abstract] methods – cases when I knew the subclass implementations would differ (e.g. in my case, filling the arrays with data) but wanted ensure that my subclasses would implement them.
Assembling the interface was my true introduction to iPhone programming and more importantly, open source code. I won’t get into the nitty-gritty of UITableViewControllers and the like, but my discovery of open source code is worth mentioning. Open source code is a phenomenal way not only to learn what good code looks like, but also to understand the role software libraries play in development. Oh yea, and if used properly, your software can end up ten times more feature-rich. Credits here to:
- Enormego for PullToRefresh and Lazy Image Loading (uses a cache)
- Tom Irving for TISwipeableTableViewCells (like the twitter app; reveals a set of buttons behind a cell)
- Facebook for their SDK and sample implementation
- Sharekit for showing me how to email a link and post to Facebook or Twitter from within an app
Note: These last three did not make it in version 1 of the app (currently in the store). I’m working on an update as we speak.
After I finally assembled my code, it was off to testing. The hardest part about testing and debugging was (unsurprisingly) memory management. While memory leaks/errors are difficult to find in C/C++, I feel that the rules for memory management are much more straightforward. You don’t have any of the retain/release jargon concealing the basic facts about memory management in the C family of languages — memory is either allocated in the stack or in the heap (Note iOS 5+ makes Objective-C more similar to Java in its memory management with Automatic Reference Counting, although it still retains elements of its heritage). Best resource I found for finding memory leaks and understanding how to use the Leaks tool in Instruments (part of the developer software) was from Mobile Orchard. Also, XCode has a feature you can enable called NSZombie, which will allow you to see if you are messaging a deallocated object. If your program is crashing with a sigabrt, I would check this out. Regardless, my recommendation: understand memory issues before embarking on a larger-scale project. It will save you a lot of debug time in the end.
All told, it took me about six weeks to teach myself Objective-C and make the app and get approved by Apple, which was extraordinarily gratifying, both on an intellectual and personal level. Hopefully, it will be the first of many!
Here are some screenshots of version 1. You can download the app here: