Ping service worker without displaying a notification - javascript

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).

Related

ServiceWorker LifeTime & Push Notifications

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.

Should I track who to send notifications to when using websockets or send to all users?

I am working on a web application where users have to log in (which gives me a handle that I can track them by in the websocket server) and am wondering whether it is worth it to track them or not. I need to send out a notification to make changes to the home page only if they are on that page. Would it be better to maintain a map of everyone who is on the home page and only send the notification to them, or send the notification to everyone and then have the javascript see if they are on the home page?
Thanks for any input!
Generally speaking, Websocket (and TCP/IP) Unicasting is less resource intensive than broadcasting.
TCP/IP doesn't really allow broadcasting, so broadcasting is implemented by iterating over the connections and sending each one a message (unicasting).
Having said that, the server's code might be better optimized than your own, so you might get better performance while broadcasting under some circumstances than if you iterated over the connections yourself to run some code on each one. This would be the exception rather than the rule.
Some websocket libraries in the wild have a PUB/SUB feature, which let you subscribe connections to a channel that you can publish specific content to.
Knowing whether or not such a feature runs well with respect to performance (etc.), would requires some research into the specific library.

Building a real time stock quotes application? (lots of XMLHttpRequest?)

I'm creating a personal application which displays stock quotes realtime (updating every second), and I was wondering what was the best way to approach this project?
I'm going to query using Yahoo YQL: example query.
I've been researching WebSockets and sockets.io, but I don't believe you can use this unless you own the server with the data. Is this approach not possible?
Send an XMLHttpRequest every second? This seems really bad for some reason, just seeing all the requests in the developer tools makes me cringe and my laptop heat up.
Any thoughts? I've heard of people using an iframe or something to make the requests?
I cannot for the love of programming figure out how Google and Yahoo do it.
An IFRAME that updates each second would have similar effect than an AJAX request every second. Some pages uses an IFRAME that refresh each X time, but there is no magic there, an IFRAME is like another browser window inside the web page.
You are right about websockets, the server must expose a websocket endpoint, otherwise is not possible. If you have this option, go for it.
There is other push technology named "Server Sent Events" (aka SSE, Event Source): http://caniuse.com/eventsource Again the server must expose it, but it basically allows the client to keep a persistent connection to the server, and this push events to the client. Again if you have this option, and websocket is not available, go for it.
If you are not in control of the server, and the only provided option is regular HTTP calls, I guess you have no other option. Please mind that some trading providers limit the amount of requests you can do per minute, or limit the amount of times the information changes per minute, so maybe doing one per second your are not achieving anything relevant... or you can get yourself banned.
I'm pretty new to javascript and API's but I think a google or yahoo API (Application Programming Interface) would be appropriate to link the stock quotes to your app.

using long polling with facebook graph API (for "real-time" notifications)

I'm looking into implementing a web page to show the user's news feed with real-time updates, without using simple polling to the facebook servers.
after browsing through similar questions:
How to implement facebook line notification?
How does facebook, gmail send the real time notification?
Facebook notification system: Is it polling?
As I understand - long polling (see Comet model) is the most preferable way for me to achieve "push"-like events for when a new post is added to a user's feed.
I'm using javascript, on IE browser (6 and above), and the page is actually stored locally, and not on a server.
I'm aware of the real-time updates subscription graph API, but as I mentioned, my page will run locally, not on a server (not even localhost), that's why long polling seems so attractive at the moment.
My question is - does anyone know if and how long polling (or any other Comet model alternative) is available to use via the Facebook API? or maybe any other suggestions?
Thanks.
I think the only long polling available is for the chat API. Otherwise you're stuck with either real-time updates or using a javascript timer to poll.

'Web' based push notifications for internal-only application

I'm already tossing around a solution but as I haven't done something like this before I wanted to check what SO thought before implementation.
Basically I need to modify an existing web based application that has approximately 20 users to add push notifications. It is important that the users get the notifications at the same time (PC-A shouldn't get an alert 20 seconds before PC-B). Currently the system works off of AJAX requests, sending to the server every 20 seconds and requesting any updates and completely rebuilding the table of data each time (even if data hasn't changed). This seems really sloppy so there's two methods I've come up with.
Don't break the connection from server-client. This idea I'm tossing around involves keeping the connection between server and client active the entire time. Bandwidth isn't really an issue with any solution as this is in an internal network for only approximately 20 people. With this solution the server could push Javascript to the client whenever there's an update and modify the table of data accordingly. Again, it's very important that every connected PC receives the updates as close to the same time as possible. The main drawback to this is my experience, I've never done it before so I'm not sure how well it'd work or if it's just generally a bad idea.
Continue with the AJAX request, but only respond in intervals. A second solution I've thought of would be to allow the clients to make AJAX requests as per usual (currently every 20 seconds) but have the server only respond in 30 second intervals (eg 2:00:00 and 2:00:30 regardless of how many AJAX requests it recieves in that span of time). This would require adjusting the timeout for the AJAX request to prevent the request timing out, but it sounds okay in theory, at least to me.
This is for an internal network only, so bandwidth isn't the primary concern, more so that the notification is received as close to each other as possible. I'm open to other ideas, those are just the two that I have thought of so far.
Edit
Primarily looking for pros and cons of each approach. DashK has another interesting approach but I'm wondering if anyone has experience with any of these methods and can attest to the strengths and weaknesses of each approach, or possibly another method.
If I understand well your needs I think you should take a look to Comet
Comet is a web application model in which a long-held HTTP request allows a web server to push data to a browser, without the browser explicitly requesting it. Comet is an umbrella term, encompassing multiple techniques for achieving this interaction. All these methods rely on features included by default in browsers, such as JavaScript, rather than on non-default plugins.
The Comet approach differs from the original model of the web, in which a browser requests a complete web page at a time.
How about using an XMPP server to solve the problem?
Originally designed to be an Instant Messaging platform, XMPP is a messaging protocol that enables users in the system to exchange messages. (There's more to this - But let's keep it simple.)
Let's simplify the scenario a little bit. Imagine the following:
You're a system admin. When the system
has a problem, you need to let all the
employees, about 20 of them, know that
the system is down.
In the old days, every employee will
ask you, "Is the system up?" every
hour or so, and you'll response
passively. While this works, you are
overloaded - Not by fixing system
outage, but by 20 people asking for
system status every hour.
Now, AIM is invented! Since every
employee has access to AIM, you
thought, "Hey, how about having every
single one of them join a 'System
Status' chat room, and I'll just send
a message to the room when the system
is down (or is back)?" By doing so,
employees who are interested in
knowing system status will simply join
the 'System Status' room, and will be
notified of system status update.
Back to the problem we're trying to solve...
System admin = "System" who wants to notify the web app users.
Employees = Web app users who wants to receive notification.
System Status chat room = Still, system Status chat room
When web app user signs on to your web app, make the page automatically logs them onto the XMPP server, and join the system status chat room.
When system wants to notify the user, write code to logon to the XMPP server, join the chat room, and broadcast a message to the room.
By using XMPP, you don't have to worry about:
Setting up "Lasting connection" - Some open source XMPP server, eJabberd/OpenFire, has built-in support for BOSH, XMPP's implementation of the Comet model.
How the message is delivered
You however will need the following:
Find a Javascript library that can help you to logon to an XMPP server. (Just Google. There're a lot.)
Find a XMPP library for the server-side code. (XMPP library exists for both Java & C#. But I'm not sure what system you're using behind the scene.)
Manually provision each user on the XMPP server (Seems like you only have 20 people. That should be easy - However, if the group grows bigger, you may want to perform auto-provisioning - Which is achievable through client-side Javascript XMPP library.)
As far as long-lasting AJAX calls, this implementation is limited by the at-most-2-connection-to-the-same-domain issue. If you used up one connection for this XMPP call, you only have 1 more connection to perform other AJAX calls in the web-app. Depending on how complex your webapp is, this may or may not be desirable, since if 2 AJAX calls have already been made, any subsequent AJAX call will have to wait until one of the AJAX pipeline freed up, which may cause "slowness" on your app.
You can fix this by converting all AJAX calls into XMPP messages, and have a bot-like user on the server to listen to those messages, and response to it by, say, sending back HTML snippets/JSON objects with the data. This however might be too much for what you're trying to achieve.
Ahh. Hope this makes sense... or not. :p
See http://ajaxpatterns.org/HTTP_Streaming
It allows You to push data from the server when server wants it. Not just after the query.
You could use this technique without making large changes to the current application, and synchronize output by the time on the server.
In addition to the other two great options above, you could look at Web Workers if you know they have latest Chrome, Safari, FF, or Opera for a browser.
A Worker has the added benefit of not operating in the same thread as the rest of the page, so performance will be better. The downside is that, for security purposes, you can only send string data between the two scripts and the worker does not have window or document context. However, JSON can be represented as a string, so there's really no limit to the data.
Workers can receive data multiple times and asynchronously. You set the onmessage handler to act each time it receives something.
If you can ask every user to use a specific browser (Latest Safari or Chrome), you can try WebSockets too.

Categories