Multitask-Masters: Hock vs. Alfke vs. Gruber

<

p>

iPhone_multitasking.jpg

Here we go with another hand of high-stakes SDK multitasking three-blogger stud. Commenters (as always) wild.

Craig Hockenberry, developer of Twitterrific for Icon Factory, opens with two reasons why he understands the current Apple-enforced no multitasking policy, power:

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.

And presentation:

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.”

Jens Alfke, who developed iChat for Apple before going indie due to creative differences over the importance of social software, sees power:

[... H]ow much less power does it take to leave the EDGE radio passively listening for packets, as opposed to sending them? [... M]y 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.

And raises on presence:

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.

(Be sure to hit up the original posts linked to above and read the comments for several bonus rounds of back-and-forth between the two and with others.)

John Gruber of Daring Fireball brings the hand to an end, calling:

I believe the number one reason why the iPhone OS doesn’t allow background processes is RAM. Battery life, CPU sharing, bandwidth — all of these are factors, too, but I think RAM is foremost. The iPhone only has just 128 MB of RAM and no swap space. A good chunk of that 128 MB goes to the OS itself and the built-in apps that do run in the background — Phone, Safari, and iPod. There really just isn’t much left over. If Apple were to just allow background processing now, what would happen is that background processes would often wind up getting killed by the OS at some point when the frontmost app needs more memory. From the user’s perspective, it would seem as though background apps inevitably mysteriously fail and stop running. You can argue that you’d rather have that than no third-party background apps at all, but it’s clearly a reasonable trade-off for Apple in terms of consistency and obviousness in the user experience.

Is Hockenberry right? Alfke? Personally I'm not betting against Gruber on this one. The iPhone is the first smart phone (can we call it that yet?) I've ever owned that didn't crash almost daily when making or receiving calls, and being a smart PHONE, that's the functionality I -- and it appears Apple -- is most concerned with. As things progress, Apple can always add functionality. It's far more difficult (and nightmarish from a PR standpoint -- right AirDrive Time Machine?) to take it away when it falls apart later.

Come June, when Apple lays all their cards on the table, we might just have a better idea. Until then, what do you think?

Have something to say about this story? Share your comments below! Need help with something else? Submit your question!

Rene Ritchie

Editor-in-Chief of iMore, co-host of Iterate, Debug, Review, Vector, and MacBreak Weekly podcasts. Cook, grappler, photon wrangler. Follow him on Twitter and Google+.

More Posts

 

0
loading...
0
loading...
0
loading...
0
loading...

← Previously

iPhone Risk: Sights Set on Singapore?

Next up →

Gaming: iPhone vs. Nintendo DS and Sony PSP

Reader comments

Multitask-Masters: Hock vs. Alfke vs. Gruber

12 Comments

So Jobs (or any CEO) should never change their mind, even when wrong?
There seems to be an air of "Jobs knows best" when these decisions are handed up from up high, and all the Apple fanboys spend the rest of the time thinking up reasons why his benevolentness has protected Apple users from the horrors of the big bad world again.
Jobs has been wrong before, so when a controversial decision is made, maybe the default position should be scepticism vs faith.
Surur

There is a theory (sometimes used to explain the apple mouse) that Jobs and Ive are so canny and correct so often, on the rare occasions they are wrong, the people around them just assume its them, and not Jobs et all who are mistaken. This is probably one of Apple's greatest weaknesses.
That they do change their minds and their course, except for that mouse(!), is one of their greatest strengths.

The iPhone only has just 128 MB of RAM and no swap space. A good chunk of that 128 MB goes to the OS itself and the built-in apps that do run in the background — Phone, Safari, and iPod.
Are there numbers for this somewhere? Would make Gruber's argument easier to judge.

The "no swap space" thing is clearly incorrect. The principle is right - no matter how much memory the OS is taking, 128 MB is not a lot of headroom. However, other phone OS's allow background processes even with 32MB or less available.

Although I think the point is that it doesn't work "well" from an end-user perspective on many other phones. I know my WinMob and even Treo became unstable as heck very quickly.

Although I think the point is that it doesn't work "well" from an end-user perspective on many other phones. I know my WinMob and even Treo became unstable as heck very quickly.
Actually when there's enough RAM (enough means about 128MB on WM) multi-tasking doesn't cause much problems at all.
Surur

Actually when there's enough RAM (enough means about 128MB on WM) multi-tasking doesn't cause much problems at all.
Surur
Agreed. After the first few versions of WM, they got it fairly stable (older versions used to run out of resource memory prior to running out of memory).

There are lots of other reasons for WM instability. :-) For example, it's pretty easy to write bad code on WM.