Monday, June 23, 2008

iPhone Push Notification - Doesn't Solve My Problem

The recent Apple WWDC heralded the arrival of Push Notification for third-party applications on the iPhone, which we can probably expect in the 2.0 release of the iPhone (and maybe the iPod Touch?) software. Much of the focus of the keynote presentation that covered this topic was the use of these notifications for social networking applications. If you have the infrastructure set up to run a server and send out these messages via Apple's exclusive link to the phone, then I think it's clear that the notifications will obviate the need for a background process. However, this only works for applications that fit one particular model.

Working in biomechanics, I'm interested in seeing the iPhone used as an activity monitor. The existence of both an accelerometer and the Core Location APIs means that the phone has all the ingredients of a basic fitness computer. Indeed, someone has already written a pedometer application, showing that this sort of functionality is possible. Whether or not it is practical is yet to be demonstrated, but unfortunately we can't properly develop fully-fledged versions of such applications anyway... read on.

Imagine some hypothetical software on your iPhone... let's say you go jogging and you use a personal fitness program designed for runners. The program uses Core Location to establish your initial position and logs your route. It uses the accelerometer to count your steps. With this information, it can give you speed, cadence and stride length statistics, it can tell you about the hills you've climbed, and even without heart-rate data it can evaluate your general fitness. The application could also log all of this data, so that you can see your training schedule and how you progress over time. All of this on a phone that fits in the palm of your hand! However, the dream ends as soon as you receive a phone call or want to listen to music while you run. If you do anything like this, you effectively end the application, and its logging will be suspended until you activate it again. Such interruptions would make the use of the program and the phone mutually exclusive of each other.

This is just one example of an application which, if it is to run on the iPhone, will need to be able to set up a true background process. You can't get around this kind of problem with push notifications. I agree with Apple that we shouldn't use background processes to listen for instant messages or to achieve background downloads. These can be done using callback mechanisms, whether they're server-pushed notifications or API hooks that Apple may provide. Also clear is the fact that an application like the one I've described above will be processor-intensive and will drain your battery relatively quickly. But just imagine how great it would be! I'm relatively sure that the iPhone battery would be able to cope with logging for the periods of time that most of us are actually capable of running. I hope Apple eventually gives us the ability to run true background processes, for times like this, when we actually need them.

No comments:

Post a Comment