There’s millions of UI frameworks out there, but the one thing I always find is that they fall into 2 categories, they either do too little so I spend my time writing extra bits and adapting things to fit into their system or they do wayyyy too much for what I need such as Eclipse RCP - its an amazing system that can really scale but often you spend so much time coding for it that your project is never going to arrive on time!

The third choice is to write your own. Often when it comes to programming people say that the best programmers cheat, they reuse code, call on libraries and do anything but write code. I completely agree, but in the real world you have the ever looming fact that you don’t have all the time to build and RCP type monolithic system and if your going to spend £5k on a library, then 100 hours adding to it could you have just done it in 100 hours? Ill leave that debate for another day, on with the framework!

The goal of this system is to provide a simple but powerful action framework the separates the action doing the work from the UI system calling this, in my next post ill show you how this type of orthogonal programming can give huge benefits.

What this 2 minute diagram is showing you is that the UI bits are wayyyy over on the left and the action bits are wayyy over on the right. Brilliant our actions have no idea about the UI, so we can swap them out, change them, TEST THEM and pretty much do what we like without even bothering the UI code.

This pretty much looks like this in code, first our UI components must invoke the action via the manager class (this is also a perfect time to get off the EDT).

JButton button = new JButton();

button.addActionListener(new ActionListener() {

           public void actionPerformed(ActionEvent e) {

            new Thread(new Runnable() {

public void run() {
ActionManager.getInstance().runAction(actionId);
}
}).start();
}}

What happens here is that it first gets the action event on the EDT, switches to a new thread and runs the action via the action manager.

The action manager class simply stores the actionID to action pairing in a hashmap for fast look up and as defined in the IAction class invokes the run method.

Finally an instance of IAction may have the following code snippet

public void run(){

//here i run the action

System.out.println("Action Has Been Run");

}

The final bit of the puzzle is how do you pass the id’s around and how does the action manager know about all the ID to action pairings. These solutions depend on the type of system you are building, if its a simple little application maybe its ok to define the ID’s in IAction so you end up with:

ActionManager.getInstance().runAction(IAction.SaveAction);

If this is the case the the constructor of ActionManager may look like this:

//create the hashmap
this.actionMap = new HashMap<String, IAction>();

//add all the local actions in
this.actionMap.put(IAction.SaveAction, new SaveAction());

Sometimes systems are more dynamic that this, you don’t know about all the actions until run-time, for instance when you have plug-ins to your application you need to give them the ability to register themselves to the action manager and to the GUI. Its easy with the action manager, just provide a method to add in an action, with your GUI I would suggest you define locations where these UI objects can be added but that is outside the scope of this post, maybe one for the future.

Now that you have a very simple action framework you can knock up some actions, hook them into the manager and call them from the GUI! Pretty cool for only a few classes, following this post ill explain how we can improve on this framework to provide on/off actions that reflect their state in the GUI, I will also post a demonstration of just how useful it is to separate your UI completely from your action layer in a post on truly native cross platform java apps.