iPad @ Home

The week after Thanksgiving, my wife called me at work from our treadmill at home:

“We need an iPad for the treadmill,” she puffed.

“Um, well… Okay!” I replied, trying not to sound too eager. “But, only since you’ve identified a use case.”

“Funny,” she huffed over the sound of her eyes rolling.

“Um… Okay. You’re serious?” I say, skeptically.

“Yes, as long as I can watch Netflix on it.”

“Sure. You can watch Netflix on it.”



“You pick it out. We’ll make that our big Christmas present to each other.”

“Really!?! You sure you want me choosing?”

“Yup. Just don’t, you know, go crazy.”

“Oh, well, of course not.”

Long story short, my household is now the proud owner of a shiny new iPad 16GB 3G. And, surprise! We love it. Jill’s been doing Netflix. I’ve been reading the news and surfing. The kids really like the Disney Read-Along™ story book versions of Toy Story and The Princess and the Frog. And, really, who wouldn’t love Angry Birds and Fruit Ninja? There’s just one problem…

We only have the one.

But, there’s no sense buying another one right now, since the iPad 2 should be here this spring.

Apple’s iPad finds a place in the enterprise

This article in MacWorld, today, reminded me of something I learned last week at a Microsoft technology briefing. During a discussion of Microsoft’s strategy related to the iPad, Microsoft’s representative asked how we’re using iPads today. I already knew we were developing sales tools and looking to find ways to make our applications accessible from the device. But, I didn’t know that our board is using iPads extensively. In fact, all of the documents for our last board meeting were distributed and reviewed on iPads. Everyone in the meeting had an iPad and could follow along in the documents as the presenter talked. And, apparently, even our septuagenarian board members loved it!

How else might we use iPads (or other tablet computers)? Clearly, those of us who write software every day won’t be using them for that. But, what about email and note taking in meetings? I’ll bet most managers in the company would gladly give up their laptop for an iPad, as long as it was able to open documents on SharePoint, crunch a few numbers and provide access to their email, and do it all securely.

What are your thoughts? Is there a job function around here that could benefit from a smaller, more portable computer?

iPhone 3GS Security Flaw

Apparently, the iPhone 3GS has a security flaw that would allow someone to access the data on a PIN protected device by connecting it to a computer running Ubuntu Lucid Lynx. (There was no mention of the iPhone 3G or the iPad having the problem. And, the original iPhone device didn’t offer encryption at all.)

Obviously, this kind of attack would only work if the hacker had possession of the actual iPhone. But, phones get misplaced all the time. Because of this, if you own an iPhone and you care about the security of the information on the device, you need the ability to reset the device remotely.

For corporations running Microsoft Exchange 2007:

You can initiate a remote wipe using the Exchange Management Console, Outlook Web Access, or the Exchange ActiveSync Mobile Administration Web Tool.

iPhone OS Enterprise Deployment Guide (page 9)

Individual iPhone owners can use MobileMe to “Remote Wipe” their device should it be irretrievably lost. Though, the service costs $99/year, it does include many other services.

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.