Re: Ambient light API redesign

On Fri, Aug 29, 2014 at 7:05 AM, Tobie Langel <tobie.langel@gmail.com>
wrote:

> On Tue, Aug 26, 2014 at 11:17 PM, Marcos Caceres <marcos@marcosc.com>
> wrote:
>
>> We are actually discussing this on Twitter right now. It seems you don't
>> need the promise. The constructor causes the subscription to the sensor,
>> and then you can potentially just observe `.value` until it gets updated.
>
>
> How do you handle permissioning with that model?
>

> More precisely, how do you handle cases when access is refused?
>

For the instances: "onerror" with an appropriately named event.type or
event.data

For the currentValue promise: reject and allow the program to handle the
rejected promise


>
> Should there be an onerror callback?
>

Yes


>
> Secondly, must the onchange event be called when .value is changed from
> null to its first value? Seems to be useful in a number of scenarios (e.g.
> do something with the first value and do it again whenever there's a value
> change).
>

Yes


Rick


>
> --tobie
>
>

Received on Friday, 29 August 2014 14:10:52 UTC