Listeners
A listener is called when the user does something to the user interface that causes an event. Altho these events usually come from the user interface, they can have other sources (eg, a Timer).
Button listener example
After a button is created, you will add a listener to it. Eg,
b.addActionListener(listener_object);
When the button is clicked, a call is made to the actionPerformed() method defined in the class of the listener object. An ActionEvent object is passed as a parameter to it actionPerformed().
The listener method must be called actionPerformed
There is (unfortunately) no way to use any given method as a listener -- the listener must be called actionPerformed.
One per class. Because there can only be one actionPerformed method in a class, a new class is needed for every separate listener, or you have to share an actionPerformed method and use the ugly technique of figuring out who caused the call.
Incidental note. To address this awkward situation C# has delegates, which allow any method to be a listener, provided it has the correct return type and parameters. This doesn't provide any additional functionality, but it is more convenient.
You need to create an instance of the class which defines the actionPerformed method for the button, and it is this instance that becomes the button listener.
Common Listener Strategies
Here are common ways to write listeners:
- Named Inner Class Listeners are one of the most common ways to write small programs. They are convenient to write and and be shared with several components.
- Anonymous Inner Class Listeners are sometimes used to associate a different listener with each button or other control. This is a little quicker to write, but lacks some of the flexibility of inner class listeners.
- Top-level Listeners (this) are commonly used where there is only one source of an event. For example, if you are defining a subclass of JPanel to use for drawing with a mouse, an instance of this new class will typically also be the mouse event listener. Similarly with a JPanel used for animation -- the panel itself may serve as the ActionListener for the Timer. Do not use "this" as a listener for buttons, menus, etc. because all controls must then share that one action listener.
- Action and AbstractAction objects are action listeners. In some ways they are more powerful than other action listener strategies in that they can easily be used to enable or disable multiple controls. An action object can be shared with many controls; eg, the same action is sometimes accomplished with a menu item and a button or toolbar tool. They encapsulate the name, description, enabled status, listener, and icon information. This is a good choice for large interfaces, and quite compatible with the MVC pattern (see below).
- External Listeners - To implement the Model-View-Controller pattern, all listeners will effectively be in the Controller module. There are a number of ways to split the controller actions from the View part of the interface. One example is in Model-View-Controller (MVC) Structure.
- Subclassing a component and overriding processActionEvent(). This peculiar scheme certainly isn't general, and I've never seen it done in a serious program. Do not do this.
The examples in these notes use named inner class listeners most often, anonymous inner class listeners in a few examples, and top-level listeners for mouse listeners for graphics panels.
