Comments about battery status API

Hi All,

   I have two suggests about battery status api: 

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.
 
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. 

    Best Regards.

2012-03-17 



*******************************************
Derek Jiang
China Unicom Research Institute
Mobile:18601105110 ; 
Tel: +8610 66522726
Email: jianglin9@chinaunicom.cn
Add: No.33, Erlong Road, Xicheng District, Beijing 100032, P.R.China
********************************************   

Received on Sunday, 18 March 2012 10:30:49 UTC