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
Related
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 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.
My application has 2 features: "base" and "extend".
manifest extend feature:
<dist:module
dist:onDemand="true"
dist:title="#string/title_extend">
<dist:fusing dist:include="true" />
</dist:module>
download feature with SplitInstallManager -> startInstall
unintsalling with SplitInstallManager -> deferredUninstall
Check installed modules with SplitInstallManager -> getInstalledModules
Extend feature is loading from play store success and work as expected. When this feature has become unnecessary - uninstall it.
more, SplitInstallManager has callbacks: SuccessListener, FailureListener, CompleteListener. Install and Uninstall completely with success (no errors).
But, after uninstalling Extend feature (and after restart application) it is stay installed.
How to delete uninstalled feature from the application (need remove no used code and resources) ?
As explained in the API of the deferredUninstall method:
Once called, the Play Store will try to eventually remove those modules in the background.
The uninstalled modules will be removed while the app is not working at some point in the next 24 hours.
Here is what I noticed.
1) Uninstalling the app removes the downloaded modules, so the next time you run the app, the app will download the modules again.
2) Clearing the app data (e.g. adb shell pm clear APP_PACKAGE_NAME) makes the module not available to the app immediately, but if the module is already downloaded before clearing the app data, it won't be downloaded again. In other words, you won't see SplitInstallSessionStatus.DOWNLOADING.
3) Once the downloadable module becomes available to the app, clearing the app data of "Google Play services" (i.e. adb shell pm clear com.google.android.gms) doesn't make a difference. But occasionally, the downloadable module sticks around even after uninstalling the app, especially when the module's name changes. Then 3) becomes handy to clear the stale modules.
I think what's happening here is when the app requests a downloadable module, Google Play services downloads the module, hands it over to the app, and caches a copy of it, just in case the app requests it again. If the app is uninstalled, Google Play services removes the cached module. deferredUninstall() is just asking Google Play services to uninstall the modules if necessary, but we have no control on when that would happen, if ever.
from https://developer.android.com/guide/app-bundle/playcore#uninstall_modules:
Module uninstalls do not occur immediately. That is, the device uninstalls them in the background as needed to save storage space. You can confirm that the device has deleted a module by invoking SplitInstallManager.getInstalledModules() and inspecting the result, as described in the previous section.
So You could try to fill up storage space on your device and see if that triggers an uninstall :)
By the way: On the play store page for the app that I am currently testing via "internal early access", there is a section "deferred actions" which lists all modules marked for deferred uninstall. There also is a button "run deferred actions" which actually removes those modules completely.
As far as my own testing has gone, uninstall is deferred until the app is updated by Play Store. Otherwise I assume Play Store services will eventually wait for the app to be totally inactivate to update its uninstalled module (the app has to be restarted for that update to occur).
I've filled a bug to find out if there's anyway to force the (un)install of on-demand modules: https://issuetracker.google.com/u/1/issues/172108742. And a way to tell which modules are truly installed.
Same goes for installing actually, until app is updated, on-demand modules are "emulated", which prevents those 2 things from happening:
The platform can not apply any new manifest entries introduced by the module.
The platform can not access the module’s resources for system UI components, such as notifications. If you need to use such resources immediately, consider including those resource in the base module of your app.
As explained here: https://developer.android.com/guide/playcore/play-feature-delivery#access_downloaded_modules
There seem to be a long road ahead before on-demand modules work properly.
I noticed this afternoon that my Bluemix IoT Application was in the 'Unknown' state. When I mined into the app to see what the problem could be, I got the following pop-up:
App staging failed in the buildpack compile phase
I haven't made any changes to my NodeRED flows in months, and if I spin up a new IOT Foundation app, it starts just fine.
Any ideas on what is going on here?
A recent update to the underlying application stack has caused an incompatibility with older versions of the IoTF boilerplate.
The fix is to edit your application's package.json file and remove the 'mqlight' entry under the dependencies section. New instances of the boilerplate already have this entry removed - hence why they work.
Perhaps check the bluemix server status at https://developer.ibm.com/bluemix/support/#status
There were some issues reported around scheduled maintenance. There are also buildpack updates scheduled.
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