Event Based Programming

Dr Andy Evans

[Fullscreen]

Event Based Programming

• Programs don't usually run in a set sequence, they wait for something to happen.
• When they're used or clicked, GUI Components send out objects that subclass java.awt.AWTEvent.
• Other classes can register as 'listeners' with the Components that send out the event objects.
• Listeners get sent the AWTEvent objects. They can then do appropriate actions.

Event based programming

• Listeners must implement particular sub-interfaces of the EventListener interface. These are in the package java.awt.event.
• By implementing these interfaces the listener classes are forced to provide methods that cope with the AWTEvent objects they are sent.

Example

Sending events

• When a class registers with an event producer, the producer adds the class to an array of EventListeners inside itself.

Sending events

• When an event is 'sent' the Component producing the event calls the appropriate method inside all the objects in the array.

Sending events

• Remember that because the classes in the array implement EventListeners, we can guarantee that they always have the right methods.
• Our implementing classes are automatically treated as the superclass Interface, because we never use any other methods.

Destroying the Frame

• Frames produce a WindowEvent when they're opened, closed, minimized etc.
• You can register with a Frame if you implement WindowListener, and its seven methods.

Destroying the Frame

• We could implement WindowListener to listen for the closing event.
• There is, alternatively, an abstract class WindowAdapter we could extend. We'd then overload its default windowClosing method.
• However, for such a minor case we tend to use the following code. This sets up an anonymous inner class which does the same thing:

  	
  addWindowListener(new WindowAdapter(){
      public void windowClosing(WindowEvent e){
  		((Frame)e.getSource()).dispose();
  		// or
  		System.exit(0);
      }
  });
  
  

Why go through so many hoops?

• Encapsulation would seem to dictate GUI and listeners should be the same class.
• But, it's quite possible that the GUI is on one machine and the controller objects on another.
• We are trying to encourage two forms of software architecture:
  • Model-View-Controller.
  • n-tier.

Model-View-Controller (MVC) architecture

• Separate Look and Feel from actions and data.
• In Swing each component has an associated Model class which contains the data.
• You can provide your own model for a component by subclassing the Model class or by implementing the appropriate interface.
• For example, you could subclass DefaultListModel or implement the ListModel interface, and then use the JList setModel method to attach your data-model to the component.

N-tier architecture

• Usually run over networks.
• Three-tier architecture:
  • A 'thin' GUI client on the user's machine ('fat' clients do more analysis).
  • A processing application (usually on a machine dedicated to complex processing).
  • A data server (usually a database).
• Client talks to Processor which talks to Data server.
• Divides resources to most appropriate machines.
• N-tier: more middle level apps talking to each other.

Summary

• The GUI is a set of nested subclasses of 'Component'.
• GUI based programs don't run in a set sequence, they wait for events.
• Most components when used send out 'events'. We make 'listener' objects which we register with each component.
• When something happens, the listener is informed through an interface defined method and acts.
• This allows us to separate the look from the processing and data.