Re: Standby API Specification Proposal

On 05/28/14 06:37, Frederick Hirsch wrote:
> Regarding the three proposals on the list related to a possible standby API [1], I think what was noted in the Chromium log is important [2]:
> 
> "Applications can receive other forms of input than touch, whereas only touch will prevent the device from sleeping after N seconds”
> 
> I suggest that we should attempt to avoid  the risk of apps requesting locks and then not freeing them due to programmer error or other error conditions.  (One denial of service attack might be to disable screen sleep to either cause burn-in or battery drain..)
> 
> it seems Dom’s poke proposal gets at the idea of allowing programmatic notice of input other than touch, avoiding the issue of locks
> 
> Is it possible that the browser implementation could detect window refresh associated with video or games, thus obviating the need for use of an API entirely in some cases? (that still would not address the use case of viewing a recipe)

There are some more cases to think of here.  For example, if I'm playing
audio, I don't care if the screen dims or blanks, but I do care that the
device not go to sleep/standby because there's no input activity. In the
audio case, we don't actually even care if the app is the foreground app.

I think I'm personally coming around to being more comfortable with the
poke idea. Does the API need a way to set a callback for the app for the
next time it needs to poke if it's still going to do so, or is it
sufficient to use an alarm for that?

Received on Wednesday, 28 May 2014 13:29:21 UTC