PWA Service Workers on Angular level?

Hi,

I am still experimenting with PWAs under iOS. Unfortunately, the App does not cache image resources, once the network connection is lost.

I tried to install the Corodva Service Workers plugin, but it throws an error during built - looks like it is outdated and not really usable anymore.

Would it be possible to implement Service Worker's Caching on Angular level?

https://angular.io/guide/service-worker-intro

Hello Harald,

I have no experience with service workers, however, I think we no need to do anything related with Angular, but with the Service Worker API. Are you try with that? Note that this is a more or less "draft" API and may don't work in all the browsers...

---

I digged further into it an successfully implemented the following scripts:

https://css-tricks.com/serviceworker-for-offline/

After this, the app runs fluently, even with a cut network connection. Here is the complete procedure:

Add this to AppOptions/HTML/CustomMetaData:

<script src="service-worker-global.js"></script>

Copy service-worker-global.js to the www folder:

(function() { var allNavItems = $(".main-nav li"); var allTabs = $(".tab"); allNavItems.on("click", function(e) { e.preventDefault(); allNavItems.removeClass("active"); allTabs.removeClass("active"); // this = list item $(this).addClass("active"); var selector = $(this).find("a").attr("href"); $(selector).addClass("active"); }); // ServiceWorker is a progressive technology. Ignore unsupported browsers if ('serviceWorker' in navigator) { console.log('CLIENT: service worker registration in progress.'); navigator.serviceWorker.register('service-worker.js').then(function() { console.log('CLIENT: service worker registration complete.'); }, function() { console.log('CLIENT: service worker registration failure.'); }); } else { console.log('CLIENT: service worker is not supported.'); } })();

Copy service-worker.js also to the www folder

"use strict"; console.log('WORKER: executing.'); var version = 'v2::'; /* These resources will be downloaded and cached by the service worker during the installation process. If any resource fails to be downloaded, then the service worker won't be installed either. */ var offlineFundamentals = [ '', 'app/images/card-info.png', 'app/images/card-news.png', 'app/views/Home.html', 'app/views/Info.html', 'app/views/Impressum.html', 'app/views/Datenschutz.html' ]; self.addEventListener("install", function(event) { console.log('WORKER: install event in progress.'); event.waitUntil( caches .open(version + 'fundamentals') .then(function(cache) { return cache.addAll(offlineFundamentals); }) .then(function() { console.log('WORKER: install completed'); }) ); }); self.addEventListener("fetch", function(event) { console.log('WORKER: fetch event in progress.'); if (event.request.method !== 'GET') { console.log('WORKER: fetch event ignored.', event.request.method, event.request.url); return; } event.respondWith( caches .match(event.request) .then(function(cached) { var networked = fetch(event.request) // We handle the network request with success and failure scenarios. .then(fetchedFromNetwork, unableToResolve) // We should catch errors on the fetchedFromNetwork handler as well. .catch(unableToResolve); /* We return the cached response immediately if there is one, and fall back to waiting on the network as usual. */ console.log('WORKER: fetch event', cached ? '(cached)' : '(network)', event.request.url); return cached || networked; function fetchedFromNetwork(response) { /* We copy the response before replying to the network request. This is the response that will be stored on the ServiceWorker cache. */ var cacheCopy = response.clone(); console.log('WORKER: fetch response from network.', event.request.url); caches // We open a cache to store the response for this request. .open(version + 'pages') .then(function add(cache) { /* We store the response for this request. It'll later become available to caches.match(event.request) calls, when looking for cached responses. */ cache.put(event.request, cacheCopy); }) .then(function() { console.log('WORKER: fetch response stored in cache.', event.request.url); }); // Return the response so that the promise is settled in fulfillment. return response; } /* When this method is called, it means we were unable to produce a response from either the cache or the network. This is our opportunity to produce a meaningful response even when all else fails. It's the last chance, so you probably want to display a "Service Unavailable" view or a generic error response. */ function unableToResolve () { /* There's a couple of things we can do here. - Test the Accept header and then return one of the `offlineFundamentals` e.g: `return caches.match('/some/cached/image.png')` - You should also consider the origin. It's easier to decide what "unavailable" means for requests against your origins than for requests against a third party, such as an ad provider. - Generate a Response programmaticaly, as shown below, and return that. */ console.log('WORKER: fetch request failed in both cache and network.'); /* Here we're creating a response programmatically. The first parameter is the response body, and the second one defines the options for the response. */ return new Response('<h1>Service Unavailable</h1>', { status: 503, statusText: 'Service Unavailable', headers: new Headers({ 'Content-Type': 'text/html' }) }); } }) ); }); /* The activate event fires after a service worker has been successfully installed. It is most useful when phasing out an older version of a service worker, as at this point you know that the new worker was installed correctly. In this example, we delete old caches that don't match the version in the worker we just finished installing. */ self.addEventListener("activate", function(event) { /* Just like with the install event, event.waitUntil blocks activate on a promise. Activation will fail unless the promise is fulfilled. */ console.log('WORKER: activate event in progress.'); event.waitUntil( caches /* This method returns a promise which will resolve to an array of available cache keys. */ .keys() .then(function (keys) { // We return a promise that settles when all outdated caches are deleted. return Promise.all( keys .filter(function (key) { // Filter by keys that don't start with the latest version prefix. return !key.startsWith(version); }) .map(function (key) { /* Return a promise that's fulfilled when each outdated cache is deleted. */ return caches.delete(key); }) ); }) .then(function() { console.log('WORKER: activate completed.'); }) ); });

Edit the offlineFundamentals array in service-worker.js. It should contain all your views and all image resources. All other dependencies are cached automatically then:

var offlineFundamentals = [ '', 'app/images/card-info.png', 'app/images/card-news.png', 'app/views/Home.html', 'app/views/Info.html', 'app/views/Impressum.html', 'app/views/Datenschutz.html' ];

If everything is OK, you can track the service worker's cache management in the console of e.g. Firefox Dev Edition:

WORKER: fetch event in progress. service-worker.js:62:11 WORKER: fetch event (cached) https://www.marketmix.com/pwa/marketmix/www/app/images/icon.png service-worker.js:103:17 WORKER: fetch response from network. https://www.marketmix.com/pwa/marketmix/www/app/images/icon.png

Hello Harald,

Thanks for share that information here. Can be very interesting for PWA (Progressive Web Apps). I have a question for you... why you use the "AppOptions/HTML/CustomMetaData"? Is not better to use the app's files management? If we add an script... that script is linked properly in the app's index.html file...

---

The scripts have to reside in the www folder to work properly. When I add them via filemanager, they are copied to www/app/...

Hello Harald,

Yes; certainly the scripts are copied into the app's files folder... however, what we need to put that script in the "www" folder? Is there any reason? Of course, I mention this, because, in principle, I can't see a reason to need to copy an script in an specific folder... if the script is linked... then we can use their stuff... or I am missing something...

---

If you put them into www/app, the the the cached URLs are not correctly assembled. Putting them into www just saved me the time to modify the original script ;-)

Hello Harald,

If I am not wrong... we can use relative paths... so if our scripts are placed in "www/app/scripts", maybe we can use something like this:

var offlineFundamentals = [ '../', '../app/images/card-info.png', '../app/images/card-news.png', '../app/views/Home.html', '../app/views/Info.html', '../app/views/Impressum.html', '../app/views/Datenschutz.html' ];

Note that the above is correct if the script is placed in "www/app/scripts"... in other words, if you place the above code inside the "app.js" (in the app's Ready event, or a view's Show event), when maybe you can use the URLs like before... not in a relative way than the above.

Try it, Harald, if you can do it, then you no need to place files in specific directories, etc.

---

Hi David

The only thing that works, is moving service-worker-global.js via AB Filemanager to app/scripts

Caching breaks, when there are double dots in the offlineFundamentals paths. Furthermore, if we would link service-worker.js vial Filemanager, it would be executed twice: By the generated link in index.html and when the script is registered by the global script:

navigator.serviceWorker.register('service-worker.js')

So at least service-worker.js has to reside in the www folder.

Hello Harald,

What if you change the "navigator.serviceWorker.register('service-worker.js')" for the right app's path? This means that, at least, you only need to touch that line of code?

---

I also tried that without success.

Hello Harald,

Then it's a bad thing... because the objective must be to no need to touch or take care about any file... I have no time right now in order to try it, Harald. Maybe I can do it in the future... because it's quite are... certainly, if an script refers to an specific file location... the questions must be why that specific location is used... and if we can do the job in other way, maybe moving that "require" to other file... maybe edit the script to refer to our file location...

I hope at least that, if there is not another way, you can get it working with not too much efforts...

---

It is OK for me. It is just 1 line more in the build script, which copies the file to the www folder. Thanks for your support!

So at least you can use another option in order to place the "copy" command, right? ;-)

---

Absolutely :-)

Hello Harald,

So... just to conclude... :-) Are you using the App options -> Cordova -> Batch or maybe the App options -> Build options?

---

Not in my case. I keep data on the Mac's side. Here I use a small script which fixes permissions and does the build and copy job.

If I would be a pure Windows user, I would prefer one of the other options. That's what I like on AB - it allows flexible solutions for most problems :-)

Hello Harald,

[...] That's what I like on AB - it allows flexible solutions for most problems :-)

Thanks for your kindly words, sir, I really appreciate it. :-)

---