Re: Standby API Specification Proposal

Hi Ilya, 

On May 29, 2014 at 9:05:09 AM, Ilya Bogdanovich (bogdanovichiy@yandex-team.ru) wrote:
> > 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, 

ok, just to be clear you mean:

//assign it to some context so it doesn't get GC'd!
(function(){
   this.wakeLock =  screen.getWakeLock();

  ...some point in the future...
  delete this.wakeLock; 
}()) 

The problem here is that you then put the developer into a situation where you are exposing how GC works. This means that, as a dev, you have to either put the returned object in the global scope or in some JS scope and then manage it manually:

myWakeLock = undefined; 

And 

delete myWakeLock;
 
Or you the unknowing developer could do:

function stayawake(){
   //there, this will fix it 
   screen.getWakeLock();
   //oh noes, the wake lock is gone... 
}


Although that is clever, this is not very idiomatic in JS and could lead to confusion.   

> 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();

This could also happen with the GC-based model, as the object needs to be kept alive and explicitly deleted to be useful.  

this.wakeLock =  screen.getWakeLock(); 

function youCanSleepAgain(){
  doSomething(); // exception thrown
  delete this.wakeLock; 
}

> 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.

Oh, we definitely don't want to show a permission prompt - specially not on request! That's what motivated poke() in the first place. I envision getWakeLock() working more like how Chrome shows you which tab is making noise. There are lots of different ways to show which apps are using excessive amounts of battery. It's not a problem until it is, and then the browser can intervene. For example, it may do nothing for an "installed" app and just track usage that is reported in a separate "battery usage panel" ... like FxOS does - or may display a non-modal overlay after a while, though that would suck if you are doing a presentation that is not in "presentation mode" or anything like that.

Having said that, we could still return a promise because getting a wake lock may fail for other reasons. I actually had Promises already included in the proposal for this reason.  

Anyway, the point is that there are lots of ways to manage this - and the underlying OS may give the user means to override allowing apps stopping the screen from going to sleep or dimming.

Received on Thursday, 29 May 2014 15:04:02 UTC