Re: Comments about battery status API

On 03/17/2012 04:43 PM, jianglin9 wrote:
> 1) Suggest changing the ‘chargingTime’, ‘dischargingTime’,
> ‘onchargingtimechange’ and ‘ondischargingtimechange’ attributes as optional.
> 
> From the implementation point of view, unlike PC and laptops which have
> advanced power management components, most mobile devices do not have or
> provide the ability to compute the fully charged or completely
> discharged time. In particular, currently, the major mobile OSs, like
> iOS，Android, Windows Phone etc., do not provide such kinds of native
> functions. Therefore, if an implementation of this Battery API wants to
> get the accurate battery time in seconds, in addition to get the
> remaining power percentage, it also needs to obtain a few sophisticated
> factors, such as the power management IC characteristics, the connected
> peripherals with their power consumption rates etc. Meanwhile, the
> implementation also needs to refer some experiential data to calculate
> the remaining time which is not precise enough. Obviously, it's not
> feasible to implement these attributes on most mobile phones and tablets
> driven by current major mobile operating systems.

First of all, as said Anssi pointed, there is a default value you can
use if the OS doesn't give you that information.
However, I did implement the Battery API for Firefox on Android and even
if those information are not directly available, I've been able to
provide a value for chargingTime and dischargingTime. You only have to
wait for two level changes and extrapolate the time it will take before
the battery will be charged/empty. This can be improved by taking into
account battery characteristics and charging curve.

> 2) Alternatively, by frequently retrieving the ‘level’ attribute, a web
> app could get aware of the current battery power status, and be able to
> adjust its behavior.
> 
> In addition to the ‘charging’ attribute, is it possible to add a
> readonly DOMString type attribute ‘state’ with a corresponding Function
> ‘onstatechange’(or other suitable names) to reflect some more
> informative battery status? For example, over charging voltage, over
> heat, low battery, fully-charged, AC or USB charger plugged in etc.
> These properties are already available on these major mobile OSs, and
> are also valuable to developers. 

Fully charged can be found with level=100 (and charging=true). No need
for a state.
Low battery could be discussed but I think scripts should check level
(like assume that level<20 means low battery) or use a library that will
provide a low battery state. In my opinion, it wouldn't be correct if
the Battery API was providing a low battery state because the level
threshold would be completely arbitrary.
For charging voltage, over heat, AC/USB charger, etc. I don't see what
the use cases are. In addition, that might increase dramatically
fingerprinting. Though, if there are use cases, we could consider that
for a next version, maybe behind some permission model.

Cheers,
--
Mounir

Received on Monday, 19 March 2012 15:10:54 UTC