I bow to my esteemed colleague Craig Hockenberry’s greater experience in iPhone development; but I must disagree with his take on the infeasibility of background applications. He gives two reasons why networked apps shouldn’t run in the background — one technical and one user-interface.
Battery life.
The heart of the problem are the radios. Both the EDGE and Wi-Fi transceivers have significant power requirements. Whenever that hardware is on, your battery life is going to suck. My 5 minute refresh kept the hardware on and used up a lot of precious power. *
My immediate response is that, yes, polling is inefficient. Everybody knows this; but it’s also easy to implement, which is why way too many protocols use it. Normally the problems with polling first manifest as scalability problems on the server (as Twitter quickly discovered), but in the case of mobile devices, polling kills battery life.
So it’s a good thing that none of the real instant-messaging services poll. AIM, Jabber, MSN, Yahoo and ICQ all open a socket at login and leave it open, sending data only when necessary. If you suppress buddy-list updates while the app isn’t active, then data only needs to be sent when you send or receive an IM.
The remaining issue is one I don’t have the technical knowledge to answer: how much less power does it take to leave the EDGE radio passively listening for packets, as opposed to sending them? (Anyone who knows, please comment.)
One possibility is that it’s the same standby state the radio is already in (since obviously it has to be listening for incoming cellphone calls and SMS messages), so it incurs no extra battery drain. That would make non-polling background network services like IM clients totally feasible.
The other possibility, though, is that even listening for EDGE IP packets uses a lot of power. Which would be bad news, as it makes any background notifications other than phone calls and SMS impractical. But I don’t really believe this is the case — because if it were, how would the iPhone’s upcoming “push email” support for Microsoft Exchange work?
(Moreover, I have to point out that my prior cellphone, the T-Mobile Sidekick, had excellent AIM support, as well as push email, from day one, so it clearly is possible. The Sidekick’s battery life was decent, with maybe 3/4 the standby time of my iPhone.)
User-interface clutter.
From Craig’s second post:
You now have five independent sources for notifications. How do you let the user know which one is which? One might say, “make the sound different.” Another might say, “make something flash in the status bar.” Someone else might say, “make the phone vibrate.” Or even, “put up an alert box.” A truly sick individual might say, “Do all four.”
Can you see where I’m going with this? Your phone soon becomes a fricken’ pinball machine as multiple applications fight for your attention. With 24 notification permutations for every application, things will quickly get out of hand. *
I don’t buy this at all. In fact, I think it’s paternalistic. Yes, user interface design has to consider unintended consequences of users’ own actions, but this is a situation where the consequences are entirely obvious to the user: the more notifications you turn on, the more distractions you’ll get. The remedy is just as obvious: if you end up with too many distractions, you turn some of them down or off by using the exact same steps you used to turn them on in the first place.
I don’t mean to put words in Craig’s mouth, but I think that between the lines, that quote says: “You’d be able to turn on so many notifications that I would find it intolerable.” He’s dismissing a huge swath of functionality because it could be overused in ways that he personally would not want on his phone. That’s not a valid argument.
[It is, however, the kind of thing that’s already gone on with Apple’s own iPhone apps. My pet peeve is that the calendar’s alarm cannot be customized. It’s hardwired to emit two pathetic little bleeps, and that’s all, whereas phone ringtones are customizable and repeat. Clearly this was designed by and for people who have no problem remembering to attend meetings, and never procrastinate appointments, but will drop everything to answer the phone. Unfortunately I am completely the other way around, and I’m sure I’m not the only one.]
There’s also considerable irony here, in the fact that Craig’s best-known application is a client for Twitter, the service that is today’s poster child for “constant annoying notifications”. Clearly, then, he finds Twitter’s level of intrusiveness tolerable, whereas I generally don’t (I have an account but almost never use it.) On the other hand, I do find instant messaging invaluable, and mourn the loss of the mobile AIM presence I used to have on my Sidekick. Not that I got a lot of IMs while away from the computer; but the ones I did get, or sent, were often important to me. Chacun a son gout.
Gloomy conclusions.
I’ll end this with two spot-on quotes. First, from developer Hank Williams:
Prohibiting background processing is not just a question of one feature being left off a long list of otherwise very well executed features. The issue of background processing is the issue for a mobile device because it is key to two things:
• telling the world about your status in some ongoing way
• receiving notification of important events
These two things are the key to most new real innovations in the mobile space.
And c|net’s Tom Krazit’s response:
That makes sense; remember that friend or relative who got a mobile phone but never turned it on? That practice greatly diminishes (although some might say it enhances) the value of a mobile communications device, and one-way communication is not what has made the Web so interesting in its second decade.
Bingo. I’ve been obsessed with what we now call “social software” for over a decade; and the iPhone SDK doesn’t give us the full functionality we need to do this kind of stuff. Basically, the iPhone has blinders on, like a cart-horse: if it’s not already looking at you (in your online manifestation) it can’t see you, and you can’t get its attention. That’s great for a cart-horse, but it’s death for any kind of social interaction.
As I said above, I am aware of the technical issues (and would like to understand the details better). There may need to be work done to allow multiple applications to receive background notifications, in a practical manner. For all we know, Apple may already be working on this. But of course we have no way of knowing, because, in typical Apple fashion, they will absolutely refuse to admit the existence of the problem, much less any efforts to work around it, until they have a complete solution to spring on us. Unless of course they just don’t care; entirely likely, since quite a lot of people upstairs at Apple don’t seem to ‘get’ social software at all. We just have no way of knowing…
