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.

Model-View-Controller

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:

Object.Method;

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.)

Conclusion

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.

iPhone OS 4 News

As I prepare for the iPhone training and conference next week, I’ve been paying close attention to all the news I can find about the recently announced iPhone OS 4. Here are some relevant (and not so relevant) links from my news reader:

  • iPhone in Business (teaser from Apple re: iPhone OS 4)
  • What iPhone 4.0 means for IT (MacWorld speculation re: iPhone OS 4)
  • iPhone Developer Program (Apple page with link to compare different developer programs)
    • Individual ($99) – Must distribute apps via AppStore, cannot create development teams
    • Company ($99) – Must distribute apps via AppStore, can create development teams
    • Enterprise ($299) – Must distribute apps in-house, can create development teams

And, then there’s this:

image

The NativeUnion MM01H not only works with the iPhone, BlackBerry and other mobile phones, but can (with an adapter sold separately), be used as a USB headset for use with Skype and other VOIP services on your computer. It looks like the iBatPhone. Of course, I want one.

iPhone Developers Conference

As I mentioned in the previous post, I will be attending an iPhone Developers Conference in late April.

Here are the sessions I plan to attend:

Friday, 4/23:

Saturday, 4/24:

Sunday, 4/25:

Disappointingly, not all of the sessions have an abstract. However, the remainder of the sessions seem to focus on game development and things like “in app purchasing,” which seem much less relevant to our environment. So, I’m pretty sure I’m in the right sessions.

I’ll likely be tweeting while I’m at the event – like I did from the Agile Open Northwest conference last month. (That turned out to be a great way to remember what I learned.) And, when I get back I’ll likely be blogging, so watch this space!