I have a Flutter web app that is deployed on Firebase Hosting. When deploying a new version Safari does not pick up the new version even when doing refresh. I assume this is due to the installed service worker, that will serve the old content. How can one bypass this problem? I know that a hard refresh solves the problem, but that is not a good solution as we cannot expect the users to know to do that.
One alternative that requires client code, would be that I track the current version of the app that is currently loaded, and if that change I create "New version available" screen when I detect that a new version is available, and perform a location.reload(true) call from the client to bypass cache and get the new service worker installed.
Any other options?
In more recent versions, they are appending a random hash on every build to the flutter_service_worker.js URL so it should break the cache and refresh properly.
Related
I have just created a hosted blazor webassembly pwa project, which generates client, server and shared projects, all fine. I start the solution and everything runs fine.
But after I start to add small changes to the projects it stops working with a message like this:
"Failed to find a valid digest in the 'integrity' attribute for resource '' with computed SHA-256 integrity '47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU='. The resource has been blocked."
I search the net and stack overflow and find others having almost the same problem. Some can do clean and rebuild to solve this, but that's not working for me.
So, what is this? Why is this happening, totally useless?
Is it the PWA feature? Should I create a new solution without the pwa enabled?
It started happening to me recently. Only on a published released solution. Not on local debug.
Clean+rebuild didn't work for me. I had to delete bin and obj folders from both Client and Server (note: tried client only and, it did not work but, did not try server only) then republish.
cf. Failed to find a valid digest in the 'integrity' attribute for resource in Blazor app
It now occurs each time I upgrade or downgrade a package.
I've done several tests and can confirm :
DLL are the right ones (SHA256 hash validated) on the server.
the string in the blazor.publish.boot.json is the right ones.
I was even able to get rid of the problem by reverting to the previous package version prior to the bug (which changes back the related entry in blazor.publish.boot.json). Which for me confirms a reference is not updated somewhere.
The only significant changes I've made recently are switching to VS2022 and .NET6. The bug appeared after I did my first successful publish on Azure through VS2022: 1st package upgrade after that triggered the bug.
Today I see that many articles were released about Flutter 2.2 and its new functionality. One of them is background caching using service workers. Has anyone an idea of what does it mean and how to use it?
for web apps, we offer background caching using service workers
UPDATE:
Ok I've found some information in this article
Flutter’s newest stable platform, web, has been improved in this release.
To start, we’ve optimized caching behavior with a new service worker-loading mechanism, and fixed double-downloading of main.dart.js. In previous versions of Flutter web, the service worker downloaded updates to your app in the background while giving your user access to the stale version of your app. Once that update was downloaded, the user wouldn’t see those changes until they refreshed the browser page a couple times. As of Flutter 2.2, when the new service worker detects a change, the user will wait until the updates are downloaded to use the app, but then they’ll see the updates without requiring a second manual refresh of the page.
I can't tell you what exactly they changed in caching but for how to use it:
Just upgrade flutter
flutter upgrade
and recompile
flutter build web --release
It should automatically build with the new service worker
The Google Actions SDK has been rewritten again for version 3 and comes with a completely new developer platform with different ways of working. As far as I can tell, there is no way to migrate a legacy (Actions SDK V2) action to the new SDK and Actions Console experience.
Is there a documented way to migrate to V3?
Is anyone who has successfully migrated able to share their experience and any problems they ran into?
I haven't found any usable documentation on switching versions so my best guess is to start from scratch with a new project, then delete the old one and rename the new one. Is that likely to work?
My app is a simple conversational Action implemented with the actions-on-google#v2.x SDK. I did not use Dialogflow at all.
Progress so far
I've had some partial success by using the new version of the gactions CLI.
I created a new project using the new web console experience then pulled the configuration down from the server. I then pulled my existing project configuration down, edited the files to match the test project, then pushed it back up.
This has resulted in the web console UX changing to match the new experience but there is a residual error that prevents me from testing my app.
Custom actions can only be specified in Conversational Actions projects.
This makes me think that there is some kind of project type in the back-end that determines what should happen in the web console. Pushing a modernised configuration up to the server seems to have changed the UI mode without changing the project type, causing an issue that prevents any maintenance on the old app or any migration to the new version of the system.
Update: A new migration workflow for Dialogflow Actions was just released. This is not relevant to my app because I never used Dialogflow.
I'm working with Google App Engine in Eclipse w/ JSP pages in Windows 7.
I already have an app deployed and working, but I am unable to make changes to it for some reason.
If I make changes and debug locally, my localhost page is showing the changes that I implement.
While I am not getting any errors in the deployment, the same changes that work on my local debug are no longer showing up, so I can't update my app.
I thought updating the version number might help, but I had no luck with this.
Any ideas? Thanks.
Are you deploying the same version (as specified in appengine-web.xml) as the default version that is running on your app? If not, you'll have to access your new deployment at http://newversion.appname.appspot.com, or change your default version in app engine to your newly deployed version.
I have had the same problems too, especially when the changes concerned the static pages. Some little things to check:
If you have set an expiration date in your app.yaml, your browser cache could be holding the file.
If it’s specific to the online contents, it could be an intermediary cache (such as a squid server) serving the outdated contents, in which case you’d have to flush the cache to get the new version.
You could start by checking the log on the GAE console to see if the request is received by the server, that would help you debug.
Another trick, if you’re being served an outdated version of http://yourapp.appspot.com/index, try and pass a dummy argument to force the browser to update the version, for instance : http://yourapp.appspot.com/index?p=1
I work in a service organization where users of our internal tools are often disconnected. It is often the case that service engineers on service assignments are "stranded" with an outdated version of some internal tool.
These tools are deployed using ClickOnce publish VS2010 .NET4 . If the users run all their apps while still connected to corporate network, they would get a notification that a new version was available. As the number of various tools increase, the chance increases that some app is not updated.
Is it possible to automate this process, by a batch file or something?
So that the engineers just need to run one file when connected to corporate nw to get all the newest versions of their installed tools?
Added:
An easier way of saying it would be to have "something like Windows update" operating on corporate net, but for internal ClickOnce apps.
Very interesting question. I can't think of a quick way to do this, but it's definitely possible.
I would create another ClickOnce app whose job is to update the other ClickOnce apps. This app needs the url of each app's .application file. If all engineers are supposed to have all apps, that's easy. If not, maybe you could look through their start menu and find all the ClickOnce Application Reference files. Those files contain the url.
Next, just launch the url and pass a query string argument...
http://server/MyApp/MyApp.application?UpdateOnly=true
In the startup of your applications, you can check the query string argument and shut down the app if it's run with UpdateOnly=true.
One side note. If you set the minimum required version of each of your apps to the latest version, users won't get prompted with the new version dialog. Seems like you'd want to do that or the user would still have to pay attention and do a lot of clicking.