- From: Thomas Steiner via GitHub <sysbot+gh@w3.org>
- Date: Mon, 23 Sep 2019 07:06:53 +0000
- To: public-device-apis-log@w3.org
I tried to rewrite my example from https://github.com/w3c/wake-lock/issues/226#issue-477803265 with the new new new API proposal:
```js
(async () => {
let lock = null;
try {
lock = await navigator.wakeLock.request('screen');
console.log('Wake Lock is active');
// This would fire on visibility changes
lock.addEventListener('statechange', async (e) => {
// Re-request a new lock after a visibility change
lock = await navigator.wakeLock.request('screen'); // (♲)
});
// Schedule a regular release
window.setTimeout(() => {
lock.release();
lock = null; // (←)
}, 5000);
} catch (e) {
// This would catch browser interventions
// like battery saver force-releasing the wake lock
console.error(e.name, e.message);
lock = null; // (←)
}
})();
```
Two and a half questions:
- Would `onstatechange` fire in case of a browser intervention (that would be `catch`'ed (ugh, well, caught))?
- As the only state change that's possible is 'active' to 'released', maybe `onstatechange` could be renamed to `onrelease`?
- Not entirely sure about garbage collection here. If I `null`-ify the `lock` variable (above marked with ` // (←)`), would it's event listeners be GC'ed? And if I recycle the variable to re-acquire a new lock (above marked with ` // (♲)`), would a previously created event listener be still there?
--
GitHub Notification of comment by tomayac
Please view or discuss this issue at https://github.com/w3c/wake-lock/issues/226#issuecomment-533982302 using your GitHub account
Received on Monday, 23 September 2019 07:06:54 UTC