W3C home > Mailing lists > Public > public-device-apis@w3.org > March 2012

Re: Re: Comments about battery status API

From: jianglin9 <jianglin9@chinaunicom.cn>
Date: Tue, 20 Mar 2012 16:54:13 +0800
To: Anssi Kostiainen <anssi.kostiainen@nokia.com>
CC: public-device-apis <public-device-apis@w3.org>, mounir <mounir@lamouri.fr>
Message-ID: <201203201654131168924@chinaunicom.cn>
Hi Anssi,

1)       
Let's take an example. If there's no support for the dischargingTime attribute, the following condition will evaluate to false (because the attribute is set to the value positive Infinity):

if (navigator.battery.dischargingTime < 60 * 10) {
  // ...
}
    This situation will be happend if implement as optional, so I explain the reason why I don't supprot these 4 attributes.
I make this suggest from below two points:
From the function and accuracy perspective: developers can use ‘level’ attribute to got the  battery remain and can display as a percentage way. This method is more accuracy obviously. 
From the performance perspective, if we attach a huge JavaScript funcation into ‘onchargingtimechange’ or ‘onunchargingtimechange’ attributes, then this JavaScript funcation will be called per second, this increase the user agent’s payload(especially for mobile device). If calculate from ‘level’attribute, ‘onlevelchange’ even handler will only be trigger 100 times totally. 
So, ‘chargingTime’ and ‘dischargingTime’ attributes induce developers to use an inaccuracy and inefficient manner by default. Compare with the ‘chargingTime’, ‘dischargingTime’, the percentate way is more accuracy and more effective.

2)
What's the use case?
The use case of battery ‘state’ :
When the laptop’s battery was removed and the charger plugedin. In this situation, the ‘charging’ attribute can’t express the current state of battery. By ‘state’ attribute, user can know the laptop is using external power supply. 
‘state’ (or naming ‘criticalstate’) of type DOMString, readonly
Represents the current status of the event target. The status may be one of the following:
·         lowbattery
·         fullcharged
·         hightemperature
·         chargerplugedin
·         batteryremoved
·         batteryinserted
 
Event though we don’t have many use case of battery status now, but as Mounir said we could consider it in the future version.


Best Regards.



2012-03-20 



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



发件人: Anssi Kostiainen 
发送时间: 2012-03-19  19:07:34 
收件人: Lin Jiang(联通集团中国联合网络通信集团有限公司研究院) 
抄送: public-device-apis; Bo Chen(联通集团技术部) 
主题: Re: Comments about battery status API 
 
Hi Derek,
On 16.3.2012, at 11.11, ext jianglin9 wrote:
> 1) Suggest changing the ‘chargingTime’, ‘dischargingTime’, ‘onchargingtimechange’ and ‘ondischargingtimechange’ attributes as optional.
The spec defines default values for the attributes. That allows the same code path to be used for supported and not supported cases in a future proof way. This minimizes the fingerprinting surface too.
Let's take an example. If there's no support for the dischargingTime attribute, the following condition will evaluate to false (because the attribute is set to the value positive Infinity):
if (navigator.battery.dischargingTime < 60 * 10) {
  // ...
}
The same code will continue to work as intended if the support is added later on.
> 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.
What's the use case?
-Anssi
Received on Tuesday, 20 March 2012 08:54:59 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:53:53 UTC