Tag Archives: Yale Daily News

iPhone Programming, Part II

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:

  1. figuring out which methods would be identical among subclasses
  2. figuring out how to write code that could be extended
  3. 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:

YDN App Screenshot

YDN App Screenshot 2

Leave a comment

Posted by on December 21, 2011 in Programming, Projects


Tags: , , , , , , , , , ,

iPhone Programming and Objective-C, Part I

So two months ago the Yale Daily News was looking for a CS major to make an iPhone app for them.  They have quite and extensive business team, with a highly visible website (100,000+ views per week!) and internet presence, so this was the logical next step.  At the time, I had never worked on a real project before (all of my programming knowledge was either self-taught or limited to a few functions/methods in one or two files), but I volunteered because I figured it would be a good opportunity to try my hands at some real coding.  A few days and a couple of meetings later, I was working on the project.  Alone.  Talk about getting thrown in the deep end and learning how to swim.

First thing to do, of course,was to teach myself Objective-C.  Having worked through Stephen Prata’s C++ Primer Plus, 5th Edition I was reasonably familiar with object-oriented concepts and general C-syntax, but boy, was I in for a surprise.  At first glance, Objective-C is hideous.  You have to put [] around every method call, and its function names (or “selectors,” as they call them), can get absurdly long (try keysSortedByValueWithOptions:usingComparator: for a short one).  However, after doing some reading, I found that it was reasonably easy to learn, and actually had a lot to like:

Highlights are as follows:

  • Apple Developer’s Library – top notch; includes sample code and extensive class references
  • sending messages to nil/NULL – really neat feature that allows your program to avoid crashing when you send a message to nil.  Prevents you from having to write extra logic to deal with nil/NULL cases.
  • dynamic (run-time) typing – you can make pointers of type “id” (Objective-C’s equivalent to Java’s “Object”) – and because each instance of an object contains a reference to its class ([self class] or equivalently, self.class), you can write a single function for any data/object type, and vary the implementation within the function itself based on the data type
  • selectors  – you always know what each parameter to a function/method represents, because the selector (i.e. function name) varies based on the required parameters.  As a result, there is no function overloading; technically, you are writing an entirely new function.
Of course, there are two sides to every coin:
  • sending messages to nil/NULL – dangerous!!! Can lead to some very undesirable functionality if you’re not careful.  The feature is good if you know what you’re doing, but it can lead to some very sloppy code.  Also, the functionality does not prevent against the more common error of messaging / dereferencing a pointer to deallocated memory, so that is something to watch out for.  Good practice would be to set a pointer to nil as soon as its pointee has been deallocated.  That way, you can avoid crashes.
  • dynamic typing – code might compile but crash at run time.  Java, on the other hand, is strongly typed, so this kind of problem is less frequent.  However, in Objective-C, you can type your variables (usually pointers) if you want.
  • retain/release and memory management – it’s a pain to understand exactly how retaining works, and whose responsibility it is to release an object.  (NOTE: iOS SDK 5.0+ uses automatic reference counting, which takes the burden of memory management off the developer.  You should still understand how it works).  Here’s a good resource for memory management in Objective-C
  • It’s incorporation of C is very awkward.  Although Objective-C is functionally a superset of C, it looks very strange when you have C code in an Objective-C class.  You have to sort of treat them as two languages when coding/debugging, which can get kind of annoying
Part II (the process of making the app) to follow.
In the mean time, here’s the book I used to help me with iOS programming.

If you’re interested, you can check out my app here (it’s free).

1 Comment

Posted by on December 19, 2011 in Programming, Projects


Tags: , , , , , , ,