Battery-Friendly Timer
Mobile applications using setInterval
to poll a server are a battery hogs. Save battery life by fetching data at the right moment.
Motivation
Using AJAX polling on mobile is a very bad idea, because it drains the battery extremely fast. But why is that exactly?
Mobile devices use radio transmitters to communicate via 3G/4G, and their radio components are power hungry. Network providers and phone manufacturers have invented an escalation protocol to save battery life, called Radio Resource Control (RRC). Most of the time, a mobile device is idle, and uses low-power mode. When the user asks for an HTTP resource, the mobile device switches to high-power mode, downloads the resource, then switches back to low-power mode after a few seconds. The process of escalating to high power mode implies asking the radio tower for a dedicated channel and bandwidth allocation, and takes time and energy.
Therefore, mobile data network are optimized for burst: it's better to download all the data you need within a few seconds, then return to low-power mode. AJAX polling prevents the return to the low power mode, and keeps the device in high power mode until the battery is drained - even if it's only to download a few dozen bytes every minute or so.
Instead of polling a server at regular interval, you'd better call it when a download is already occurring. In that case, you know the device is in high power mode, and it's the ideal time to use the network.
The Battery-Friendly Timer listens to AJAX calls, and then triggers timeouts and intervals.
Usage
Usage is similar to setInterval
, except you need to pass two delays instead of just one:
; timer;
setInterval
takes two delays:
- the first is the
tryDelay
. The timer does it best to trigger the callback at this interval, but only when the network is actively used. Therefore, if there is no network activity, the interval may never be called. - the second is the
forceDelay
. Whether there is network acticity or not, the callback will be triggered at that interval.
In the previous example, the server is polled every 60 seconds if there is an active HTTP connexion. If not, the server is polled every hour.
The Timer
object provides setTimeout
, clearTimeout
, setInterval
, and clearInterval
methods. Apart from the forceDelay
argument, the signature of these methods is the same as the window
methods.
Example: Suggest refresh after code update of a Single-Page-Application
This scripts displays a banner inviting the user to reload the application if the JS code has changed on the server side:
Myapp has a new version. Click to reload
; let previousHtml;timer;
This works if you use Webpack, because the index.html
is small, and includes a different cache buster param for the JS script each time you deploy. For instance, here is a typical index.html
generated by Webpack:
MyApp
In that case, comparing the HTML source is a fast and easy way to detect changes in the JS code.
If the HTML is bigger, instead of comparing the HTML source, you can compare a hash of the source. See for instance http://stackoverflow.com/a/7616484/1333479 for a fast and simple JS hash function for strings.
FAQ
fetch()
?
Why not use Service Workers to intercept Because Service Workers are restricted to HTTPS, and require a more complex setup (loading an additional script).
Why not use push notifications?
If you can use push notifications (e.g. in a hybrid app), by all means do so. It's the best compromise in terms of reactivity and battery life. But web apps don't have an easy access to push notifications, and AJAX polling is the usual fallback.
fetch()
?
Does it work if I use XHR instead of No, the timer only listens to fetch()
calls. If you're still using XHR in a single-page application, it's time to make the switch.