MacRumors

macrumors bot
Original poster
Apr 12, 2001
52,980
14,724
https://www.macrumors.com/images/macrumorsthreadlogodarkd.png

Twitterific's author, Craig Hockenberry, notes 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
 

Telp

macrumors 68040
Feb 6, 2007
3,069
18
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.
 
Comment

arn

macrumors god
Staff member
Apr 9, 2001
15,756
4,611
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
 
Comment

ChrisA

macrumors G4
Jan 5, 2006
11,812
592
Redondo Beach, California
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.
 
Comment

MichaelLatta

macrumors member
Mar 29, 2005
67
0
Loveland, CO
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.
 
Comment

Buschmaster

macrumors 65816
Feb 12, 2006
1,306
26
Minnesota
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.
 
Comment

Telp

macrumors 68040
Feb 6, 2007
3,069
18
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.
 
Comment

jacobhb

macrumors newbie
Jan 2, 2007
23
0
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? :)
 
Comment

bravedeer

macrumors member
Nov 14, 2006
65
0
I don't think it's smart...

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

naroola

macrumors member
Sep 28, 2007
99
3
Chicago, IL
Huh?

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

Phobophobia

macrumors 6502
Dec 1, 2003
477
0
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
 
Comment

Curtis72

macrumors member
Feb 4, 2007
61
0
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.
 
Comment

lord patton

macrumors 65816
Jun 6, 2005
1,052
10
Chicago
does this mean twitter was accepted into the developer beta (since they have tested on a phone requiring v2.0)?
 
Comment

neven

macrumors 6502a
Oct 10, 2006
815
0
Portland, OR
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.
 
Comment

yoman

macrumors 6502a
Nov 11, 2003
635
0
In the Bowels of the Cosmos
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.
 
Comment

Telp

macrumors 68040
Feb 6, 2007
3,069
18
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.
 
Comment

nagromme

macrumors G5
May 2, 2002
12,546
1,196
"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.
 
Comment

notnek

macrumors 6502
Oct 25, 2007
327
0
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.
 
Comment

thejadedmonkey

macrumors G3
May 28, 2005
8,582
1,870
Pennsylvania
Twitterific's author, Craig Hockenberry, notes 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.
 
Comment

naroola

macrumors member
Sep 28, 2007
99
3
Chicago, IL
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.
 
Comment

nagromme

macrumors G5
May 2, 2002
12,546
1,196
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.
 
Comment

perkelation

macrumors newbie
Feb 7, 2008
2
0
Santa Cruz, CA
not so sure

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
 
Comment

stevin

macrumors regular
Jan 29, 2008
168
0
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.
 
Comment

matticus008

macrumors 68040
Jan 16, 2005
3,330
1
Bay Area, CA
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.
 
Comment

57004

Cancelled
Aug 18, 2005
1,022
340
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.
 
Comment
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.