[DougWebb]

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.

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.

[king_jester]

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

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.

[tjohns]

Foreground prefetching aside, there are controls that let users disable background data prefetching/syncing. In fact, it's even one of the buttons on the standard "power control" widget.

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

[DougWebb]

That control, like the permissions approval dialog, is a blunt tool. Sure, I can turn background data completely off, or I can let my apps run wild with it. There's no middle ground and no per-app control (unless the app developer provides one.)

KB of data could be reasonable, depending on how often its being fetched. But the OA specifically mentioned retrieving several MB of data for use "during the next few minutes." If that's an app that doing some kind of news feed to an always-running widget, and it's grabbing images and stories in case I might want to read them, it can really add up.

[ianstallings]

It's funny I came here to mention how the handshaking from constant dropped connections and cell location changes should be accounted for. I've had to consolidate multiple calls into single calls in order to increase the network performance of mobile applications. It wasn't until I actually sniffed what was happening that I noticed the handshake issue as I walked around, went down into the subway, hit alleys, etc.

As for prefetching, I think that should be a user setting. I've had to pre-fetch and cache data because the content was enormous and the backend was out of my control. But I do agree that a user should be able to decide themselves how the device uses resources and I try to push this into every app. Give the user a choice if they feel inclined.

[kintamanimatt]

> I can easily control how much battery life is remaining on my phone by plugging it in.

Except when you can't. Are you really always near a power outlet? There have been plenty cases where I just haven't been able to charge my phone and have had to turn it off rather than use it for what I want.

> I can't control how much of my data plan an app is using, except by uninstalling the app.

Depending on where you are, get an unlimited data plan. I know not every country has these, but most do.

[DougWebb]

I'm in the US. My data plan is capped when I'm on my carrier's network, and unlimited (and much more expensive) when I'm roaming. Typical US carrier.

This highlights a good point: it's not just the number of bytes of data, it's the cost per byte. Many data plans have an explicit cost per byte, but even ones that don't will have an opportunity cost: if your app is sucking up a portion of my bandwidth, you're preventing my other apps from retrieving data. Even if my data was free, my bandwidth is limited.

[levosmetalo]

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

For this reason I'm pretty happy that my Android has an option to force 2G network for battery savings. Gives me 50% better battery life with no noticeable speed difference.

[DougWebb]

Yeah, most of the time my Android is on a WiFi network (office or home) and the cell data connection is turned off. My battery can last a pretty long time if I'm not away from my WiFis much and I don't have the screen on full brightness.