An explanation of Progressive Web Apps for the non-PWA crowd
Tags: Pwa, Programming, Tech, Web Development, Coding

The world of applications was classified into two categories not too long ago. You were either creating an application for Android devices or for iOS. Enter PWAs, or elongated, Progressive Web Applications. You have probably been hearing all about them for the past couple of years, but besides a nice acronym, you have no idea what a PWA is. As their popularity increases, it might be a good idea to get to know what all the fuss is about.

In this article, I’ll take you on a tour of what a PWA is, what components it is built from, and show you how you can make one on your own.

The Basics

A progressive web application is a website turned into an application. What this means is, that instead of having to code either in Java or Objective-C (or more recent mobile coding languages), you can write the code for the application, like you would for a website. You have your html files, your stylesheets, and your scripts.

Why would you build a PWA instead of a native application? For starters, imagine that once you release a PWA, you can change it constantly without having to republish your application. Since all the code is hosted on a server and not part of the APK/IPA, any change you make happens in real time.

If you have ever used an application that relies on a network connection, you are familiar with the frustration of not being able to do anything. With PWAs, you have the ability to offer an offline experience to your users in case of network issues.

And to add the cherry on top, there is an ability to prompt the user to add your PWA to their home screen. Something that native applications do not possess.

Components

There is a standard regarding a PWA, and you must adhere to it if you want to publish one. Each PWA is built from the following components:

A web app manifest

A service worker

Install experience

HTTPS

Creating an APK

Lighthouse audit

The Manifest

This is purely a configuration file (.JSON), enabling you to change various settings of your PWA and how it will appear to the user. Below is an example of one:

manifest.json

You must set either a name/short name key. When setting both, short name will be used on the home screen and the launcher. The name value will be used in the Add to Home Screen experience (or, application install prompt).

Display can have four different values:

fullscreen - this allows your application to take up the whole screen when it is opened

- this allows your application to take up the whole screen when it is opened standalone - your application looks like a native application, hiding browser elements

- your application looks like a native application, hiding browser elements minimal-ui - provides some browsing controls (only supported for Chrome mobile)

- provides some browsing controls (only supported for Chrome mobile) browser - like the name says your application’s look will be identical to a browsing experience

You can also set the orientation of your application and the scope of the pages considered to be within your application.

Don’t forget to add the manifest to your main html file by putting the following meta tag inside of your head tag:

Photo by sol on Unsplash

The Service Worker

A service worker is a component running in the background of your website on the browser. It has a wide set of functionalities including, push notifications, caching assets and providing them for an offline experience and the ability to defer actions until the user has a stable connection to the internet. A service worker can be a whole Medium article on its own, so I won’t delve into the inner details of how it works. But, I will supply a vanilla example of one for you to use in your PWA.

It is customary to save the code related to the service worker in a file called sw.js.

✋ The location of the service worker is important since it can only access files that are in the same directory or subdirectory as itself.

A service worker has a lifecycle that can be summed up to the following phases:

Registration

Installation/Activation

Responding to various events

Pay attention to the comments to understand where to place the different lines of code

Install Experience

One of the unique features of a PWA is its install experience. What this translates to is prompting the user to install your application. To allow us to present this ability to the user, we will need to listen in on an event called beforeinstallprompt. Below is a code sample demonstrating the flow from presenting the user with the option to add the application to activating logic based on their choice.

Install Experience Flow

Photo by James Sutton on Unsplash

HTTPS

Not too long ago, websites could still use the all too common http protocol. Due to recent changes in security and in Chrome, all websites that do not operate under the https protocol will be marked as not secured. Even if your website does not handle user data or sensitive communication, it is still good practice to switch over to https.

And like I mentioned earlier, if you want to be able to release a PWA, it has to use the https protocol. If you don’t want to get into the hassle of acquiring a domain, finding a proper host for it and then enabling SSL, you can go for the easy option of Github. If you have an account, you can open a repository and set up a GitHub Page. This process is fairly simple and straightforward and the bonus is getting the HTTPS built in as part of Github.

Creating An APK

In order for our PWA to be available inside the Google Play Store, we need to create an APK. You can use the popular tool, PWA2APK, which will do the hard work for you. But if you prefer to learn how to do it yourself, keep reading.

Google has introduced a new way to integrate your PWA into the Play store using what is called a Trusted Web Activity, or TWA. With just a few simple steps you will learn how to create a TWA, which you can then upload to the Play store.

Open Android Studio and create an empty activity Go to the project’s build.gradle file and add the jitpack repository

3. Go to the module level build.gradle file and add the following lines to enable Java8 compatibility

4. Add the TWA support library as a dependency

5. Add the activity XML inside your AndroidManifest file between the application tags

Replace the android:value and android:host with your URL

6. We need to create an association from the application to the website using a digital assets link. Paste the following inside your strings.xml file

Change the site value to point to your URL

7. Add the next meta tag as a child to your application tag inside the AndroidManifest.xml

8. Create an upload key and keystore

9. Use the following command to extract the SHA-256

Remember the details you entered when generating a keystore and your upload key

10. Go to the assets link generator, supply the SHA-256 fingerprint, the package of your application and the web site's domain

11. Place the result in a file named assetlinks.json under the location /.well-known in your website’s directory. Chrome will look for this destination specifically.

12. Generate a signed APK and upload to the Play store

Photo by Aaron Burden on Unsplash

Lighthouse

By now, I am sure you have already lost track of what is required from your PWA so it will be valid for publishing. There are so many things to take into consideration, that it is easy to lose track of what the requirements are.

Luckily for us, Google has created Lighthouse. It can be found in the Chrome Developer Tools (from Chrome version 60). It can be accessed easily by right-clicking inside the browser and selecting inspect. When the new pane opens, you will see an Audits tab at the far right corner.