Assets overwriting, dead resources and cache buster

i have 3 problems, all related to assets persistency.

In project.xml I have

<assets path="Assets/Symbols" unless="mobile" rename="Assets/Symbols" />
<assets path="Assets/SymbolsMOBILE" if="mobile" rename="Assets/Symbols" />

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

Another solution might be to copy to different folders, this preserves the browser cache, and bypasses the modification date issue

Within your project, you could do something like:

public static var assetDirectory = #if mobile "mobile/" #else "desktop/" #end


Assets.getBitmapData (assetDirectory + "image.png");

about mobile and desktop resource loading I will have to try the Lime.Assets cached contents we were talking about here -Asynchronous to synchronous resources-.

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?

Hmm, perhaps we should add the build number or version number (or both?) to the end of HTML5 strings to bust the cache when the JS has been recompiled

I could add a random value like “1413412” at the end of the string to get from Assets, like this

Assets.getImage("test.png?1413412", ...);

but I am pretty sure this wouldn’t work…

So tell me again – is this on a local testing server, or online? Is this the same project (but new version) uploaded, or are you uploading different projects to the same location for some reason?

I think the solution would really vary depending on what’s going on :wink:

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

Like this

Assets.getImage("test.png?1413412", ...);


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 :wink:

Okay! I think this will help


How/where do you set the “version” parameter? Assets loading is executed before everything else.

I’m doing it as a compile-time random number, so if you load the same JS file again, it’s the same cache number and will remain cached, but recompile and it will break the cache to load again :slight_smile:

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