As some people know, I have been very passionate about Windows Phone since the early days of the platform. I am still using a Windows 10 Mobile device, and I still love the operating system and the Windows 10 platform. However, I am not living in a cave, and I do realise that the future potential of the Windows mobile platform is limited. I still don't think it is "dead", but it is certainly limited. I started learning Xamarin a couple of years ago, to use my C# knowledge and skills for building mobile apps for both iOS and Android. Xamarin is a brilliant platform for creating native apps and as it matures, it has become a tool of great importance in my toolbox. 

Lately, a new way of creating mobile apps has come out of Google's masterminds. Progressive Web Apps. Or PWAs. So what is this new fandangled craze the cool kids are talking about? There are a number of points that should be fulfilled for a PWA.

  • Progressive - Works for every user, on every browser using progressive enhancement at a core tenet.
  • Responsive - Fits any form factor: desktop, mobile, tablet, or whatever is next.
  • Connectivity independent - Enhanced with service workers to work offline or on low-quality networks.
  • App-like - Feels like an app, because the app shell model separates the application functionality from application content .
  • Fresh - Always up-to-date thanks to the service worker update process.
  • Safe - Served via HTTPS to prevent snooping and to ensure content hasn't been tampered with.
  • Discoverable - Is identifiable as an "application" thanks to W3C manifest and service worker registration scope, allowing search engines to find it.
  • Re-engageable - Makes re-engagement easy through features like push notifications.
  • Installable - Allows users to add apps they find most useful to their home screen without the hassle of an app store.
  • Linkable - Easily share the application via URL, does not require complex installation.

List by Google

Google is emphasizing three points in particular to make a successful PWA. 

Reliable

A PWA should always be available. Part of the aim is to mimic a native app, which can always be launched. Doing this in a PWA uses service workers, which is part of the JavaScript language and supported in Chrome and Firefox. Service workers provides hooks to enable bootstrapping of web applications while offline, which is exactly what we are after (they do other functions as well). To register a service worker in your project (which doesn't have to be a PWA), use code like this.

AخA
 
1
if ('serviceWorker' in navigator) {
2
  window.addEventListener('load', function() {
3
    navigator.serviceWorker.register('/sw.js').then(function(registration) {
4
      // Registration was successful
5
      console.log('ServiceWorker registration successful with scope: ', registration.scope);
6
    }, function(err) {
7
      // registration failed :(
8
      console.log('ServiceWorker registration failed: ', err);
9
    });
10
  });
11
}

Code from Google

This code checks to see if the service worker API is available, meaning the user is using either Chrome or Firefox. If it is, the service worker at /sw.js is registered once the page is loaded. The web app now have access to local databases, rendering websites and offline functions that make the app seem native. And it is a reliable experience. It works every time.

Fast

Performance is king. Consumers expect experiences, and especially native apps on their smartphones, to be snappy and super responsive. Especially any interaction with the user has to be immediate or you can lose them in seconds. Google recommend the RAIL approach to performance.

Response

Your PWA has to feel natural and honour the action-reaction connection. This means you have about 100ms to respond to any user input, before they lose trust in the experience. On the other hand it also means that you have 100ms to perform a task or a piece of work before you have to give the user feedback. This might not seem like a lot of time, but in the programming world, it is significant. 

Of course you can have actions that will take longer than the prescribed 100ms, such as retrieving data from a web service, synchronizing some information or other known outdrawn task. If this is the case, then inform the user that they have to wait.

Animation

Performance during an animation is all about frame rate. Animations such as scrolling and pinching are only convincing if they are smooth, which means a target frame rate of 60 frame per second (fps). This means you have about 10ms per frame of the animation (after the browser gets hold of the instructions) to keep it smooth. 

Idle 

The best time to do your calculations and setting up is when the user is not interacting with the app, and it is idle. There are strategies to group units of work into blocks that can be done during idle time. The balance is to make sure you don't block the thread when the user needs it though.

Load

 We're talking about load time, not load of number of processes. You have to load your PWA in one second or less. Yes, 1000ms is the maximum time you have to load before users lose interest. Or worse, they think your app is broken. 

You don't have to load everything in one second, but enough to make the user believe in the experience. Use the idle time (above) to finish loading anything non-essential.

Engaging

There are no app stores for PWAs and they work on any platform with a supported browser. They can be installed to work offline and have an icon on the home screen to mimic any native experience. Heck, you can even send push notifications to your users.

Web App Manifest

The Web App Manifest is in charge of how your app is launched and how it appears on the device. You can specify what icons should look like, what the start page is for the experience, if you are showing the browser chrome or not, and more. The following is a simple example of a manifest file for a PWA.

x
22
 
1
{
2
  "short_name": "AirHorner",
3
  "name": "Kinlan's AirHorner of Infamy",
4
  "icons": [
5
    {
6
      "src": "launcher-icon-1x.png",
7
      "type": "image/png",
8
      "sizes": "48x48"
9
    },
10
    {
11
      "src": "launcher-icon-2x.png",
12
      "type": "image/png",
13
      "sizes": "96x96"
14
    },
15
    {
16
      "src": "launcher-icon-4x.png",
17
      "type": "image/png",
18
      "sizes": "192x192"
19
    }
20
  ],
21
  "start_url": "index.html?launcher=true"
22
}

Code from Google

Web Push Notifications

Just like allowing a PWA to work offline, service workers are also used for push notifications for the web. If you want to get technical push and notifications are two different APIs.  Push is invoked when a server supplies information to a service worker; a notification is the action of a service worker or web page script showing information to a user.

1
10
 
1
{
2
  "body": "Did you make a $1,000,000 purchase at Dr. Evil...",
3
  "icon": "images/ccard.png",
4
  "vibrate": [200, 100, 200, 100, 200, 100, 400],
5
  "tag": "request",
6
  "actions": [
7
    { "action": "yes", "title": "Yes", "icon": "images/yes.png" },
8
    { "action": "no", "title": "No", "icon": "images/no.png" }
9
  ]
10
}

A simple JavaScript object defining a push notification. Code from Google.

Your turn

If you have any experience with HTML, CSS and JavaScript, you will feel at home with PWAs. They build upon the basics and enables incredibly powerful experiences for users. They provide a best of both worlds, when it comes to native experience and cross platform capabilities. To start building your own PWA, you can use the Google tutorial, which is excellent.