Re: Last Call of Battery API published, LC ends 2 October 2014

On Mon, Sep 1, 2014 at 8:41 PM, Rick Waldron <waldron.rick@gmail.com> wrote:

>
> On Mon, Sep 1, 2014 at 6:21 AM, Mounir Lamouri <mounir@lamouri.fr> wrote:
>
>> On Fri, 29 Aug 2014, at 20:12, Tobie Langel wrote:
>> > Hi,
>> >
>> > I don't understand why this API is developed separately from other
>> sensor
>> > APIs.
>> >
>> > It would be much better for developers if all sensor APIs were
>> > consistent.
>> >
>> > The API difference between DeviceOrientation and Geolocation was bad
>> > enough. Why are we repeating such mistakes over and over again?
>> >
>> > Sorry for the late and negative feedback.
>>
>> Battery API has never been very similar to those APIs and I'm not sure
>> the proposed Ambient Light proposal is really mature. It's not sure it
>> would easily apply to Battery API too. How would you change it?
>>
>
>
>   // Create an instance that checks battery level at 1hz:
>   var battery = new Sensor.Battery({
>     frequency: 1
>   });
>
>   battery.onchange = ...;
>
> Or, just get the value for some kind of one-time operation:
>
>   Sensor.Battery.requestValue().then(data => ...)
>

So the Battery API currently exposes more high-level data, such as whether
it is connected or not, time left to charge the battery, etc.[1]

How would those be exposed?

Directly on the Battery instance, like so:

    battery.charging; // true or false
    battery.chargingTime; // time in s

Or on a value object like so:

    battery.value.charging; // true or false
    battery.value.chargingTime; // time in s

Likewise, how do you handle events in that case? Do you only keep a generic
onchange event? Or do you have more fine grained events
(e.g. onchargingtimechange, ondischargingtimechange)? Or both?

In the first case, how does the developer know which fields have changed
without keeping a reference to the previous state object? Etc.

--tobie

---

[1]: http://www.w3.org/TR/battery-status/#idl-def-BatteryManager