5 ms·
This is not a good idea. HTTP polling is enough traffic to put the mobile radio into its DCH state, which uses a lot of power. (Second only to the screen on mos
by oasisbob 15y ago
This is not a good idea. HTTP polling is enough traffic to put the mobile radio into its DCH state, which uses a lot of power. (Second only to the screen on most phones.) Once you're in DCH, there's a timer (typically ~8 seconds) before it turns off again. When polling, you just wasted orders of magnitude more power to wake the radio than was used to actively communicate for that 500ms or so.
One of the great things about the internet is that you can neglect considerations of the physical layer when you design your app.
One of the sad things about the mobile web is that you can't neglect considerations of the physical layer when you design your app.
Some things that seem like a great idea at first (eg lazy loading of lists as the user scrolls) can actually be detrimental and counter-productive when it comes to battery life.
- simonw 15y agoCould you expand on your point about loading more content as the user scrolls? Why would that affect power usage?
- jarek 15y agoThis is a bit simplified since often your app's activity won't be the only thing on the radio, but: Full load: large transmission to start off, but radio is idle after, if the list is long or user scrolls slowly radio might go to sleep after its programmed idle timer (8 seconds in GP's post) Lazy load: keep on making transmissions periodically, either waking up the radio (and keeping it on for another 8 seconds) or outright never letting it sleep (if you lazy load every 7 seconds or less)
- shalmanese 15y agoIt repeatedly toggles the CPU away from a low power state rather than just doing a single chunk of computation and then letting it sleep.