I want to set version number in PWA such as 1.2.3 and also set minimum supported version for example 1.1.5
if current user site version less than minimum version
we force user to update PWA site and user can not cancel it,
but if user current version is bigger than minimum version user can select update if he want.
example:
current user version 1.2.3
min required version 1.2.5
new version 1.2.8
user must update to new version to continue use the site
current user version 1.2.6
min required version 1.2.5
new version 1.2.8
user can decide to update or not
keep in mind that browsers will update it automatically if:
Your service worker is considered updated if it's byte-different to the one the browser already has
The updated service worker is launched alongside the existing one, and gets its own install event.
Have a look in Service Worker Lifecycle
which means, in both scenarios that you described, if the servicer worker is not controlling any web page, when the user returns or refresh the page, the new and latest service worker will be installed regardless
you can show a banner to display when new versions are available:
https://deanhume.com/displaying-a-new-version-available-progressive-web-app/
but the browser itself "controls the version", or in other words, browsers always install the latest file version of the service worker
Related
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
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.
In experimenting with a sample SF app and playing with upgrades and versioning I am noticing that it keeps a rather long history of versions. Below is a screenshot of my app in SFExplorer. Is there any way to control how much history is retained, or can I cull out versions I'll never use again.
Or should I not even be concerned with this? (even though I am!)
What you're seeing here is application registration. Before you can create an application instance, you have to register the application type and a version. When you upgrade your application, you register a new version of the same application type. This is the PowerShell command that does it (Visual Studio uses this on your behalf when you upgrade through it):
Register-ServiceFabricApplicationType
Over time, you'll see a bunch of versions of your application registered. If you don't want them registered anymore, you can simply unregister them using the corollary command:
Unregister-ServiceFabricApplicationType -ApplicationTypeName SFDemoType -ApplicationTypeVersion 1.0.2
While we have that screenshot in front of us, here are a couple cool things about application registration:
You can create instances of any registered application type + version at any time with the new commands:
New-ServiceFabricApplication -ApplicationName fabric:/SFDemo2 -ApplicationTypeName SFDemoType -ApplicationTypeVersion 1.0.7
This means you can do cool things like create side-by-side instances of the same application type but of different versions. Say you want to test out a new version of an application without upgrading an existing instance yet. You can register the new version, but instead of upgrading an existing instance of that application type, you can simply create a new instances of the new version of the application type.
You can "upgrade" a running application instance from any version of an application type to any other version of an application type using the upgrade command:
Start-ServiceFabricApplicationUpgrade -ApplicationName fabric:/SFDemo -ApplicationTypeVersion 1.0.20 -FailureAction Rollback -Monitored
For example, say you just upgraded your application instance from 1.0.15 to 1.0.20. After a while, you find a bug in 1.0.20. You can use the same application upgrade command to "upgrade" back to 1.0.15. In fact, the version strings are just strings - they can be anything you want. You can upgrade from version "banana" to version "Tuesday" if you want!
So yeah, you can unregister old versions if you think you'll never need them again. But it's great to have a version history, because you can actually do interesting stuff with it!
I have a Service Fabric application with a few services underneath it. They are all currently sitting at version 1.0.0.
I deploy an update out to the cluster for version 2.0.0. Everything is running fine and the deployment succeeds. I notice a very large but in the version. Is there a way to manually rollback to version 1.0.0? The only thing I have found is automatic rollback during an upgrade.
Matt's answer is correct, but I'll elaborate a bit on it here.
The key is in understanding the different steps during application deployment:
Copy
Register
Create
Upgrade
Visual Studio rolls these up into single "publish" and "upgrade" operations to make it easy and convenient. But these are actually individual commands in the Service Fabric management API (through PowerShell, C# or HTTP). Let's take a quick look at what these steps are:
Copy:
This just takes your compiled application package and copies it up to the cluster. No big deal.
Register:
This is the important step in your case. Register basically tells the cluster that it can now create instances of your application. Most importantly, you can register multiple versions of the same application. At this point, your applications aren't running yet.
Create:
This is where instances of your registered applications are created and start running.
Before we get to upgrade, let's look at what's on your cluster. The first time you go through this deployment process with version 1.0.0 of your application (call it FooType), you'll have just that one type registered:
FooType 1.0.0
Now you're ready to upgrade. You first copy your new application package with a new version (2.0.0) up to the cluster. Then, you register the new version of your application. Now you have two versions of that type registered:
FooType 1.0.0
FooType 2.0.0
Then when you run the upgrade command, Service Fabric takes your instance of 1.0.0 and upgrades it to 2.0.0. If you need to roll it back once the upgrade is complete, you simply use the same upgrade command to "upgrade" the application instance from 2.0.0 back to 1.0.0. You can do this because 1.0.0 is still registered in the cluster. Note that the version numbers are in fact not meaningful to Service Fabric other than that they are different strings. I can use "orange" and "banana" as my version strings if I want.
So the key here is that when you do a "publish" from Visual Studio to upgrade your application, it's doing all of these steps: it's copying, registering, and upgrading. In your case, you don't actually want to re-register 1.0.0 because it's already registered on the cluster. You just want to issue the upgrade command again.
For an even longer explanation, see: Blue/Green Deployments with Azure ServiceFabric
Just follow the same upgrade procedure, but targeting your 1.0.0 version instead. "Rollback" is just an "upgrade" to your older version.
Is there a service available that responds with the latest version of Java that's available?
I'm writing system check for an application that uses applets. As part of the check I'd like to inform users if a new version of Java is available for download. Is there any online service that simply responds with the version number for the latest Java version?
How about a different strategy of 'leave it to the manufacturer'?
The JRE is configured by default to be auto-updating to the latest version Oracle considers to be stable enough for general use. Best leave it to the auto-update feature.
Run-time testing
Of course, there is always How do I test whether Java is working on my computer?
FireFox
An old version of Java has been detected on your system.
Update Java by clicking the button below:
A polite way of saying 'no plug-in found for FF'.
Chrome
User Friendly
But ultimately either way, leave it to the end-user's discretion as to what version to use, and whether to update.