Posted: 15 May 2012
Tags: files, desktop, libgdx, internal, hack

In libGDX, the Files API nicely abstracts away a lot of the details and differences between desktop and Android builds. However, there is at least one limitation that can be frustrating and surprising.

Specifically, code like this that tries to walk an 'internal' directory:

FileHandle dirHandle = Gdx.files.internal("some/directory");
for (FileHandle entry: dirHandle.list()) {
   // yadda ...
}

will not work when running on the Desktop. In particular, the list() call will always return an empty list, and isDirectory() will return false.

You will only run into this if you've setup your desktop build's assets folder in Eclipse as a "Linked Source" to the Android assets folder (as you're supposed to). In this setup, the files in that assets directory will be found on the classpath when running in the Desktop build. Because of this, "directories" cannot be listed (I believe this is because libGDX is using some of the platform's classpath lookup functions on the desktop side, but I'm not sure).

One work-around is to not link the assets, but have a local copy (or a symlink on Linux). This solution seems too fragile to me.

Another work-around is, on a desktop build, to look for the assets with a relative path. As a side-effect of linking to the assets folder, Eclipse will copy its contents in your Desktop build's bin directory. This means you can prefix the path with "./bin/" on a desktop build to find the files. Like this:

FileHandle dirHandle;
if (Gdx.app.getType() == ApplicationType.Android) {
  dirHandle = Gdx.files.internal("some/directory");
} else {
  // ApplicationType.Desktop ..
  dirHandle = Gdx.files.internal("./bin/some/directory");
}
for (FileHandle entry: dirHandle.list()) {
   // yadda ...
}

I doubt this is the right thing to do if you're going to package up your Desktop builds for distribution, but if you're just testing your Android builds, this should be adequate.

I'm not sure what the right thing for applet or webgl builds is.