No Open Blockers

I’m totally addicted to the Java preferences framework.

For a while, I’ve wanted to add user preferences to CodeTurtle. My motivation was less letting the user explicitly set certain values and more about adding in polish to the UI. For instance, I wanted to remember the last position and size of the UI if the user moved it (rather than always starting maximized or something like that). Little things like that are somewhat taken for granted until you use a UI that doesn’t have them, at which time phrases like “This sucks” tends to come out. Besides, it seemed like a fun challenge.

I thought I was going to have to choose between using a simple key/value pair serialized to disk or actually adding in an XML framework for more flexibility and dealing with that headache (or some other unholy third option). What I found out was how little I actually knew. The Java preferences framework gives you both for pretty much free.

Java will keep track of storing the preferences in wherever it makes sense based on the native operating system (for instance, they are stored in a directory named .java in the user’s home directory on Linux). The format is XML, but it’s actually not necessary to know that since I don’t have to do squat to actually interact with it.

To load the preferences, it’s a one line call:

Preferences preferences = Preferences.userNodeForPackage(this.getClass());

After that, it’s simple getters to get your values. The Preferences object even has some really nice polish on the API letting you use type specific getters (getString, getBoolean, etc) and specify a default value. Setting values uses a put notation that functions like the Map interface.

int windowWidth = preferences.getInt("window.width", 800);
...
preferences.putInt("window.width", frame.getWidth());

That’s it. That’s all you need to cover reading/writing the file, determining the proper home directory location, and serializing/deserializing the XML store of the data. My daughter could write code to use this if she could stop drooling long enough to not short circuit the keyboard.

You technically don’t even have to worry about saving, it will periodically do that for you. However, if you want to explicitly trigger a save, simply call the flush() method on the preferences object.

I even built in a command line option to CodeTurtle to clear the user preferences, which is in itself a simple call:

preferences.removeNode();

I was happy to see that my design of having a central data manager passed throughout the GUI came in handy here as I was able to stuff the preferences object into it and access it from virtually anywhere else in the UI. At that point, it was just a matter of figuring out what I wanted to store. In the beginning it was things like the window placement, window size, and tab placement. Tonight I decided to add a flag indicating if it’s the first time the user is running CodeTurtle. If it is, I enter a bit of a “demo mode” where the sample project included with the CodeTurtle distribution is automatically loaded to more easily show off its complete awesomeness.

I still have other (reasonable) ideas on things I want to stuff into user preferences. Rather than requiring an environment variable to indicate the compiler path (i.e. TURTLE_JDK_HOME, JAVA_HOME), I’d like to move that to the user preferences to make it easier to see where the value came from. The real challenge at this point is trying to not abuse this new found power and stuff every imaginable value into it.

My annoyingly over-engineered (and pretty much completely unnecessary) wrapper on top of the Java preferences framework can be found in CodeTurtle’s SourceForge repository.