Imagine if you could program your app to adapt to the end user's device -- such as turning off certain processes if the user's device has a low battery status. Well, you can.
The Device APIs Working Group is a series of specifications drafted to provide developers with access to additional information about a user's device, so that a more tailored experience can be created. This working group contains several evolving standards, including the Battery API which we will take a look at in this tutorial.
The Battery API is now supported on several desktop and mobile browsers, so now is a good time to look at the Battery API and see what it is, where it's supported, and why you should consider leveraging it in your upcoming projects.
The Battery API: A Brief Introduction
The Battery Status API (Battery API) is exactly what it sounds like: an interface that lets developers access information about the current user's battery.
It's a JavaScript-level API that enables developers to hook into various events and properties of the user's device. For example, if we have access to the API, we can get the current battery percentage and, based on that value, set good default settings. For example, if the user's device is in a low battery state, we can remove all background tasks and make them manual only.
Since early 2011, this API has been continually under development, moving back and forth from working draft to candidate recommendation status at the W3C. Over this period, several browsers have adopted support -- though some more than others.
How Can the API Help Us?
Since the specification is not yet finalized, we can't count on developing websites or web apps that fully depend on the Battery API. What we can do, however, is provide additional functionality, or a more customized experience, if the current browser supports the API -- i.e., using it in a progressive enhancement style.
What Information Can We Access?
Since we can access the user's battery state, we can determine their current battery level and whether the device is charging or discharging. In addition, we can sometimes get the device's approximate charge or discharge time (the time until the device is either charged or dead).
With this information, we can start to change the user experience to help the user.
What Could We Use This Information for Anyway?
Even though battery optimization generally isn't in the forefront of a developer's mind, it's a factor that should be considered, especially with everything moving towards mobiles.
Websites offer a range of useful but expensive operations that could be adjusted so that your users spend less of their battery on your website. (No one likes a website or web app that demolishes your battery.)
Let's look at some of the ways we could save some battery power:
- We could customize the Geolocation elements so that they have a lower accuracy and don't request usage of the inbuilt GPS by default. We could have two options displayed to the user, one to request it normally and another with high accuracy.
- We could set video streams or playback to lower quality levels by default, making data transfers are quicker (and thus requiring less work of the device). An option to download the high quality stream could be provided.
- We could reduce complex CSS animations or interface elements and provide a more basic interface.
- We could use the battery level to determine the default interval in which background tasks are run -- such as Ajax and Web Workers. We could use the state to determine how frequently our tasks should be called, in order to minimize network usage. Providing an option or setting so users could set what they want is also a good idea.
Overall, the idea is that we can use the Battery API to provide some good defaults that save battery power, while providing more options for interacting with the website.
Browser Support
Since the Battery API is not finalized, it doesn't have universal support across all browsers yet.
On a positive note, a good number of browsers now support it (as of November 2015), so now's the perfect time to get up and running with this API.
Mobile Devices
Mobile browsers are where support is most important. FireFox mobile has had the longest support, ranging back to early days of version 18 (January 2013). Opera followed suit in version 25 (October 2014) and finally Chrome in version 40 (April 2015).
- Firefox 18+
- Opera Mobile 25+
- Chrome 42 +
Desktops
While the Battery API makes the most sense for mobile devices (and their browsers), it's still important to have support for the API across the traditional browsers, as they're often used on laptops and other portable devices (where the API is useful).
Firefox, again, has the longest history of support, back to version 18 (launched in 2012). Chrome added support in version 39 (October 2014), closely followed by Opera with its 25th version (October 2014)
- Firefox 18+
- Chrome 39+
- Opera 25+
Continue reading %Using the Battery Status API to Optimize Your Development%
by Simon Codrington via SitePoint
No comments:
Post a Comment