Today I wanted to share a few screenshots with you. Screenshots of my phone.
One of the installed apps serves the coaches of our basketball club. It allows them to communicate with their team and provides access to educational material, for planning practice sessions, selected by the club.
This app however, isn't an app at all! It's just a website!
A website that adapts itself to the environment in which it is installed. On a phone it will behave like a mobile app, but on a desktop it behaves and looks totally different.
This kind of website is called a Progressive Web App, or PWA. Progressive means that it progressively enhances itself to take advantage of the hosts capabilities.
In order to promote a regular website to a PWA, you need at least 3 of these capabilities: a web app manifest, a service worker and a way to enforce SSL.
Web App Manifest
The web app manifest is a json file which describes how the app should be integrated into the host environment. Among others it should contain the app name, icon information, the start url, and some theming information.
{
"short_name": "Clubmanagement Coaching",
"name": "Clubmanagement Coaching",
"description": "An app for coaches",
"lang": "nl-BE",
"icons": [
{
"src": "/img/logo_256.png",
"type": "image/png",
"sizes": "256x256"
},
{
"src": "/img/logo_192.png",
"type": "image/png",
"sizes": "192x192"
},
{
"src": "/img/logo_512.png",
"type": "image/png",
"sizes": "512x512"
}
],
"start_url": "/dashboard/",
"background_color": "#EEEEEE",
"theme_color": "#00A5D5",
"display": "standalone"
}
The manifest file can be named as you wish, but it must be included into the html of the page from which you want to allow installation to happen.
It must be referenced using a <link rel="manifest" href="/manifest.json"> tag.
Service Worker
A Service Worker is a background worker for your app. It's a script that will always be running in the background.
When your app is active, it will be active in the background. But even when the user shuts down your app or closes the browser it will still be given some cpu time to perform work, albeit occasionally.
To progressively enhance your website with a service worker, you will need to register a script sw.js on the global navigator.serviceWorker property if available.
if ('serviceWorker' in navigator) {
window.addEventListener('load', function() {
navigator.serviceWorker
.register('/sw.js')
.then(function(registration) {
console.log('ServiceWorker registration successful with scope: ', registration.scope);
}, function(err) {
console.log('ServiceWorker registration failed: ', err);
});
});
}
Service workers have a lot of super powers: they can act as client side proxy servers to intercept requests, they can cache static files in local storage, use a local database to provide store and forward queues, raise OS notifications and perform background database syncs.
I will certainly come back to these super powers in future posts, but it would be to much to cover them all right now.
Served over HTTPS
The service worker specification is implemented by all browsers, but because of their super powers they will only be available when traffic is encrypted. Otherwise the request interception capabilities would turn into a security hazard.
Therefor it is mandatory that you figure out a way to redirect all website traffic over SSL if you want to ensure your service worker is operation. I use CDN routing rules for this purpose.
A great alternative for native apps
Next to those 3 capabilities, there are a myriad of others that you could also take advantage of. The website What PWA can do today provides a nice overview of all of them.
I firmly believe PWAs are a great alternative for many native apps. With a single code base you can target all environments, while still being able to use many native features. What do you think?
Back to guide
This article is part of the building offline progressive web apps guide. Return to this guide to explore more aspects of building offline progressive web apps.
