What I'm saying is it's literally not possible to use them for a calendar app or a video calling app or anything along those lines. People simply won't get the notifications until ten minutes after the person called or the calendar event started. (No, it's not consistently 10 minutes, it's random, and can be several hours in the worst case, so you can't schedule the notification earlier to compensate in the calendar case).
If these things were possible then maybe people would see the benefit of web push. But spam is the only possible application right now, so spam is all you see. It's really unfortunate because there are many other legitimate uses that should be possible...
Let me add to this, they're also not possible to use without a serverside component. Using them for a calendar should be possible without a server, you should be able to just schedule a web notification locally. But you can't, you can only subscribe to a server.
I agree with this, Google made a system that's only good for spam, refuses to fix it or expand on it, and as a result everyone hates it.
A server component isn’t a surprise to me, as something needs to be sending the “push” to the client. It’s either your servers, or Apple and googles servers.
What I don’t fully understand about webpush, and the people trying to use it who are having issues, why not just use regular websockets/what is the difference between webpush and websockets. Both require a server, both require a persistent connection, both allow the server to “push” data to any client connected.
In my mind the “push” mechanism should be a system that isn’t constantly connected to a server, yet a server would still be able to route packets to a client where it wanted. Do our phones really have nonstop persistent connections to apns to get pushes? How could that run all the time and not kill batteries? Maybe I don’t know what webpush is even thought I’ve read about it lol
> Web Push works even when all browser windows are closed.
Well... "works" ;)
But that is the idea, and that is why a lot of developers were excited about web push. It says something about the state of web notifications that we all got excited about being given the opportunity to set up a remote server, track notification subscriptions, and manually trigger them via an HTTPS request. And yet, we did get excited about that; that was seen as an improvement.
And I guess the joke is on us for thinking that if we did all that the phone would finally actually show the user the notification reliably :)
> 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.
If these things were possible then maybe people would see the benefit of web push. But spam is the only possible application right now, so spam is all you see. It's really unfortunate because there are many other legitimate uses that should be possible...