Re: Wake Lock API as [Observable] candidate, Re: [whatwg] Object.observe()able properties on the web platform

On Mon, Aug 25, 2014 at 3:26 PM, Marcos Caceres <w3c@marcosc.com> wrote:
>
>> The second problem with the above is that it makes it very hard for
>> components on a webpage to cooperate about keeping the screen on.
>>
>> If this is a use case that we at all care about then I think we need
>> something better. For example something like:
>>
>> x = new ScreenWakeLock();
>> x.request();
>> object.observe(x, myHandler, ["lockGranted"]);
>>
>> would make it much easier for separate components on a page to not
>> stomp on each other's locks.
>
>
> Sorry, I (and the other Editor) are still having a hard time understanding why this is easier.
>
> If you have 2 (or more) locks:
>
> ```
> x = new ScreenWakeLock();
> x.request();
> object.observe(x, myHandler, ["lockGranted"]);
>
> //some other script later creates "y"
> y = new ScreenWakeLock();
> //auto granted... page is allowed to request.
> y.request();
> object.observe(y, myOtherHandler, ["lockGranted"]);
> ```
>
> Does changing x.lockGranted also change y.lockGranted?

No.

> In any case, it seems to me that what you are proposing gets super messy (for developers) because you need to track multiple locks.

Why? Just assume that if your lock instance hasn't been granted, that
the screen isn't locked.

Note that the screen might always be locked even if your page hasn't
been granted a lock. For example another tab might be holding the
screen locked, or the user might have disabled the screen timeouts in
the OS settings, or the user might have placed the cursor in a "hot
corner" which disable screen timeouts, or the user might be touching
the screen every 5 seconds in an effort to ensure that the screen
doesn't timeout.

You can never be sure that the screen will time out. But if you are
granted a lock, then you can be sure that the screen won't time out.

/ Jonas

Received on Monday, 25 August 2014 22:45:55 UTC