i have a question regarding to ServiceWorkers. I know that those Workers may be terminated by the user agent. Will a so terminated ServiceWorker be able to still receive Push Notifications and wake up to them?
If not, are there any information about how long the service is allow to run usually? I'm targeting Chrome on Desktop as well as Chrome Mobile.
I'm curious about how much i can rely on the workers and how much i can integrate them in my further apps.
Edit: What i really did not expected: If i go to this example and manually stop the Service Worker (should be equal to termination trough user agent) and then submit a push notification, the service worker gets resumed.
Therefore i assume that Push Notifications can wake up a terminated service worker. Is there any limitation?
A terminated service worker is still capable of handling a push event. The browser will start up the appropriate service worker when it detects an incoming push notification from the Web Push server (e.g., Google Cloud Messaging). The incoming push message includes registration information, which allows the browser to figure out which specific service worker to start up.
There are some requirements to fulfill in order for the browser to receive the incoming push notification from the Web Push server.
On desktop operating systems, the actual browser process needs to be running. So, for example, if you're a Chrome on OS X user and you quit Chrome, you won't receive any push notifications until you start up Chrome again. (At which point, a bunch might all flow in at once.)
On Android, the connection with the Web Push server is handled via the operating system, and Chrome (and I believe Firefox) does not have to be "running" in order to process the incoming notification and start up the correct service worker.
Related
I’m trying to monitor which service workers are active (ie, which users have their browsers open). I came up with a solution that sends a simple ping through the web push API, and that would trigger the service worker to send a ping request to my server. But I’m finding that if I don’t display a notification to the user, I get an alert from Chrome.
This site has been updated in the background
Am I doing something wrong, or is there another way to solve this problem?
No, you're not doing anything wrong. This is by design.
It is not possible to contact the Service Worker in the background using the Web Push APIs and have the system not tell the user. You're describing a passive tracking system where you track the user even though the user is not using the product, and that has been restricted by SW design. When you use Web Push you should show your own notification (the API is for notifications) and if you don't, that's what the browser does.
I understand that it would be super nice to be able to contact the SW from the server and have it run some little errands but unfortunately that would make it possible to carry on some mischief too. You also cannot eg. leave open a WebSocket (not available in the SW) or schedule tasks in the future to have it ping (not guaranteed to run).
From my researches, creating a PWA with the ability of receiving push notifications is pretty straightforward.
But what happens if the user reboots the device? Will the app (previously added to home screen, and thus downloaded) able to already receive push notification or the user will have to re-open the app at least once (to start the background service worker)?
If not, there is a way to restart a service worker automagically after device reboot?
The idea that you would restart a service worker at runtime is a complete misunderstanding of service worker architecture.
The whole concept is they are short lived processes, invoked in response to an event and terminated upon completion of their task.
Receiving notifications via the Push API is dependent upon the browser process running, not your specific PWA. Notification subscription endpoints point at browser specific servers which cannot be changed, eg chrome endpoints all start https://fcm.googleapis.com/fcm/send/....
Your application server posts push notifications to these servers, which in turn push them to your subscribers browsers. The browser then launches the relevant service worker which invokes the processes within its push event listener. Once the event.waitUntil promise resolves the service worker exits.
You don't have to open the app after reboot or keep it in the background explicitly to receive push notifications. Its part of web standard and works without manually intervention. iOS support is still limited. You can read more about it here.
I'm working on a website where some events are broadcasted to the clients using SSE (EventSource API). When testing my site on the mobile version of Chrome for Android, I noticed the connection is lost when the channel is idle for about five minutes.
I used several Android devices, with different carriers and different browsers and the result is the same, no matter if the screen is on or off. Desktop Chrome seems to keep the connection alive for a longer time.
Couldn't find any info about this, and when trying to debug the issue, all I got was a TCP "FIN" packet received from the telephone IP address about 3 and a half minutes after the last event was sent.
EventSource's onerror event doesn't get fired so I can't know when the connection was dropped to initiate a new one.
Is there any way to avoid this problem or should I just send some fake message every 30 secs to prevent connection idling?
Thanks in advance
Your connection was probably taken by a "push proxy" - a feature that is designed to improve battery life in phones.
Quote from "https://html.spec.whatwg.org/multipage/server-sent-events.html":
User agents running in controlled environments, e.g. browsers on
mobile handsets tied to specific carriers, may offload the management
of the connection to a proxy on the network. In such a situation, the
user agent for the purposes of conformance is considered to include
both the handset software and the network proxy.
For example, a browser on a mobile device, after having established a
connection, might detect that it is on a supporting network and
request that a proxy server on the network take over the management of
the connection. The timeline for such a situation might be as follows:
Browser connects to a remote HTTP server and requests the resource specified by the author in the EventSource constructor.
The server sends occasional messages.
In between two messages, the browser detects that it is idle except for the network activity involved in keeping the TCP connection alive,
and decides to switch to sleep mode to save power.
The browser disconnects from the server.
The browser contacts a service on the network, and requests that the service, a "push proxy", maintain the connection instead.
The "push proxy" service contacts the remote HTTP server and requests the resource specified by the author in the EventSource
constructor (possibly including a Last-Event-ID HTTP header, etc).
The browser allows the mobile device to go to sleep.
The server sends another message.
The "push proxy" service uses a technology such as OMA push to convey the event to the mobile device, which wakes only enough to
process the event and then returns to sleep.
This can reduce the total data usage, and can therefore result in
considerable power savings.
You can set the retry field to establish the reconnection time of EventSource instance
If the field name is "retry"
If the field value consists of only ASCII digits, then interpret the field value as an integer in base ten, and set the event stream's
reconnection time to that integer. Otherwise, ignore the field.
I'm building a push notification service for my web users using Google Chrome Push Notification Service based on Service Workers.
Currently GCM don't allow push messages to contains payloads in order to overcome this gap my service-worker detects the push-notification event and pulls message from server, however the service worker have no means to identify itself to the server in order to fetch the correct message.
Is subscription.getKey('p256dh') the best approach to accomplish this? Any examples or code available?
Firefox dev version now support push notification with encrypted payload. You can find live example here https://people.mozilla.org/~ewong2/push-notification-test/. And source code here . If you want use firefox push notifications download and install https://www.mozilla.org/en-US/firefox/developer/
I´m a web programmer and I'm experienced in regular synchronous and asynchronous web services. So the normal way to get data from a web server is to request it (pull it) or to establish a permanent connection.
Now I'm asking myself if there is any possibility to run this the other way round so that the server pushes new data to the client without a previous request of the client by using native technologies like HTML5 and Javascript.
Summarized: I'm searching for a way to realise a server side push system what works with any modern web browser (IE, FF, Chrome, Safari,...) by using regular technologies like HTML5 and Javascript without any plugins or additional software.
The client should just listen for new data as long as the web site is opened and the only connection from the server should happen if new data gets pushed. It must work even through NAT or Firewalls.
Well main reason is to save server load and data transfer with many connected clients. Please also mind that not each push will be a broadcast, single client push must also be available.
Is this somehow possible or still no way to handle it without extra software?
Thank you
Though it’s not implemented in all browsers yet, you can try using the standard Web Push API.
You can read more on it in the articles Using the Push API & Push Notifications on the Open Web.
The Push API is a W3C standard to let you enable users of your Web app to get push notifications at any time—even in the background; i.e., even when your Web app isn’t running in the foreground on the user’s device (or even when the browser’s not currently running on the user’s device).
It uses Service Workers to handle messages sent using common push services, and to allow your Web app to react to the push notifications it receives.
It exposes a new push event to scripts. Here’s a simple code example from the Push Notifications on the Open Web article that shows how to use that push event to show an actual notification.
self.addEventListener('push', function(event) {
console.log('Received a push message', event);
var title = 'Yay a message.';
var body = 'We have received a push message.';
var icon = '/images/icon-192x192.png';
var tag = 'simple-push-demo-notification-tag';
event.waitUntil(
self.registration.showNotification(title, {
body: body,
icon: icon,
tag: tag
})
);
});
Update 2016-02-12
The Microsoft Edge team recently moved the status of Web Push support in Edge to Roadmap Priority: High — We intend to begin development soon. Since Chrome and Firefox have already shipped support for it, that means
once Edge lands that support, you’ll be able to send standard push notifications to Edge, Chrome, and Firefox users of your Web apps.
There is WebSockets technology, it allows continuous full-duplex connection stream between a client and a server. More detailed here https://developer.mozilla.org/en-US/docs/WebSockets/Writing_WebSocket_client_applications.
WebSocket is standardized protocol and each server supports it.