JavaScript in the Background

Background Detection

Maximiliano Firtman

Maximiliano Firtman

Independent Consultant
JavaScript in the Background

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

The "Background Detection" 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 detecting whether or not an app is currently in the background. Student questions regarding if there is data to tell what type of visibility change occurred, what happens with the RAM allocated to the application, and if the document.wasDiscard boolean ever returns to false is also covered in the segment.


Transcript from the "Background Detection" Lesson

>> So it's time now to talk about detection. So how can we know that we are in the background or that we are back from the background? So, the real situation on most browsers, it's actually complex, okay? So, this is actually the diagram from Chromium browser's, okay? So this is the official diagram from Chrome.

So you can see there are many, we are not going through the whole diagram, we are going to simplify it for whatever matters to us. So, but there is an active state. That's actually when your web app is in the foreground, a passive state, a hidden state of frozen state.

And then some kind of a state, but it's actually the final state called us discard. So let's try to simplify this. And by the way, every yellow rectangle that you see there, it's an event. So for example, the whole window also has events like the old focus and blue events.

But to actually make a more cross platform solution, let's see a simpler life cycle. So you load a PWA a website, okay? You open that website, that's the first step. Then you go the background. In that case there is an event call visibility change that's actually the event that we will use no matter how the website is not visible anymore.

Or why visibility change will be fire, okay? So that's like the simplest way to do this. So the app while in the background may be suspended. Again after 5 minutes in Chrome, it gets suspended. On iOS, it gets suspended after three seconds, okay? So on Chromium-based browsers unfortunately, we have an event for that, but not on Safari.

So it's not going to work on iOS, okay? After three seconds. It's called freeze. Freeze will be executed before the browser or the iOS it's going to actually freeze the whole context, okay? So, we can do something there. The problem is that it's Chromium based. All right, so the user may go back to the app while the app is still in memory.

So it's defreezing the app. So it was still in memory, but now it has execution rights again. In that case, resume is going to be executed and then also visibility change. Visibility change is executed from visible to invisible and vice versa. It's the same event, okay? And of course there is an argument there and we will know if we are coming from the background or we're going to the background, okay?

So the problem is that while the app is suspended, while the app is in the background, there may be another situation that the app is scattered. For example, I'm recording a video. So that takes a lot of memory from your phone. So it says okay that website, that PWA we're going to discard that app, okay?

So in that case what happens when the user goes back to the app, it starts from scratch, okay? On Chromium based browsers there is a new Boolean property in the document properties was discarded. That gives you a true, when actually the user is going back from a discarded app.

It's false, if the user is opening the app from a scratch, which is creating a new navigation from a scratch, okay? But that's Chromium only. So to summarize this from our web app, so if we are going from our web app to another app, web app or not.

This is what typically happens. On desktop, we are still running but we are not the active one. We are not being paused. So the PWA is still in memory and it's going to execute visibility change and blur. You can see that visibility change is kind of on every situation and it's also multi-platform, okay?

So it works on every OS that we have in the market this day. On mobile, when we are in our web app and we are going somewhere else, it goes through a paused state. And it's also executing visibility change. And later in the timeline, it may execute phrase.

At any time from polls, it can be discarded. There is no event for that. So meaning that like your last minute, your last dinner, okay? Before a possible this card, it's actually freeze or visibility change. So if we wanna be multiplatform, it's going to be visibility change. So if you wanna save whatever the user is doing in our web app, just in case our web app is discarded by the OS, or by the user.

We have to do that in or within visibility to change. So the question is that if there is a data come in as an argument in visibility change to know which kind of change is happening. Or why the visibility change is happening. So you will know only if you are going to the background or from the background, but you don't have enough details to know what's going on.

In fact, let me tell you something. There is another situation that will trigger visibility change. When you're unloading the website. I mean, the user is clicking on a link that goes somewhere else. And loading that website will also trigger visibility change, because your website won't be visible anymore, okay?

So yeah, it's tricky if you want to get really deep about why your web app bits is getting out of the active window. It's not so simple to know why. To be honest, on many situations, maybe you shouldn't care about why. It's just, yeah. The web app it's gone.

So let's save the data. Or let's stop the timers. Let's stop the socket, okay? But yeah, there are some situations where you might want to keep that. So it's tricky. So it's not so simple, okay? Mostly if you want a multi platform solution, yeah.
>> One more clarification.

>> Yep.
>> Is it fair to say that for the frozen state or the suspended state, execution is paused. And the RAM allocated to your web application is maybe it's in RAM or maybe it's swapped out and can be restored. Its whole state is restored and discarded just means it's destroyed.

And your state is lost and all your RAM is deallocated.
>> Yeah, that's correct. So actually, when you are in the background, what will happen is that on mobile, we are talking about mobile right now. If it's paused, okay, you know it's still in the RAM so it is in memory.

So your context is still there, but you will know for how much time. And you don't know if it's coming back or not. So that's why in the moment that we are going to the background if that's the best place to say okay just in case we are going to save the data.

So on Chromium based browsers, you can keep visibility change and do this on the free event. Well, you know for sure that you're going to the background and you're going to be hibernating, okay? But on visibility change the parameter that on Firefox, it's also being executed when you are putting another window on top of it.

So yeah, maybe you're saving data and in that situation wasn't actually necessary, okay? But if you want a multiplatform solution, you want only one code visibility change if your friend. Yeah, then you can try to think your own algorithm to try to understand what's going on, but at some point I think it's not worth the effort, okay?

So this is again, we are in our web app, and the user is getting out of the web app in any of the situations. Whenever when we are going back, okay? So when we're going back from the other web app to our web app, or to other the other app that you can be the home screen.

It can be Microsoft Word, wherever, okay? And we're going back to our app. On desktop it's actually pretty simple, so it just makes visible the app, and on most situations just visibility change will be fire. And also focus after that. On mobile, and also on some rare desktop situation, such as some.

Such as brave that can also discard tabs or some rare situation let's say for now on desktop. But a mobile is always the normal situation. We are actually like resuming a suspended state. So we are going from the state to be running again. Visibility change will be fire and on Chromium resume will be fire, okay?

What happens if the app was discarded? In that case, a new load event will be fired. Again, remember, the user sees a screenshot that it feels like the app was there. The web was there, but it's actually not there anymore. So, probably you have already felt that as a user.

That sometimes you go back to an app and the app is still there. Sometimes you go back to an app and the app restarts. Well, that's when That app was discarded by the OS, okay? And we have a boolean property in the document on Chromium-based browsers to know after the load or why the load is happening.

If this is a new load, this is a new page navigation, or this is actually the user coming back to an app. So the user is expecting the app to be on the previous state, yep
>> When does the Boolean go to false so, if document was discarded equals true does it ever go back to false on its own in the native API.

>> On the same load process or?
>> So when the load process is done, does it go to false or like?
>> No, because that patient navigation. It's actually until you make a new patient navigation, it's going. It's going to become true. So, yeah, that Boolean property won't change in the same context.

So it starts with true or with false and it will stay there, okay? Now we will actually write that code. So, because there are so many possibilities for background and there are many APIs and ways like focus and resume. If you want to detect multi-platform code, page visibility is your friend.

Page visibility is the visibility change event.

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