Code Base for PWA

TABLE OF CONTENTS

1. Introduction to Progressive Web apps

2. Why Progressive Web Apps?

3. Objective of the Project

4. Advantages of Progressive Web App

5. Advantages of PWA over Native Apps

6. Benefits of Progressive Web App

7. Use Cases

8. The Future of PWA

9. Software Requirements

10. Reference

11. REQUIREMENTS GATHERING

12. Introduction to PWA Architectures

13. Introduction to PWA Architectures

14. Using libraries to code service workers

15. Add to Homescreen

16. Push Notifications

17. Payments and Credential Management

18. Recommended patterns for PWAs

19. CLUSTER AND OUTLINE OF PAGES

20. Code Base

21. Serve the app shell from the cache

22. Automate development tasks

23. Creating a package.json

24. Customizing the init process

25. Managing dependency versions

Code Base:

Folder structure

1. APP

App folder will contain the production code ready to go live.

1.1 . CSS

This folder will contain .css files which will be responsible for styling the app and designing purpose.

1.2 . data

This folder contains data.json.

1.2.1 data.json

JSON stands for JavaScript Object Notation. JSON is a lightweight data-interchange format. When exchanging data between a browser and a server, the data can only be text.

JSON is text, and we can convert any JavaScript object into JSON, and send JSON to the server. We can also convert any JSON received from the server into JavaScript objects. This way we can work with the data as JavaScript objects, with no complicated parsing and translations.

1.3 . images

This folder will contain all the images which will be required for Web Application on different pages.

1.4 js

1.5 index.html

1.6 manifest.json

Nobody likes to have to type in long URLs on a mobile keyboard if they don't need to. With the Add To home screen feature, user can choose to add a shortcut link to their device just as they would install a native app from a store, but with a lot less friction.

Web app install banners give the ability to let the users quickly and seamlessly add web app to their home screen, making it easy to launch and return to the app. Adding app install banners is easy, and Chrome handles most of the heavy lifting for you. We simply need to include a web app manifest file with details about the app.

Chrome then uses a set of criteria including the use of a service worker, SSL status and visit frequency heuristics to determine when to show the banner. In addition a user can manually add it via the "Add to Home Screen" menu button in Chrome.

Declare an app manifest with a manifest.json file

The web app manifest is a simple JSON file that gives the developer, the ability to control how the app appears to the user in the areas that they would expect to see apps (for example the mobile home screen), direct what the user can launch and more importantly how they can launch it.

Using the web app manifest, web app can:

· Have a rich presence on the user's Android home screen

· Be launched in full-screen mode on Android with no URL bar

· Define a "splash screen" launch experience and theme color for the site

· Track whether you're launched from the home screen or URL bar.

Create a file named manifest.json in your work folder and copy/paste the following contents:

The manifest supports an array of icons, intended for different screen sizes. At the time of this writing, Chrome and Opera Mobile, the only browsers that support web app manifests, won't use anything smaller than 192px.

An easy way to track how the app is launched is to add a query string to the start_url parameter and then use an analytics suite to track the query string. If we use this method, we should remember to update the list of files cached by the App Shell to ensure that the file with the query string is cached.

Tell the browser about manifest file

Now we have added the following line to the bottom of the <head> element in index.html file:

· Place the manifest link on all your site's pages, so it will be retrieved by Chrome right when the user first visits, no matter what page they land on.

· Define icon sets for different density screens. Chrome will attempt to use the icon closest to 48dp, for example, 96px on a 2x device or 144px for a 3x device.

· Remember to include an icon with a size that is sensible for a splash screen and don't forget to set the background_color.

Add to Homescreen elements for Safari on iOS

In index.html, we have added the following to the bottom of the <head> element:

Tile Icon for Windows

In index.html, we have added the following to the bottom of the <head> element:

1.7 Service-worker.js.

Progressive Web Apps have to be fast, and installable, which means that they work online, offline, and on intermittent, slow connections. To achieve this, we need to cache our app shell using service worker, so that it's always available quickly and reliably.

Features provided via service workers should be considered a progressive enhancement, and added only if supported by the browser. For example, with service workers we can cache the app shell and data for the app, so that it's available even when the network isn't. When service workers aren't supported, the offline code isn't called, and the user gets a basic experience. Using feature detection to provide progressive enhancement has little overhead and it won't break in older browsers that don't support that feature.

The first step to making the app work offline is to register a service worker, a script that allows background functionality without the need for an open web page or user interaction.

This takes two simple steps:

· Tell the browser to register the JavaScript file as the service worker.

· Create a JavaScript file containing the service worker.

First, we need to check if the browser supports service workers, and if it does, register the service worker. Add the following code to app.js

When the service worker is registered, an install event is triggered the first time the user visits the page. In this event handler, we will cache all the assets that are needed for the application.

When the service worker is fired, it should open the caches object and populate it with the assets necessary to load the App Shell. Create a file called service-worker.js in your application root folder (which should be your-first-pwapp-master/work directory). This file must live in the application root because the scope for service workers is defined by the directory in which the file resides. Add this code to your new service-worker.js file:

First, we need to open the cache with caches.open() and provide a cache name. Providing a cache name allows us to version files, or separate data from the app shell so that we can easily update one but not affect the other.

Once the cache is open, we can then call cache.addAll(), which takes a list of URLs, then fetches them from the server and adds the response to the cache. Unfortunately, cache.addAll() is atomic, if any of the files fail, the entire cache step fails!

Alright, let's start getting familiar with how you can use DevTools to understand and debug service workers. Before reloading your page, open up DevTools, go the Service Worker pane on the Application panel. It should look like this.

When you see a blank page like this, it means that the currently open page does not have any registered service workers.

Now, reload your page. The Service Worker pane should now look like this.

When you see information like this, it means the page has a service worker running.

Now we're going to take a brief detour and demonstrate a gotcha that we may encounter when developing service workers. To demonstrate, let's add an activate event listener below the install event listener in your service-worker.js file.

The activate event is fired when the service worker starts up.

Open up the DevTools Console and reload the page, switch to the Service Worker pane in the Application panel and click inspect on the activated service worker. You expect to see the [ServiceWorker] Activate message logged to the console, but it didn't happen. Check out your Service Worker pane and you can see that the new service worker (that includes the activate event listener) appears to be in a "waiting" state.

Basically, the old service worker continues to control the page as long as there is a tab open to the page. So, you could close and re-open the page or press the skipWaiting button, but a longer-term solution is to just enable the Update on Reload checkbox on the Service Worker pane of DevTools. When this checkbox is enabled, the service worker is forcibly updated every time that the page reloads.

Enable the update on reload checkbox now and reload the page to confirm that the new service worker gets activated.

Note: We may see an error in the Service Worker pane of the Application panel similar to the one below, it's safe to ignore this error.

Let's expand on the activate event listener to include some logic to update the cache. Update code to match the code below.

his code ensures that your service worker updates its cache whenever any of the app shell files change. In order for this to work, you'd need to increment the cacheName variable at the top of your service worker file.

Finally, let's update the list of files required for the app shell. In the array, we need to include all of the files our app needs, including images, JavaScript, stylesheets, etc. Near the top of your service-worker.js file, replace var filesToCache = []; with the code below:

Our app doesn't work offline quite yet. We've cached the app shell components, but we still need to load them from the local cache.