W3C home > Mailing lists > Public > public-device-apis@w3.org > December 2011

Re: no longer possible to detect battery presence? RE: Battery API in Last Call

From: Mounir Lamouri <mounir@lamouri.fr>
Date: Fri, 02 Dec 2011 15:28:16 +0100
Message-ID: <4ED8E080.5050607@lamouri.fr>
To: public-device-apis@w3.org
On 12/02/2011 03:16 PM, Philip Gladstone wrote:
> On 12/2/2011 8:32 AM, Mounir Lamouri wrote:
>> You seem to complain because the API doesn't let the webapp know if
>> there is a battery or not in the device but do you actually need that?
>> If yes, I would be interested in the use case. While discussing this,
>> the only use case that was mentioned was a system UI for the battery
>> which is a tiny use case that could be fulfilled with another API or a
>> future version of the API (very likely requiring permissions).
>
> There are cases when the device cannot figure out the runtime left, and
> yet it does have a battery. Consider a handheld device like an advanced
> TV remote control (think Harmony on steroids). It might only contain a
> primary cell (i.e. not rechargeable). The remaining runtime is
> critically dependent on what the usage of the device is. Probably the
> runtime is unknowable until right near the end. I know that batteries in
> my remote controls last from months to years (at least an order of
> magnitude difference). Part of this may be that sometimes I put in cheap
> batteries. Sometimes the kids jam the remote controls by the side of the
> chairs and I suspect that the buttons get held down.

How knowing if the device has a battery would help? In addition, here, 
you are using a device always discharging. If you can't compute the 
discharging time, I believe the specifications say you should have 
something like:
{
   charging: false,
   level: X,
   dischargingTime: Infinity, // that means "unkwown"
   chargingTime: Infinity,
}

--
Mounir
Received on Friday, 2 December 2011 14:28:49 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:14:26 GMT