I’ve been working on an android application for a Special Topics class here at UMich. I chose the android platform for the app, because it offered me one great asset: background processes. I had to give up the much larger user base of the iPhone just for this. (Well, there’s also the fact that android is open, java based etc etc etc).
It’s now coming to that time of the semester when I’ve got to stop procrastinating and get started on the app. I now also have an Android Dev 1 device to play around with. So with all of that in mind, I decided to do get to work. First, I wanted to see how well background processes integrate into the android framework, so I downloaded a few generally useful applications to test this. I tried: meebo (for IM), and twidroid (for twitter). I very quickly found that these apps integrate into the android system beautifully. They use the notifications area to display alerts and also use the phone’s vibrate/LED/ring tone features to alert me. I was very encouraged by this. That’s when I hit the snag.
Most of my testing was being done at home and on campus (which is where I spend all of my time). Both places have access to Wifi networks, and therefore I was using those instead of the much slower EDGE network (no T-Mobile 3G in Ann Arbor yet). The result was that the first time I pulled the phone out of my pocket to make a phone call, the battery level was critically low. I was pretty shocked by this considering that I’d charged the phone overnight, and it had been on for barely 2 hours. Initially I thought this was a one off thing, maybe the charger had been unplugged accidentally or something. But, turned out that was not the case since it happened 3-4 times repeatedly. That’s when I thought it was because I was using Wifi all the time. So, I turned off the Wifi and started using EDGE instead. This helped significantly. The battery life went up to roughly 4-6 hours (keep in mind that I’m not much of a cell phone user – I made/received approximately 1-2 calls in each period). Still, this was really no good (who charges their phone every 4-6 hours).
Having seen this I started playing around with the apps themselves. Meebo pretty much has to run continuously and use the network. I thought this might be the root cause of the problem and turned meebo off. I also set twidroid to look for updates every 1 hours instead of every 5 minutes. And voila! I haven’t charged my phone for over a day, and the battery level indicator is still showing well above 50%.
This led me to the following belief: running background processes on a cell phone is simply *not* a good idea. The drain on battery life that it poses is absurd.
As if to prove me right, Apple said the very same thing at the preview of iPhone OS 3.0. They said that background processes reduced battery life by roughly 80% even if the phone was not being used. They cite this as their reason for using push notifications instead. I think they’ve got it absolutely right on this one. While it’d be amazing to have background processes, as things stand, they’re of no real value. I’d much rather have push notifications.
1. It’s pretty obvious that push notifications are a better way of doing things (given current technology). But, there are some uses of background processes that push notifications can’t handle. It turns out the app that I’m building is one such use. What if you need to constantly receive the phone’s location (via GPS, say)? There’s no way you can do that with push notifications. If you know a good solution to this problem, please let me know :)
2. I didn’t mention earlier that the android system keeps your contacts, gmail and google calendar in sync (almost instantaneously). I also have the phone set up to receive my UMich email via IMAP (also almost instantaneously0. Somehow, this doesn’t seem to drain battery life at all. Is it just the case that the applications I chose are badly written?
- Sir Lapog Kahn.