> Network traffic, in aggregate, was very small, but it just killed the batteries.

And as most developers here would know, radios are an expensive piece to wake and won't go to sleep immediately, so doing more smaller network interactions is usually going to be much more expensive (power-wise) than doing fewer big ones (or using notification systems piggybacking on other stuff and bundling req/rep for all applications, e.g. what I hope GCM does)

That second one seems like an easy mistake to make. If you're thinking of ethernet or WiFi, then a few bytes every couple of minutes is no big deal. But on 3G, every time you activate the radio when it's not being used, it's a few seconds of fairly intensive setup, then your communication, then a few seconds before it times out to a lower-power state, then a few more seconds before it goes fully back to sleep. It'll be something like 10-20 seconds total, so your quick blip every 2 minutes ends up keeping the radio on a 10-15% duty cycle!

I've never done mobile dev. I get the problem, but what's the preferred alternative? For, say, email, sports scores, VOIP messages, stats dashboards, etc?

For truly time critical stuff, push notifications, done however the platform vendor does it for optimum battery life.

If not, then some sort of exponential backoff helps so that you're not updating scores every 2 minutes all night.

Apple provides push notifications, which work similar to SMS messages, in that your server can push data to the device without needing the device to poll, due to deep integration with the lower level cellular whatsis. I think Android has something similar as well, but I'm not completely familiar with it.

Basically, IP over 3G works pretty well overall but can be a real battery hog, and dropping down to something more native can be a big win. Cellular radios are built to use very little electricity while monitoring for a wakeup call from the tower they're connected to, so if you can take advantage of that like push notifications let you do, then you'll do a lot better.

A somewhat less wonderful alternative is to keep a persistent TCP connection open with a very long timeout, with the remote end sending a notification to wake up the phone when needed. You'll have no traffic most of the time, and the wakeup being initiated from the remote end removes the need to poll. I believe this is how Skype (and other VoIP apps that allow incoming calls in the background) works on iOS.

Edit: I forgot another technique that some iOS developers have used: register with the "significant location change" API, which can be used to wake up your app when the cell radio switches towers, and then check for new data then. This is technically an abuse of the API (which is intended for when you actually need to know about location changes) but works well enough. It can help to e.g. ensure your stuff is recently synced before the user goes into the subway and beyond data coverage. Once again, this is using low-level cell radio stuff to avoid overtaxing things.