Multitask-Masters: Brain Surgeon Stat!

<

p>

iPhone_multitasking.jpg

The iPhone SDK will not allow 3rd party apps to multitask or run background services. We've previously covered both initial developer Twitter-rage at this, and pundit counter-points. We've also covered Craig Hockenberry before -- the man who (perhaps poetically) develops Twitterrific for the Mac and jailbroken iPhones, and is now bringing it to the SDK.

Hockenberry, via his furbo.org blog, shares his experience on iPhone development and his views on the multitasking (non-?) issue.

To be blunt, I’ve never seen so many experts without a fricken’ clue. If you haven’t written code using the jailbreak tool chain, your opinions on the iPhone SDK, based entirely on what you see in a simulator, just aren’t relevant. You might as well be explaining the nuances of brain surgery.

Wha-wha-wha-what? Please, allow Mr. Hockenberry to continue:

Twitterrific on the iPhone could definitely make use of a background process to gather new tweets. In fact, a prototype version of the software did just that. And it was a huge design failure: after doing XML queries every 5 minutes, the phone’s battery was almost dead after 4 hours. In fact, the first thing I said after giving Gruber this test version was “don’t use auto-refresh.”

Hockenberry goes on to discuss the power demand problem of the radios, both EDGE and Wi-Fi, and the danger of even well-intentioned developers getting individually reasonable but collectively overwhelming access to background services. He does, however, expect that in a future release Apple may include some method of notifying network apps that the radios are being used (for example, by MobileMail Touch), and allowing brief TCP/IP connections during that period. Bottom-line, at the OS's discretion, not the individual apps'.

Sound reasonable? Sound crazy? Should Apple give unfettered access to everyone immediately an trust users to sort through it themselves? Or should Apple be as strict as possible from the get-go? What do you think?

Rene Ritchie

Editor-in-Chief of iMore, co-host of Iterate, Debug, ZEN and TECH, MacBreak Weekly. Cook, grappler, photon wrangler. Follow him on Twitter, App.net, Google+.

More Posts

 

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

← Previously

Web App Review: Pimp My News!

Next up →

Down the Rabbit-Hole: From Treo to iPhone

There are 13 comments. Add yours.

surur says:

The iPhone has a serious problem in the power management which Jobs is so proud of if polling for a small snippet of data every 5 minutes results in draining a 1400 mAh battery in only 4 hours.
As usual people blame the technology vs the iPhones poor implementation for the problems.
Multi-tasking is fine. The iPhone needs brain surgery.
Surur

Dieter Bohn says:

I tend to agree with Surur that multitasking shouldn't be that big of a battery drain.
It's funny when you think about it - Windows Mobile *DEFAULTS* to leaving stuff OPEN in the background unless you explicitly close it....

Rene Ritchie says:

Dunno. My experience with WinMob involved really poor battery life and an almost OCD-like paranoia about killing apps because the system always seemed so sluggish.
And I think Hockenberry is referring to multitasking in the sense of background services hitting the radios.
The fact that the iPhone can (for me) run for more than a day with Bluetooth, Wi-Fi, and media running as background apps means that OS X mobile has some serious power management chops. (I had to turn off Bluetooth all the time on my Treo for it to last a day, and that didn't even have Wi-Fi or decent media).
What Hockenberry is pointing out is that 3rd parties, who unlike Apple do not have an OS-centric or UE-centric view, but an individual app-centric view, may not manage power as well or judiciously as Apple, especially when you have multiple 3rd party apps trying to hit all those services all at once (or staggered).
So far I'm appreciating Apple's conservative approach on that score.

Bri Guy says:

Having been a former long-time Palm/Treo user, multitasking is not a big deal to me. The most important issue, at least for me, is whether or not an interrupted app (i.e., receiving a phone call while in the midst of using an app) will resume seamlessly or if data loss will occur.

AnteL0pe says:

Their needs to be some balance between the failed WinMo implementation of just leaving everything open unless explicitly closed and the limiting Palm method of only allowing a single app at a time. If the solution is to collect background internet data requests into a shared window, thats fine as long as that has a beneficial impact and provides a reasonable user experience. If background apps need to "sleep" when the phone is active or whenever the stock apps (or any app for that matter) need more processing power then so be it. I'm sure the developers will be able to work within those kind of limits.

surur says:

Dunno. My experience with WinMob involved really poor battery life and an almost OCD-like paranoia about killing apps because the system always seemed so sluggish.
And I think Hockenberry is referring to multitasking in the sense of background services hitting the radios.
So far I'm appreciating Apple's conservative approach on that score.
Are you seriously telling me your WM phone would die in 4 hours if you set it to poll e-mail every 5 minute?
Apple is very good with illusions. They gave the illusion of having good power management, but when exposed the harsh reality it proves rather the poorer. Doesn't the e-mail client only poll every 15 minutes at the minimum? Now they want developers to give the illusion of multi-tasking when thats far from the case.
Surur

Rene Ritchie says:

You're giving a single-tasking example, email. (And as a matter of fact, when I switched my Treo to ActiveSync exchange push, the battery drained *significantly* faster all by itself. Adding in BlueTooth killed it before end-of-business).
It's not email every 15 min. It's email (ME + GM + YM + ?) + IM (AIM + WM + GT + ?) + XML (Twitter + Jaiku + Facebook + LinkedIn + ?) + next big wannabes (corelocation dating, social wine tasting, etc. etc. etc. etc. etc.)
Turn everything on continuously on any device (much less WinMob!) and you don't have any management to do of the power. You just have constant drain.
So far Apple seems to be the only OS maker who remembers it's a mobile *phone*

surur says:

You're giving a single-tasking example, email. (And as a matter of fact, when I switched my Treo to ActiveSync exchange push, the battery drained *significantly* faster all by itself. Adding in BlueTooth killed it before end-of-business).
It's not email every 15 min. It's email (ME + GM + YM + ?) + IM (AIM + WM + GT + ?) + XML (Twitter + Jaiku + Facebook + LinkedIn + ?) + next big wannabes (corelocation dating, social wine tasting, etc. etc. etc. etc. etc.)
Turn everything on continuously on any device (much less WinMob!) and you don't have any management to do of the power. You just have constant drain.
So far Apple seems to be the only OS maker who remembers it's a mobile *phone*
Thats not the claim. The claim is that on the iPhone, simply activating the network every 5 minutes drains the battery in 4 hours.
I am saying no WM phone is as bad as that, and that therefore WM power management is better than the touted "advanced" power management of the iPhone.
Surur

Rene Ritchie says:

Not really following you. At most you could say "3rd party hacks on jailbroken iPhones that accessed the network every 5min. drained the battery in 4hrs."
Again, real world, the iPhone has thus far trumped battery life on both my old WinMob and Palm devices, and done so with more functionality (WiFi) and heftier multimedia specs (including a far bigger screen).
No comparing Apples to prunes now... :)

surur says:

Not really following you. At most you could say "3rd party hacks on jailbroken iPhones that accessed the network every 5min. drained the battery in 4hrs."
Again, real world, the iPhone has thus far trumped battery life on both my old WinMob and Palm devices, and done so with more functionality (WiFi) and heftier multimedia specs (including a far bigger screen).
No comparing Apples to prunes now... :)
So, do you accept this guys argument or not.
Either Hockenberry does not know what he is talking about, and cant program his way out of a paper bag, and his experience with his twitter client is not indicative of the effect of background network access, at which point one questions why you posted the article.
Or he is talking sense, and on the iPhone network access really drains the battery, and the iPhone has poor power management.
Which is it then?
Surur

Rene Ritchie says:

"Do you still beat your wife?" Nice.
I agree with Hockenberry that unrestricted access to the radios by any developer will lead to power problems (because it becomes unmanaged, much as happens with WinMob today). I'd also add my own security concerns to that as well.
What developers want and what they need are not always the same thing.
(Remind me, if I don't remember, how multiple network radio access was managed on WinMob 1.0 and what the success rate was with early SDK developments?)

surur says:

"Do you still beat your wife?" Nice.
I agree with Hockenberry that unrestricted access to the radios by any developer will lead to power problems (because it becomes unmanaged, much as happens with WinMob today). I'd also add my own security concerns to that as well.
Its NOT unmanaged. The user should be able to measure the utility of the 3rd party app vs the powerdrain it causes. Its a pity Apple consider most of its users dunces.
(Remind me, if I don't remember, how multiple network radio access was managed on WinMob 1.0 and what the success rate was with early SDK developments?)
When WM 1.0 came out, PDA's did not have radios at all.
Look, no keyboard and a grid of icons!! Its clearly a rip off of the iPhone!!!
Surur

Rene Ritchie says:

For now, if you want tinker-ware you need WinMob just like if you want a tictac keyboard you need a Treo/WinMob/BB.
(reminds me of old tech support joke about Mac being yes/no and PC being maybe but...)