Background Tasking and Battery

[MacRumors]

http://www.macrumors.com/images/macrumorsthreadlogo.gif (http://www.macrumors.com)

Twitterific's (http://iconfactory.com/software/twitterrific) author, Craig Hockenberry, notes (http://furbo.org/2008/03/16/brain-surgeons/) that enabling background tasks for an iPhone version of Twitterific resulted in battery drainage in 4 hours.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.
This information provides some perspective on Apple's decision to limit background applications from running on the iPhone.



Article Link (http://www.macrumors.com/iphone/2008/03/17/background-tasking-and-battery/)

[Telp]

Webapps do the same thing. Seems to me people should be able to worry about it themselves, im thinking mostly of AIM. That should run in the background, and i know its gunna waste battery, thats my problem.

[arn]

Webapps do the same thing. Seems to me people should be able to worry about it themselves, im thinking mostly of AIM. That should run in the background, and i know its gunna waste battery, thats my problem.

I agree it should be user selectable.

arn

[ChrisA]

Webapps do the same thing. Seems to me people should be able to worry about it themselves, im thinking mostly of AIM. That should run in the background, and i know its gunna waste battery, thats my problem.

A smarter design would be to create an AIM server. That would be a big computer in a data center that is always on 24x7. When your AIM client is active in the forground the first thing it does it suck up any messages from the AIM server. Then when you kill your AIm client the last thing it does before it dies is redirect any messages to the AIM server. The user would think the client was running in the background.

How to pay for the server? The user pays for the client and some portion of that goes to a hosting company.

[MichaelLatta]

The reason for background communications is to have it be able to interrupt what you are doing or notify you of a message. To make the AIM scenario work it would need to text message or email you to get the Apple provided app to let you know there was a message waiting. That is way sub-par.

I think Apple needs to have some user control over radio use, and over background apps, but that is not the same as only allowing Apple apps in the background. I am sure that market pressure will move things in that direction in time. It may also be that Apple will support background apps but with a more stringent validation requirement.

[Buschmaster]

A smarter design would be to create an AIM server. That would be a big computer in a data center that is always on 24x7. When your AIM client is active in the forground the first thing it does it suck up any messages from the AIM server. Then when you kill your AIm client the last thing it does before it dies is redirect any messages to the AIM server. The user would think the client was running in the background.

How to pay for the server? The user pays for the client and some portion of that goes to a hosting company.
Many-a-client already act this way, in their own way.

When I log into FlickIM I get my messages that I missed. I think what people want are the alerts.

[Telp]

Many-a-client already act this way, in their own way.

When I log into FlickIM I get my messages that I missed. I think what people want are the alerts.

Thats what i want. No use having the messages if i dont know about them.

[jacobhb]

A smarter design would be to create an AIM server. That would be a big computer in a data center that is always on 24x7. When your AIM client is active in the forground the first thing it does it suck up any messages from the AIM server. Then when you kill your AIm client the last thing it does before it dies is redirect any messages to the AIM server. The user would think the client was running in the background.


You mean email? :)

[bravedeer]

To have AIM contacting the server if the iPhone is asleep in our pockets. In my opinion, SMS works better for alerts/important messages.

What I did wish is that I could still use other apps with AIM running.

[naroola]

I have an iPhone (personal) and a blackberry (work-provided). I run GTalk natively on my Blackberry all day (use is occasionally, but I'm logged on in the background) and I don't see much of a battery drain on the BB. I don't see why Apple/AOL can't make the iPhone work similarly.

[Phobophobia]

I have an iPhone (personal) and a blackberry (work-provided). I run GTalk natively on my Blackberry all day (use is occasionally, but I'm logged on in the background) and I don't see much of a battery drain on the BB. I don't see why Apple/AOL can't make the iPhone work similarly.

maybe the blackberry has a better battery

[Curtis72]

I have an iPhone (personal) and a blackberry (work-provided). I run GTalk natively on my Blackberry all day (use is occasionally, but I'm logged on in the background) and I don't see much of a battery drain on the BB. I don't see why Apple/AOL can't make the iPhone work similarly.

Do you actually know that it is running in the background?
Being logged on doesn't mean the client still is running. Just that the session on the server is still active.

[lord patton]

does this mean twitter was accepted into the developer beta (since they have tested on a phone requiring v2.0)?

[neven]

does this mean twitter was accepted into the developer beta (since they have tested on a phone requiring v2.0)?

Hockenberry is talking about his unofficial, hacked-iPhone Twitter client. It's neither made by Twitter nor is it an iPhone SDK product.

Web apps don't run in the background. If you set a page to refresh, it will not be doing so when you're not running Safari.

It's disingenuous to say that Apple should just let users make the choice. If you actually read Hockenberry's post, you'll see he has examples of situations where the typical user would have no idea what app was draining their battery and how - they'd just know that their iPhone was all of a sudden acting like a 5-year old first-gen iPod.

You always have the choice of hacking your iPhone, running Installer, and installing FlamingMonkeyPoo 2.0 if you want. Apple won't come into your house and stop you from doing it, but don't expect any help from them either.

[yoman]

Wirelessly posted (Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en) AppleWebKit/420.1 (KHTML, like Gecko) Version/3.0 Mobile/4A102 Safari/419.3)

As arn said earlier it should be user selectable. Maybe with a warning that battery life will suffer while in this "background" mode.

[Telp]

Wirelessly posted (Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en) AppleWebKit/420.1 (KHTML, like Gecko) Version/3.0 Mobile/4A102 Safari/419.3)

As arn said earlier it should be user selectable. Maybe with a warning that battery life will suffer while in this "background" mode.

I was thinking the same thing with a battery life warning when going to instal the apps. It would make sense, and you could no longer complain to apple or the developer. All problems solved.

[nagromme]

"And right about now, you’re thinking “But I’ll be smart about how I use the hardware.” Sorry, bucko, but you’re the exact reason why we don’t have background processing in the current SDK. You’re living in your own little dream world.

What happens when App A uses the network at 5 minutes past the hour, and App B uses it at 10 minutes past, and App C uses it at 15 minutes past, and so on? There’s no way for you to know what other apps are doing is there? And yet the battery is still taking a pounding."

Very convincing. Very, very few users would actually CHOOSE to have their phone to die (no calls in or out!) in no time flat. Or choose to have their music/movies die early. The risk would sometimes be just that great--and worsening as devices age--and it's not a risk users can make a fully INFORMED choice about if they don't know exactly what multiple apps are doing relative to each other. User choice is not a good option, and Apple WOULD be publicly crucified for giving users such a choice. Much worse, I expect, than they'll be attacked (tempest in a teacup) for not giving the choice--considering that people are already very satisfied with their iPhones before ANY 3rd-party apps have been officially offered.

The end of the article suggests a clever technical solution, coordinating multiple apps at a lower level, but rightly points out that expecting such a solution in the first beta SDK isn't realistic. The SDK and iPhone OS are greats tool already, but that doesn't mean new features won't be added to them in time.

I was thinking the same thing with a battery life warning when going to instal the apps. It would make sense, and you could no longer complain to apple or the developer. All problems solved.

I don't think a warning and a choice is the effective, simple fix some people are imagining.

People WOULD still complain, a lot. And then the press would exaggerate the complaints further. The reality of the situation would mean little.

And the fact is that saying "Yes" to the warning would be a poor choice for most people, when you start talking more than one app bought for the same phone. So it would need to be a very direct and clear warning, enough to STOP most people (who are not tech-heads like us) from going ahead. And it would need to be presented clearly every time you consider an app--not just hidden in the Terms of Service. Nor could Apple show the warning only once--on the first background app you buy, or on a single global setting that allows/denies all apps to run in the background. That would be a warning people would see once (and probably not give their full attention to) while exploring a million other things on their new device, and then they'd forget about it. And then when they go to buy an app, if that warning does not re-appear, tons of people later on will accidentally either do something that could kill their talk time, or else will pay money for an app that they can't fully use. One that can't really do what's expected unless the background option is enabled.

A clear, informative notice might be something like "WARNING - this app may have harmful results for many users: installing this app, especially in conjunction with other apps, may greatly reduce your device's battery life, possibly to the point where it no longer functions acceptably for your needs. You purchase this app at your own risk, and Apple will not provide recourse or support if the device's battery performance becomes unacceptable."

Should such a warning be presented before or after purchase? Before would mean people browsing apps would get the frustrating impression that Apple was allowing lots of "bad apps" in their store that they get warned away from. After would be worse. And either way, Apple would have to spend time CHECKING every app (or doing programming modifying the SDK to automate this) to see if each app earned the warning or not. You can't give the warning for ALL apps or it will be ignored, a la Vista security. And you can't be on an honor system where developers voluntarily say whether their app should have a warning (one that would slash sales) or not.

Then, if the warning IS clear enough to be effective for non-techie users, you would have the backlash from developers objecting to the warnings. This too would be blown out of proportion by the press. (In fact, even a vague and nearly useless warning would cause some developers to raise a stink. No matter how few, the press would make it sound like a major uprising.) Then we have the press not only scaring off Apple customers, but worse: scaring off would-be developers!

And then there would be the battery-life bad press: "my 2-year-old iPhone dies in less than an hour of talking!"--situations resulting from apps that may have shown warnings "way back when," but later on, when battery life becomes unacceptable, will the aggrieved party remember the warnings and say "oh well, my bad" and remove the apps? Or will they rant loudly and get quoted by the Associated Press in articles that mention iPhone battery life but never mention 3rd-party background apps at all?

And when a user or developer who REALLY wants a certain background app tries it on a brand new iPhone with no other such apps, and gets acceptable talk times, of course that rosy best-case situation will be passed on to other would-be buyers of the app. But then one day the battery consequences will still happen, and some users will see a worst-case instead of a best-case.

It's just too complex a situation for Apple to solve simply, as much as I would love it to be otherwise. This is a very real, practical battery life concern. And I really don't see any way that mere warnings could prevent everyday users (not us tech-focused form-goers) from getting really mad--with resulting bad press on a large scale.

And don't forget the possibility that other iPhones and touch devices may be coming--and some may have less battery life to spare. 3G phones. Maybe smaller phones. Certainly, one day, smaller iPods. (Which would spend battery trying to find WiFi even if none is available--and for many people, WiFi IS available all day, both at work and at home.)

Now, I can certainly understand some people wanting a device that doesn't hold their hand, and lets them trash the battery at will. But they already have a choice: choose a different platform. (Which might include jailbroken iPhones, for that matter.) But I think MOST people--who don't crawl tech forums, rant on developer blogs, and the like--the everyday people who make calls, surf the Web, listen to music, watch TV shows, and love that their iPhone/iPod "just works"--will actually benefit from Apple's no-background-apps policy. These are the people who will make the mobile OS X platform far bigger and more mainstream than any PDA, smartphone, or ultramobile platform has ever been. They'd love to get instant AIM notifications, but they love their talk time more, and are used to having no AIM (or whatever) on the go--so AIM with limitations will still be welcomed. This huge group won't suffer much from having to touch the AIM button before AIM (or whatever) is functional.

A technical solution at the OS level may be doable--there would still be battery loss, but less so. That's not simple either, and will have to evolve with time. Remember how surprised developers seem to be with just how capable the SKD already is. Apple hasn't wasted their time, but they can't deliver everything immediately. Eventually we may have our cake and eat it too! I certainly hope people keep Apple aware of the demand for background apps.

[notnek]

I was thinking the same thing with a battery life warning when going to instal the apps. It would make sense, and you could no longer complain to apple or the developer. All problems solved.


I agree.

[thejadedmonkey]

Twitterific's (http://iconfactory.com/software/twitterrific) author, Craig Hockenberry, notes (http://furbo.org/2008/03/16/brain-surgeons/) that enabling background tasks for an iPhone version of Twitterific resulted in battery drainage in 4 hours.
This information provides some perspective on Apple's decision to limit background applications from running on the iPhone.

Well then something else in the iPhone is sucking the battery dry, because my Sony-Ericsson phone can stay on AIM for well over 24 hours with light phone use.

[naroola]

Do you actually know that it is running in the background?
Being logged on doesn't mean the client still is running. Just that the session on the server is still active.

It's definitely up and running in the background. Anytime someone sends me an IM, I get it instantly. If any of you have a Blackberry, try it out yourself... it's a free app.

[nagromme]

Well then something else in the iPhone is sucking the battery dry, because my Sony-Ericsson phone can stay on AIM for well over 24 hours with light phone use.

Good to know. I do think technical solutions may be hoped for.

But the average user will likely expect more than just one day of standby time--and if you say "light" phone use then that means LESS than a day of standby with moderate or heavy use. Not acceptable to many people.

For comparison, Apple advertises up to 8 hours talk time (and several reviewers found it even better) or over 10 days standby. Split that in half and you get 4 hours talk time with 5 days standby. That's a lot better than your Sony-Ericsson gets running AIM, if I understand your report. (Many smartphones have poor battery life, which is one reason you see people with a phone PLUS a BlackBerry--but the iPhone is an exception. That's one of the factors that is helping it make "smartphones" mainstream, and not something Apple should tamper with lightly. Especially if the coming 3G models are power-hungry.)

Also, as the article in question notes, the problem compounds when running MORE than one background app. If they access the network at different intervals, then the radio ends up being powered on much more of the time. Your AIM app may power up the radio for brief intervals, but as you install more apps the problem could increase--in ways it's difficult for anyone (much less the average phone user) to predict and understand.

[perkelation]

I'm not so sure if we should believe Mr. Twitterrific... I have plenty of apps running in the background on my jailbroken iPhone. (Like IMAPidle)

And my iPhone lasts all day. And you shouldn't expect more than that... who said something about 5-10 days of standby time? you must be crazy. Any smartphone that I've had, I've needed to charge every night.

AND... the iPhone OS is running stuff in the background too !! Like, checking my email every 15 minutes. I'm calling BS... and maybe this Hockenberry guy can't code for ****. I mean look at Twitterrific... it's popular only because there's nothing better. And it sucks.

(I wouldn't mind seeing that mobile version, however) =D

[stevin]

Correct me if I'm wrong *which i very well might be* but isn't the major difference between push email and imap/whatever the iphone supports right now that push email will actually "push" the email from the server to your phone so you get it right away (why the blackberry is useful)...

Didn't I read somewhere that apple licensed active sync from microsoft which also some sort of push type email service? if thats the case then however that works should be the same way that aim could/should work.

I honestly couldn't care much about anything running in the background other than a chat app.

I can live with autochecking email every 15 min but even thats a pain in the *** sometimes.

[matticus008]

Well then something else in the iPhone is sucking the battery dry, because my Sony-Ericsson phone can stay on AIM for well over 24 hours with light phone use.
The mobile phone client doesn't use a constant data connection. It operates like SMS for the handset models that have licensed it, for exactly this reason (and to time-delay messages while using the voice radio).

The situation is similar with the Blackberry client, and it does not, in fact, maintain a constant connection in the background as claimed by some here. Instead, it's based on Blackberry push. The particular features are carrier and device specific for cell phones and smartphones.

The issue, of course, being that the official AIM client for these devices is not the same as a regular data-based IM app that might be written by a developer. It's also the reason why the official AIM client for iPhone will likely work with the same comprehensiveness as on the Blackberry. Again, the AIM client is not a background process on any mobile device on the market. That people are complaining about it without really understanding the effects of the limitation or the (relatively minor) differences between the iPhone approach and the Windows Mobile or Symbian approaches is telling, but I suppose not surprising.

[GekkePrutser]

And we have to believe that from someone that calls the iPhone a 'satellite phone'?

I agree that WiFi is heavy on battery but the EDGE radio shouldn't be (or even switched down into GPRS mode, it's all that's needed in most cases).

Consider similar devices such as blackberries and others. On my Nokia E60 I get a battery life of 1 day while constantly logged into my email inbox using imap idle (with mail turned off it was still less than my iphone gets). By the way, the blackberry does use push but in order to receive the push messages, it does have to keep the GPRS connection active.

I think he's just not doing something right, maybe he's sending too many updates over the network, or the XML decoding routines are too big. It could also be that they're not using the sleep mode of the CPU. But the edge radio really shouldn't be killing the battery in 4 hours with just a few IM's coming in and out.

[freediverdude]

Hey, if I jump start my car with the iPhone, will that reduce the battery life to 4 hours? And if so, do the iJumpercables have an HDCP authentication chip in them, so I can't also transfer movies to the in-car entertainment system? Hehe, ok, so I'm tired and silly today......

[dvkid]

Could Apple not implement some sort of core service that handles "background" processes. In a similar fashion to how some PHP scripts place all MySQL database calls into one call to make database usage more efficient, could Apple not have a service that a program that would need "background" functionality could call and this would, at a user selectable interval (30 sec, 1 min, 5 min, 10 min, etc.) look for every "background" process that needs to be run and run it in a single burst of radio activity. As opposed to one app getting radio activity every minute and another app getting radio activity every 30 seconds creating an upswing in radio usage.

[iLeoMarc]

A smarter design would be to create an AIM server. That would be a big computer in a data center that is always on 24x7. When your AIM client is active in the forground the first thing it does it suck up any messages from the AIM server. Then when you kill your AIm client the last thing it does before it dies is redirect any messages to the AIM server. The user would think the client was running in the background.

How to pay for the server? The user pays for the client and some portion of that goes to a hosting company.

If I am not mistaken ATT and AOL already has a deal in place. This keeps aim constantly alive within a server as well as sent notification when a message has been received. The only problem is that ATT charges for the Instant Messages, which makes it similar to SMS Text. Now if ATT makes this AIM client within the same bounds, then how many people will actually use it and pay monthly for it?

Note: Not all AIM phones are based on this bound, only those who come with AIM pre-installed within the phone.

[ert3]

This sort of lends its self to the whole adobe wanting its own PDF reader on the iPhone before flash support can be incorporated.

Sure flash only kills battery when in use but the PDF reader would have to remain working in the background in-order to make it appear as snappy and quick as the other iPhone apps.

Thusly killing the battery as we all know adobe would sneak in some spyware

[kingtj]

I know, for example, I downloaded the RSS reader software for the iPhone a while back, and configured it to update the list of feeds every 5 minutes. Right after that, I discovered that by the end of the workday, my battery was almost dead. Before that, it would typically still be around 80% or 90% charged, if I didn't talk much on it.

There's probably a "threshold", where you can run a background app that polls the Internet infrequently enough so the wi-fi (or edge) circuitry still gets to go to sleep between polling events. But doing it too often apparently leaves the radio running *all the time*, and drains the battery excessively quickly.

IM clients are probably notoriously bad for leaving the radio in an "always on" state, since unlike email checking, they're going to be polling more often than once every 15 minutes or so.

I think I like the guy's idea who mentioned SMS. How about an IM client that runs in the foreground like normal, but when you exit the program, it sends info to that effect to a "middle man" server. If you exit, telling it you wish to appear "online" to people still, it tells the server in the middle to keep up that appearance and to cache new incoming messages for you until you return. When new ones DO come in, it could use a single SMS message to notify you that you have new IMs to pick up.


I'm not so sure if we should believe Mr. Twitterrific... I have plenty of apps running in the background on my jailbroken iPhone. (Like IMAPidle)

And my iPhone lasts all day. And you shouldn't expect more than that... who said something about 5-10 days of standby time? you must be crazy. Any smartphone that I've had, I've needed to charge every night.

AND... the iPhone OS is running stuff in the background too !! Like, checking my email every 15 minutes. I'm calling BS... and maybe this Hockenberry guy can't code for ****. I mean look at Twitterrific... it's popular only because there's nothing better. And it sucks.

(I wouldn't mind seeing that mobile version, however) =D

[njchris]

Agile Messenger on my Treo 700wx was left active all day. The only time the battery goes faster is when I was messaging a lot.

[sdeluca]

Batterie perspective woudn't be the only one issue. As mentionned in this article http://boursomac.com/article/819 whenever twitterific should use the radio, your incoming call will be missed :(

[pauldy]

Who is he trying to fool. People make all types of compromises based off their wants/needs. The iPhone is a mobile messaging platform capable of delivering a very rich interactive user experience for users on the go. You might as well make the argument that because playing movies on the device drains so much battery that should be disabled as well or because web browsing could prevent you from receiving a phone call edge should be disabled as well. The reality is as a user I can budget and make the kinds of compromises that fit in with my own needs or objectives better than anyone else can.

The post just doesn't seem very well thought out, seems more like a string of excuses as to why Apple was doing us a favor.