App Change Detection

[00:00:00]
>> So when you're going back, you have these two situations. So the event is called resume, the first one. In this case, we are back from suspension, and we were still in memory, okay? So no need to restore the state because all my global variables are still there.

[00:00:19]
My focus, my cursor is still there. What the user has typed is still there. Everything is still there because we are dephrasing the context. Makes sense? But maybe my tab was discarded by the browser or by the operating system. Or maybe the whole browser was discarded including my context.

[00:00:42]
So in that case, the second part is the one that we use. It's just the load event or the DOMContentLoaded. It's a normal load but in this case, we check the wasDiscarded property. So if it's true, we have to restore the state. Yep.
>> Are freeze and resume on a standards track or is that proprietary?

[00:01:07]
>> So it's in the standard track. It's a W3C API but because Chromium is the only implementer. So it's not actually a final editor recommended spec, so it's a draft. And as many Chromium only things, I'm not sure if they will get stable spec because they need at least two engines implementing the API.

[00:01:32]
We haven't heard a word from WebKit or Gecko about this. So that's the problem. So, in fact, I think if you Google the API, you will probably find an article on the Chrome website. It's really a Chromium API but it's open. I mean, it's in W3C, the draft, but it's Chromium only.

[00:02:02]
That's why we are not going to focus too much on this API. It's actually pretty simple anyway, but that's why I encourage you to play with the visibility change. And unless you have really a heavy state, or really you have a lot of heavy situations, I shouldn't encourage you to try this API.

[00:02:21]
In fact, out there, like 0.0002% of the websites are using this API, compared to 5 to 8% using the page visibility API. That's the simplest one. But yeah, we are overdoing things with the page visibility API. Maybe we're saving the state more than we need. On mobile devices, as I mentioned before, the page lifecycle API.

[00:02:46]
So this one that is their freeze event and their resume event, it's not typically available. Again, you save data but I encourage you to use visibilitychange, that will work on iPhone, on iPad, on Android, on desktop as well. On desktop, you have more situations to handle, in case you wanna be more specific.

[00:03:09]
On mobile it's simpler actually, the user is getting out of the browser most of the time. And you restore the state, in the case of mobile devices, when the page loads. Using the timestamp you can decide to restore the state or start a new navigation. So I'm saying this, on mobile, it's actually a pretty common design pattern to actually restore the state through the previous session.

[00:03:36]
It doesn't matter if the user closed the app or not. So typically when you open an app, the app tries to restore the state. It doesn't matter how you ended up using the state. Unless, one, large amount of time has passed. In that case, you decide to just reload the app.

[00:03:55]
Okay, on a website, it's actually not so simple. I mean, if you type facebook.com in your browser, Facebook is not trying to restore what you were reading previously. That's not typically what happens. But on mobile apps, typically we try to restore whatever you had in the recent past.

[00:04:19]
Unless a day has passed or a week has passed since last session. So you can replicate that UX pattern for your web apps as well.