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

I'm not sure why you want to make Battery implements Sensors. It doesn't
behave like the usual sensors. Most of the sensors are constantly
sending value, they are updated all the time and the implementation will
define the frequency at which it wants to get updates. Battery is fairly
different in the sense that the system will send events when there are
changes. For example, on Android, you get an event send for every 1%
change. On other platforms, the events might be more often.

Because of that, I'm not sure if trying to make Battery fit the Sensors
design is right in the first place.

-- Mounir

On Tue, 2 Sep 2014, at 05:54, Tobie Langel wrote:
> On Mon, Sep 1, 2014 at 9:36 PM, Rick Waldron <waldron.rick@gmail.com>
> wrote:
> 
> >
> >
> >
> > 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.
> >
> 
> I think so too. In which case it's weird to have the value getter defined
> on the abstract constructor's prototype. Inheritance-wise, you might want
> to have something like the following, where SingleValueSensor
> (bikeshed-able) defines the value and range getters along as the onchange
> event handling:
> 
> Temp|Prox|Light < SingleValueSensor < Sensor
> 
> Battery, Geoloc, and friends, would inherit directly from Sensor.
> 
> 
> > 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?
> >
> 
> Yes. See my comments above, though.
> 
> --tobie

Received on Tuesday, 2 September 2014 10:28:40 UTC