Would Like to See Examples of Listeners

[Hal Vaughan]

I've said here before that I'm self taught. I have 4 reference books, and
they mention listeners and give partial examples, but not one gives me a
good, clear example of setting up a listener, using it, and disposing it.

Can anyone either point me to some good examples online, or show me one? It
would save me a day or two of try different ways to do it.

Thanks for any help.

Hal

[Neomorph]

On Thu, 07 Aug 2003 22:39:01 GMT, Hal Vaughan <ha*@thresholdd igital.com>
two-finger typed:

I've said here before that I'm self taught. I have 4 reference books, and
they mention listeners and give partial examples, but not one gives me a
good, clear example of setting up a listener, using it, and disposing it.

Can anyone either point me to some good examples online, or show me one?It
would save me a day or two of try different ways to do it.

Thanks for any help.

Hal

A listener is basically a class that implements the method or methods
described in the listener interface, such as java.awt.event. ActionListener.

I. using a listener

Just add the listener implemenation to an 'event' source:
myButton.addAct ionListener(myL istener);

II. disposing of a listener

Just remove the listener implemenation from the 'event' source:
myButton.remove ActionListener( myListener);

III. creating a listener

You can do this in three different ways:
1) make one of your public classes implement the listener itself.
2) create an anonymous inner class that creates the listener.
3) create a named inner class that implements the listener.

1: Example1Class.j ava

import java.awt.* ;
import java.awt.event. * ;

// Advantages:
// - no complex code
// - external classes can issue the command
// (accessibility e.g. by using Example1Class.C OMMAND)
// - listener can be removed again (disable method in this case).
// - single class file implementation.
//
// Disadvantage:
// - events can be spoofed (made look like they are authentic
// and come from myButton without user interaction).
public Example1Class implements ActionListener {
public final static String COMMAND = "CLICKED";
Button myButton = new Button("Click here");
public Example1Class(C ontainer parent) {
super();
myButton.setAct ionCommand(COMM AND);
myButton.setBou nds(10,10,200,2 0);
parent.add(myBu tton);
}
public void enable() {
myButton.addAct ionListener(thi s);
}
public void disable() {
myButton.remove ActionListener( this);
}
public void actionPerformed (ActionEvent event) {
Object source = event.getSource ();
String action = event.getAction Command();
System.out.prin tln(
"Action issued from "+source.toStri ng());
System.out.prin tln("Command: "+action);
}
}

2: Example2Class.j ava

import java.awt.* ;
import java.awt.event. * ;

// Advantages:
// - no complex code
// - information hiding, security (no spoofing):
// only the button can/will issue the events.
//
// Disadvantages:
// - listener cannot be removed easily, since no reference exists
// (except in the button itself).
// - two class files to distribute (one with added $1 in the name)

public Example2Class {
Button myButton = new Button("Click here");
public Example2Class(C ontainer parent) {
super();
myButton.setAct ionCommand("CLI CKED");
myButton.setBou nds(10,10,200,2 0);
parent.add(myBu tton);
}
public void enable() {
myButton.addAct ionListener(new ActionListener(
{
public void actionPerformed (ActionEvent event) {
Object source = event.getSource ();
String action = event.getAction Command();
System.out.prin tln(
"Action issued from "+source.toStri ng());
System.out.prin tln("Command: "+action);
}
});
}
}

3: Example3Class.j ava

import java.awt.* ;
import java.awt.event. * ;

// Advantages:
// - information hiding, security (no spoofing):
// only the button can/will issue the events.
// - listener can be removed again (disable method in this case).
//
// Disadvantages:
// - more complex code
// - two class files to distribute (one with added $Respond)

public Example3Class {
Button myButton = new Button("Click here");
public Example2Class(C ontainer parent) {
super();
myButton.setAct ionCommand("CLI CKED");
myButton.setBou nds(10,10,200,2 0);
parent.add(myBu tton);
}
class Respond {
public void actionPerformed (ActionEvent event) {
Object source = event.getSource ();
String action = event.getAction Command();
System.out.prin tln(
"Action issued from "+source.toStri ng());
System.out.prin tln("Command: "+action);
}
} responder = new Respond();

public void enable() {
myButton.addAct ionListener(res ponder);
}
public void disable() {
myButton.remove ActionListener( responder);
}
}
Have fun,
Cheers.

[FISH]

Hal Vaughan <ha*@thresholdd igital.com> wrote in message news:<8yAYa.603 41$cF.20558@rwc rnsc53>...

I've said here before that I'm self taught. I have 4 reference books, and
they mention listeners and give partial examples, but not one gives me a
good, clear example of setting up a listener, using it, and disposing it.
What do you mean by 'partial' ?

You're unlikely to find a tutorial or examples which focus specifically
on listeners, as they are merely the mechanics which enable events to be
delivered from one part of a Java application to another, and as such
they tend to be taught as part of something bigger (usually AWT/Swing!)
rather than as an isolated topic in their own right.

Can anyone either point me to some good examples online, or show me one? It
would save me a day or two of try different ways to do it.

There's nothing magically about listeners. A given piece of Java code
which may be required to signal events to other parts of an application
(for example, a button when it is clicked) will provide the facility to
remember one or more listeners, who are interested in receiving notifi-
cation of its events. The interested parties are responsible for
registering themselves with the event source, so the source knows of
their existance and can dispatch events to them, as and when...

The actual coupling between event source and listener is typically done
in the form of an interface, which each interested party implements, to
provide methods which the event source can then call to signal that a
given event has occured - typically passing over an event object which
contains specific details of the event.

There are certain naming patterns (conventions) which apply. They are
not mandatory, but they do make the code more readable. Each set of
events is known by a given name, and that name is then used as the
basis of the various classes, interfaces and methods which define the
listener mechanism for that set of events.

As some listeners handle several events (several event methods) you'll
also find 'adapter' classes are often available to help minimise the
amount of coding needed to implement a listener. Adapters provide a
default implementation of an interface (typically not doing anything
useful with the events) allowing the programmer to override only those
event handling methods she is interested in - rather than providing
code for *every* method in the listener interface. You'll usually find
that adapters are build using inner classes of the class which is actua-
lly interested in the event - but they don't *have* to be!
-FISH- ><>

[Hal Vaughan]

Wow!

I've been wading through my books, the web, the OpenOffice.org idl ref and
the Java SDK references. You did a great job at simplifying everything and
making it quite clear. I didn't realize it was so simple.

Hal

Neomorph wrote:

On Thu, 07 Aug 2003 22:39:01 GMT, Hal Vaughan <ha*@thresholdd igital.com>
two-finger typed:

I've said here before that I'm self taught. I have 4 reference books, and
they mention listeners and give partial examples, but not one gives me a
good, clear example of setting up a listener, using it, and disposing it.

Can anyone either point me to some good examples online, or show me one?
It would save me a day or two of try different ways to do it.

Thanks for any help.

Hal

A listener is basically a class that implements the method or methods
described in the listener interface, such as
java.awt.event. ActionListener.

I. using a listener

Just add the listener implemenation to an 'event' source:
myButton.addAct ionListener(myL istener);

II. disposing of a listener

Just remove the listener implemenation from the 'event' source:
myButton.remove ActionListener( myListener);

III. creating a listener

You can do this in three different ways:
1) make one of your public classes implement the listener itself.
2) create an anonymous inner class that creates the listener.
3) create a named inner class that implements the listener.

1: Example1Class.j ava

import java.awt.* ;
import java.awt.event. * ;

// Advantages:
// - no complex code
// - external classes can issue the command
// (accessibility e.g. by using Example1Class.C OMMAND)
// - listener can be removed again (disable method in this case).
// - single class file implementation.
//
// Disadvantage:
// - events can be spoofed (made look like they are authentic
// and come from myButton without user interaction).
public Example1Class implements ActionListener {
public final static String COMMAND = "CLICKED";
Button myButton = new Button("Click here");
public Example1Class(C ontainer parent) {
super();
myButton.setAct ionCommand(COMM AND);
myButton.setBou nds(10,10,200,2 0);
parent.add(myBu tton);
}
public void enable() {
myButton.addAct ionListener(thi s);
}
public void disable() {
myButton.remove ActionListener( this);
}
public void actionPerformed (ActionEvent event) {
Object source = event.getSource ();
String action = event.getAction Command();
System.out.prin tln(
"Action issued from "+source.toStri ng());
System.out.prin tln("Command: "+action);
}
}

2: Example2Class.j ava

import java.awt.* ;
import java.awt.event. * ;

// Advantages:
// - no complex code
// - information hiding, security (no spoofing):
// only the button can/will issue the events.
//
// Disadvantages:
// - listener cannot be removed easily, since no reference exists
// (except in the button itself).
// - two class files to distribute (one with added $1 in the name)

public Example2Class {
Button myButton = new Button("Click here");
public Example2Class(C ontainer parent) {
super();
myButton.setAct ionCommand("CLI CKED");
myButton.setBou nds(10,10,200,2 0);
parent.add(myBu tton);
}
public void enable() {
myButton.addAct ionListener(new ActionListener(
{
public void actionPerformed (ActionEvent event) {
Object source = event.getSource ();
String action = event.getAction Command();
System.out.prin tln(
"Action issued from "+source.toStri ng());
System.out.prin tln("Command: "+action);
}
});
}
}

3: Example3Class.j ava

import java.awt.* ;
import java.awt.event. * ;

// Advantages:
// - information hiding, security (no spoofing):
// only the button can/will issue the events.
// - listener can be removed again (disable method in this case).
//
// Disadvantages:
// - more complex code
// - two class files to distribute (one with added $Respond)

public Example3Class {
Button myButton = new Button("Click here");
public Example2Class(C ontainer parent) {
super();
myButton.setAct ionCommand("CLI CKED");
myButton.setBou nds(10,10,200,2 0);
parent.add(myBu tton);
}
class Respond {
public void actionPerformed (ActionEvent event) {
Object source = event.getSource ();
String action = event.getAction Command();
System.out.prin tln(
"Action issued from "+source.toStri ng());
System.out.prin tln("Command: "+action);
}
} responder = new Respond();

public void enable() {
myButton.addAct ionListener(res ponder);
}
public void disable() {
myButton.remove ActionListener( responder);
}
}
Have fun,
Cheers.

[Hal Vaughan]

FISH wrote:

Hal Vaughan <ha*@thresholdd igital.com> wrote in message
news:<8yAYa.603 41$cF.20558@rwc rnsc53>...

I've said here before that I'm self taught. I have 4 reference books,
and they mention listeners and give partial examples, but not one gives
me a good, clear example of setting up a listener, using it, and
disposing it.
What do you mean by 'partial' ?

You're unlikely to find a tutorial or examples which focus specifically
on listeners, as they are merely the mechanics which enable events to be
delivered from one part of a Java application to another, and as such
they tend to be taught as part of something bigger (usually AWT/Swing!)
rather than as an isolated topic in their own right.

Can anyone either point me to some good examples online, or show me one?
It would save me a day or two of try different ways to do it.

There's nothing magically about listeners. A given piece of Java code
which may be required to signal events to other parts of an application
(for example, a button when it is clicked) will provide the facility to
remember one or more listeners, who are interested in receiving notifi-
cation of its events. The interested parties are responsible for
registering themselves with the event source, so the source knows of
their existance and can dispatch events to them, as and when...

That's what it took me time to figure out. I found so little on them, it
seemed like there was something going on that I was missing. It took me a
few days of poking around to finally get one working correctly.
The actual coupling between event source and listener is typically done
in the form of an interface, which each interested party implements, to
provide methods which the event source can then call to signal that a
given event has occured - typically passing over an event object which
contains specific details of the event.

There are certain naming patterns (conventions) which apply. They are
not mandatory, but they do make the code more readable. Each set of
events is known by a given name, and that name is then used as the
basis of the various classes, interfaces and methods which define the
listener mechanism for that set of events.

As some listeners handle several events (several event methods) you'll
also find 'adapter' classes are often available to help minimise the
amount of coding needed to implement a listener. Adapters provide a
default implementation of an interface (typically not doing anything
useful with the events) allowing the programmer to override only those
event handling methods she is interested in - rather than providing
code for *every* method in the listener interface. You'll usually find
that adapters are build using inner classes of the class which is actua-
lly interested in the event - but they don't *have* to be!
Actually, I found more on "adapter" classes than on just listeners.
Thanks!

Hal
-FISH- ><>