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

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

> If the processor and sensor hub are powered, then hardware is 
already active.

Well, sensors aren't running all the time. They consume a lot more 
battery when they do. Thus a discovery API couldn't spawn lots of 
`Sensor` instances if those actually activated the underlying sensor 
on instantiation.

> Also, not all use cases will specifically register events in order 
to access the sensor data:

Agreed. `startObserving()` might be the wrong name, here, maybe 
`activate()` is better (fixing above):
```js
let sensor = new Sensor({ accuracy: "high" });
sensor.activate();
requestAnimationFrame(function frame() {
  console.log(sensor.reading);
  requestAnimationFrame(frame);
});
```
> That doesn't look awkward to me, it looks clean and completely 
understandable. Also, I like that `read(...)` accepts similar options 
as the class constructor, that's valuable.

OK, I'm glad _someone_ likes it. :) I've been of feeling conflicted 
about it because it works pretty well when you look at it (it's 
concise and reads well), but it combines two different concepts in the
 same method: 1) find the hardware sensor with these characteristics, 
and 2) read from it.

> What I would suggest is that you hold firmly on that design choice 
and let the built-ins work for you.

I think that's irrelevant. The following would work just as well:

```js
Promise.all([
  new Proximity({ position: "bottom-left", direction: "rear" 
}).read(),
  new Proximity({ position: "top-middle-left", direction: "front" 
}).read()
]).then(…);
```

Overall, you're clearly in favor of Solution 3 and don't even consider
 Solution 1 as worth discussing. thanks for your input. It's super 
useful.

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

Received on Sunday, 6 March 2016 20:22:21 UTC