Java: 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.
Other Resources