Offline install issue about vamigaweb

[Vweber73]

When you feel it's ready! :)

[mithrendal]

Yes. I did and will do change the versions without and with version management a couple of times. In order to test a smooth migration for the regular version in mind.

Hard to test otherwise. Testing phase will finished today or tomorrow…

[mithrendal]

@Vweber73

1. could you test vc64web.github.io whether you see the issue there too ?
2. could you test vAmigaWeb.github.io on your iPodTouch or iPad ?

can you post the message which pops up ?

[Vweber73]

Hi,

1. On my Z3 In flight mode no problem to start vc64, even after closing all app's, but...the same thing with vAmigaWeb ! It seems that the failure on startup is not systematic, that sometimes everything is cached ok.
2. On my ipod touch in flight mode, first startup of vAmigaWeb is ok. Closing the app and restart gave the error attached.
   Cheers
   

[mithrendal]

2.On my ipod touch in flight mode, first startup of vAmigaWeb is ok. Closing the app and restart gave the error attached.

do you remember when did you turn WLAN off ? Was it after the first startup?

[mithrendal]

Why I am asking this is because it seems that vAmigaWeb has a wrong implementation of the service workers lifecycle...

there is a lifycycle which is describe here https://flaviocopes.com/service-workers/#activation

it explicitely says

The Install stage
If the browser determines that a service worker is outdated or has never been registered before, it will proceed to install it.

self.addEventListener('install', (event) => {
  //...
});
This is a good event to prepare the Service Worker to be used, by initializing a cache, and cache the App Shell and static assets using the Cache API.

what does our service worker ?

vAmigaWeb/sw.js

Lines 4 to 7 in 1024a74

	self.addEventListener('install', evt => {
	console.log('service worker installed');
	});

correct nothing... it does not fill the cache ...

then after install of the new service worker i.e. after the app has been closed or reloaded activation stage begins ...

The activation stage is the third step, once the service worker has been successfully registered and installed.
...
It cannot interact with pages already loaded, which means the service worker is only useful on the second time the user interacts with the app, or reloads one of the pages already open.

A good use case for this event is to cleanup old caches and things associated with the old version but unused in the new version of the service worker.

now see look at what we do in activation 🙄

vAmigaWeb/sw.js

Lines 9 to 20 in 1024a74

	self.addEventListener('activate', evt => {
	console.log('service worker activated');
	evt.waitUntil(
	caches.keys().then(keys => {
	console.log('deleting cache files:'+keys);
	return Promise.all(keys
	.map(key => caches.delete(key))
	);
	})
	);
	});

we delete the old existing version and have nothing in cache after this event .... we rely that the following fetch events will fill the new version into the cache automatically

under which circumstances is vAmigaWeb not offline capable ?

1. you start vAmigaWeb -> there is a new version on the server
2. it detects this and fires the install event -> we do nothing
3. you close the app
4. turn on flight mode / offline
5. start the app -> new service worker activates -> deletes caches
6. wants to load new version from server -> booom!

that means vAmigaWeb is offline capable as long there is no new version on the server ... when there is a new version on the server it will install it after the current app has been closed and reopened .. the button "update installation" does fill the old cache because the new service worker has not been activated yet ... so when clicking "update installation" manually it will install this twice

[Vweber73]

I don't remember if I started vAmigaWeb a first time before switching off WLAN... maybe...
I tried again: I closed the app (which was on the error page I sent), switched WLAN off (it was on again), and started vAmigaWeb again: same error...
I switched WLAN off, came back to the app, booted fine. I closed the app, switched WLAN off, started vAmigaWeb, this time it booted fine.

Does it help ?

[mithrendal]

I switched WLAN off, came back to the app, booted fine. I closed the app, switched WLAN off, started vAmigaWeb, this time it booted fine.

you mean the first off is an on right ?

if yes , then yes that helped ... and from now on vAmigaWeb is offline capable on your iPod touch until we publish a new version again ...

okay we can fix this by implementing the PWA install event correctly ...

[Vweber73]

Yes, sorry i meant "ON".
Great news ! same on my Z3 ? New version out ?
Cheers

[mithrendal]

No new version out. What do you mean with „same on my z3“? Do you mean that once we move the installation from fetch to installation event whether that fixes it too on the z3 then the answer is yes 😀

[Vweber73]

I thought you said you fixed the problem for iOS, but not necessarily for Android.

[mithrendal]

Yes it is platform independent. I screwed up the PWA livecycle … when I correctly implement it then it should be ok

for now it is only partial offline capable 😬

[Vweber73]

Got it, thanks !

[mithrendal]

for reference a how to guide for implementing updates which are controlled by the user instead of automatic

https://whatwebcando.today/articles/handling-service-worker-updates/

[Vweber73]

Interesting, thanks !

[mithrendal]

That is a receipt for me how I have to change the installation process…

[mithrendal]

Hi just wanted to report that I am on my journey of making the "offline" installation process more transparent to the user.

Here are two screen shots which did ...

first when a new version is available it will report this with a toaster message to the user and let him decide whether to install or skip ...

the second screen shot shows that in the settings dialog there is now information about what is currently installed

I also like to try whether it is maybe possible to switch between several installed versions ... this way also older snapshots would be still playable...

[Vweber73]

Hi,
Excellent, many thanks!
It seems there is no new version online yet?
Cheers

[mithrendal]

no ... I don't dare to push it to uat.... It is still so alpha...

should I dare it?

[mithrendal]

development version on my mac does not delete older installations anymore and can therefore activate different versions of vAmigaWeb ... solving thereby the "broken snapshot on upgrade to new version" problem ...

see here three different versions are installed ...

the list of installed versions would become too big over time, no? 🙄

how to design the deletion of older versions 🤔? hmm.... lets think about it tomorrow 😴

[Vweber73]

I personnally don't require several versions installed at one time :) but if the feature is there, why not, thanks!
Cheers

[mithrendal]

I will put it to uat now....

when you got an older version without installation management then it will enforce the upgrade as usual ... once you are on the newer version ... everything will be completely transparent ... and off line mode should work reliably ...

[Vweber73]

Excellent, thanks!
First time I tried I got this... But I relaunched and it was OK. Only a one off problem?

[mithrendal]

yes me too ... just pushed a bugfix

[Vweber73]

Great!

[mithrendal]

I did reatart the app a few times without clicking “update installation” and it gives me this

Looks as it does work on iOS 😎

[Vweber73]

Works well on my side! And doesn't even break my snapshots :)

[mithrendal]

No because the core is still the same 😂

now we can upgrade to beta3 soon without fear. Because we can always go back in history 😎

[Vweber73]

Fantastic job! Thanks and cheers

[Vweber73]

Hi,
Today the uat version was back to prior the versions management feature. I upgraded and this version was restored, but without letting me install previous versions as before. The version is dated yesterday, has anything changed?
Cheers

[mithrendal]

new version out. Uat and regular 😎