PWA

• A Progressive Web App is a type of web application which can be used as a web page
and mobile app on any given device. PWAs are created by fulfilling the majority of
requirements listed in Google's checklist, after which a Progressive Web Application is
fast, reliable and engaging.
• Progressive Web Apps are user experiences that have the reach of the web, and are:
• Reliable - Load instantly and never show the downasaur, even in uncertain network
conditions.
• Fast - Respond quickly to user interactions with silky smooth animations and no janky
scrolling.
• Engaging - Feel like a natural app on the device, with immersive user experience.
 KEY ADVANTAGES OF PROGRESSIVE WEB APPS

• Mobile-first approach. PWAs are the direct answer to mobile users’ needs and allow businesses to build
web solutions that first and foremost work excellently on mobile devices.
• All in one. With a PWA, it is possible to develop a web page and app at the same time with lower costs
and a shorter time-to-market. On the other hand, users don’t have to visit app stores to get the app; they
can install it directly from the browser.
• Short loading times. PWAs load 2-3 times faster than responsive web pages, so users don’t get annoyed
with loading bars and get instantly engaged.
• Native-like UX. Push notifications, icon on the homepage and offline access are some of the native app
features that come with PWAs.
• Offline capacity. A lot of customers suffer from low internet connectivity. A PWA allows them to continue
browsing without obstacles. a PWA’s offline readiness also supports traffic peaks on Black Fridays.
• SEO-friendliness. A PWA can be optimized according to Google’s guidelines and indexed by Googlebot,
COMPARISON
 TECHNICAL COMPONENTS OF PWAS
• The Web App manifest
• The Web App manifest — a JSON file — is the first component that gives the progressive its native app
interface appearance. With the manifest, a developer can control the way the app is displayed to the
user (i.e. full-screen mode without visible URL bar) and how it can be launched. The file allows a
developer to find a centralized place for the web app’s metadata. The manifest usually contains starting
URL, an app’s full and short name, links to icons and icons’ sizes, type, and location. A developer can
also define a splash screen and a theme color for the address bar.
• Service Worker
• A service worker is another technical element that supports one of the main features of progressive
web applications — the offline work mode, background syncs, and push notifications typical for
native apps. The service worker is a JavaScript file running separately from the web page/app. It
responds to user interactions with the app, including network requests made from pages it serves.
Because the service worker runs only to process a specific event, its lifetime is short.
• Offline work mode. The service worker allows for caching an application shell (interface), so it
loads instantly on repeat visits. The necessary dynamic content (i.e. message or payment history,
shopping cart, avatars) is refreshed every time the connection is back. These mechanics allows for
decent app performance and improved user experience. For example, a messenger user won’t see
the difference between the online and offline modes regarding interface: It still works; a message
history is available. However, messaging requires connection.
• Push notifications. Push notifications are an efficient tool for user re-engagement through the
content and prompt updates from websites they like. Progressive web apps can send push
notifications even when the browser is closed, and the app isn’t active.
• Background synchronization. The service worker is also in charge of this feature. It delays
actions until stable connectivity is back. For example, the message sent right before the connection
fails will be marked as sent and then will be delivered as soon as service is restored. So, servers can
send periodic updates to the app allowing it to update itself when the connection is restored.
• Transport Layer Security (TLS)
• PWAs leverage the Transport Layer Security (TLS) protocol. TLS is the standard of secure
and robust data exchange between two applications. The integrity of the data requires
serving the website via HTTPS and installing an SSL certificate on a server.
 CONS OF PWAS

• PWAs aren’t only about pros: Their drawbacks are directly connected to the benefits.
• Limited functionality and increased battery use compared to native apps
• Despite their progressiveness, these are still web apps. Without access to device hardware,
PWAs can’t support such native-app typical features as fingerprint scanning, vicinity sensors,
NFC, Bluetooth, geofencing, inter-app communications, and advanced camera controls. While
app sharing via URL is convenient, it requires the connection, which drains a device battery
faster than a native app.
• Search traffic losses due to no presence on app stores
• We mentioned that presence on app stores eliminates several steps users take before running an
app, which reduces installation friction. Mobile web traffic can be redirected to an app store to
showcase the app to users, while not being in an app store leads to potential traffic losses.
 MANIFEST
• {
•     "name": "input type PWA example",
•     "short_name":"PWA input type ex:1",
•     "display" : "standalone",
•     "background_color": "#0000FF",
•     "theme_color": "#00FF00",
•     "orientation" : "portrait-primary"
•   
•   }
 CONFIGURING DISPLAY MODE

• The web app manifest specification enables developers to set how the browser renders an
installed app’s UI using the display property. The available options control how much of the
browser’s UI (its chrome) displays around the app window. The supported options are
 fullscreen
 standalone
 minimal-ui
 browser
Remember, one of the criteria for a browser to consider an app installable is a display property
set to fullscreen, standalone, or minimal-ui.
The browser property value does not affect PWA app installation through the web app manifest.
• Offline work mode.
• Push notifications.
SERVICE WORKER
• Background synchronization.
• Service workers are java script file which runs in background process
 SERVICE WORKER
• It runs in the background even if we runs it in browser or closes the browser and even if we
closes the app
• There job is to handle app like functionalities, applied functionalities by listening and
reacting to events that occur in browser such as puch notification, fetch http request
• Sw.js file is created in the root of the file since it give access to all files
Steps to creating service register
1.Step 1: Register it with the browser---will in done outside the sw.js file ..
2.Step 2: Install the service worker
3.Step 3: Browser fire an active event---once its active sw.js file can acess all
files in root directory
SERVICE WORKER
 STAGES
• If the page is reloaded the service worker will get registered if there is any change happened from that time after
which it was installed earlier
If there is any change in service worker file it installs and waits in waiting, UNTIL ITS MADE ACTIVE
Until new service worker file is activated, the old sw.js file will be active.
It will become active only after all tabs related to that app is closed in browser of if the app is totally closed and reoped.
• Include the source file in the body of the main pages that is present in your application
• Eg.
• <script src=“/js/app.js”</script>
Registering the service worker in app.js file ( you cam use any file name.js)
• if ('ServiceWorker' in navigator) {
•     navigator.serviceWorker.register('/sw.js')
• .then((reg)=>console.log('service worker registered',reg))
• .catch((err)=>console.log('service Worker not registered',err));
• }
 SERVICE WORKER
sw.js
//install service worker
self.addEventListener('install',evt=>{
    console.log('service worker has been installed')
});

//activate service worker

self.addEventListener('activate',evt=>{
    console.log('service worker has been activated')
});
 FETCH
SW essentially acts as a proxy between our app and the server. Once our app makes a request anything from the server, the
server processes it and sends back its service .When there is sw.js present in between here it keep on listening for fetch
request and server response.
 Based on the listening of the sw.js file , it can fetch events.
 If the user want to intercept the request , then it can be done in sw.js file.
 Since all the actions are saved as cache assets in sw.js file.

// activate service worker

self.addEventListener(‘fetch',evt=>{
    console.log(‘fetch event‘,evt);
}
 DATA OFFLINE
You can emulate this offline emulator behavior in service worker ,by clicking offline inside service worker or also in
network tab also.
PWA has the abilot to load content offline mode.
 CACHE API
Different types of Cashe
Browsher Cashe ..eg.Images ,
-so that we need not download images each time when we open the browser.Problem is that it stores and manages all data by itself. We don’t have any
control on that..In order to stop the browser cache we will disable it in network tab
• Service worker can fetch assets from cache much quicker than from server.
• So if we pre cache assets with the service worker first load, then we can improve the performance of the app fro the future both in online
and off line mode.
• Pre cache assets in general will be those items that we will be using in all pages of our app eg.logo
• Its Best to include it in install event of the service worker file
• Reason is that it will be not be installed every time we reload the load ,It reinstall only if we make any changes in the service register file.

const staticCacheName = 'site-static';

const assets = [
'/',
'/index.html',
'/js/app.js',
'/js/ui.js',
'/js/materialize.min.js',
'/css/styles.css',
'/css/materialize.min.css',
'/img/dish.png',
'https://fonts.googleapis.com/icon?family=Material+Icons',
'https://fonts.gstatic.com/s/materialicons/v47/flUhRq6tzZclQEJ-Vdg-IuiaDsNcIhQ8tQ.woff2'
];
• // install event
• self.addEventListener('install', evt => {
•   //console.log('service worker installed');
•   evt.waitUntil(
•     caches.open(staticCacheName).then((cache) => {
•       console.log('caching shell assets');
•       cache.addAll(assets);
•     })
•   );
• });
 INTERCEPTING THE FETCH
REQUEST
• // fetch event
• self.addEventListener('fetch', evt => {
•   //console.log('fetch event', evt);
•   evt.respondWith(
•     caches.match(evt.request).then(cacheRes => {
•       return cacheRes || fetch(evt.request);
•     })
•   );
• });
 CONNECT MIT APP TO SERVER
• https://www.000webhost.com/
• Once you sighup and login to will land up in this webpage

• https://www.000webhost.com/members/website/list
FIRE BASE