Hi
Would it make sense to tie the system lock to a notification?
For example:
new Notification("Processing...", {tag: "abc", progressBar: 0.8,
wakeLock: "system"});
There are many myths and rumors about how to conserve battery on mobile
devices. A small improvement could be to require apps to show some kind
of UI whenever they are allowed to consume resources in the background.
-
Jesper Kristensen
Den 14-08-2014 kl. 03:00 skrev Jonas Sicking:
On Thu, Jul 17, 2014 at 7:17 AM, Marcos Caceres wrote:
On Thursday, July 17, 2014 at 6:12 AM, Mounir Lamouri wrote:
On Thu, 17 Jul 2014, at 01:56, Marcos Caceres wrote:
I don't have a strong opinion. My concern was mostly about developers
having to watch for a whole bunch of different interaction queues (touch
events, mouse events, focus events, orientation-change events, etc.) in
order to release the lock at the right time.
Do you have specific UC? The basic UC I have in mind (reading a book,
watching a video, playing a game) would not use a timeout.
Yes, Google Play Books will wait five minutes from the last interaction to turn
off the screen. This is nice if you fall a sleep while reading and long enough
for a user to read a page without having the screen dim.
See:
http://w3c-webmob.github.io/wake-lock-use-cases/#google-play-books
I was trying to model that problem with the API.
Question remains if there are other kinds of locks that we might need.
For example, Firefox OS has "wifi" as a lock type. I'm assuming that
their model keeps the "cpu" on, but the device can still shut down the
radios on a device. In the proposal, we lump "wifi" and "cpu" into
"system".
Why not breaking these in different sub-systems? I can definitely
imagine my phone having the CPU kept at 100% while the screen is off if
it requires to do a heavy computation. Forcing the screen to stay on
while doing that would be a waste of battery.
Sorry, I was trying to say exactly what you said above. No need to keep the screen on
when using "system", obviously.
Ideally, we could do something like:
"display" = keep display on + system/cpu + network
"network" (wifi/cell) = system/cpu + network (screen off)
"system" = just cpu, turn off screen and radio.
Hopefully, something like that means you don't need to pick an choose amongst
numerous options.
I think the locks are fairly orthogonal.
Holding the "display" lock just prevents the normal "turn off device
because user hasn't interacted with it for X minutes" timer from
firing. I.e. while the display lock is held, the screen won't
automatically time out and put the device to sleep.
However if the user presses the "power" button the screen would still
turn off and the device would still go to sleep.
Holding the "system" lock however wouldn't prevent the screen from
turning off. But it would prevent the CPU from going to sleep even if
the screen times out or if the user presses the power button.
Holding both "display" and "system" means that the screen won't time
out. If the user presses the power button the screen would turn off
but the CPU would still not be put to sleep.
So I think it makes sense to expose an array of which locks the page
holds since all combinations of the "system" and "display" locks yield
different behavior.
I am however more worried about that only having a request() and a
release() function means that pages that contain multiple independent
subsystems will have to make sure that they don't stomp on each
other's locks. Simply counting request() calls vs. release() calls
helps, but doesn't fully solve the problem. It's very easy to
accidentally call release too many times, in response to some UI
action for example.
An alternative design would be something like
x = new WakeLock("display");
x.request();
x.release();
Extra calls of either request() or release() are ignored, but pages
can create any number of WakeLocks of the same type.
Regarding timeouts, the use case that I've come across many times is
pages that contain a lot of text, or some form of puzzle. In those
cases you don't want to completely disable the screen timeout. But you
might want to set it to some larger large value, say 15 minutes.
It's somewhat hard to work around the lack of a timeout. What you
could do is to release the lock after 15 minutes, but then that means
that the normal screen timer kicks in, which adds an unknown number of
minutes of the screen being on.
If you instead were able to create a "display" lock with a 15 minute
timeout, the platform could use the longest value of 15 minutes and
the platform screen timeout.
And note that you in normal use cases *do* want the normal screen
timeout to kick in when a &
