Apple’s decision to refuse third-party developers from using background processes on the iPhone has been a regular sore-point in discussion of whether the handset is a “true smartphone”, and at first glance Rupert Goodwin’s article on the subject comes across as just more bile-bait. However, what differentiates Goodwin’s piece – once you look past his comparison of the iPhone to a 1981 IBM PC – is the fact that he offers some actual suggestions for how Apple could have handled the situation differently.
“If the design of the iPhone precludes proper always-on connectivity — which wouldn’t be the first time the company has gone for form over function — then have a decent scheduler, which understands the metrics of wireless access and makes intelligent decisions about when to allow what to connect. This does put the onus on application designers to understand the limitations and capabilities of such a channel and to create software accordingly, but then that is their job”Rupert Goodwins, ZDNet
“Whatever the reason [for denying background processes], it reflects badly on Apple. It’s either not as clever as it makes out, greedier than it likes to admit, more hemmed in by its design decisions than it wishes to make apparent or just determined to force its vision on the world regardless of what the world wants. Think different?”Rupert Goodwins, ZDNet
I’m in two minds about the restriction: part of me thinks it’s a mistake on Apple’s part, when as Rupert suggests there are other ways in which Apple could have achieved the same stability and consistency outcome, and part of me is looking forward to seeing what clever solutions developers come up with to deal with it all. The iPhone as a platform is unique, perhaps, in that its popularity and lust-factor will make sure coders still attempt to produce software for it, whereas similar limitations in a lesser device would probably see it ignored. That presents the opportunity for the cellphone to educate desktop development, rather than the more usual reverse; who wouldn’t prefer background apps on their computer to be less greedy with their memory and CPU cycle requirements?
(….) (….)
a sleeper post… but to quote ZDNet?
http://www.roughlydrafted.com/2008/03/13/iphone-20-sdk-the-no-multitasking-myth/
Its amazing how many people can actually sit there and trow rocks at the Apple .
its really easy to wait for something to come out and find things that are wrong with it but when it comes down to reality all those morrons that write stuff on new products and technology never actually invented anything I thinks it takes balls to compete in the tech world and I totally respect what Apple is trying to acheive ,sure there is going to be a couple of duds along the way but overall they are still way ahead of the game .
apple iphone is really amazing product
A suggestion for Goodwin, try to join Apple and get into their iPhone development team. Or write an app for Apple to use so that third party apps can be run in the background without consuming the power of the battery and processor.
The problem is that, sometimes, there’s not a good solution for the problem.
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…
Peter has a fantastic point.
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?
Thing is, Arn, how do I know whether I’ve got IMs waiting for me if AOL’s app has to close and can’t alert me to them? Gathering missed messages is only half of the problem, it’s doing something meaningful with them that’s the bigger issue.
This web is great make money shortening your links!! http://adf.ly/X8Wd
Excellent post. I was checking constantly this blog and I am impressed! Very helpful info particularly the last part :) I care for such information much. I was seeking this certain info for a long time. Thank you and best of luck.