JavaScript in the Background

Notifications & UI

Maximiliano Firtman

Maximiliano Firtman

Independent Consultant
JavaScript in the Background

Check out a free preview of the full JavaScript in the Background course

The "Notifications & UI" Lesson is part of the full, JavaScript in the Background course featured in this preview video. Here's what you'd learn in this lesson:

Maximiliano discusses notifying users when the UI updates in the background, previously used methods of notifying users, and a cross-platform solution being used today. Web Notifications is currently the only cross-platform solution, but it requires the user's permission, and it is the same permission used for Push messaging.


Transcript from the "Notifications & UI" Lesson

>> So our service worker for now is ready, ready for adding more code later, okay? So far, I'm done with this, so I don't need the debugger line, okay? So we will have more event listeners, one per API. Make sense? Okay, so now going back to the slides, it's time to talk a little bit about user interface and notifications.

So we are in the background, so updating the user interface, okay, if possible. Why if possible? Because maybe the client, the website is still there, maybe it's not. But let's say it's there, updating the DOM won't notice the user. The user is not seeing my app, that's why we're in the background.

So what if we wanna notify the user that something is happening? Well, a little bit of history here. So we could only notify the user for background tabs before changing the title. In fact, there are still some websites doing this, like eCommerce websites or things like Expedia or wherever you were searching for a flight.

Then you change tabs and you see the title change, hey, hey, hey, hey, don't forget your flight. Your flight is here, okay? The offer is ending. So you change the title element, document.title using JavaScript, okay? That's an old trick, which is still working. Another trick was the changing the favicon.

I will show you one example in a minute. We can still do that. Yeah, it's there, okay? That's maybe a little evil, little, little, okay? But anyway, [COUGH] you can do that if the user is still seeing the browser. You don't know if the user is watching or seeing the browser on the screen anyway.

Playing audio. Yeah, and I'm not saying do that, but it's there. Force a refocus. Fortunately for us, that's not working in most browsers these days. But that was a way to do things a few years ago. For example, even making an alert will actually refocus the tab that is making the alert in the background, which was actually really, really bad.

Anyway, so even we had tricks to not letting the user unload the page. The old trick that when you try to close the page, the page says, no, are you sure you wanna close the page, things like that. Fortunately, that's history. So let's say that the favicon and the title is still there, but yeah, maybe it's not the best of the solutions.

So let me show you one thing in action with this website that you can try if you want as well. So this website is showing you an example of the animating favicon. So you need to look at the favicon there on my tab. If I load this, can you see that?

Of course, you can do any animation. You can do a canvas. In fact, there are some games in the favicon. There is a pong game in the favicon, okay? Anyway, but I wanna show you something. Let's see if you can catch what's going on. I will hit Load, so it will start.

And of course, you can start this process with page visibility, on visibility change, okay? So look at this, it's loading. But look now, what's going on? Is it stopped? What do you think? I know it's really small.
>> It's going in the background, so the set time or the set interval has been slowed down.

>> Exactly, so the timer throttle now, so now it's slower. So you can see in action the timer issue. And if I go back to that tab, you can see it speed up, and now it's slow again. So here we can see in action, okay? The timer's issue, how the timer is being throttled, okay?

Anyway, this is just for having some fun really quickly. That's not how we are going to notify things to the user. So today, the only cross-platform solution is web notifications. Is this push? Not really. A web notification, it's actually a notification that appears in the operating system in the same place as push notifications from native apps, but they are local.

In fact, let me tell you this. In the web, or from the web, at least, we don't have really web push notifications. We have web push and we have local notifications. Web push, we accept the service worker, and the service worker creates a notification, but we don't have a direct line here.

It's not like the server creates a notification that you will see on the page. That's how the web works. So we have actually two different APIs, the web notification API that was known as the desktop notification API initially, and the push API, two different APIs. In fact, now in Safari, that now is they are supported, when you go to Experimental Features, we have the Push API there, that's enabled by default, and you also have notifications.

I think it says enabled, well, somewhere it's notifications. It's a different API, okay? The only problem with this API with notification is that it requires user's permission, and it's the same permission for push. So this is a mess. So that's how it works. So you don't have a permission for local notification and another permission for push.

It's just notifications. If the user is granting you permission, then you can create local notifications and or send push messages to your web app. We don't have two permissions, and a lot of users hate push notifications. So they will say no, okay? So that's a problem, I think that we have a problem as a web platform community here, okay?

So this is not well specced, I think. In fact, there are two APIs to create a notification right now. And if you try to google them or even to read about them in MDN or the W3C, it's not completely clear which one you should be using. We have the classic Desktop Notification API that is only available in the window lower scope and in web workers, not in service workers.

So we cannot use them from a service worker, that's the old one, okay? But it's still there. And then we have Web Push, but I mentioned, hey, Web Push is not for the notification, yeah, but the Web Push spec came with another API that replaces the previous one for notifying the user.

And this one is available from the service worker's scope. So it's kind of messy, okay? In fact, which one you should be using, because we here, we are going to probably, we want to render messages from the background. Probably, we want the one from service workers. In fact, only on Android, only on Android, I don't know why only on Android, so the desktop notification API, it's marked as deprecated.

So if you try to use this one on Chrome on Android, you will see a message in the console saying that the API is deprecated, not on desktop, okay? Anyway, the first step to use this API is to ask for permission. The API is actually pretty simple because it's an old API, because it's coming from a couple of years ago, it's not like promise base, it's like a classic API.

It's a directly Notification.requestPermission. Fortunately, today, we have a version that is promise base. So the original one was not actually giving me anything in return, but now it returns you a promise. And it can be granted, denied, or default. Default means that the user has closed the dialog.

So the user didn't pick any option, that means you cannot send notifications, but you can ask again later. If you get denied, you won't be able to ask the user again for notifications. So if the user denies you permission, next time you ask for permission, it's denied automatically.

And typically in that case, the option is to offer the user instructions, hey, you need to go to there, to the menu and enable this manually, okay? And if it's granted, well, then you can start notifying the user from the main window, from a web worker, or from a service worker, because the permission is the same no matter the API that you will use later to notify the user.

So the confusion is even worse. This is the permission also for push. It's the same permission for old classic desktop notification, for the new push-based notification, and also for subscribing to a push. Same permission, it's called notification, okay? After you have permission, then you can create a notification like this.

It's also weird because you don't send that object that you create to a manager, you just create a notification, that's all. Automatically, that object will talk to the OS, somehow, okay? We won't use this API, this is the classic one. So that's why I'm giving you the code, but we will use the other one, the new one, okay?

Make sense? Any question? With this API, you can notify the user in the background only from workers or from a background tab. So your app must be up and running, maybe throttled, hidden, but it's still running, not from a service worker, okay? So it's a local notification. It's only available on Windows and Worker, what I said a second ago, and we can update the same notification in the future.

So if the notification is still there, we can actually update the text with something new, instead of creating a new one. So there are some ideas to actually improve the user experience. And there are some events that you can listen with add event listener like show, click, or error.

As I mentioned before, this is deprecated on Android, so it's marked as deprecated.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now