Design pattern for window management in a Java Swing app

Question

I've just started creating my very first little Java Swing app. When the program opens, it brings up a single, simple window with a label and a couple buttons. Clicking one of those buttons is supposed to wipe out the welcome screen and replace it with a totally different panel.

I'm not sure what the best way to create that functionality is. One method would be to pass my JFrame as an argument into... just about every other component, but that feels hacky to me. Or, there's making each panel double as an action listener, but that doesn't seem right, either.

Is there a design pattern I should be applying here? "Replace the contents of the main — and only — window" must be a reasonably common operation. A name for the pattern would be enough; I can use Google on my own from there. (I wouldn't say no to a longer explanation, though.)

Answer 1

When building Swing apps, I usually base it on the Mediator Pattern. In this pattern, a Mediator class (usually the main JFrame) handles the different GUI parts (usually the JPanels, JMenus...) and takes care of communication between them.

For example, if an event occurred in JPanel1, JPanel1 notifies the mediator (the JFrame). the JFrame then takes action by modifying JPanel2.

FYI: all my projects were small-to-mid GUI apps, so I'm not sure this patterns scales well. But if you could design an adequate architecture, the Mediator pattern can be a solid base.

Answer 2

You can have the main method display a JDialog. When the dialog is closed, the main JFrame is created and displayed.

JDialog gives you easy-to-use static methods that display a dialog with custom contents and buttons, and return the code of the button that was clicked. By testing this value, your main method can decide to either display the main frame or exit (or anything else). Please read the Javadoc.

Unlike some older UI frameworks, a Swing application is not tied to a specific frame or window. You can create as many windows as you want. The application ends when all threads end, not when all windows have been disposed. This is typically achieved with System.exit(0).

I don't know if there is a specific design pattern for that case. I recommend the Java Swing tutorial.

Answer 3

Many UI frameworks have different rules regarding the 'main' or 'active' window. One way to manage that complexity is by having your main window, which controls the main message loop, to be an invisible one (or small, chromeless 1 pixel one, off screen for the particularly annoying frameworks). then have all other windows and dialogs be a child of that window.

This method has many advantages, especially when dealing with global keyclicks and mouse events, as well as in top-level logging and exception handling.