iPhone Developers Training Notes

It’s been a couple of weeks now since I attended the Voices That Matter: iPhone Developers Conference. That distance has given me an opportunity to get plugged back in at work – and forget everything I heard at the conference. Fortunately, I took notes.

The conference was hosted by (can you guess?) a book publisher – namely, Pearson Education. As such, they happened to know of a couple of guys who’d just written a book about development on the iPhone OS platform: Aaron Hillegass and Joe Conway of Big Nerd Ranch. Everyone at the class received first editions of the book, which hadn’t even hit the shelves yet.

The class centered around the book, which was clearly drawn from their experiences teaching classes. We’d spend a while listening to lecture, then we’d code for a while. Nothing too complex. But, I learned a whole lot. Here are some of the good bits:

The iPhone OS is a modern, event-driven operating system, not unlike Windows or OS X.

(Oo! Big surprise!)

Basically, the OS sits around waiting for events to happen. An event might be the user swiping their finger across the screen. Or, it might be system generated, like an incoming phone call. In any case, the OS spends most of its time waiting. And, when it’s not waiting, it’s executing “the event loop” which looks like this:

iOS Main Event Loop

Thank Apple for the pretty picture. The Big Nerd Ranch guys had a better, more technical drawing in their slides. Alas, they did not share their slides with us.


Everything about the iPhone OS is based on the Model-View-Controller (MVC) design pattern. There does not appear to be a way to write an iPhone OS application without using that pattern – at least not with XCode, the Apple development environment. (Think Visual Studio for Mac OS X and iPhone OS apps.)

Frankly, I find this incredibly impressive and beautifully elegant. Each application you build consists of one or more Views (screens or sub-screens); a Controller for each and every View; and one or more Model objects for storing data.

Objective-C is weird!

You know those warm and fuzzy things like “dot notation” that C programmers have been accustomed to for decades? Yeah, they changed that in Objective-C. Instead of using periods to call a method on an object, like this:


Objective-C uses a square bracket notation, like this:

[Object Method];

Furthermore, you know that old familiar way you’ve been sending parameters to methods, comma separated lists inside parenthesis? Yeah, they changed that, too. So, instead of this:

aCircle.draw(point, radius);

In Objective-C, you write this:

[aCircle drawAtPoint:point OfRadius:radius];

In other words, Objective-C forces you to name your parameters. And, they even include them in the method name. The method above is called “drawAtPoint:OfRadius:”. They even pronounce the colons! Too weird!

Note: As a side effect of including the parameters in the name of the method, Objective-C does not support method overloading, since changing the parameters changes the name of the method.

No Garbage Collection

But, not all of the old, time-honored traditions of the C language are gone. No! Memory leaks are as prevalent as ever thanks to the lack of a memory manager with garbage collection.

Actually, OS X (on which the iPhone OS is based) does have garbage collection. Apple chose to remove it due to the memory constraints on the devices (according to Aaron and Joe).

Here’s how it works. When you want to declare a variable, you first allocate memory for it on the heap, and initialize (or zero out) the memory:

myArray = [[NSMutableArray alloc] init];

This line of code calls the static “alloc” method on the NSMutableArray class in order to set aside enough memory for the array, then calls the “init” instance method on the new object to zero out the allocated memory. After the methods run, a pointer to the memory in the heap is placed on the stack in a variable called myArray.

Note: It’s quite common to see methods strung together like this.

Now, if you just allocate more and more memory without ever releasing any of it, you’ve produced a classic memory leak, ala C programs on MS-DOS in 1981. So, the good programmer will clean up after themselves, like this:

[myArray release];

Simple enough. But, easy to forget.

Alternatively, you could flag the variable as to “autorelease” at the end of the current event loop, like this:

myArray = [[[NSMutableArray alloc] init] autorelease];

It’s not quite that simple in reality. But, you get the point. (And, one veteran OS X and iPhone OS developer I spoke to at the conference recommended that until I really understand what I’m doing, I should always autorelease my variables just to be safe.)


I could keep writing for hours. The class was fantastic. I learned an incredible amount. But, I’ll wrap it up here with a couple thoughts about developing on the iPhone OS platform.

First, developing on the iPhone OS is not easy – especially if you haven’t developed on the OS X platform. Therefore, outsourcing a native application will likely be quite expensive – much more so than a typical business application. But, training internal staff would likely take too long, resulting in potential opportunity cost.

Second, the iPhone OS platform offers some particularly attractive features. But, beyond the cool factor and the general mobility of the device, corporations need to think long and hard about why they want an iPhone OS application over an HTML5 application before they invest their money.



0 responses