Service worker and offline content

service worker

I have recently been working on a project to share driving licence information using an offline method for users. I created an apple wallet offline pass first. I have now started looking at alternatives to apple wallet that would work across other platforms.

Introducing service workers

A service worker is a script that stands between your website and the network, giving you, among other things, the ability to intercept network requests and respond to them in different ways. The idea being that we create a simple HTML representation of the apple wallet driving licence share pass and make this available offline using service worker technology. We will also use other progressive web application methods like the manifest.json to create an app like user experience so a user has a shortcut icon on their phone to the driving licence share pass.

Registering a service worker

You make a service worker take effect by registering it. This registration is done from outside the service worker, by another page or script on your website. On my website, a global site.js script is included on every HTML page. I register my service worker from there.

When you register a service worker, you (optionally) also tell it what scope it should apply itself to. You can instruct a service worker only to handle stuff for part of your website (for example, ‘/blog/’) or you can register it for your whole website (‘/’) like I do.

Service worker life-cycle

A service worker does the bulk of its work by listening for relevant events and responding to them in useful ways. Different events are triggered at different points in a service worker’s life-cycle.

Once the service worker has been registered and downloaded, it gets installed in the background. Your service worker can listen for the install event and perform tasks appropriate for this stage.

In our case, we want to take advantage of the install state to pre-cache a bunch of assets that we know we will want available offline later.

After the install stage is finished, the service worker is then activated. That means the service worker is now in control of things within its scope and can do its thing. The activate event isn’t too exciting for a new service worker, but we’ll see how it’s useful when updating a service worker with a new version.

Exactly when activation occurs depends on whether this is a brand-new service worker or an updated version of a pre-existing service worker. If the browser does not have a previous version of a given service worker already registered, activation will happen immediately after installation is complete.

Once installation and activation are complete, they won’t occur again until an updated version of the service worker is downloaded and registered.

Beyond installation and activation, we’ll be looking primarily at the fetch event today to make our service worker useful. But there are several useful events beyond that: sync events and notification events, for example.

The fetch event intercepts any request made by the user. We can then use this event to return requests from cache and not the network.

I adopted a cache first falling back to network on all the assets and page responsible for rendering the html version of the apple wallet driving licence share pass.

Leave a Reply

Your email address will not be published. Required fields are marked *