- 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