Files implementation

[czyzby]

• [x] Abstract file handle base for handles not based on java.io.File. Support for determining names of extensions, directories, etc. based solely of file path.
• [x] Prohibited write operations.
• [ ] Internal and classpath files support. File loading from the server.
• [ ] Directory files listing - should we support this?
• [ ] Absolute file handles. GWT backend does not support these, but we could allow users to make HTTP requests to pretty much any URL.
• [ ] Gradle task that copies all resource folders to dist folder and inspects all jars, copying all classpath resources.

[czyzby]

GWT uses a source generator to create a file with all assets listed in it. Since Dragome does not have similar functionality (or does it?), I think we should rely on native JS XMLHttpRequest functionalities or simulate assets file generation with a Gradle task. If we don't generate assets file, we might have problems with directory listing operations, exists and simulating sync API with async operations.

[czyzby]

@fpetrola The way I see it, there are two ways we can handle files:

• synchronously (load on request): application's resource folders (and classpath resources?) are copied to the build folder. Files are loaded by simply making synchronous XMLHttpRequests to the selected resources. This will make it pretty much impossible to create responsive loading screens, unless we "override" AssetManager to make it use asynchronous requests instead and force the users to manage their assets this way (which they should be doing anyway). This will considerably lower the initial pre-loading time of the game and limit unnecessary HTTP requests, as opposed to GWT which seems to load all files at once (even the unnecessary ones). We will not be able to list files, though.
• "asynchronously" (pre-load all assets): we hook up to the Dragome compiler, move all assets and generate an assets list file, similarly to GWT. Then, using the files list, we pre-load all assets on application start-up, making it possible to simulate synchronous FileHandle API. This seems to be working fine, but considering we have to load all the files we don't need (even if the user does not want to start the game at all), I think the other approach should be considered at the very least.

[fpetrola]

I think second approach should be enough good for a first implementation. A third approach could be to make use of statistical analysis, we can pre-load all assets in a first execution attempt and store assets usage statistics in order to determine which ones are required to be loaded together, creating more specific pre-loading blocks as each successive execution gives more info about assets usage.