Effect of http requests on battery life

Question

I have a project where a client app, probably on an android device, will request some files from a server. One implementation is to have burst transmissions from the server to device where X files are sent together with a link/pointer to the next block. The other implementation is to send a list of file IDs and then make one http request for each of the IDs and get files individually. I've heard this really hurts the battery life. Is that true?

Another issue is bandwidth, the client might not want/need all the files being sent in one burst, so the server is kind of forcing the client to accept them all together. In the individual submission, the client can get the files when he wants if he wants them.

Is the effect on battery life so great that it would be a valid option to overstep on bandwidth? Or are there alternatives?

Answer 1

I've heard this really hurts the battery life. Is that true?

Not necessarily. On most Android devices, both HttpClient and HttpUrlConnection can support Keep-Alive, so if your HTTP server is set up properly, and you make the requests in fairly rapid succession, I would not expect a major difference.

In the individual submission, the client can get the files when he wants if he wants them.

If you mean that they might be requesting them over a substantial period of time, this will not be able to leverage Keep-Alive. However, it may be that you will request fewer files overall and consume substantially less bandwidth. It is impossible to tell you, in the abstract, which will be better for battery consumption.

Is the effect on battery life so great that it would be a valid option to overstep on bandwidth?

That would depend on how much you are downloading, how frequently, etc.

However, IMHO, you are focusing on the wrong problem.

If you are consuming so much bandwidth that you are worried about battery life, your users will be attacking you with pitchforks and pickaxes for costing them so much money on their metered data plan.

Hence, I would use TrafficStats and try out various scenarios to see how much bandwidth you really use, and therefore whether you need to find ways to consume less bandwidth in general (e.g., poll less frequently), so users are not bankrupted by your app. I suspect that your battery concerns will take care of themselves as a side-effect.

However, if in your testing, you find your app showing up on the "battery blame screen" in Settings, then start worrying about battery consumption, whether from bandwidth or other sources (e.g., excessive use of WakeLocks).

Answer 2

Have a look at these slides from a Google IO session about battery life:

http://dl.google.com/io/2009/pres/W_0300_CodingforLife-BatteryLifeThatIs.pdf

Specifically, AlarmManager which has a method setInexactRepeating(...). The system can bin your update together with others which is more power-efficient and avoids waking the device from sleep more than necessary.