Too frequently I see issues where customers/clients have to refresh the webpage, typically after clearing their history/cache, only to find out that the webpage is perfectly fine.
Is there any way to add a version or just force the browser to download all resources, such as scripts, images, ...etc?
One common way to do this is to append a nonce or version number to the URL of these resources:
myStylesheet.css?ver=1.1
logo.png?ver=13.1
When you change the file, you update the version number and any cached resource gets updated.
You can also ensure you are using the same version number (or whatever) for every time you make any changes to the codebase.
Related
I've recently transitioned my iOS Unity app to use asset bundles as on demand resources. This all works great! The only problem is that when the application first starts up and all the ODRs are preloaded it just starts to download them from the apple servers. I need to know before preloading them if they require downloading and if so, how big of a download. I need this info to show a prompt for the user to let them know that additional data needs to be downloaded and maybe turn on their wifi etc.
If you are using WWW class then there is this WWW.LoadFromCacheOrDownload, this function takes in a version parameter which you can probably use for checking on versions.
If you are using UnityWebRequest, then maybe you can use the meta files which get generated with asset bundle and then download it and read version or a hash (You will probably have to google a little bit on this what to use) to actually look if you have a version change and do you need to download new version or not.
If none of the above suits you then the hard coded way would be to setup a list of your asset bundles with your versions on a webserver and download it to match it with your local version everytime you start the app.
I hope this atleast helps you look in the correct direction.
I've managed to do this myself in the end. My current setup is the following:
I have a bunch of assetbundles marked as On Demand Resources.
When I build the assetbundles I save a file containing the CRC and file sizes of all these bundles and I save it in StreamingAssets to always have it available
Whenever the app starts up, I try to load the assetbundles from PersistentDataPath against their latest CRC (at first launch there will be no bundles there)
If any bundles are missing or have invalid CRC, show a prompt to the user that x MB of data needs to be downloaded (taken from the file made at build time)
After the ODR resources are downloaded, I reencrypt the assetbundle from res:// (the only way I could access it) and move it to PersistentDataPath
Whenever a new updated comes it, it should contain new CRCs for the changed bundles and the process should restart
It seems to work quite well. The only real issues that I have is that I currently don't know how to delete the downloaded ODR data, and there could be a version mismatch if a user installs the app and defers downloading the extra data, and only opts to do so when an updated version of the app (with different bundle CRCs) is available on the server but they still stay on the older version. This would probabily load the new bundles but will fail the CRC checks for them...
Whenever I navigate to maps.google.com via my dcef3 instance (TChromium), the "welcome" bit always appears over the top. Can I turn this off somehow with some setting? If I go to maps.google.com in Chrome or Firefox, it doesn't appear.
I thought it may have been something to do with cookies maybe, so tried setting CefPersistSessionCookies to true but no luck. Maybe I need to set an Option property with TChromium or handle some other event? I have made no other changes to the default values for TChromium.
It seems I needed to have a cache_path set (CefCache). According to doco:
cache_path The location where cache data will be stored on disk. If
empty an in-memory cache will be used for some features and a
temporary disk cache will be used for others. HTML5 databases such as
localStorage will only persist across sessions if a cache path is
specified.
So it seems (almost obviously to me now) that cache is needed.
Currently image_tag("file.jpg") produces normal image html tag, BUT src="file.jpg**?7485793246**" What are those numbers anyway and how to disable them?
Those are refered to as Asset Timestamps they can be used by the server to cache files. For example lets say you have a file called file.jpg on your server, you can set up your server to tell browsers like firefox to cache the file.jpg so the next time that browser visits your web-page it loads faster because file.jpg was already in memory.
The problem comes when you upload a new file.jpg because even though the image is different, your old users who have the image cached will still see the cached image, that is where asset timestamps come into play. Those numbers represent a timestamp of when the file was updated, so if you replace file.jpg?123456789 with file.jpg?987654321 then the user's browser will not use the cached version.
http://api.rubyonrails.org/classes/ActionView/Helpers/AssetTagHelper.html
long story short, it is only there to help you, and doesn't affect the way the file behaves at all. Users can still download the file and operating systems will see it as being a valid .jpg.
thats your development mode making sure that nothing gets cached so that if you change the image it actually gets to the browser. the production version won't have it.
Solved, add this to environment.rb => ENV['RAILS_ASSET_ID'] = ''
Conclusion: yes, its a good rails stuff, but when you deal with ie6 and PNG images it can break your script. So be careful.
Does anyone know why there are question marks (with a number) after the images and css files (when looking at the html code)? And how can I turn them off?
From Rails API documentation:
By default, Rails will append all
asset paths with that asset‘s
timestamp. This allows you to set a
cache-expiration date for the asset
far into the future, but still be able
to instantly invalidate it by simply
updating the file (and hence updating
the timestamp, which then updates the
URL as the timestamp is part of that,
which in turn busts the cache).
Hope it helps.
It is to be able to cache the file on the client and still making sure the client receive the newest version when there is a change. So each file modification results in a new timestamp which the client will do a new request to the server to receive the modified file.
If you do not want to use (though I cannot see why - it is a good thing) simple do not use the rails helpers for including javascripts or stylesheets. Just include the normal HTML tags: link and script.
We built a PWA with Ionic 3, which is a multiple page application. We host this on a linux server with nginx and use Laravel as a backend
The situation
We have seen that a update to a PWA is not always instantly, our client requested that if we released a update this would happen instantly and automatically.
What we tried
File based caching:
Our first thought was to use the concept of (old fashioned?) cache busting, so when building the app we use a random hash string in the filename. This ended up causing a major issue: Some PWA’s seem to hold on to the old index.html. In our access log we can see that old files get requested. The result being people will see a white screen after the splash screen. The only way for them to fix it is to reinstall the PWA completely.
Url based caching:
We devised a new plan: instead of using random hash string in the filename we moved in to the folder name. The request path would look like this: ./build/98312uj91eh9u2e/vendor.js. With NGINX we remove the hash and serve the same file, so it will return the the file from this path: ./build/vendor.js. This caused another issue where files would be mismatched. So some user would have parts of the old version and parts of the news versions which caused a lot of random issues.
Hosting multiple versions hoping they would update:
This pretty much did nothing other than creating lot of confusion. because some PWA’s would never update some people would be stuck on a old version and not see the new features.
Our current idea
Instead of using a static html file we are thinking of using javascript to make an API call to the backend of the PWA. Which will return a string with the current version of the PWA. This version will be the random string contain within the file names. This way, regardless of index.html updates, the content well be dynamic and not cause issue before description issues.
So what is the question?
Is it a good idea to make use of the concept where we would use JavaScript for making an API call or would this cause other issues we have not thought about yet.