html5 -Dmobile works, but I am having problems with file overwriting and browser cache:
If I compile html5, in the Assets folder I see the folder Symbols, containing the Assets/Symbols content.
If I compile html5 -Dmobile I should see the same folder, but containing Assets/SymbolsMOBILE content: the previous content is not overwritten by the second compilation: 1 - how do I force overwriting when compiling? I can’t always delete the Symbols folder before compiling.
Sometimes I find dead assets in folders such Assets/Symbols, copied in a previous compilation but not used anymore: 2 - is it possible to do an automatic cleanup of unused files?
Another problem is the browser: if I run the first version I see the standard assets, but when I run the second version (with the mobile assets) I still see the first assets: 3 - how do I force the browser to reload the new assets in the preloader?
When copying, it should compare the file modification dates, if you do -clean when building, it should delete the files first before copying, ensuring that it’s definitely the ones you wanted (even if older) and removing other files
What about unwanted cache? I have different applications in different folder but containing the same file and folder structure, with a lot of files with the same names between the various applications, and sometimes in HTML5 happens that an application loads the resources of the previously loaded application! How Can I avoid this? I’d like to apply cache busting to the resource assets, but how?
Yes, I know, part of the problem of the local testing could be the common path “http://localhost:2000/”, and yes, I have different projects folders in the same folder of the local server, but I have to avoid both problems: local redundant filenames must be treated as different filenames, and when online I have to avoid overlapping versions.
I thought that our local server was set to not cache anything. Perhaps I am wrong?
For online content (where you are unlikely to replace one version with another), appending the version, build number (or both) or some salted ID of some kind to each asset could help with caching issues
It would have to be internal, that would return “cannot find asset with ID …” but internally, we could do something similar.
However, the concept would be that it is tied to the build or version number at compile time, so that it is hardcoded into the JS, so once you cache the new version, it remains in cache. I used to have a system that worked kind of like this before in ActionScript 3, but I did not have the benefit of using a build system that could give me a new cache version number automatically
Will you give the possibility to break the cache also adding the “version” number when using Assets methods like loadText, loadSound etc…? I think this is the most obvious use-case where the version number would come in handy