The native vs. hybrid vs. web application war has been raging for years, with millions of apps having become zombies, trapped in app stores across the planet. Progressive web apps promise an end to those wars, but what are they and how can they change the mobile landscape?

Garr! Just about as soon as you put your feet up and rest after delivering your sweet web application to your boss, the next challenge does come! Your salespeople like the app, but they want it to look more “app-ey.”Sigh! Salespeople can be such a pain, and the boss isn't helping things any by saying, “IT developers can do anything.Yep. Anything to make everyone 'appy (I say in my best Cockney accent...).

The goal is to produce something that looks like a native app without being one (sheesh!). Time to poke around a bit in the ever-changing world of mobile development. You don't have to poke far because you have been keeping track of the progress of Progressive Web Apps (PWAs). In some respects, there isn't much new here. The stuff you have been talking to the boss about for years—about staying away from native apps because the browsers on mobile devices are basically going to evolve to the point where all the functionality you need is right there in the browser—has been borne out over the past few months. That “browser does it all” functionality has come true and your mobile web application delivered on almost every promise. But nothing stands still for long, and there have been loads of improvements in just the past few months. Our friends at Google and Mozilla haven't been sleeping.

So, PWAs are the way to go. But what are they? Rather than a new technology or framework, PWAs are really just a discipline in the way a mobile web app is created, developed, and delivered, with a few new APIs sprinkled in. Here are the basics:

• Fast startup—Even when disconnected from the Internet
• Background services
• Push notifications—Sweet!
• Local caching of resources
• Responsiveness—Looks good on mobile and laptop/tablet devices
• Installable—You get an icon on the home screen without effort

Plus there are other advantages that are less technical and more practical for your company. Chrome now has a billion mobile users, just to give an indication of the reach of the web on a mobile device. Mobile web apps are used 2.5 times more than a mobile app for accessing content. Building a web app, for all the reasons you stated to your boss, is about 1/10 the cost of building a mobile app presence. Users who use a mobile web app and, even better, a PWA are more engaged and return more often if the experience of AliExpress and The Washington Post is any indicator.

PWAs are called “progressive” because not all resources are automatically loaded the first time the app is loaded. Service workers monitor for access to each page or resource as it is loaded by the server, but then those resources are also added to cache for quick access later. Only what the user actually uses is retrieved. Your web app has been put on a diet (which reminds you to stop in at your local health club on the way home).

So let’s take a quick look at each of these features and see how we would implement them in our existing mobile web app.

Accelerated Mobile Pages (AMP)

This falls into a best practices + JavaScript library + Internet caching strategy category. Best practices is just our usual mantra of “be a good citizen”—refrain from including large JavaScript libraries, images, lots of CSS and eliminate some heavyweight HTML tags that slow the loading of a page. With AMP there’s a JavaScript library that contains code to help discipline your HTML development, and Google has created a caching CDN that will automagically cache and deliver your pages as they are requested, even if you have a slow server. Additionally, that CDN plus the JavaScript is designed to make sure that the latest content is delivered. If your server has more recent data, it’s fetched and cached. AMP is new, it's cool, and it’s designed to speed up your mobile app. We're in!

Service Workers

In concept, you’ve been using something like this all along; the Service Worker API has just made it all that much simpler for you. Using service workers, you can retrieve content in the background, receive push notifications, and cache content and an ever-growing list of additional services. The great feature about service workers is that once they’re installed and registered, they just continue to work in the background. And since they can be associated within a scope of a page or pages, you can have different service workers for different pages. But the cool part is that the service worker isn't tied to a page. It isn't like a regular JavaScript file that loads when the page loads and then is no longer referenced when you’re off the page. A service worker activates when your app is used for the first time and then quietly runs in the background, doing whatever you designed it to do. It might check for inventory updates or notifications from HQ. You might have a long-running query that it runs and returns the results from later with a notification flag. There are probably dozens of ways you could use service workers. Our original app design had these functional requirements:

1. Real-time access to IBM i data and local storage when no mobile connectivity is available
2. Ability to take pictures, store them on the device, and upload them
3. Ability to retrieve and store geolocation information
4. Ability to record audio for taking “audio notes”

A service worker could be created for each of these items. Grabbing data and caching for #1. Pushing the photos up to the server in the background on #2. You could have #3 done in your sleep, and #4 is just like #2. Service workers would replace some of your existing store and retrieve logic that was user-initiated with a background process that the user doesn't have to worry about.

Home ScreenIcon

To make your web app look more“app-ey,”you can include a home screen icon in your manifest file that you include with your app. The PWA is smart enough to notice whether the page has been accessed multiple times, and if so, it will prompt the user to optionally add the app to the home screen by using a Web App install banner.

Push Notifications

Wouldn't you love to send out a notification to your salespeople that they are exceeding a storage quota (clean up!) or that you have customers in an area they are visiting (sure, they can see that on their mapping app, but a notification could alert them to a local sales opportunity). You could push out almost any helpful notice to them without having to use a text message. They may actually pay attention to it!

Fetch API

All of your previous work was done using AJAX (XHR). Promises have made the asynchronous nature of the calls a little easier to handle, but what if you could write something like this:

fetch('url_that_returns_json') 

  .then( 

    function(response) { 

      if (response.status !== 200) { 

        console.log('No joy!. Status Code: response.status);

        return; 

      }

      // Evaluate the returned data 

      response.json().then(function(data) { 

        console.log(data); 

      }); 

    } 

  ) 

  .catch(function(err) { 

    console.log('Fetch failed', err); 

  });

The fetch API makes life easier for you. It’s brand new, so you might need a polyfill for unsupported browsers, but in your case, all your salespeople use Android with Chrome installed, so no problemo.

Other Benefits

Here’s something else to consider on your public site: No doubt your boss will show up (soon) asking for the same kind of web app for your order status inquiry web page on your website. Currently, customers come to your site, log in, and then get a page with a menu of options that allows them to choose among several panels of information. Some of the data is used, some isn't, yet you deliver the “whole tamale” to them when they sign in. Imagine them on a PWA! Wait! That means more work, and you already have a list of things to do to transition your sales web app to a PWA. Well, another adventure awaits! Better get on with it.

Peter Helgren is programmer/team lead at Bible Study Fellowship International. Pete is an experienced programmer in the ILE RPG, PHP, Java, Ruby/Rails, C++, and C# languages with more than 25 years of system 3X/AS400/iSeries/IBM i experience. He holds certifications as a GIAC certified Secure Software Programmer-Java and as an MCSE. He is currently executive vice president on the COMMON Board of Directors and is active on several COMMON committees. His passion has always been in system integration, and he focuses on open-source applications and integration activities on IBM i. Pete is a speaker/trainer in RPG modernization, open-source integration, mobile application development, Java programming, and PHP and actively blogs at petesworkshop.com.

---

MC Press books written by Peter Helgren available now on the MC Press Bookstore.

		Open Source Starter Guide for IBM i Developers Check out this practical introduction to open-source development options, including XMLSERVICE, Ruby/Rails, PHP, Python, Node.js, and Apache Tomcat. List Price $59.95 Now On Sale

Also Read

TechTip: A Primer to Bootstrap 4, Part 2

TechTip: A Primer to Bootstrap 4, Part 1

A Hand-Holding App Builder for Handheld Devices