Introduction to Push Notifications
Pulling your web app one step closer to native apps
Push Notifications are a great way to stay in touch with your userbase. It takes your webapp one step closer to native desktop and mobile apps.
These notifications can be triggered either by your running app or even from your server when your app is not running. The API requires the user’s permission so you can be sure you only send notification to those who really want them.
They are working on top a Service Worker, a special type of web worker whose purpose is to make your app usable when users are offline. So in order to use push notifications, you have to have a service worker in place. After establishing a service worker we can go ahead and check for support and user permission.
Checking Support and Permission
If we check support on caniuse, we can see that the notification API is not yet widely adopted, it’s currently sitting at 78%.
This is why we need to check whether the browser supports it. Luckily it can be done with a single if statement:
As you can see, we also need to check for the presence of
serviceWorker since notifications are sent through them. Apart from support, we also need to check for permission, since we need to get user permissions to show notifications:
If the first if statements have been fulfilled, we can start sending notification to the users.
As mentioned in the beginning of this article, to send notifications we have to have a
serviceWorker registered. To show notifications, we will need to use the service worker registration object:
After registration and checking for support/permission, we can call
serviceWorker.getRegistration() to request the registration object from the service worker, then we can send out our very first push notification:
Looks good but nothing fancy so far. Let’s add some more options.
Adding More Options
For adding options, we can create a new object and add it as a second parameter to
In this case, the first parameter becomes the title. For a full list of available options, please see the documentation on MDN. There are plenty of useful properties you can pass, such as:
vibrate: the vibration pattern used for mobile devices
silent: a boolean specifying whether the notification is silent or not
data: an arbitrary data containing any value so that you can identify which notification was interacted with
actions: an array of
NotificationActionsavailable for the user to choose from, which we will look into right now
If we want the user to interact with our push notification we need to add an
actions object to our options. Adding the following object will add two new buttons to the notification:
There are three properties you can use here:
action: used for indentifying the action the user takes
title: this will be the text on the button
icon: in case there’s not enough space for the title an icon will be displayed instead
Listening for Events
Last thing to do is to listen when the user clicks one of the buttons so we can take actions accordingly. For that, we need to attach an event listener inside the Service Worker:
Adding the above lines into
sw.js (the service worker which we have registered) will log out the emitted event:
NotificationEvent, we have access to the
action which can tell us which button was clicked by the user.
Now you can send notifications to users whenever it is suitable. It’s a great way to keep in touch with your users, increase engagement and deliver updates right into their devices. Users can opt-in and out-out any time and the number of options you can provide for your notifications can make your content rich as well as tailored to your users.
Now comes the hard part: making good business decisions and figuring out the what, when and how. What you should notify users about, when is the right time to notify them (don’t do it in the middle of the night) and how frequent your notifications should be. The answers to these questions will differ for each application so the best way is to start experimenting right now.