Power Consumption on Mobile – People Do Notice And Act

When recently talking to someone about the apps he's using on his mobile device and which social networks he is active in he noted that he likes Facebook a lot but the app for it on his mobile device is so power hungry, he doesn't dare to let it run in the background because his battery will go flat in a matter of hours. That tells me that he probably gets a lot of updates that are then immediately pushed down to the mobile, which in turn requies the radio to be switched on quite often. There we go, a natural barrier hit.

So what is needed in this case is that the apps becomes more situational aware. When the display backlight is switched off and the phone is locked there's no need for updates to be pushed continuously and the app could inform the backend server so status info is collected and stored until the user actually checks for updates again. I don't think that would be difficult to do. And surely, network operators would be happy about it as well as it reduces the signaling load on the network.

4 thoughts on “Power Consumption on Mobile – People Do Notice And Act”

  1. There is a nice app for Android called Screebl which uses the accelerometer and various other events to do just what you’re suggesting. It seems to work quite nicely on my HTC Desire. Cheers Robin

  2. I was thinking about exact same thing – I own android-base mobile and my battery is being killed by facebook/exchange/(…) sync within a day, sometimes even faster.

    Couple of weekeks ago I stumbled upon ericsson slides about using WAP-Push to deliver such realitime contents, instead of keeping TCP connections alive constantly.

    That’s a great idea, of course. But unfortunately stock android does not support wap-push (service indication), so in order to use it reliably accross wide range of android handsets one should provide his own wap protocol stack implementation. (!)
    (That’s pretty strange, because Android must implement some of WAP in order to support MMS).

    Best regards

  3. The fact that a 3rd party app needs to be added on top of the native UX to do that (suggestion from the first commenter) says a lot about mobile devices and the type of coding or best practice standards that need to be addressed.

    Would make a bit more sense if the network APIs for mobile devices were developed to be context smart out of the box, and even integrated into a learning/AI API so that it would just happen without the user needing to configure anything.

  4. I had to uninstall Foursquare from my Blackberry after I discovered it drained the battery in a few hours even if I don’t actually open the application!

Comments are closed.