Hunky Doray

So, Monday saw the official announcement of the iPhone 3G. We all knew it was coming, and most of us had started budgeting in anticipation. It turned out that the budgeting may have been unnecessary, as Apple have tried to address the affordability of the device. They also announced MobileMe, the replacement for the aging .Mac service (I say aging when I really mean decrepit). That, again, had been widely predicted.

There was one announcement that was made that I didn’t hear anyone predicting; the push notification service. This is Apple’s proposed fix to the background applications problem (at least, Apple see it as a problem).

As you probably know, appplications written using the official iPhone SDK cannot be run in the background. You cannot write background tasks, servers or daemons that run concurrently on the device. Apple have continually cited battery life and dropped calls as the reasons why they would not support background tasks. That hasn’t stopped developers asking (nay, demanding) it though. So, Apple have listened, thought about it, and come up with a cool (read, over-engineered) approach, that is scalable (read, controllable) and goes most of the way (read, half-way) to meeting the requirements of developers.

The Push Notification Service (or whatever they eventually call it) is, essentially, an proxy service that accepts notifications from developers’ servers that are pushed to iPhones that have installed the developers’ applications. The developer can push badges (those cure little number thingies that tell you how many mails and texts you have waiting), notification sounds and dialogs (I guess that’s actually the ‘description’ of a dialog, along with buttons to be displayed etc.).

A couple of things to note:

1. The notifications are tied to users.  By necessity, the notifications must be linked to users as they will only be sent if you need to receive them, i.e. you have installed an application from a developer that requires notifications. That’s going to give Apple the opportunity to collect a lot of data about users and the applications they are using. If you trust Apple, that’s not a problem.
2. The system is only one way. OK, so full details haven’t been released yet, and I may have misunderstood what little is known, but there’s no way for the device to reply to any notifications.

The first one may not be a problem. Apple could use the data collected to simply track the most successful applications and developers. No bad thing. The second point, I see as more of an issue.

I have an idea for an application on the iPhone that requires the device to report it’s location every now and then (”Yea, you and everyone else mate”). Now, I could simply ask the user to click a button on a dialog pushed from a notification, which, at least, gives the user the option *not* to update their location if they choose. But, from a usability point of view, it blows. I’d much rather give the user a preference to turn off automatic location updates when they want some privacy, rather than bother them with periodic notifications flashing up every now and again. And I can’t have anything running to respond to notifications that come from the server, because that’s just a background task, and I’m not allowed those.

(I could, of course, just develop my app with the unoffical toolchain.)

What about a small service, running on the iPhone as a client side addition to the push notification system,  with which developers could register bundles to respond to notifications from their servers? That way, developers would effectively delegate the handling of notifications on the client side to an Apple process, keeping Apple in control, yet giving developers some of the flexibility of developing their own background services.

The full details of the service have not been disclosed, and I’m not at WWDC to hear if any further details are given. I’ll be interested to see how they deliver this one.