Concept of Event Handling

[Piyush Arora]

I am currently reading Head First Java, and trying to supplement it with other sources. But things are starting to get hairy! As if constructors, polymorphism, interfaces etc. alone weren't bad enough, event handling is blowing my mind away. Ok so below is what I think I know, and what confuses me. Your help in clarifying these concepts is very much appreciated.

What I know:
Interfaces define methods which must be later implemented by another class. They are useful because they allow objects to interact with the outside world, much like classes, but are more flexible from an inheritance standpoint.

Event handling - allows us to listen to user actions, i.e. mousePressed.

Event is a class,
Has sub-classes including MouseEvent class,
MouseEvent class has a MouseListener interface,
which defines methods like mousePressed.

By definition, mousePressed must be an abstract method, aka no body.

What I don't understand:
How does it know when the mouse has been pressed if there is no code in it?

Hope this makes sense!

[Sresh Rangi]

The mouse listener is abstract, but classes that implement it are not. When you add a mouse listener, you add a concrete subclass that will contain the code to response to the event.

A simplified implementation might go something like this:

The event and listener:

public class MouseEvent {
	private int button;
	
	public MouseEvent(int button) {
		this.button = button;
	}
	
	public int getButton() {
		return button;
	}
}

public interface MouseListener {
	void mouseClicked(MouseEvent event);
}

A widget class:

public class Window {
	private List<MouseListener> mouseListeners = new ArrayList<MouseListener>();

	public void addMouseListener(MouseListener mouseListener) {
		mouseListeners.add(mouseListener);
	}
	
	void fireMouseEvent(MouseEvent event) {
		for(MouseListener listener:mouseListeners) {
			listener.mouseClicked(event);
		}
	}
}

Adding and firing the event:

Window window = new Window();		
window.addMouseListener(new MouseListener() {
	public void mouseClicked(MouseEvent event) {
		System.out.println("Clicked: " + event.getButton());
	}
});
		
// Somewhere else...
window.fireMouseEvent(new MouseEvent(1));

Here the code is added so the client does something in response to the event. The fireMouseEvent method would be called internally within the library when the user clicks the mouse, probably involving some native operating system calls at some point. If you're using an existing library, then the only code you need is that to create an object, and add the listener to it. The firing of the events then happens elsewhere. This allows you to respond to events without having to directly check what causes them.

[Piyush Arora]

Thank you, Sresh! That makes a lot more sense. One final question, what is the usage / purpose of "this"? How does it work?

[Sresh Rangi]

Piyush Arora wrote:Thank you, Sresh! That makes a lot more sense. One final question, what is the usage / purpose of "this"? How does it work?

"this" is a reference to the current instance. The one that a constructor or method was called on. See the this keyword

[Maneesh Godbole]

Welcome to the Ranch.
The usual way to describe all this is called an event delegation model.

An event of interest might occur. A listener is delegated to process it, when it occurs.

I went to a cafe with my 10 year old daughter. I ordered and paid for the coffee. Since it was expected to take some time, we sat at a table. I told my daughter, when our coffee is ready, they will call out our name. You need to keep an ear out for that, and when our coffee is ready, you can go and collect it all by yourself.
The event expected to occur was the coffee being ready.
My daughter was the listener (who would process the event when it occurred) for the event.
I delegated her to listen to the event.
She would process the event by collecting our coffee and bringing it to our table

[Campbell Ritchie]

You hardly ever create events yourself. When you move your mouse onto the GUI, mouse events start appearing. If Maneesh orders his coffee and the barista shouts, “Coffee for Campbell!”, nothing happens because it is an event Maneesh is not listening for.
When you write the program, you decide which events you are interested in, and instruct the components to listen for them. Any other events disappear into cyber‑limbo never to be seen again. There are probably hundreds of events every minute when you have a GUI active. They vary depending on how you click on it, move it, cover it, bring it to the front, etc etc.

[Robert D. Smith]

Maneesh, just wanted to say I loved the example. I'll have to keep it in mind and steal it (with proper recognition of course).

[Maneesh Godbole]

Robert D. Smith wrote:Maneesh, just wanted to say I loved the example. I'll have to keep it in mind and steal it (with proper recognition of course).

As long as you don,t steal my coffee we should be good
Also keep in mind one very important point cited by Campbell, you get notified for only those events you subscribe to. I totally missed it in my post.

[Campbell Ritchie]

Since events are a GUI phenomenon, I shall move this discussion to the GUIs forum.

You almost always create an event by moving the mouse, clicking a button, etc etc. Not by programming the fireXXX methods.