Introduction

If you are a developer, then you have no doubt heard of Progressive Web Apps (PWA).  If you are a hybrid or web developer, then you may be considering developing your next application as a PWA.  There are already some great resources online explaining exactly what PWAs are and how to get started writing your own so I won’t cover any of that here; the top results you’ll find will be Google’s overview , Google’s getting started guide and another good getting started blog from a Google engineer, all dating back to late 2015 just after Google announced the methodology at their IO conference.

 

So, after a year in the wild you would expect the technology to have matured a bit.  In this blog I will look at PWAs from an enterprise perspective and see if they a sensible choice for an enterprise application.

 

What is a Progressive Web App (PWA)?

The important point about PWAs is that they are not a single technology, PWA is an umbrella term to describe a development methodology that encompasses numerous characteristics.  From Google’s own definition these characteristics are:

 

Progressive, Responsive, Connectivity independent, App-like, Fresh, Safe, Discoverable, Re-engageable, Installable, Linkable.

 

At first glance the focus on consumer use cases is evident.  Consumer applications are concerned with the discoverability of their applications in app stores [Discoverable], are seeking their users to engage frequently with their apps to maximize add revenue [Re-engageable] and are seeking to overcome the installation barrier where most users are dissuaded from installing an application in the first place as it involves multiple steps (visit app store, click install, wait for download, open etc) [Installable].

 

There is substantial overlap however between enterprise use cases and progressive web apps: As we see tablets proliferate in the enterprise space then [Responsive] apps increase in importance; keeping the application fully server-based avoids the need to coordinate application updates across remote devices [Fresh] and being [Connectivity Independent] might finally deliver on the promises made but never quite realised by Application Cache in HTML5

 

Are Progressive Web Apps a good fit for Enterprise Development?

As mentioned in the previous section there are clear benefits for enterprise applications to use a subset of Progressive Web app functionality.

 

Let us assume the following use cases when developing an enterprise progressive web app:

 

• We want to make use of service workers and cache so our application is available offline or during poor connectivity
• We want to use the Web manifest to remove the browser UI and brand our application with the appropriate theme colour, splash screen & icons.
• We do not want to rely on the end user installing the PWA themselves after being prompted by a mysterious Google heuristic.
• The connection to our server will be over HTTPS in line with best practice, PWA mandating use of HTTPS is therefore not a problem.
• We want our application to make use of push notifications

 

Critically here the enterprise requirement to not allow users to install progressive web apps themselves goes against the fundamental tenets of PWAs.  A primary use case of progressive web apps is that the end user will visit a mobile web site and then add that site to their device home screen, either after receiving a prompt or manually doing so through the browser menu. Adding the PWA to the home screen through any other technique is not supported by Google and further, we cannot prevent Google offering the installation popup to the user so long as our application meets the requirements of a PWA (i.e. it runs over HTTPS, has a service worker and has an application manifest).

 

Note: Although manually adding an application to the home screen is not officially supported, see the end of this blog for a discussion of how that might be achieved.

 

In conclusion

Progressive web applications are not suitable for Enterprise Development because they put the role of application management solely in the hands of the end user, bypassing any IT management solution.  By disallowing user-centric application management we also lose the branding benefits of being installable (icons on the home screen and a custom splash screen) so a manifest is also no longer required.

 

Being an umbrella term however we can choose to leverage those aspects of Progressive web applications which offer potential value to the Enterprise:

• Service workers
• Push notifications
• HTTPS
• Server-based application logic

 

Are Progressive Web Apps supported on Enterprise Devices?

As mentioned in the previous section, an end to end PWA solution is not applicable for Enterprise applications but we will leverage the best of what PWAs have to offer for our Enterprise use cases, specifically:

 

• Service Workers:   Bringing together previous functionality offered by ‘Web workers’ and ‘Application Cache’, Service workers seek to make an app function in a partially connected environment.

 

• Push notifications:  Making use of service workers’ background processing, push notifications offer a platform agnostic notification mechanism independent of Google / Firebase cloud messaging.

 

• HTTPS and server-based application logic:  Fundamental to the idea of a ‘web app’ is to ensure the latest version of your application is available on your device in a secure fashion.

 

Support for service workers and push notifications are delivered through Chromium and are therefore dependant on the webview being used.

 

A Chromium Blog from late 2014 states that Service Workers were introduced in Chromium version 40 however as with any software development I suspect the true level of support has been enhanced over time.  This blog is a good resource to track Service Worker status across the different versions of Chromium.

 

Which webview is in use can become confusing so please see below:

 

Chrome for Android: GMS devices will have Chrome for Android pre-installed as part of Google services along with other Google value adds such as the Play Store, location services etc. Chrome for Android (com.android.chrome) can be updated via the play store and is built on the Chromium open source project.  There are a number of variants present in the play store supporting different versions of Chromium e.g. Chrome Canary & Chrome Beta.  Importantly, you will not find Chrome for Android on non-GMS devices or be able to install it in a supported manner.

 

Android Browser: This will be used as the rendering engine for natively built applications that expose a webview to the user, for example Enterprise Browser and by default with Ionic, Cordova and PhoneGap.  The Android Browser also has a browser UI which will be the only browser present by default on non-GMS devices.  For enterprise GMS devices, it is conceivable that you would have two browsers: Chrome for Android and the Android Browser.  Prior to Android 5.0 (Lollipop) the Android Browser version was not independently updatable and required the whole Android OS to be updated. From Android 5.0 onwards the Android Browser is updatable through the Google Play Store under “Android System WebView” so a more recent Chromium version can be supported.  Android Browser tends to lag slightly behind Chrome for Android in terms of the version of Chromium supported.

 

Crosswalk: This popular third party browser view is also built on Chromium so will support service workers and push notifications. Crosswalk is popular amongst Enterprise developers as it provides a consistent and known webview instead of having to worry about which versions of Android Browser or Chrome are present on the device.  Developers of Cordova based applications may choose to use Crosswalk and there are tentative plans to add Crosswalk support to Enterprise Browser in a future version.

 

Opera: A third party browser built on Chromium.  Opera does not ship by default on any Zebra device but is an option for app development as it claims support for progressive web applications.  Opera could be a replacement for Chrome for Android with one possible use case being the application needs to run on a non-GMS device and the customer has side-loaded Opera onto devices as the default browser.

 

Is it supported on my device?

The best way to check if Service Workers or the Push API are supported on your target devices is to use the website ‘caniuse.com’:

 

ServiceWorkers / Cache: http://caniuse.com/#feat=serviceworkers

 

Push API: http://caniuse.com/#search=push%20api

 

Bearing in mind you are interested in either ‘Android Browser’ or ‘Chrome for Android’, depending on how you are targeting your application.

 

One limitation of the site is it only shows results for the latest version of Chromium supported by the browser.  For example you might have a non-GMS Lollipop device whose ‘Android Browser’ is not up to date with the latest ‘Android System WebView’.  In this instance, it is helpful to use https://www.whatismybrowser.com which will tell you the version of Chromium being run.

 

Code solutions to check for the presence of the JavaScript features would be to test as follows:

 

if ('serviceWorker' in navigator) {  console.log(‘service workers supported’);}

if ('PushManager' in window) { console.log(‘push messaging supported’);} 

 

Accessing Enterprise APIs

If you are writing an application to run on Enterprise devices then it is very likely you need to make use of enterprise hardware such as the barcode scanner, Bluetooth payment solution or NFC.

There are a number of ways to achieve this through a web app (though technically if you are using hardware APIs this could be classified as a hybrid application).

 

Enterprise Browser (EB)

Enterprise Browser is the Zebra recommended solution for developing web-based or hybrid applications.  As previously mentioned the webview in which your EB application is running is based on the Android Browser and therefore on Lollipop devices or above you should expect to be able to make use of service workers but not push notifications.  This is because at the time of writing Push Messaging is not supported in the Android Browser.

 

As well as many other features Enterprise Browser includes an “eb” JavaScript namespace offering JavaScript APIs for barcode scanning, NFC and much more.

 

Note that there are tentative plans for Enterprise Browser to more thoroughly flesh out which PWA features are supported on which devices in their documentation and samples.

 

DataWedge

DataWedge is a powerful service running on every Zebra device which offers a zero-code method to integrate with the device hardware.  To use DataWedge you define ‘profiles’ which describe how to control the hardware when specified applications come to the foreground, for example you can enable the barcode scanner when your application is launched.  Data would be returned to the application in the form of keystrokes, so scanning a barcode with the cursor in a text box would result in the text box being populated with the decoded data.

 

One advantage of DataWedge is it is able to run with any application being in the foreground, including Chrome for Android.  Since Chrome for Android supports the push API (unlike the ‘Android Browser’ at the time of writing) it would be possible to write a web application running in Chrome and utilising both push notifications and barcode scanning.

 

When defining the application to be associated with the Datawedge profile you would choose com.android.chrome.  The Chrome activity to choose is less obvious, if you were developing a true Progressive Web Application then the activity would look something like org.chromium.chrome.browser.webapps.WebappActivity0 but for a web-app just running in a Chrome tab it might be safest to specify * for the activity.

 

To view a list of current running activities you can run

$adb shell dumpsys activity

 

Custom proxy activity

Though a bit more work, it would be possible to interface with the device hardware by writing a custom android application which would act as a proxy between the web application and the native APIs.

The proxy application would expose some custom defined URI scheme which could then be invoked from the browser, similar to how clicking a tel:xxxx”>dial link will bring up the Android phone dialer.  Rather than dial a number however the proxy application could use native APIs such as the EMDK for Android to perform any action e.g. integrate with a Bluetooth payment peripheral.

 

Note however that this communication would only be one way, the options for returning data back to the calling web-app are limited and would require some ingenuity.

 

The linked stack overflow question is relevant to this scenario.

 

 

An Aside: Provisioning a PWA home screen icon

As mentioned earlier the only officially supported techniques for adding a PWA icon to the device home screen are initiated by the device user, either the user selects the relevant menu item from the browser menu or they give a positive response to a popup presented to them by Chrome after some Google heuristic determines they have been interacting with the web app sufficiently.

 

It would be nice if it were possible to have greater control over whether or not those icons are placed on the home screen and ideally provision a device so the Progressive Web Apps are already present without the user having to interact with the application at all.

 

It is possible to create a shortcut on the home screen using the undocumented INSTALL_SHORTCUT action but whilst creating a shortcut to a URL is straight forward, the intent to launch a progressive web app is more complicated (containing the application icon amongst other details).  The intent which we need to store in this shortcut and defines the PWA is undocumented but we can find out the details of shortcuts on the home screen using the technique detailed here.

 

Unfortunately, my attempts to reconstitute the Intent required to launch the PWA were unsuccessful. Invoking the intent directly from adb produced an unresolvable permission error and attempting to insert the Intent into a shortcut proved troublesome.

 

After a few hours of trying I did not pursue this avenue any further given the completely unsupported nature of adding shortcuts to the home screen on Android.  Your typical developer would not want to rely on this functionality continuing to work moving forward, further, there are currently no plans by Zebra to offer shortcut installation as part of their MX suite or Enterprise Home Screen.