W3C home > Mailing lists > Public > public-device-apis@w3.org > September 2014

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

From: Rick Waldron <waldron.rick@gmail.com>
Date: Mon, 1 Sep 2014 14:41:59 -0400
Message-ID: <CAHfnhfr=hvAMrD8xdXrd0H=zER1UkrBWBDWwrrBJ64uo16jjjw@mail.gmail.com>
To: Mounir Lamouri <mounir@lamouri.fr>
Cc: Tobie Langel <tobie.langel@gmail.com>, public-device-apis <public-device-apis@w3.org>
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 => ...)



Instances produced by Sensor.Battery should have their own object identity,
but could easily be defined to report data from one shared battery source.


Rick





> -- Mounir
>
>
Received on Monday, 1 September 2014 18:42:49 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:33:12 UTC