If You're Programming a Cell Phone Like a Server, You're Doing it Wrong

Prefetching isn't applicable to every situation, but in some circumstances it makes apps more enjoyable to use. The trick is to analyze and understand the high volume usage patterns for your app and to target those for improvement. If you see that the vast majority of your users will take a next step to view content that must be web loaded, it may make sense to prefetch when the wi-fi or cell radio is already on so you can piggy back on the high power state and avoid waking the hardware.

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

As someone who has encountered apps with bugs that do constantly make or maintain network connections, these kinds of bugs are a much more severe drain on battery compared to the screen. We're talking about bugs that are constantly powering your wifi or cell radio hardware 90% of the time. This will kill your battery in no time, screen on or off.

I think the average mobile app developer has no business thinking about radio optimization.

They should however be spending lots of time thinking about cacheing and minimizing interaction with servers. Developers in general have gotten too comfortable with unnecessary traffic on Desktop machines. There are too many devs who have been focused on speed as the limiting factor for mobile apps, when it fact should be cost. The end user is paying not only to acquire your app, but also to use the mobile provider's transport.

We should take every opportunity to reinforce the importance of minimizing mobile traffic to only what is necessary. Just because you can use a 4G connection to move a ton of data doesn't mean you should.

While the screen is definitely a huge power drain, it's easily controlled by the user. Poorly behaved apps will drain battery regardless of what the user does, and definitely _can_ be a huge drain. These used to be a lot more common when Android first came out -- many of these apps got better when users got better visibility of battery usage and started complaining to app developers.

And in general, we're talking kilobytes of data here. Not megabytes. Prefetching is good for metadata and text content; image content and other large assets should be an opt-in feature. (Android's "News and Weather" app was a good example of how to do this right.)

However, changing behaviour based on battery level is trickier than it seems.

* The point of reducing energy usage is to leave the user more juice for the actions that are most important to them. It could be that your app is the important one.

* Stopping expensive operations at 20% or 30% battery level means that 70-80% was already wasted. If there are good ways of optimising energy use, they should be applied at all times, and prolonging the time until you reach 20%.

* The appropriate threshold depends on what the user imagines doing for the rest of the day. If I'm travelling to another city, I disable background data in the morning to make sure I still have battery left for phone calls in the evening after heavy use of maps during the day. If I'm travelling to the office, it doesn't matter, since a charger is nearby. Predicting "time to next charging" and "use of other apps before charging" automatically for context-aware app behaviour is non-trivial.