- From: Tobie Langel <tobie@fb.com>
- Date: Thu, 10 Jan 2013 14:44:09 +0000
- To: Anssi Kostiainen <anssi.kostiainen@nokia.com>, "public-device-apis public-device-apis@w3.org" <public-device-apis@w3.org>
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 }; There are various options as how to get the initial value. 1) IndexedDB-like: als.open(function() { // called once the value of the sensor is first provided. this.lightLevel; // dim|light|normal }); 2) with a dedicated event: als.open(); als.onopen = function() { // called once the connection to the sensor is first established. this.lightLevel; // dim|light|normal }; Best, --tobie --- [1]: http://www.w3.org/TR/api-design/#dfn-returning-an-eventtarget-object
Received on Thursday, 10 January 2013 14:44:33 UTC