search

beverloo / notification-triggers

Explainer and spec for the Triggered Notifications proposal
31 stars 6 forks source link

Recurring notification triggers #8

Open stroobandt opened 3 years ago

stroobandt commented 3 years ago

The need for recurring triggers was clearly voiced in the feedback of the Chrome M80-M83 Origin Trial. I would like to echo this pressing need by presenting the following humanitarian use case.

As an international nonprofit organisation, we are currently developing a progressive web application (PWA) for researching the aetiology (origin) of a number of medical conditions in the setting of clinical trials.

Indefinitely recurring notification triggers would allow to remind patients to take their medicine or to fill in a form at specific times of the day.

The preceding notification(s) would be cleared prior to showing the new notification.

As this application is not intended for a general audience, it cannot be offered as a native app in the Google Play Store. Whereas to keep the barriers to installation low, we went for a PWA. A low barrier to unassisted installation is especially important right now during the ongoing SARS-CoV-2 pandemic, where interaction with patients and their smartphones or tablets should be kept to an absolute minimum. Nonetheless, non-COVID patients and their needs should not be left unattended during the current crisis.

For your information, there exists also a 2018 StackExchange question about this topic, which I recently answered to the best of my knowledge.

Slightly related, Manifest V3 for Chrome Extensions has a chrome.alarms API for service workers, as explained here. Obviously, this is of no use to the Android Chrome browser, but perhaps some ideas may be borrowed.

stroobandt commented 3 years ago

I actually tried to create a shim for delayed and recurring notification triggers. Here is how I did this:

A dedicated web worker runs the setTimeout or setInterval and sends its notification request messages to the core PWA client. The client relays these notification requests to the service worker which wakes up, deletes any previous notifications and finally shows the new notification.

This works perfectly on the Chrome desktop browser with the installed PWA running in a tab without focus and with DevTools closed, as this influences sleeping behaviour. Timers with 30 minute or longer intervals are no problem at all.

Unfortunately, this does not work with the Chrome browser for Android. The dedicated web worker gets put to sleep shortly after (about 5 minutes) moving the PWA to the background.

My questions are:

  1. Is putting dedicated web workers to sleep for PWAs in the background intended mobile behaviour or are we dealing here with a Chrome for Android bug? Reading the spec, I would be inclined to say, yes, it is a Chrome for Android bug. The reason being: A web worker with an outstanding timer should be treated as a protected worker.
  2. As shared workers are not supported in Chrome for Android, is there a way to keep a dedicated web worker indefinitely awake and running in Chrome for Android?
stroobandt commented 3 years ago

The Google Firestore team also seems to have issues with the lack of persistence in web workers.

It really looks like corporate Google engineers of different Google divisions are waging similar battles against a common problem.