Re: [ambient light] Updated ED as per LC comments

On Thu, Jan 10, 2013 at 9:44 AM, Tobie Langel <tobie@fb.com> wrote:

> On 1/10/13 2:08 PM, "Anssi Kostiainen" <anssi.kostiainen@nokia.com> wrote:
>
> >All except the following is addressed by ACTION-605:
> >
> >[[
> >
> >If your device is not doing anything, e.g. completely stationary,
> >these sensors would theoretically not change and you would never be
> >able to get the actual state. That might be a mostly academic problem,
> >but this seems like another set of events that violate the spirit of
> >DOM Events. Kinda ambivalent on whether that's good or bad, but I
> >think it at least ought to be pointed out more clearly. And perhaps we
> >ought to define this more explicitly by having some kind of hook in
> >addEventListener?
> >
> >]]
> >
> >Any suggestions how to address the above concern?
>
> Have you looked at returning an event target object as described in the
> Web API Design Cookbook[1]?
>
> This would roughly translate to something like this for the Ambient Light
> Sensor (bikeshed event and method names at will):
>
> var als = new Sensors.AmbientLight();
>
> als.lightLevel; // null
> als.onchange = function() {
>   // called every time there's a change in value.
>   this.lightLevel; // dim|light|normal
> };
>
>
>
+1

This very closely matches the proposal I made for Proximity, Ambient Light
and Magnetic Field (ie. any arbitrary sensor that a device can have),
though I also prefer Tobie's global object identifier "Sensors" over my
original "Device".

http://lists.w3.org/Archives/Public/public-device-apis/2012Dec/0060.html

http://lists.w3.org/Archives/Public/public-device-apis/2012Dec/0024.html

This proposal comes from my experience implementing JavaScript APIs for
interacting with arbitrary device sensors—without limitation on the number
of any specific type of sensor[1-8]. At present, the iPhone 4s and 5 have
two proximity sensors: near the ear speaker and another for "raise to
speak", which means that DeviceProximity is already coming up short. This
can be resolved ahead of the game if these APIs are designed such that they
abandon the notion that a window object should dispatch events on behalf of
a device sensor.



Rick

[1] https://github.com/rwldrn/johnny-five
[2] http://2012.nodeconf.com/theatre/rick_waldron.html
[3] http://www.youtube.com/watch?v=HT2e4QLGDLs
[4] https://github.com/rwldrn/johnny-five/blob/master/docs/ir-proximity.md
[5] https://github.com/rwldrn/johnny-five/blob/master/docs/magnetometer.md
[6] https://github.com/rwldrn/johnny-five/blob/master/docs/potentiometer.md
[7] https://github.com/rwldrn/johnny-five/blob/master/docs/accelerometer.md
[8] https://github.com/rwldrn/johnny-five/blob/master/docs/sonar.md



--tobie
>
>
> ---
> [1]: http://www.w3.org/TR/api-design/#dfn-returning-an-eventtarget-object
>
>
>