W3C's Battery Status API Powers Web App Usability

The W3C's Battery Status API defines a way for developers to determine the battery status of a hosting device, enabling them to create more power-efficient Web content and applications. The Battery Status API, a candidate recommendation (CR), can be used to throttle back an application when a device's battery is low.

The W3C’s proposal opens up various interface properties. For example, the BatteryManager interface's "charging" attribute represents the charging state of the system's battery; the "chargingTime" attribute represents the time remaining in seconds until the battery is fully charged; the dischargingTime attribute is the time remaining in seconds until the system's battery is completely discharged; and "level" represents the level of the system's battery. The standard also calls for four event handlers: The  "onchargingchange" and "onchargingtimechange" handlers allow developers to detect, at intervals, when the device is being charged; the "ondischargingtimechange" handler detects when the device battery is being depleted; the "onlevelchange" can be positive or negative, enabling developers to take of note of fluctuations and have an action performed when a specific battery level has been reached.

When should you use Battery Status API?

There are several business use cases that make this standard important.

1. Defer or alter processor-intensive actions

If the host device is running low on battery, you can opt to defer processor-intensive actions, such as working with complicated graphics rendering. You could also provide an alternative action that would degrade the battery less.

For instance, if the device battery is depleted to critical levels, you could pause or prevent animation from occuring, or swap animating effects with static effects, saving precious battery power. You could also provide the user with a warning or error, recommending that the device be charged. If you have an action that has been running for a long period of time, you can opt to pause or terminate that action.

2. Save data gracefully

When it comes to smart devices, there are few things more frustrating from a user experience perspective than to have your battery die while you are in the middle of a task--taking all of your data with it. With the Battery Status API, developers can program an app to pre-emptively, not to mention gracefully, save a snapshot of the application, along with its current state and user settings.

Whether this means making use of HTML5 Local Storage, or saving remotely via REST, you provide the user with a good and safe experience when using your app. Native mobile apps already make use of measures for unexpected app exits, such as when a phone call interrupts an app in use or the app crashes.

3. Enforce active charging

There may be times when you want to require that a device be plugged into a power source. Apple does this, for example, when its devices require software updates. So, you may want to have the ability to distinguish whether a device is plugged in or not, so that you can craft your app to be more energy-efficient. Or, as the W3C suggests, you could change the frequency of polling a remote REST server, such as an email client, from every minute to every 15 minutes, based on whether the device battery level is at 100%, 25%, 5%, and so on. Also, there are certain processing actions that take significantly more power than others--whether it's a graphically intense process or video/audio functionalities. The API could detect battery charge degredation, as well as whether the device is actively being charged.

Why is Battery Status API important?

Giving developers the power to programmatically decide how their apps should react, based on on the battery status of a device, removes any false assumptions that a host device has sufficient battery. This enables developers to craft apps more power-efficiently and battery-conciously.

Native app developers have the duty to ensure that their apps maintain data integrity, and that users do not lose their data due to various anticipated (getting a phone call) or unanticipated (app crashes or network disruption mid-stream) interruptions. Mobile devices require more frequent charging, and their use between battery charges is much more limited.

Prior to this standard, developers had to assume that users' devices were capable of running their app, without any consideration for the level of battery remaining, and that the devices would run with the same processor configuration, whether they were powered, off-charge, with full-capacity battery or at critically low battery levels. (Many devices slow down their processor based on battery factors, affecting app performance.)

The Battery Status API helps developers maintain the usability convenant with users, helping to make the next generation of apps processor- and battery-sustainable. This brings Web apps a step closer to parity with native apps, allowing Web developers to make the same optimization decisions based on system-level factors that native app developers would. 

What’s next for the Battery Status API?

The W3C Standard Formation Process within the W3C Process Document sets the maturity levels that each standard must progress through.

The Battery Status API has just been promoted to Candidate Recommendation (CR), and the decision-making group has been satisfied that the standard is at a level that it does what is "needed of it." As of Dec. 9, the development community has been invited to implement the standard and provide any other feedback. In 2015, the standard is expected to progress from Candidate Recommendation to Proposed Recommendation (PR). At that point, all input from the community will have been received, and the document will be ready to be submitted to the W3C Advisory Council for final approval.

Web References

Battery Status API - W3C

Doron Katz A keen passion for emerging technologies, practices and methodologies, Doron embraces the vision of lean development with continuous customer development. Consultant for various startups, as a Project and Product Manager, with a mobile engineering background in iOS, and over 10 years of professional web development experience.