Re: [sensors] Add solution for one-shot readings

Re @darobin's 
[comment](https://github.com/w3c/sensors/issues/88#issuecomment-193003582):

> So, I might be missing something here but would it be wrong to have 
a sensor being active when it has event listeners and deactivated when
 it doesn't?

Yeah, you want to be able to cater for the following use case:

```js
let sensor = new Sensor({ accuracy: "high" });
requestAnimationFrame(function frame() {
  console.log(sensor.reading);
  requestAnimationFrame(frame);
});
```
> The difference between listening continuously and asking just for 
one value:
> 
> ```js
> let sensor = new GenericSensor();
> // listen
> sensor.on('whatever', val => console.log(val));
> // just get one
> sensor.once('whatever', val => console.log(val));
> ```

Ahem. You're spending too much time in environments which have more 
modern primitives than we do. We're still in `EventTarget` land here.

> As for caching, the sensor instance can expose a cache event 
emitter. It's a simple (generic) interface that fires the appropriate 
event whenever its cache is set. The difference with the sensor is 
that it remembers the last event for every event type, such that when 
you register a listener you always get the latest value (but if there 
is none it will wait for one to happen).

The use case here is to hit the cache, but not necessarily hit the 
sensor if there is no cached values. For example, offer reverse 
geolocation to fill-in your current address, but not if your battery's
 super low and there is no cache.


-- 
GitHub Notification of comment by tobie
Please view or discuss this issue at 
https://github.com/w3c/sensors/issues/88#issuecomment-193006136 using 
your GitHub account

Received on Sunday, 6 March 2016 22:14:27 UTC