Professional Java.JDK.5.Edition (Wrox)

Chapter 4

private JPreviousButton previousButton = new JPreviousButton(“<< Previous”); private JNextButton nextButton = new JNextButton(“Next >>”);

private JFinishButton finishButton = new JFinishButton(“Finish”); private JPanel componentPanel;

private JPanel buttonPanel;

private Context context = new Context();

InstallationWizard() { super(“State Pattern”);

setDefaultCloseOperation(EXIT_ON_CLOSE);

The application establishes a context reference that the application uses to determine proper panel visualization flows. The FlowLayout manager is used with the buttonPanel to position the buttons used for directing the wizard flow. The context reference invokes the getColor() method to set the background color of the panel component (the default color is Yellow) with the setBackground(Color bg) method. Additionally, the previousButton and finishButton components are disabled by the setEnabled(Boolean b) method:

context = new Context();

componentPanel = new JPanel();

previousButton.addActionListener(this);

nextButton.addActionListener(this);

finishButton.addActionListener(this);

buttonPanel = new JPanel(); buttonPanel.setLayout(new FlowLayout()); buttonPanel.add(previousButton); buttonPanel.add(nextButton); buttonPanel.add(finishButton);

getContentPane().add(componentPanel, BorderLayout.CENTER); getContentPane().add(buttonPanel, BorderLayout.SOUTH);

// default is yellow

componentPanel.setBackground(context.getColor());

previousButton.setEnabled(false);

finishButton.setEnabled(false); componentPanel.add(context.getPanel(), BorderLayout.CENTER); componentPanel.setBackground(context.getColor()); componentPanel.validate();

setSize(700,300);

}

public void actionPerformed(ActionEvent e) { Command obj = (Command)e.getSource(); obj.execute();

}

public interface Command { public void execute();

}

216

Developing Effective User Interfaces with JFC

The JPreviousButton component manages all user requests when the Previous button is clicked by the user. The execute() method uses the application’s context reference to invoke the previous() and getState() methods to set the application to its previous state. The removeAll() method of the Container class is then used to remove all of the components from the container so that the appropriate panel display will be positioned in the user visualization:

class JPreviousButton extends JButton implements Command {

public JPreviousButton(String caption) { super(caption); } public void execute() {

context.previous();

context.getState();

componentPanel.removeAll(); componentPanel.add(context.getPanel(), BorderLayout.CENTER); componentPanel.setBackground(context.getColor()); componentPanel.validate();

nextButton.setEnabled(true);

finishButton.setEnabled(false);

if (context.getColor() == Color.yellow) { previousButton.setEnabled(false);

}else { previousButton.setEnabled(true);

}

}

}

The JNextButton component implements the same methods as the JPreviousButton component to render the appropriate user display when the installation invokes the Next button on the GUI presentation. When the Next button is invoked by the user, all of the components on the panel display will be removed using the removeAll() method. Once the remove operation has been executed, the next color panel will be discovered by using the reference state of the application using the context reference:

class JNextButton extends JButton implements Command {

public JNextButton(String caption) { super(caption); } public void execute() {

context.next();

context.getState();

componentPanel.removeAll(); componentPanel.add(context.getPanel(), BorderLayout.CENTER); componentPanel.setBackground(context.getColor()); componentPanel.validate();

previousButton.setEnabled(true);

if (context.getColor() == Color.blue) { nextButton.setEnabled(false); finishButton.setEnabled(true);

}else { nextButton.setEnabled(true); finishButton.setEnabled(false);

217

Chapter 4

}

}

}

The FinishButton class is enabled when the user has reached the final panel display in the series of four panel components:

class JFinishButton extends JButton implements Command {

public JFinishButton(String caption) { super(caption); } public void execute() {

System.exit(1);

}

}

public static void main(String s[]) { InstallationWizard st = new InstallationWizard(); st.setVisible(true);

}

}

The abstract State class is a generalized class used by the Context class to establish a blueprint needed to describe the methods needed to handle the state flows in the wizard across the different panel displays. Two get methods, getColor() and getPanel(), are used to retrieve color and panel values of the individual JPanel components implemented for display:

[State.java]

public abstract class State {

public abstract void handlePrevious(Context c); public abstract void handleNext(Context c); public abstract Color getColor();

public abstract JPanel getPanel();

}

The Context class below sets the initial state to yellow, so the YellowState application will start the installation program and create objects for the four color applications: Blue, Green, Orange, and Yellow:

//[Context.java]

//package name and import statements omitted

public class Context {

private State state = null; public BlueState blueState; public GreenState greenState;

public OrangeState orangeState; public YellowState yellowState;

public Context(State state) { this.state = state; } public Context() {

// get instances for all panels blueState = new BlueState(); greenState = new GreenState();

218

Developing Effective User Interfaces with JFC

orangeState = new OrangeState(); yellowState = new YellowState();

state = getYellowInstance();

}

public State getState() { return state; }

public void setState(State state) { this.state = state; } public void previous() { state.handlePrevious(this); } public void next() { state.handleNext(this); }

public Color getColor() { return state.getColor();

}

public JPanel getPanel() { return state.getPanel();

}

The following methods are used to return references to the object instances of the four different panel displays:

public BlueState getBlueInstance() { return blueState.getInstance();

}

public GreenState getGreenInstance() { return greenState.getInstance();

}

public OrangeState getOrangeInstance() { return orangeState.getInstance();

}

public YellowState getYellowInstance() { return yellowState.getInstance();

}

}

The YellowState class is the first panel display invoked by the Installation Wizard to start the install process. The YellowState constructor method initializes all of the different textfield components that are used for data collection. The getInstance() method creates a new YellowState instance for reference by other objects if the reference has not been created. If a reference value has already been established, then the reference will be returned to the object that references it:

//[YellowState.java]

//package name and import statements omitted

public class YellowState extends State {

// component declarations and initialization omitted for better clarity

static private YellowState _instance = null;

public YellowState() { firstName = “”;

219

Chapter 4

lastName = “”; city = “”; state = “”; zipcode = “”; generatePanel();

}

static public YellowState getInstance() { if(null == instance) {

instance = new YellowState();

}

return instance;

}

The handlePrevious(Context c) and handleNext(Context c) methods invoke the setValues() method to persist the values entered into the form display by the user. Once the data has been saved off the local instance variables, the context reference is implemented to obtain the reference to the next panel display. The get<color>Instance() method acquires the Singleton instance generated in the individual panel components:

public void handlePrevious(Context c) { setValues(); c.setState(c.getBlueInstance());

}

public void handleNext(Context c) { setValues(); c.setState(c.getOrangeInstance());

}

public Color getColor() { return (Color.yellow); }

public JPanel getPanel() { return panelYellow;

}

public void generatePanel() { log.info(“[YellowState:generatePanel]”); panelYellow = new JPanel(new GridLayout(0,1)); panelYellow.setSize(200,200);

formPanel.add(fnameLabel);

formPanel.add(fnameTextfield);

formPanel.add(lnameLabel);

formPanel.add(lnameTextfield);

formPanel.add(cityLabel);

formPanel.add(cityTextfield);

formPanel.add(stateLabel);

formPanel.add(stateTextfield);

formPanel.add(zipcodeLabel);

formPanel.add(zipcodeTextfield);

Border etchedBdr = BorderFactory.createEtchedBorder();

Border titledBdr = BorderFactory.createTitledBorder(etchedBdr, “Registration Form”);

220

Developing Effective User Interfaces with JFC

Border emptyBdr = BorderFactory.createEmptyBorder(15,15,15,15);

Border compoundBdr=BorderFactory.createCompoundBorder(titledBdr, emptyBdr); formPanel.setBorder(compoundBdr);

getValues();

panelYellow.add(formPanel);

}

The getValues() method sets the text in the various textfield components using the setText methods that are part of the JTextField class. The setValues() method retrieves the text from the textfield components and saves them to the various instance variables associated with the panel display:

public void getValues() { fnameTextfield.setText(firstName); lnameTextfield.setText(lastName); cityTextfield.setText(city); stateTextfield.setText(state); zipcodeTextfield.setText(zipcode);

}

public void setValues() {

firstName = fnameTextfield.getText(); lastName = lnameTextfield.getText(); city = cityTextfield.getText(); state = stateTextfield.getText(); zipcode = zipcodeTextfield.getText();

}

}

An important object-oriented (OO) concept to remember is that the InstallationWizard uses object composition to alter the behavior of the objects during run time. The wizard application delegates behavior to a known interface and varies the implementation details for the different installation panels.

Summar y

This chapter covered a tremendous amount of ground regarding all of the JFC components. All of the Swing top-level containers were discussed (JFrame, JDialog, and JPanel), as well as many of the other Swing visualization components (JButton, JLabel, JSpinner, JTextField, JTextArea, and others).

Lastly, Swing listener and layout managers were implemented along with GoF design patterns to craft effective user interface displays. All of the sample applications should help developers address complex GUI development activities and influence designers with their modeling conceptualizations.

The difficulty in explaining the Java Foundation Class (JFC) libraries is that they’re broad and varied. The complexities of their implementation can be overcome, as with many things in software development, by actually doing it. With a better understanding of what is possible with JFC packages, a developer can approach a task with confidence that it will get done.

221

Chapter 5

The Imager Application — Since saving an application’s state can be a rather abstract topic, the various persistence strategies that are appropriate to use with the three different APIs with concrete examples will be discussed. A hypothetical image manipulation program will be created and the focus will be on using the Java Serialization API, the XMLEncoder/Decoder API, and JAXB to persist its state to disk. The image manipulation program will be referred to as The Imager Application throughout the chapter, and is hypothetical because it will not actually implement image manipulation, since the focus of this chapter is persistence, not GUI development (see the previous chapter for more information on building graphical user interfaces with Swing and the Java Foundation Classes).

Application Data

Every application has some sort of in-memory data structure from which to retrieve its data. Besides data structures like maps, lists, sets, and trees, custom data structures are often built. For an application to save its state, the data in these structures must be saved to disk, and then at a later time, loaded back into the same data structure. Web browsers, for example, create what’s called a Document Object Model (DOM) in memory for every Web page that is loaded. It is their internal data structure for displaying HTML pages. Word processors also keep some sort of document object model as well — some way to represent the fact that certain pieces of text are aligned to the right, or possibly that other paragraphs of text are highlighted in a particular color. These custom data structures are necessary for the application to display the data properly to the user.

Viewer applications like Web browsers essentially read files and display them to the user. Web browsers first read HTML files over a network or from a disk, and then parse the data into its internal in-memory data structure, the DOM. Once the data is in the Web browser’s data structure, its rendering functions can now properly display the page to the user. Image viewing programs are similar, in that they read an image into their internal data structure representing images, and then display that image to the user. Other types of applications, though, also allow the user to manipulate the data. Word processors, in addition to reading files into their internal data structures and displaying them, also must allow the user to manipulate the data, and therefore the internal data structure, and then write the data back to disk.

Many of these other applications that allow the user to manipulate data follow the Model-View- Controller (MVC) design pattern (see Chapter 3 more for information on design patterns). In this pattern, the internal data structures of the application are called its data model. This data model is contained in structures that are separate from UI components and UI-related data structures. In Java-based applications, the data model usually consists of Java Bean components, along with other data storage and collection classes. These data classes are manipulated and modified by UI controller classes (such as events generated by buttons, menus, et cetera), and viewed and presented by other UI components. A simple MVC diagram is shown in Figure 5-1, illustrating how only the data model of an MVC-based application needs to be saved to restore the state of the application. Swing or other UI toolkit/utility classes would be in both the view and controller areas while the internal data model specific to the domain of the application would be contained in the data model. This step of separating domain data from UI components allows for a much easier process of saving and loading the data from disk since the data is all in one place: the model.

224

Persisting Your Application Using Files

Controller

Figure 5-1

Once all the domain data is contained in its own model, separate from the UI components, the parts of the data model that need to be persisted can be identified. Some pieces of an internal data structure need not necessarily be saved. Some parts of the data structure in an application will not change from time to time or they can be recreated given that certain other aspects of the data structure exist. Developers wishing to save the state of their application must look carefully at the data they hold in memory in their model, identify the pieces of it that must be saved, and then write routines for saving and loading the data from the data structure to and from disk.

Saving Application Data

Now that application data structures have been discussed in a general sense, it is time to move to something a little more tangible and realistic. How exactly do Java applications store their data model in memory? Since Java is an object-oriented language, most applications have a set of data classes (which is the application’s data model). Instances of these data classes reside in memory. The viewer and controller components (the UI) of the application interact with them to produce the functionality of the application.

Any Java class that has attributes (or properties in Java Bean terms) can be thought of as a data structure. A simplistic data structure could be simply a Person class with two String attributes, representing a first name and last name. More complex classes, which in addition to storing primitive data types contain references to other classes, effectively form an object graph. An object graph is a graph in which objects are the nodes in the graph and the connections are references from one instance of an object to another. The notion of object graphs is important because when you want to serialize the information contained in a class, you must also consider what data the class relies on that is stored in other classes, the dependencies these other classes have, and so on. In the next section, a tangible data model for The Imager will be outlined and its object graph will be viewed.

A Configuration Data Model for the Imager Application

Throughout this chapter, you will be developing a sample application to demonstrate different strategies for persisting application data using the three APIs discussed (Java Serialization, the XMLEncoder/ Decoder APIs, and JAXB). The application is called The Imager, and is some sort of image editing and

225