This article presents a data model based on a Collection implementation that can be used with Swing components JList and JComboBox. It also discusses a method to use these same concepts in constructing the user interface of an application.

Overview
Java Collections are indispensable for building any application, whether GUI or non-GUI. And the ArrayList class is a heavyweight in the java.util package. In a GUI application, the user often must choose items from a list, which can be presented in a variety of forms (drop down combo, list box, etc.). For example, the Java Swing components JList and JComboBox each have list data models - ListModel and ComboBoxListModel, respectively. Both components will react to changes in these models in keeping with the Model-View-Controller paradigm. However, neither of these models are based on a Collection, and therefore lack many of the convenient methods that the Collection interface provides. In addition, lists shown in an application are often populated from external sources (like a database) that return a Collection. Unfortunately, none of the Collection classes in Java broadcast changes to their contents, which is necessary for a user interface component to react to a true MVC data model.

The solution presented in this article to this dichotomy is simple - a subclass of the ArrayList Collection class that implements the ListModel Swing interface, the ArrayListModel class. A subclass, ArrayListComboBoxModel, which extends ArrayListModel implementing the ComboBoxModel model (which is itself a subclass of ListModel), is also presented.

Details
The ArrayListModel class implementation is very straightforward. You can probably already imagine what the methods look like. All ArrayList methods that modify the underlying collection are augmented. The superclass ArrayList method is invoked, and then the ArrayListModel publishes the underlying collection changes to all ListDataListeners that have been added (as part of satisfying the ListModel interface contract). Listing 1 shows the implementation of the add(), remove() and set() ArrayListModel methods.

Each method calls a corresponding fire method, which notifies any ListDataListeners what exactly in the collection has changed (see Listing 2).

Other methods in ArrayListModel work very similarly. For example, the clear() method calls the superclass method, and then fires a ListDataEvent signaling that all items from the collection (model) were removed. The ListDataEvent that is sent to each ListDataListener completely describes the collection elements (actually the indices) that have been added, removed, or modified. Because ArrayListModel implements the ListModel interface, the collection can be directly assigned as the data model of a JList. The ArrayListComboBoxModel class extends ArrayListModel implementing the two additional methods in the ComboBoxModel interface: getSelectedItem() and setSelectedItem().

To see these two classes in action, download the provided code and run the ArrayListModelTest class (see Figure 1). This is a Swing application consisting of a JToolBar, a JComboBox, and a JList. There are two data models used. One is an ArrayListModel that holds all of the data items, and the other is an empty ArrayListComboBoxModel used by both the JComboBox and JList components as their data models.

Figure 1 shows the contents of the combo and list boxes after the red, blue, magenta, and orange toolbar toggle buttons, respectively, have been pressed. Pressing a toggle button on the toolbar adds an item to the data model, while un-pressing it removes the corresponding data item from the model. The data model items are each an instance of a ColorItem, an internally defined class that consists of a name and an icon property (see Listing 3).

Listing 4 shows the method in the test program that constructs the JToolBar. The method has two arguments - an Iterator of ColorItem objects and the list to manipulate on toggle button press/un-press. The list parameter is actually the ArrayListComboBoxModel, but this method simply knows it as a generic List. Note that the ActionListener that is added to each toggle button is very trivial: it simply adds or removes the data item from the list as appropriate. The visual components (JList and JComboBox) attached to the single ArrayListComboBoxModel are automatically updated. A ListCellRenderer is used to render the ColorItem icon in the JList.

You can probably think of other uses for a Collection that announces changes to itself, and not necessarily in a GUI scenario. In that case, you might object to the fact that ArrayListModel and ArrayListComboBoxModel are connected to Java Swing, both in the interfaces they implement and the ListDataEvent/ListDataListener classes they consume. One possible solution to this would be to extend ArrayList as I have done but define your own event model and listener interface that would be more generic and not Swing biased. You could then use this class in a GUI application as I've shown by writing the necessary adapters to implement the ListModel and ComboBoxModel interfaces.

ListModels in Your UI
Have you ever considered all of the list-like elements in a GUI application? Many of the user interface constructs in your application can be thought of as lists of user interface elements that potentially have to be manipulated (items are added, ordered, and removed). Examples are menus, toolbars (their buttons), tabbed panes, internal frames of an MDI application, and potentially other custom components. And quite often you need to associate an icon, a tool tip, and some other visual component with each element.

Listing 5 shows an interface, UIElement, which defines these properties. Run the UIElementTest application that is provided as part of the code for this article. The application looks similar to ArrayListModelTest and has many of the same concepts (see Figures 2 and 3). The data model consists of UIElement objects that are obtained from a UIElementFactory. (The factory returns instances of an inner class, our ColorItem object from before that now implements the UIElement interface.) The application knows nothing about the underlying visuals, just that they implement the UIElement interface. The JList knows it can show icons from the elements and a tool tip for each element. The JList is populated by selecting toggle buttons on the toolbar as above (see Figure 2).

The toolbar is constructed in a method that is nearly identical to the one shown in Listing 4, except the ColorItem parameterized type is replaced by UIElement. When an element in the list is selected, the associated visual component is obtained from the UIElement in the list and shown in the line-bordered JPanel on the right (see Figure 3).

Note the use of tool tips in both the list and panel, which are provided by the getDescription() method of the UIElement data items. The ListCellRenderer for the JList reacts to the state of the Use large icons check box, calling the appropriate UIElement get*Icon() method. A simple change to my UIElementFactory could be coded to return a completely different implementation, but the rest of the application code would not have to be touched.

As you can see, we've implemented a simple list selection method that populates another part of the application upon selection. I would bet that most Swing developers have done something very similar in one or more applications they've worked on. And we've implemented a fairly rich user interface, with icons and tool tips using a single data model, with minimal code.

In my next article, I will present more of this list-based/UIElement framework for constructing an application's user interface. We'll start with an AbstractUIElement that will serve as the base class for our user interface data model. I'll also introduce the UIElementListModel class and its view counterpart, the UIElementListView interface (with an AbstractListView base class implementation).

Conclusion
In this article I have described a convenient way to use a simple collection (List) as the data model for JList and JComboBox Swing components. These components react to changes in the underlying collection, remaining synchronized with the data in the model. I have also introduced the beginning of a small framework that can assist in constructing a Swing application.