> you should be able to just schedule a web notification locally. But you can't, you can only subscribe to a server.
This isn't entirely true; WebPush is server only, but the Notification API can be used locally. You could schedule a timeout that causes a notification, as long as the page stays open, and to do it while the page is closed you could use a ServiceWorker. Potentially a ServiceWorker may or may not stay active depending on the user's battery settings, but native notifications too can also be disabled by the user.
ServiceWorkers are subject to the same delay issues. In fact the ServiceWorker requirement is the whole reason for the issue in the first place: receiving a Web Push notification requires running a ServiceWorker and Android won't let it run in the background except at certain times. IMO the fix is to change the Web Push API so that you can send (or schedule ahead of time) notifications that can be displayed without activating the ServiceWorker. Alternative solutions would be for Android to relax the restrictions that prevent ServiceWorkers from running, or for Chrome to try to fit ServiceWorkers into the existing restrictions somehow. But for some reason Google refuses to try any of these, and so Web Push rots.
The problem is that the notification API is next to useless. If I remember correctly, the uselessness of the notification API was one of the driving forces behind devs being so excited about web push. Finally we have a way to send notifications when the app is closed. Except... no, not really, because Google messed up that too.
I don't understand why it's so complicated to be able to just schedule a notification to go off at a specific time the same way that native notifications work, but apparently Google thinks that would be a horrible overreach of the web. Now Bluetooth and MIDI access on the other hand, they're fine with that. Google thinks that stuff is very good to have the web. Just don't let the user set alarms, that would be dangerous. /s
Snark aside, the short response is that I don't think this counts as "scheduling" -- scheduling is not "leave a process active and then manually fire the notification once you've personally checked that it needs to fire. And I have seen people try to get this working using background sync, push notifications, all kinds of nonsense. It's just bad design that people are even attempting to figure out those kinds of tricks. This is the kind of weird design that only makes sense when you remember that it came out of an advertising company.
> Potentially a ServiceWorker may or may not stay active depending on the user's battery settings, but native notifications too can also be disabled by the user.
The key difference is that if a user disables native notifications, it's because they want to. If a service worker closes, it's for some opaque reason that the user may not even be aware of. It's not user-controlled. User-controllable permissions are great. Android-controlled permissions that are opaque to the user and can't be overrided even for critical apps like alarms are less good.
Also, it's just wildly inefficient and clunky -- what we want out of notifications is not to run a background process, it's to schedule an event to happen at a specific time and to let the OS handle it. I don't want to be running code to make an alarm trigger, I want to update an event queue. Maybe I want the ability to run code in response to an event, but even that is less important than being able to say "please show the user this piece of text at 5:45 and give them a link to open the PWA."
Regardless, I shouldn't need a running service worker to tell the phone OS that in 30 minutes a notification should pop up.
----
What should happen is you schedule a notification with text and a timestamp, you get an ID back and put it in local storage, a UI is surfaced to the user by the OS that allows them to view notification access and upcoming notifications and set limits, and the app can use the returned ID if it's activated or syncing to edit the notification or remove it before it fires.
And ideally web push notifications would hook into that API. Maybe provide a way to respond to events or run code in response to the notification if you want to get fancy.
That would be the sensible, human way to design a notifications API if we were optimizing for user control, privacy, reliability, and developer ease of use instead of optimizing almost entirely for advertising and spamming people. At the very least you'd think users should have permissions and control over how notifications work instead of the phone just silently messing with things. Absolutely ludicrous that we've made an API that's so unreliable that it can't be used for timers, but also that doesn't have enough control to allow me as a user to filter notifications that apps send.
This isn't entirely true; WebPush is server only, but the Notification API can be used locally. You could schedule a timeout that causes a notification, as long as the page stays open, and to do it while the page is closed you could use a ServiceWorker. Potentially a ServiceWorker may or may not stay active depending on the user's battery settings, but native notifications too can also be disabled by the user.