Most of the issues/complaints people have raised about a lack of background tasks involve monitoring or collecting data from the internet while “minimized” in the background. Isn’t that a task better served by a server? (where, once launched, the app quickly checks in with a server to update itself on what it missed while the app was shut down).

The chat example is perfect. Why can’t AOL’s servers grab the messages I missed while I was using another app, and fill me in as soon as I get back to AOL’s app?

Consider a chat program, as a fun example. You connect to the chat server and as long as you stay connected, you are considered “on line” and able to send and receive messages. As soon as you disconnect, you are no longer “on line” and people cannot send messages to you. If your computer crashes or your network goes out or whatever, the network says you disconnected. Thus, the developer doesn’t have to write code to determine whether you are “connected”–the network does it for you.

Perfectly reasonable design decision, right?

The problem is that in order for a wireless device to do this, it has to stay “connected”, which means it’s radios have to stay on. So when you connect to the chat server, it’s the equivalent of making a phone call. While there may not be any data going over the line, the radio cannot turn off because then the other end would receive a “disconnect” signal over the network and you would no longer be “on line.”

No amount of creative iPhone process scheduling on Apple’s part is going to solve this dilemma. If your protocol demands that you must be connected in order to receive messages, those radios have to stay on. If those radios stay on, you’re going to have to eat the power. Which means your battery life will stink.

So I understand Apple’s desire here. First, Apple is “sponsoring” (for lack of a better term) the iPhone App Store. Joe Customer goes to the iPhone App Store and buys cool chat software for $29.99. He installs it on his phone, fires it up, connects, and is able to receive messages from all his buddies. Four hours later, his battery is dead. Who’s he going to blame? The guy who sold him the software? That was Apple. The guy who made the phone? That was Apple. Himself? Please…this is America: We don’t take responsibility here! ;^)

“Why did Apple sell me such crappy software! I want my money back!” he’ll complain–and rightly so. So now we need uninstallers–to get the software off the phone. We need some way to do refunds. And Apple needs some way to recreate a happy customer again…

So I understand where Apple is coming from. That said, the “no daemons” rule is a pretty inflexible way of solving the problem. There may be protocols that don’t have the problems of the chat protocol I described. There are ways of working around the problems of the chat protocol I mentioned. And since Apple is the ultimate distributor of applications, the control could be put there with some guidelines to developers for how much of the battery they’re allowed to use.

I’m definitely interested in seeing how this works out–especially since I have a “killer app” I would love to write but it will require a daemon to be effective…

a sleeper post… but to quote ZDNet?

http://www.roughlydrafted.com/2008/03/13/iphone-20-sdk-the-no-multitasking-myth/