W3C home > Mailing lists > Public > public-device-status@w3.org > November 2011

Re: Battery API: threshold attribute proposal

From: Mounir Lamouri <mounir@lamouri.fr>
Date: Tue, 08 Nov 2011 11:27:37 +0100
Message-ID: <4EB90419.7080101@lamouri.fr>
To: public-device-status@w3.org
On 11/08/2011 07:31 AM, Poussa, Sakari wrote:
> Background: During the F2F it was raised as a concern that the Battery API
> does not have the dedicated low and critical events anymore. Instead, the
> level and other events comes in on unspecified (implementation dependent)
> rate. Finally, there was no way for WebApp to be a good power management
> citizen by limiting the number (wakeup) events it was consuming. On
> battery powered devices (e.g. phones), every wake-up counts. The less
> wake-ups you have the better you battery life is.

I'm not entirely sure what wakeups mean here. Given that the UA will 
always get the event from the platorm backend, the difference between 
sending the event to the WebApp or not seems small if the WebApp is 
careful with the event handling. Does it really make a difference if the 
UA gets informed about a change but doesn't send a DOM event to the WebApp?
In addition, the WebApp is able to cleverly handle the power management 
by not listening to the battery events when in the background for 
example (using the Visibility API).

> Proposal: the discussed solution was to define a 'threshold' parameter.
> When set, the API doesn't level events if the battery level is above the
> threshold. This way the WebApp can specify when it starts to receive
> battery events. When not set, the events will behave like now (without the
> threshold parameter).

If I understand correctly, this proposal is equals to:
navigator.battery.addEventListener("levelchange", function() {
   if (navigator.battery.level > THRESHOLD) {
   /* do stuff */

It seems that this proposal is solving only partially the problem you 
mentioned: if I understand it correctly, when the level is below the 
threshold value, the events will still be sent at the implementation rate.

Furthermore, with this proposal, we are leading to conflicts between 
multiple scripts in the same page which might set the threshold value to 
different values. In addition of giving a false sensation of power 
management efficiency to the WebApp, it might lead to bugs if the event 
handler isn't ready to get values higher than the threshold.

> attribute levelThreshold : When set (scale 0 - 1.0), indicates the level
> threshold when the the system should start sending the 'onlevelchange'
> events. When not set (equals to zero), the rate of the events is left to
> implementation.

FWIW, default value should be equivalent to 1.0. If 0.0 is set, no 
levelchange event should be sent.

> Any comments?

I do not think we should go with that proposal. It doesn't seem to fully 
solve the problem it tries to solve and it opens a door for bugs.
In addition, this proposal only solves the issue of sending levelchange 
events. It doesn't take into account dischargingtimechange and 
chargingtimechange events which are actually the most complexes.

I think we should keep event sending rate as an implementation detail 
because implementations can be careful and not send them too often. For 
example, Gecko implementation on Android sends levelchange when there is 
a 1% change and dischargingchange or chargingchange events are sent when 
there is a levelchange or chargingchange events. Which make the events 
being send not very often. FTR, it's actually an Android limitation and 
we can't send those events more often if we use the public API.

Received on Tuesday, 8 November 2011 10:28:16 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:42:59 UTC