Java Swing programming structure: are listeners supposed to be the source of almost all Swing components?

Question

Hi folks,

My question boils down to this: is it standard structure in Swing programming to give listeners control over new components (e.g a new JPanel) for display and input, and to give that new component's listeners control over new components for display and input, and so on to infinity? Or does Java need to revert back to some sort of unifying class that ties all Swing components together in a procedural order?

At present, in my application that uses one JFrame only, in my listeners, my initial JFrame object is being passed as a parameter to all my JPanels so their listeners can call removeall() to clear the frame for a new JPanel. For example, short code as follows

public class MainFrame {
  JFrame jfrm;
  public MainFrame() {
    jfrm = new JFrame("Main Frame");
    JPanel mainPanel = new MainPanel(jfrm);
  }
}

public class MainPanel extends JPanel {
  public MainPanel(final JFrame mainFrame) {
    JButton example = new JButton("Example");
    example.addActionListener(new ActionListener() {
        public void actionPerformed(ActionEvent le) {
            mainFrame.removeall();
            JPanel 2ndPanel = new 2ndPanel(mainFrame);
            mainFrame.add(2ndPanel);
            mainFrame.validate();
        }
    });
  }
}

Is this the right structure - where it's the listeners that generate the new panels and not some unifying class? But if that's the case, how does Java's compiler ever get to mainFrame.validate() if there's a cascading infinity of listeners? I'm an old-school procedural programmer trying to program a Swing application in Java, and I reckon I might not have grasped the basic concepts of Swing programming. Look forward to any helpful answers, and thanks in advance!

Answer 1

I wouldn't do it like that. The Observer pattern is used in Swing to send notifications, usually as a result of an user action.

Take your example: The user 'clicks' on the button because he wants a new panel in MainFrame. But the button doesn't know what to do with a click. All he can do is notify event listeners, that it has been selected.

So we need some component that is interested in notifications. This component can register a listener with the button and receive notifications. The listener is this other components 'ear' (or it's 'eye'). But an ear (or eye) will not take action. It is just the other components sensor.

Which takes us back to the main question: who wants to be informed, if the button is clicked and who has to take action. This is a major design question. It's definitly not the listener that creates and adds a panel to main frame. It could be the main frames role to create and add sub panels or the role of a third component, which is responsible of creating a frame with sub panels.

But the listner is a bad place for this code.

Answer 2

First of all you shouldn't let the listener manipulate the frame directly, use a nested JPanel or it's ContentPane.

Your question depends on where your listener is located. You should only add components to a JFrame from the class itself. In your case it's OK, since the logic is confined to the class itself.

I don't think there is an infinity of listeners. They are in a list and are executed sequentially. Your listener should use SwingUtilities.invokeLater for manipulating the main frame.

I find the passing of the JFrame as an argument a little redundant. Why not create the listener from outside the constructor?

 final JPanel mainPanel = new MainPanel();     
 JButton example = new JButton("Example");
 example.addActionListener(new ActionListener() {
    public void actionPerformed(ActionEvent le) {
        SwingUtilities.invokeLater(new Runnable() {
            public void run() {
               MainFrame.this.removeAll();
               MainFrame.this.add(mainPanel);
            }
         });;
    }
 });
 add(example);

It's not the best of examples, but I am note sure what you are trying to do.

The bottom line is you should create the components outside the listener, and then add it using the listener.

Answer 3

Instead of destroying and creating panels you might want to look at hiding/showing them. There is a CardLayout layout manager that can do this: http://journals.ecs.soton.ac.uk/java/tutorial/ui/layout/card.html

Basically the idea is build and add all your panels at the start of your prog, then use the layout manager to flip between views.

As said by others, you might want to add some sort of model to your design, which is responsible for maintaining the state of the system.

Answer 4

There is some confusion by the, not unusual, way you have organised your code. As a general rule of Java, don't subclass where you have no reason to. It rarely makes sense to subclass JPanel or JFrame.

It also rarely makes sense to assign components to fields in the class that creates them. In fact, do less in constructors.

Also do less in anonymous inner classes. Detangle the event data and call a method that makes sense for the enclosing class to have as an operation.