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

On Mon, Sep 1, 2014 at 3:18 PM, Tobie Langel <tobie.langel@gmail.com> wrote:

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

^^ This makes sense.


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

Subclasses of Sensor should be able to have any specialized (subclass
specific) events, right?

Rick


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