[system-wake-lock] Use case: Fitness App (#2)

CheloXL has just created a new issue for https://github.com/w3c/system-wake-lock:

== Use case: Fitness App ==
Sorry if this is not the right format, but it is the first time I write on a specification.

For a Fitness App I built, I'm using the following technologies:

- Bluetooth (for heart rate tracking)
- Speech API (Text to speech, to provide audible queues)
- Timers (for timed workouts)
- Geolocation (there is already a discussion on background working its own repo)
- WebAudio (various app sounds)

Right now, all of them but WebAudio, stop working or are throttled when the screen is turned off/the application goes into background.

I'm already using the screen wake lock to prevent the screen to turn off, but that has two problems:

1. Battery consumption
2. Doesn't solve the app in background issues:
    - Bluetooth event pushing sometimes fails/disconnects.
    - Speech API stops working at all.
    - Timers are throttled.

Using some hacks I'm already preventing timers to be throttled (using a combo of workers with webaudio).

While all of this is working, it is not the best approach. If users go running outside (for example), this forces them to have the screen turned on even if they are not looking at the screen at all (that's why the TTS: it's used to provide audible queues about what to do next, lap speed, heart rate cardio zone, etc). BT also needs screen on so I get consistent reports/prevent its disconnection.

A system wake lock that prevent all the above issues will not only let me remove the workers/audio hack , but also solve all the issues I'm mentioning.

Please note that I'm totally fine with the browser allowing me to use the lock ONLY if the web is installed as app. I get the possible issues of letting people accessing an API this powerful in a untrusted web context.

Please view or discuss this issue at https://github.com/w3c/system-wake-lock/issues/2 using your GitHub account

Received on Tuesday, 7 July 2020 13:32:26 UTC