> Every decision you make should be based on minimizing the number of times the radio powers up.<p>This is lunacy. Ok, lunacy is a bit strong. But I disagree with this and am throwing a "premature optimization" flag.<p>Modern phone batteries last plenty long, and the radio being on is nothing compared to the big bright screen.<p>/edit
Given the opportunity to chose, I know I would gladly sacrifice a few minutes per charge battery life for a better user experience, especially since my phone never gets below 20%.<p>Your users will be better served by you fixing bugs or adding features. Really, unless you're a huge team with a huge budget, there's other stuff to worry about in your app experience before "maximizing battery life" should be a responsibility you want to help the OS/device maker with.(If you're one of the lucky ones who has the time and money to do both, by all means, go nuts.)<p>Being conservative with resource usage is sound advice. Making battery usage the prime concern for most apps is overkill.<p>Games and other applications that you know users will have open for extended periods of time, and/or that are already eating up battery should give this issue some thought, everyone else, really, don't worry about it.
The last thing I'd want is for my apps to each be downloading several MB of data they think I might need in the next few minutes. I can easily control how much battery life is remaining on my phone by plugging it in. I can't control how much of my data plan an app is using, except by uninstalling the app.<p>Besides, in my experience the biggest drains on battery life aren't data transfers, they're (a) having the screen on, especially when bright, and (b) being slightly out of range of a cell tower, and constantly dropping and reacquiring a 3G connection. The latter turns my phone into a hand-warmer and chews up my power.
Actual title <i>"If You're Programming A Cell Phone Like A Server You're Doing It Wrong"</i> is a much more accurate statement, and a different topic.<p>On topic, this is why I prefer native (or at least non-webview) apps. The control over the connection and app lifecycle provides a better experience and better analytics.
Great article, made me explicitly aware of something I had at the back of mind as a web developer.<p>Another point that struck me is that when I briefly used Android more than a year ago, there was a nifty tool that showed which app drained what %-age of the battery. If I am having troubles with my battery life on Android, I am likely to uninstall (or not use) an app that consumes more than its fair share of the battery.<p>I haven't seen an equivalent statistics pane in iOS, I wonder whether Apple will introduce it at some point to encourage app developers to author more efficient apps.
Since Android is an open system, would it be possible to write an app that runs on a phone and forces applications to batch transfers?<p>I'm thinking of a "limiter" app that runs locally on the phone, and disables TCP/IP transmissions every 18 minutes out of 20. That way things like email you can still get relatively quickly, but the radio's only on 10% of the time.<p>Developers and users both being aware of the problem and trying to fix it might mean their solutions collide. E.g. a badly behaved app that tries to access the network once every 30 seconds will always get through during the 2-minute window, but a well-behaved app that only hits the internet every 10 minutes might miss the window entirely.<p>So maybe the limiter should intercept outgoing TCP/IP connections, lie to the initiating app and tell it the connection happened but the remote end isn't sending any data, then connect the outgoing app to the real remote end when the radio switches on. Of course if there's an application-controlled timeout interval on the connection, it'll trigger and the 10-minute-interval app would miss the window.<p>You might get around that problem by using whatever UNIX signal Ctrl+Z generates, to lock up an app entirely when it tries to open an outgoing connection, then resume it when the radio's on. Of course, this'll probably lock the app's UI too, so it'll become totally unusable. Although if the limiter acts like a screensaver and goes away whenever the user's recently given any touch or keyboard input, that doesn't really matter, does it?<p>Or maybe Google should make an API where an app can say, "I want to make a connection, and I'm willing to wait if turning the radio on right now wouldn't be good for the user."
Shameless plug for Couchbase Lite, our embedded database for iOS and Android, with built-in sync. Let us optimize the network traffic so you can write features.<p>Dev info: <a href="http://mobile.couchbase.com" rel="nofollow">http://mobile.couchbase.com</a>
The author talks about Google Cloud Messaging to avoid polling. I've been researching the topic and gave it a try with websockets without much success. TCP connections tend to hang on cell tower switching and I suspect TCP keepalives keep turning the radio on.<p>I really wonder how to implement push to client on the html5 platform. I even wonder if this is possible at all for now.
> <i>Every decision you make should be based on minimizing the number of times the radio powers up.</i><p>It doesn't have to be "every decision" if you architect the app to not do CRUD-over-mobile-data and do sync instead.<p>This not only improves battery life, it has a strong positive effect on perceived performance and interactivity.<p>Fortunately, there will soon be a book all about that (ISBN 1118183495).
The article is specific for native apps. Is there something I can do to bundle requests together on browser-based sites? Does it matter there? I asked stackoverflow but nothing came of it yet: <a href="http://stackoverflow.com/q/18909185/1253312" rel="nofollow">http://stackoverflow.com/q/18909185/1253312</a>
Given the "preload any data the user might need in the next 2-5 mins" statement, how do people suggest we handle live streaming of updates (eg commentary on a sports event)? Presumably websockets are ok as it's more of a "push" model for the network than a "poll" model?
So what happens in a situation like long polling?<p>Suppose no data is being transferred for 60 seconds ... is the radio kept on at maximum power? Or does it power down in between? Or does it turn off and break the poll (abort the TCP connection)?
Oh, shit.<p><pre><code> apt-get remove apache2 php5 ...
</code></pre>
And here I thought running Debian (for ARM cpus) on your phone was cool. Apparently I'm Doing it Wrong.<p>Puns aside, good article. If everyone did this (for example caching for 2-5 minutes ahead) things would run a lot better! Next time I'm going to code an app, I'll read through everything on this page first.
Just another bugle call for developers and users to forfeit more of their rights to our mighty big data and cloud land owners. Is your app ready for the "Internet of Things"?
of course, if you program for anything like you do for "real man hardware" - by which i mean targetting hardware and not a software platform e.g. a games console or a proper native app, part of the 'web stack' etc.... you never have a problem like this. :P<p>eventually you realise that C isn't fast enough and you can make it faster, but nobody else cares because they spunk clock cycles and bytes everywhere like they have billions of them (which of course they do... :D)<p>...and suddenly every language and platform is solving problems you never had because you just weren't a bad programmer to start with, and instead of solving your problems they are just tying your hands to prevent other people from shooting themselves in the feet.