MICHAEL VAN OUWERKERK: If you ask
a room of developers what mobile device features are missing
from the web, push notifications are always high on the list.
And it makes sense.
Push notifications are a great way to reengage the user.
Push notifications are now available on the open web
through a new set of web APIs.
I'm Michael, and I'm an engineer on the Push API
team for Chrome.
And I'm going to show you how to add push
notifications to your web app.
To start with, you take a normal web page
and register a service worker which
will handle your push messages.
Then you subscribe the user to push messages,
which will register the user device with the Push service
and give you some information which you store
on your application server.
When your server is ready to send a push message to users,
you call an API on the Push service
to trigger a push message.
The Push service will then send a push message
to the user device, which will wake up your service worker
and fire a push event.
Then, in your event handler, you show a notification.
And done.
The first thing we need to do is set up
a project on the Google Developer Console.
This is required to use push notifications with Chrome,
because there isn't a standard API for push services
to support yet.
Hopefully, when the standard is finalized,
Chrome and GCM can support it.
Go to Console at developers.google.com
to create a new project so that you can use a GCM API.
In your new project, enable Google Cloud Messaging
for Android and Google Cloud Messaging for Chrome
on the APIs and auth, and create a new public API access key.
Make a note of the API key, as well as
the project number, which you can find on the overview
page in your project.
To let Chrome know about your GCM project number,
add a web app manifest to your site.
The web app manifest is a simple JSON file
that can be used to define icons and the name of your web app.
For Push, you need to define a GCM sender
ID in your manifest, which is the project
number we mentioned before.
Add a link tag pointing to your manifest
so Chrome knows where to find it.
You can learn more in this article.
Now that the GCM bit is done, the next step
is to register a service worker in your web page.
Don't worry if you're new to service workers.
We'll be stepping through how to use them for Push shortly.
But for more in-depth details, you
can check Jake Archibald's talk.
Call a navigator.servic eWorker.register,
passing in the location of your service worker file.
This will tie a service worker to your page.
Once it's registered, you need to set up your UI.
So let's imagine we have a toggle switch
to enable or disable Push.
For browsers which don't support Push,
we should disable the switch by checking if PushManager
exists on the window.
The next step is to subscribe the user to the Push service.
We do this when the user toggles the switch on.
Again, do serviceWorkerRegistration,
and with the registration we call
subscribe on the pushManager.
We've pass in (userVisibleOnly: true)
because Chrome only supports push
messaging with a notification.
In other words, you have to show a notification when
you receive a push message.
When we call subscribe, the browser
will show a permission prompt.
So make sure it's obvious to the user
why this prompt is being shown.
The last thing you want to do is show
a permission dialog when the user first lands on your page.
They have no idea what it is.
If the user gives you permission,
you will receive a subscription object,
and you'll need to send the endpoint variable
to your server, as this will be needed to send a push message.
Time to send a push message.
Now that you have registered with the Push service
and have an endpoint, you simply need
to call this endpoint from your application server.
Here, we'll look at a simple cURL command,
but you'll need to implement this in your chosen server
language.
For GCM, take the endpoint, parse out the subscription ID,
and make a RESTful API call to the GCM endpoint,
using your public API key as an authorization header
and passing in the subscription ID
inside the registration_ids field.
Right now, nothing's going to happen yet
when you send a push message, because we
don't have our service worker set up to handle the event.
Let's see what a push event looks
like in the service worker.
For those of you who are new to Service Workers,
you can think of them as special JavaScript files
that the browser knows about and executes in the background
without needing the web app to be open.
The browser will start up your service worker
when it receives a push message in the special push
event, which you can listen for it with an event listener.
It's inside this event listener.
We can display a notification.
It's worth noting that, when you receive a push message,
you need to show a notification.
Otherwise, Chrome will show its own notification, which you
won't have any control over.
To create your own notification, you
need to call showNotification, passing
in a title and a set of parameters
to define the notification's message and icon.
Notification tag is optional.
It can be used to replace notifications
with the same tag.
One thing to really focus on is the event.waitUntil method.
You need to pass in the return promise
from showNotification, as this tells the browser
to keep the Service Worker alive until the promise is settled.
And that's it.
You can now send push messages and show notifications.
There is one more thing.
You need to allow your users to unsubscribe from push messages.
To unsubscribe from Push, we need
to get the subscription object, which
we can do by calling getSubscription
on a pushManager.
Then call unsubscribe on a subscription object.
It's at this point you want to remove the endpoint
from your database.
This has been a quick introduction into the Push API.
We look forward to seeing what you will build.
Please go check out these articles, which cover
all of this in more detail.
Thanks for watching.