 PWA – Progressive Web Apps 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. Because 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:
 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. Notice that the Service Worker has its own scope according to the used endpoint above to registry the Service Worker at /service-worker.js. This file will be at the project root because the scope will be the whole origin. If you put this file, for instance, at /js/service-worker.js, then it will only be able to intercept requests from its origin’s scope, that is, /js, which could be a problem. Once registered, the Service Worker will be downloaded and executed. After this, its first lifecycle event is to call the installer event. At /service-worker.js file you can add listeners to be called, for example, the install event. The code statement below shows how it’s done to install the Service Worker. The method event.waitUntil receives a promise; if the promise returns, the Service Worker will have access to API cache that can be used as an intermediate cache on the client side. We can see below how API cache is strongly promises based. After creating CACHE_NAME cache, we use the cache.add method to store GET responses for each arrays file on the cache. Those specific resources are being cached, because the users will be able to visit the pages that are mapped on the array files, even when offline. Service Worker Lifecycle There are 5 possible states on a Service Worker lifecycle:
Intercepting requests with Service Workers Every time the application is requested, a Service Worker is activated, the fetch event is fired, and the request is not sent directly to the server. The event handler decides how to handle the request. Below we see an example to handle cached information: There are many approaches to this matter. For further information, have a look at a demo app build. Summary Introducing itself as a new technology, its usage has allowed for a more “boosted” web, which means, we are seeing an evolution of the platform, where we can present an experience as good as any native/hybrid app to our users. With the Service Workers, we oversee the situation, because we have several functionalities. The concept of Progressive Web Apps with Service Workers is only the beginning and it keeps growing and growing. I hope you’ve liked it! Robert Farthing – Founder & CEO Loyalty Doctors, LLC www.LoyaltyDoctors.com Demo App http://app.loyaltydoctors.com/promo/loyaltyd6 
0 Comments
|
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |
RSS Feed 
