Re: Standby API Specification Proposal

Hi all,

Few thoughts from my point of view:

Declarative proposal looks great - it is simple, clear way for applications that just want to keep screen on all the time (seems to be the most common behavior). Anyway, I think both declarative and non-declarative ways should exist.

Poke proposal may lead to performance issues in web apps - like creating unnecessary timers poking the screen and draining battery. Also, this approach doesn’t look so native for mobile platforms, like requesting a lock (Firefox OS way), see for example [1].

Also it seems to me, unlock method on returned object of requestLock() would be better then method on navigator, screen or so on, because object will automatically release the lock when it will be GC’d, otherwise we’ll have problems in such case:

var errCode = screen.getWakeLock();

doSomething(); // exception thrown

screen.releaseWakeLock();

So, Firefox’s approach seems to be best for me at the moment, except one case - requestWakeLock should return a Promise so we can show a permission prompt.

Thanks,
Ilya

[1] http://developer.android.com/reference/android/os/PowerManager.html#newWakeLock(int, java.lang.String)

On 28 мая 2014 г., at 23:25, Marcos <marcos@marcosc.com> wrote:

> 
> 
> On May 28, 2014 at 1:56:08 PM, Marcos Caceres (w3c@marcosc.com) wrote:
>> 
>> 
>> On May 28, 2014 at 12:39:55 PM, Dominique Hazael-Massieux (dom@w3.org) wrote:
>>>> If it isn't, I'm not sure it's worth going through the trouble
>>> of
>>> declaring a wake lock API; we might as well just have a declarative
>>> toggle.
>> 
>> 
>> This might also be a good option too (we should add that to the list of proposals). However,  
>> the declarative model doesn't address the use case of locking on a "as needed" basis -  
>> specially at the manifest level.
> 
> Quickly documented the declarative proposal:
> https://github.com/w3c/screen-wake/blob/gh-pages/README.md#declarative-option
> 
> It's rough, so please feel free to fix up!
> 
> Hopefully there are a few more proposals forthcoming. This has been really helpful, I think. 
> 
> 
> 
> 

Received on Thursday, 29 May 2014 13:05:49 UTC