Re: Standby API Specification Proposal

Le mercredi 28 mai 2014 à 12:15 -0400, Marcos Caceres a écrit :
> > requestWakeLock makes it easy to forget to remove the lock; poke() makes
> > it harder (the wake lock disappears as soon as you stop poking).
> 
> Sure, but poke() has the uncertainty of not knowing when you last
> poked and how long the poke lasts (5 seconds? 30 seconds? 1 min?). So
> you still need to manage state or setInterval(). Thus, you still end
> up with harmless, but useless, repetitive loop of method calls in
> blind hope that it has an effect. 

If you need setInterval most of the times, I agree poke() is useless;
but my take is that most of the times you don't (see below), and for
cases where the model is basically to never release the wakelock, a
simple declarative meta tag is better than an API.

> > Another aspect where managing lock will trip people up: if several
> > distinct libraries try to manage it, they have to carefully manage the
> > state to avoid unlocking someone else's lock.
> 
> That's author error, IMO. 

(the same way setInterval(navigator.poke,0) would be)

> There are few use cases where you want anything but the most simple wake lock:
> 
> 1. always on - e.g., a game
> 2. on per request - e.g., a recipe website. 

But what's the benefit of an API for these? I think a meta tag (or a
manifest declaration) would seem simpler.

> Can you think of other use cases?  

* video playing: I don't need the screen to remain up when I pause the
video or when it ends
* speech controlled app: if I don't interact with it, I probably don't
need it to keep the screen up (the same way I don't need it to stay up
if I don't touch a touch-controlled app)


> > > I just assume people will just do this:
> > > //Poke it, because you must never sleep!!!
> > > setInterval(poke, 0);
> >  
> > That's certainly a risk. 
> 
> I don't think that is a risk: That seems fairly logical because that's
> the only way to guarantee you will get what you mean with the API.   

Well, no; if you mean "something is happening the browser can't detect",
setInterval(poke, 0) is absurd. 

> > That said I think the mental model of replacing
> > user interaction with a poke is easier to grasp than managing locks and
> > states in asynchronous environments.
> 
> I'm biased, of course. But I find the other approach conceptually
> easier to deal with without resulting to setInterval() or hooking into
> event loops. We know that, for instance, hooking into onscroll and the
> like has a noticeable performance penalty. 
> 
> In your proposal you have:
> 
> document.querySelector("video").ontimeupdate = poke;
> 
> Which will potentially generate hundreds, if not thousands, of
> unnecessary event objects. To avoid that, you will still need to
> manage state. Like using `onvideostart`, `onvideoend`, and having a
> PokeManager written in JS that relies on setInterval, so to make sure
> you don't flood the system with events (specially on highly
> constrained environments... ok, I'm admittedly FUDing here, but
> `onscroll` remains a real problem and this potentially introduces new
> ones). 

If there is no way to optimize these events management, I agree that's
not very practical; I was (optimistically) assuming there would be easy
optimizations, but I'll easily concede that this is wishful thinking at
this point :)

> 
> I'm worried that poke() just makes it too easy to fall into traps like
> the above - because it's the logical way to use it as your own
> proposal's example shows. 
> 
> > > When what they want is:
> > > screen.getWakeLock();
> > >
> > > //If the use leaves and comes back...
> > > window.onfocus = () => {
> > > //if we've lost the lock
> > > if(screen.wakeLockState === "unlocked"){
> > > screen.getWakeLock();
> > > }
> > > }
> >  
> > Hmm... My perspective was that losing focus on the tab would stop the
> > screen wake lock implicitly (i.e. the screen would be free to dim / lock
> > again), not that it would require the developer to re-request it. That
> > seems like a recipe for bugs.
> 
> True. So yeah, would be nice if you just keep it once requested (even
> as you switch between tabs/windows/apps) - until one chooses to
> releaseWakeLock(). 
> 
> I still don't think that forgetting to release the wake lock is that big a deal, tho. 

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.

Dom

Received on Wednesday, 28 May 2014 16:40:02 UTC