Progressive Web App

From MgmtWiki
Revision as of 21:44, 14 May 2019 by Tom (talk | contribs) (References)

Jump to: navigation, search

Full Title or Meme

Progressive Web App (PWA)

Context

You certainly have already accessed a mobile website, also known as Web App, and during this access you may have noticed that most of the time they were slow and heavy, making the experience frustrating and disheartening.

The good news is that many developers have been working hard to build their web apps as fluid as those from the App Store.

The main point here is that any app from the store needs to be native or hybrid, which means, you must install it on your device and accept terms and conditions before you even try it. Let’s face it, it can be very frustrating, after all, having to install and uninstall several apps, or even install it for just one time usage is not something very practical. We must also consider that mobile Internet can be expensive and somehow limited, so if you need to download a 30 MB app, it will take a while and you risk running out of available connection.

pwa websiteBecause of that, the concept of Progressive Web Apps ( PWA ) came into being. It is all about an app that uses resources from a modern Web Browser to present a similar experience the user would have with native/hybrid apps; but in this case, they are build using HTML, CSS and JavaScript.

Right now, you must be wondering which is the difference between Web App and Progressive Web App.

The difference is that PWA is a “boosted” Web App. We have 10 key concepts, based on Google’s Patterns, that must be met to classify a Web App as a PWA:

Safe – It must use the HTTPS protocol to protect the privacy and integrity of the exchanged data. Progressive – It must work for all the users, regardless of which browser is used, because the app should be built using progressive enhancement patterns. Responsible – It must fit on any screen size: desktop, mobile phones, tablets, etc. Internet-free – With the Service Workers’ technology it is possible to access the application on bad quality connections or even offline. App-like – User should have the same experience as any other native/hybrid application; this is because of the app shell model. Always up to date – User should not download any updates. Since it is a web site, all the updates must happen in the background. Detectable – It must be identified as “application”. Thanks to W3C manifest and a proper Service Worker registry it is possible to allow the search engines to find them. Re-engageble – It should increase the engagement by push notification to bring the user back. Installable – It must allow the user to create a shortcut on his initial desktop with a personalized icon, without any resources from the store. Shareable – It must be easy to be shared with only its URL to anybody and it must keep being easy to install. Following those patterns, you will ensure that your application works very well, not only when accessed by a browser, but also by a shortcut icon.

What Progressive Web Apps is not? Any technology that needs to package executable files, whether it is a .apk, .exe, or any other that needs to be downloaded from the App Store and installed on the user’s device.

PWA does not need any installation, you just need to access the web site and create a shortcut. You do not have to concern yourself about the development and management like it is done for iOS, Android and Windows, but you must pay attention to browser support. Currently, iOS does not support everything; in that case, you must find another solution, like the appCache missing, which should be used for offline access. You may verify the iOS ‘s full support for Service Workers here.

And how is all this possible? Thanks to an event oriented script called Service Workers, which is executed by the browsers that support it. Even with a site running offline, you will be receiving push notifications, geolocation, background updates, interceptions and images cache, JavaScript, CSS files, XHR, etc. This script works like a set of functionalities.

The Service Worker does not have access to DOM, it runs on a different scope from the page, it is promise based, and it must run with HTTPS protocol. That said, let’s see an example.

The code statement below shows us how the Service Worker is progressive enhancement based; this resource test ensures that it runs even on older browsers. This is the whole code that references the Service Worker; it is in this moment that the Service Worker is registered. The code will be at /js/install.js. We’ve also worked around to work locally.

References


=Other References