Re: [w3ctag/spec-reviews] Review of WakeLock API and suitability for overall platform requested by 31 August 2016 (#126)

Thanks, this looks like it is much improved. Aside from Hadley's point above, we also came up with the idea that for some use cases currently addressed by WakeLock, there may be a more elegant solution involving a subscription to events in a ServiceWorker.  For example, if my jogging application requires the continuous tracking of a person's GPS position, with (say) a 20 second interval sample rate, and then wants to write that data to storage for later processing, then a Serviceworker could be woken up with an event each time the GPS position changed outside of that time-window debounce tolerance.  This might be more power efficient, and we wonder if the spec wants to anticipate that future solution at all.

Finally, I wonder if a system wakelock is cancelled by locking the device, and we feel this should be in the spec.  If a screen wakelock exists, then manually placing the device in standby (using a hardware lock button) would presumably cancel the wakelock, whereas manually hitting the lock button on a device with an active *system* wakelock would (we assume) not affect the wakelock and the page would continue to run as if it were foregrounded on an active screen.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/spec-reviews/issues/126#issuecomment-278485608