- From: Mounir Lamouri <mounir@lamouri.fr>
- Date: Tue, 08 Nov 2011 11:27:37 +0100
- 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) {
return;
}
/* 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.
--
Mounir
Received on Tuesday, 8 November 2011 10:28:16 UTC