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

Re: Comments about battery status API

From: Mounir Lamouri <mounir@lamouri.fr>
Date: Tue, 20 Mar 2012 10:11:13 +0100
Message-ID: <4F6849B1.2030506@lamouri.fr>
To: public-device-apis@w3.org
On 03/20/2012 10:00 AM, jianglin9 wrote:
> Hi Mounir,
> 1)
> 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.
>  In my options, We can’t assume web developer get ‘chargingTime’ or
> ‘dischargingTime’ in onlevelchange event handler, maybe use
> ‘onchargingTime’or ‘ondischargingTime’more popular.

I wasn't speaking of web developers but of implementators. Basically, if
an implementation wants to give a chargingTime/dischargingTime value
even if it's not given by the underlying platform (iOS, Android, etc.),
it's doable to do a rough estimation.

> Even though we can use ‘level’ and ‘onlevelchange’ properties to judge
> if the battery is full or low battery, but it’s not logical and not
> strict. I.e. full charged and low battery status aren’t reported by
> system but decided by web application developers.

I don't understand what you mean... If a web developer wants to do
something when the battery is low, he/she will have to decide what low
means. Is that what bothers you? If implementations were arbitrary
deciding what low means, I don't think that would be any better.

> 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
>     We don’t have many use case of battery status now, but as you said
> we could consider it in the futureversion.

I replied to that in another email.

Received on Tuesday, 20 March 2012 09:11:43 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:32:35 UTC