Scott Violet's Blog

January 2006 Archives

Architecting Applications 2: the Application class

Swing is an incredibly rich toolkit, but to date we haven't provided much guidance on how to structure your app. How should I start my app? Where should I place resource bundles in my project? How should I use preferences? Logging? ... The list goes on. While I'm not going to address all of these issues I'm going to focus on the first issue. How should I start my app? The first thing to comes to mind is something along the lines of:

public class Main {
  public static void main(String[] args) {
    JFrame frame = new JFrame(...);
    frame.pack();
    frame.show();
  }
}

We currently recommend an approach along the following lines:

public class Main {
  public static void main(String[] args) {
    SwingUtilities.invokeLater(new Runnable() {
      public void run() {
        createAndShowGUI();
      }
    });
  }
}

Here's how I would like to write main:

public class Main {
  public static void main(String[] args) {
    new MyApplication().start();
  }
}

• Registering as the uncaught exception handler such that if an uncaught exception is received the application alerts the user and exits.
• Using a ResourceBundle for localized resources. For small to mid size apps putting resources into a single resource bundle is fine, large apps will undoubtedly want finer granularity.
• Using a PreferencesNode for persistant information. Again, for small to mid size apps using the same preferences nodes is fine, for large apps you will undoubtedly want finer granularity. There are problems with using preferences in webstart/plugin, but that's for another day.
• A single point to exit the app, as well as the ability for listeners to cancel the exit.
• Ability to block exiting until background threads have finished as well as displaying a dialog to the user while this is happening.

I suspect anyone that's developed a number of Swing apps has already developed a similar class. You can find the version used in this article here, or peruse the doc of Application and ApplicationListener.

Application itself is an abstract class, a typical subclass, and the one for this blog series, looks like:

public class PasswordStoreApplication extends Application {
    public String getName() {
        return "PasswordStore";
    }

    protected void init() {
        JFrame frame = new JFrame(getName());
        frame.setDefaultCloseOperation(JFrame.DO_NOTHING_ON_CLOSE);
        frame.addWindowListener(new WindowAdapter() {
            public void windowClosing(WindowEvent e) {
                exit();
            }
        });
        frame.pack();
        frame.setVisible(true);
    }

    public static void main(String[] args) {
        new PasswordStoreApplication().start();
    }
}

Those that look at the code will notice a couple of hard code strings. Bad Scott, bad Scott! I did this to make it easier for folks to download the source and use, but this most definitely needs to come from a resource bundle. You've been warned.

I've tried to keep Application simple. It doesn't know about Frame or any other application specific components, that's up to subclasses. In fact it probably makes sense to have a subclass that knows about a single frame. Such a subclass would further reduce the code of PasswordStoreApplication as registering the window listener, packing and all that would be done for you.

One of the biggest open questions with a class like Application, is should it do dependency injection? That is, should Application contain meta information about your application that can be used in configuring it. For example, database style apps need to know what database to connect to. Does it make sense to have Application configure your connection settings so that there is a standard place for this meta information? I'm not sure, but I'm certainly interested in feedback from the community.

A related issue I mentioned is how this class would work with builders. Ideally one would be able to create a 'Swing Application' which in turn would configure things like the name of the application and perhaps a class to create on the EDT. In this way developers needn't subclass Application directly, the builders would do the wiring for you. More research is needed on this.

Hans suggested rather than using listeners you have the ability to register Runnables given a name, with the Runnables processed at well known points in the app life cycle. This would make for a more loosely specified init sequence, but one that allows for a bit more than listeners. I'll explore this in more detail later.

In the interest of keeping each blog short and sweet I'm going to wrap this one up here. I had hoped to have something running by this point, but I'll leave that to the next blog. In the next blog I'll create a controller class along with the UI that ties the model together and is started with the Application subclass. I promise that by the end of the next article you'll be able to click on a web start link to see the app running.

    -Scott

Architecting Applications 1: the model

As part of the series I'll cover architecting the app (this blog) including using beans persistence as a way to save the model, Actions, Undo, the need for an application class, data binding and various other things that come up.

In writing a series of blogs around an app I thought it important that the app be compelling enough, but not too big such that you become bogged down in all the implementation details. So, I needed something small but not too small as to be trivial. I may have erred on the side of trivial, none-the-less the concepts and points are still worth while to explore.

If you're like me you have a ton of passwords for various machines and web sites that you're expected to remember. As an added wrinkle each password should be unique and unreadable, ugh! Added together this makes it nearly impossible to remember all your passwords. For this series I'm going to stick with a simple app that manages passwords. A Java based app that stores passwords has the added bonus of being able to run from a USB memory stick on the three major platforms: Windows, OS X and Linux. I realize there are loads of commercial apps in this space that undoubtedly go way beyond what I'm going to do. None-the-less such an app is at least interesting and not too complicated (at least as far I'm going to take it).

Here's roughly where I'll end up when done with the series:

A password store will need to be encrypted, I'm going to leave that out as I don't want to worry about the legal issues of such a blog.

There are various approaches to designing apps. Some of the more popular patterns are model-view-presenter , presentation model and model-view-controller. I'm a fan of the latter, and especially for an app of this size. In creating any app you'll need to make the desicision as to which approach is applicable to your design space and requirements.

Model-View-Controller dictates that you have a clear model for your application. The Controller coordinates keeping the view and model in sync. The model for Password Store is going to be trivial. It'll consist of a List of PasswordEntrys. Each PasswordEntry will have the following properties: host, user and password. PasswordEntry will be a proper bean in that it'll communicate changes to listeners by way of a PropertyChangeListener notification. That means any time you change a property all PropertyChangeListeners are notified of the change. Here's the code for setting the host property:

    public void setHost(String host) {
        String oldHost = this.host;
        this.host = host;
        if (propertySupport != null) {
            propertySupport.firePropertyChange("host", oldHost, host);
        }
    }

The List of PasswordEntrys will be managed by a PasswordModel. PasswordModel will initially expose the List as modifiable. I suspect this is a bad long term decision, but I'm going to stick with it in hopes of keeping the API simple and not getting bogged down in details. Here's the code:

public class PasswordModel {
    private List passwordEntries;
    
    public PasswordModel() {
        passwordEntries = new ArrayList(1);
    }
    public List getPasswordEntries() {
        return passwordEntries;
    }

An added bonus of making the PasswordEntrys proper beans is that I can save and restore the PasswordEntrys using beans persistence. Here's the code:

    public void load(String file) throws IOException {
        BufferedInputStream inputStream = new BufferedInputStream(
                new FileInputStream(file));
        XMLDecoder decoder = new XMLDecoder(inputStream);
        List entries = (List)decoder.readObject();
        decoder.close();
        passwordEntries.clear();
        passwordEntries.addAll(entries);
    }
    
    public void save(String file) throws IOException {
        BufferedOutputStream outputStream = new BufferedOutputStream(
                new FileOutputStream(file));
        XMLEncoder encoder = new XMLEncoder(outputStream);
        encoder.writeObject(passwordEntries);
        encoder.close();
    }

    -Scott

This work is licensed under a Creative Commons License.