- From: Tobie Langel <tobie.langel@gmail.com>
- Date: Mon, 1 Sep 2014 21:54:42 +0200
- To: Rick Waldron <waldron.rick@gmail.com>
- Cc: Mounir Lamouri <mounir@lamouri.fr>, public-device-apis <public-device-apis@w3.org>
- Message-ID: <CAMK=o4cGCDpN=Z_acRyFyHB+mJGWnCZsd4i6HAb64XO5Z37WoQ@mail.gmail.com>
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 Monday, 1 September 2014 19:55:10 UTC