16.5 Es tut sich was – Ereignisse beim AWT

Beim Arbeiten mit grafischen Oberflächen interagiert der Benutzer mit Komponenten. Er bewegt die Maus im Fenster, klickt eine Schaltfläche an oder verschiebt einen Rollbalken. Das grafische System beobachtet die Aktionen des Benutzers und informiert die Applikation über die anfallenden Ereignisse. Dann kann das laufende Programm entsprechend reagieren.

16.5.1 Die Klasse AWTEvent

Die ausgesandten Botschaften werden in Ereignis-Klassen kategorisiert. Da es unterschiedliche Ereignisse (engl. events) gibt, kann das System somit die Ereignisse unterteilen und eine Vorauswahl treffen.

Alle Ereignisse der grafischen Oberfläche sind Objekte, die aus einer Unterklasse von AWTEvent gebildet sind. Die Klasse AWTEvent ist abstrakt und selbst von EventObject aus dem util-Paket abgeleitet. Obwohl sich die meisten Oberflächen-Ereignis-Klassen in dem Unterpaket java.awt.event befinden, ist AWTEvent selbst direkt unter java.awt und damit nicht im Ereignis-Paket.

AWTEvent und Unterklassen (wie WindowEvent, KeyEvent)

Eine wichtige Methode ist getID(). Jede Ereignis-Klasse definiert eine ID, durch die sich die Ereignisse neben ihrer Klassenzugehörigkeit unterscheiden. Für Ereignisse von gedrückten Schaltflächen ist die ID etwa ActionEvent.ACTION_PERFORMED.

Natürlich stellt sich die Frage, wieso eine ID für die Ereignisse notwendig sein soll, weil die Vererbungsbeziehung doch den Typ klärt. Das ist zwar korrekt, doch gäbe es für mehr als dreißig Events zu viele Klassen. Daher haben die Entwickler ähnliche Ereignisse zu Gruppen zusammengefasst. So etwa bei einem WindowEvent, das dann versandt wird, wenn etwa das Fenster geschlossen oder verkleinert wird. In diesem Fall gibt es ein Ereignis vom Typ Win-dowEvent, aber zwei unterschiedliche IDs. So wird eine unübersehbare Anzahl von Event-Klassen vermieden. Einige Klassen verwalten weitere Konstanten, etwa für die gedrückten Tasten. Es wäre kaum sinnvoll, für jede Taste eine eigene Klasse zu schreiben. Statt einer neuen Klasse wird der Typ als eigenes Attribut im KeyEvent gespeichert.

16.5.2 Events auf verschiedenen Ebenen

Bei den Ereignissen werden zwei Typen unterschieden: die Ereignisse auf niedriger und die auf hoher Ebene.

• Ereignisse auf niedriger Ebene (engl. low-level events). Damit sind Ereignisse auf der Ebene des grafischen Betriebssystems gemeint. Das sind etwa eine Mausbewegung oder ein Fokus auf Komponenten, Tastendrücke oder das Schließen oder Vergrößern eines Fensters.

• Ereignisse auf höherer Ebene, semantische Ereignisse (engl. high-level events). Auf der anderen Seite gibt es Ereignisse, die von GUI-Komponenten erzeugt werden, wenn etwa eine Schaltfläche aktiviert (etwa durch Mausklick oder Drücken der -Taste) oder ein Rollbalken bewegt wird (zum Beispiel durch die Maus oder durch die -Taste). Die Swing-Komponenten reagieren meistens auf Ereignisse niedriger Ebene und formulieren daraus ein semantisches Ereignis. Es ist selten nötig, auf niedrige Ereignisse zu hören.

Die Trennung fällt aber nicht weiter auf, sodass wir im Folgenden darauf nicht eingehen werden.

Da alle grafischen Komponenten von der Klasse Component abgeleitet sind, liefern sie automatisch eine Reihe von nicht semantischen Ereignissen. Wir finden die Unterklassen und die Ereignistypen in der folgenden Tabelle.

Weitere Ereignisse auf niedriger Ebene werden von Fenstern und Dialogen ausgelöst; sie senden Ereignisobjekte vom Typ WindowEvent. Wir werden uns in diesem Kapitel auch mit den unterschiedlichen Komponenten beschäftigen und immer gleich die zugehörigen Ereignisse untersuchen. Die folgende Tabelle zeigt für einige grafische Komponenten die Ereignisse und gibt an, wann sie ausgelöst werden können.

16.5.3 Swings Ereignisquellen und Horcher (Listener)

Im Ereignismodell von Java gibt es eine Reihe von Ereignisauslösern (Ereignisquellen, engl. event source), wie zum Beispiel Schaltflächen. Die Ereignisse können von der grafischen Oberfläche kommen, etwa wenn der Benutzer eine Schaltfläche anklickt, aber auch auf eigene Auslöser zurückzuführen sein. Es gibt eine Reihe von Interessenten, die gern informiert werden wollen, wenn ein Ereignis aufgetreten ist. Da der Interessent in der Regel nicht an allen ausgelösten Oberflächen-Ereignissen interessiert ist, sagt er einfach, welche Ereignisse er empfangen möchte. Dies funktioniert so, dass er sich bei einer Ereignisquelle anmeldet, und diese informiert ihn, wenn sie ein Ereignis aussendet. [Das ist so, als ob ich einer Frau, die ich gerade kennengelernt habe, meine Telefonnummer hinterlasse. Anstatt sie ewig anzurufen, warte ich. Wenn sie Interesse hat, wird sie sich melden.] Auf diese Weise leidet die Systemeffizienz nicht, da nur diejenigen informiert werden, die auch Verwendung für das Ereignis haben.

Da der Interessent an der Quelle horcht, heißt er auch Listener oder Horcher. Für jedes Ereignis gibt es einen eigenen Listener, an den das Ereignis weitergeleitet wird – darum der Name für das Modell: Delegation Model. (Die Entwickler hatten vorher den Namen »Command Model« vergeben, doch drückte dies die Arbeitsweise nicht richtig aus.) Die folgende Tabelle gibt eine Übersicht über einige Listener und was sie für Ereignisse melden.

Dem Listener übergibt das Grafiksystem jeweils ein Ereignis-Objekt, also dem ActionListener ein ActionEvent-Objekt, dem WindowListener ein WindowEvent-Objekt usw. Die Einzigen, die etwas aus der Reihe tanzen, sind MouseListener und MouseMotionListener, denn beide melden MouseEvent-Objekte.

16.5.4 Listener implementieren

Der Listener selbst ist eine Schnittstelle, die von den Interessenten implementiert wird. Da die Ereignis-Schnittstelle Callback-Methoden vorschreibt, muss der Interessent diese Operation implementieren. Wird im nächsten Schritt ein Horcher mit dem Ereignisauslöser verbunden, kann die Ereignisquelle davon ausgehen, dass der Horcher die entsprechende Methode besitzt. Diese ruft die Ereignisquelle bei einem Ereignis später auf.

Eine Klasse implementiert die Schnittstelle WindowListener

Um ein Fenster korrekt zu schließen, ist das WindowListener-Interface zu implementieren. Dafür bieten sich zwei Möglichkeiten:

• Eine Klasse, die zum Beispiel JFrame erweitert, implementiert gleichzeitig WindowListener.

• Eine ganz neue Klasse implementiert die Listener-Schnittstelle.

Während der zweite Fall im Allgemeinen der bessere ist, hat die erste Variante den Vorteil, dass der Listener leicht auf Zustände oder Variablen zugreifen kann.

Wir wollen im folgenden Beispiel unser Hauptprogramm, die Schnittstelle WindowListener, implementieren lassen.

Listing 16.6 com/tutego/insel/ui/event/CloseWindowImplementsAll.java

package com.tutego.insel.ui.event; 
 
import javax.swing.*; 
import java.awt.event.*; 
 
public class CloseWindowImplementsAll extends JFrame implements WindowListener 
{ 
  // Implement WindowListener 
 
  @Override public void windowClosing( WindowEvent event ) 
  { 
   System.exit( 0 ); 
  } 
 
  @Override public void windowClosed( WindowEvent event ) { /*Empty*/ } 
  @Override public void windowDeiconified( WindowEvent event ) { /*Empty*/ } 
  @Override public void windowIconified( WindowEvent event ) { /*Empty*/ } 
  @Override public void windowActivated( WindowEvent event ) { /*Empty*/ } 
  @Override public void windowDeactivated( WindowEvent event ) { /*Empty*/ } 
  @Override public void windowOpened( WindowEvent event ) { /*Empty*/ } 
 
  // 
 
  public CloseWindowImplementsAll() 
  { 
    setSize( 400, 400 ); 
    addWindowListener( this ); 
    setVisible( true ); 
  } 
 
  public static void main( String[] args ) 
  { 
    new CloseWindowImplementsAll(); 
  } 
}

An diesem Beispiel ist abzulesen, dass jeder, der ein WindowListener sein möchte, die vorgeschriebene Methode implementieren muss. Damit zeigt er Interesse an dem WindowEvent. Bis auf windowClosing() haben wir die anderen Operationen nicht implementiert, da sie uns nicht interessieren. Die Implementierung ist so, dass die Anwendung beendet wird, wenn der Anwender auf das x klickt.

interface java.awt.event.WindowListener 
extends EventListener

• void windowOpened( WindowEvent e )
  Wird aufgerufen, wenn das Fenster geöffnet wurde.

• void windowClosing( WindowEvent e )
  Wird aufgerufen, wenn das Fenster geschlossen wird.

• void windowClosed( WindowEvent e )
  Wird aufgerufen, wenn das Fenster mit dispose() geschlossen wurde.

• void windowIconified( WindowEvent e )
  Wird aufgerufen, wenn das Fenster zum Icon verkleinert wird.

• void windowDeiconified( WindowEvent e )
  Wird aufgerufen, wenn das Fenster wieder hochgeholt wird.

• void windowActivated( WindowEvent e )
  Wird aufgerufen, wenn das Fenster aktiviert wird.

• void windowDeactivated( WindowEvent e )
  Wird aufgerufen, wenn das Fenster deaktiviert wird.

16.5.5 Listener bei dem Ereignisauslöser anmelden/abmelden

Hat der Listener die Schnittstelle implementiert, wird er mit dem Ereignisauslöser verbunden. Dafür gibt es eine Reihe von Hinzufügen- und Entfernen-Methoden, die einer Namenskonvention folgen.

• addEreignisListener( EreignisListener )

• removeEreignisListener( EreignisListener )

Dies bedeutet, dass etwa ein Listener für Fenster-Ereignisse, ein WindowListener, der WindowEvent-Ereignisse auslöst, mit der Methode addWindowListener() an das Fenster gebunden wird. Üblicherweise lassen sich beliebig viele Listener an einen Ereignisauslöser hängen.

Listing 16.7 CloseWindowImplementsAll.java, CloseWindowImplementsAll()

  CloseWindowImplementsAll() 
  { 
    setSize( 400, 400 ); 
    addWindowListener( this ); 
    setVisible( true ); 
  }

Wir tragen mit addWindowListener() den Listener (bei this das eigene Objekt als Listener) in eine interne Liste ein. Immer wenn ein Event ausgelöst wird, kümmert sich die jeweilige Methode um dessen Abarbeitung.

Natürlich kann nicht jede Komponente jedes Ereignis auslösen. Daher gibt es nur Hinzufügemethoden für Ereignisse, die die Komponenten tatsächlich auslösen. Ein Fenster wird zum Beispiel kein ActionEvent auslösen, daher fehlt ihm eine Methode addActionListener(). Dafür kann ein Fenster Fenster-Ereignisse auslösen und besitzt eine Methode addWindowListener(). Eine Schaltfläche wiederum löst keine Fenster-Ereignisse aus, und daher gibt es die Methode addWindowListener() bei Schaltflächen nicht. So lassen sich über die angebotenen addXXXListener()-Methoden gut die Ereignisse ablesen, die eine Komponente auslösen kann, denn das XXX wird dann nach der Namenskonvention der Ereignis-Typ sein.

16.5.6 Aufrufen der Listener im AWT-Event-Thread

Nachdem der Listener implementiert und angemeldet wurde, ist das System im Fall eines aufkommenden Ereignisses bereit, es zu verteilen. Aktiviert zum Beispiel der Benutzer eine Schaltfläche, so führt der AWT-Event-Thread – auch Event-Dispatching-Thread genannt – den Programmcode im Listener selbstständig aus. Sehr wichtig ist Folgendes: Der Programmcode im Listener sollte nicht zu lange dauern, da sich sonst Ereignisse in der Queue sammeln, die der AWT-Thread nicht mehr verarbeiten kann. Diese Eigenschaft fällt dann schnell auf, wenn sich Aufforderungen zum Neuzeigen (Repaint-Ereignisse) aufstauen, da auf diese Weise leicht ein »stehendes System« entsteht.

Die Reihenfolge, in der die Listener abgearbeitet werden, ist im Prinzip undefiniert. Zwar reiht sie Sun in ihrer Implementierung in eine Liste ein, sodass es dadurch eine Reihenfolge gibt, doch sollte es keine Beachtung dieses Implementierungsdetails geben.

16.5.7 Adapterklassen nutzen

Der Nachteil der ersten Variante besteht darin, dass wir immer alle Methoden implementieren müssen, auch wenn wir nur eine der vielen Methoden benötigen. Hier helfen Adapterklassen – Klassen, die die Schnittstellen mit leeren Rümpfen implementieren. Hat beispielsweise die Schnittstelle WindowListener sieben Methoden, so steht in der Adapterklasse folgende Implementierung:

Listing 16.8 java.awt.event.WindowAdapter

public abstract class WindowAdapter 
  implements WindowListener, WindowStateListener, WindowFocusListener 
{ 
    public void windowOpened( WindowEvent e ) { } 
    public void windowClosing( WindowEvent e ) { } 
    public void windowClosed( WindowEvent e ) { } 
    public void windowIconified( WindowEvent e ) { } 
    public void windowDeiconified( WindowEvent e ) { } 
    public void windowActivated( WindowEvent e ) { } 
    public void windowDeactivated( WindowEvent e ) { } 
    public void windowStateChanged( WindowEvent e ) { } 
    public void windowGainedFocus( WindowEvent e ) { } 
    public void windowLostFocus( WindowEvent e ) { } 
}

Zusätzlich entdecken wir einige Methoden, die nicht direkt von unserem WindowListener stammen, sondern von zwei weiteren Schnittstellen, die jetzt keine Rolle spielen.

Wenn wir jetzt einen Ereignisbehandler verwenden, erweitern wir einfach die Adapterklasse. Unser Programm zum Schließen des Fensters mit einer externen Adapterklasse sieht dann wie folgt aus:

Listing 16.9 com/tutego/insel/ui/event/CloseWindowWithAdapter.java

package com.tutego.insel.ui.event; 
 
import java.awt.event.*; 
import javax.swing.*; 
 
public class CloseWindowWithAdapter 
{ 
  public static void main( String[] args ) 
  { 
    JFrame f = new JFrame(); 
    f.setSize( 400, 400 ); 
    f.setVisible( true ); 
 
    f.addWindowListener( new CloseWindowAction() ); 
  } 
} 
 
class CloseWindowAction extends WindowAdapter 
{ 
  @Override 
  public void windowClosing( WindowEvent e ) { System.exit(0); } 
}

Der Unterschied zwischen windowClosing() und windowClosed()

Die Schnittstelle WindowListener schreibt zwei Methoden vor, deren Namen sich ziemlich ähnlich anhören: windowClosing() und windowClosed(). Betrachten wir den Unterschied zwischen beiden und wie ein Programm beide Methoden nutzen oder meiden kann.

In den einfachen Programmen setzen wir in die windowClosing()-Methode einen Aufruf von System.exit(), um die Applikation zu beenden, da windowClosing() immer bei Beendigung der Applikation mit dem ´ am Fenster aufgerufen wird. Was allerdings leicht vergessen wird, ist die Tatsache, dass nicht nur der Benutzer über das ´ das Fenster schließen kann, sondern auch die Applikation über die spezielle Methode dispose(). Sie gibt alle Ressourcen frei und schließt das Fenster. Die Applikation ist dann allerdings noch nicht beendet. Damit wir das Schließen mit dem ´ und durch dispose() unterscheiden können, kümmert sich windowClosing() um das ´ und windowClosed() um das dispose(). Wenn wir lediglich mit dem ´ das Fenster schließen und die Applikation beendet werden soll, muss nicht noch extra dispose() schön brav die Ressourcen freigeben. Daher reicht oft ein System.exit(). Soll das Fenster jedoch mit ´ und dispose() einfach nur geschlossen werden oder ist eine gemeinsame Behandlung gewünscht, ist es sinnvoll, in windowClosing() mit dispose() indirekt window-Closed() aufzurufen. Das sieht dann folgendermaßen aus:

class WL extends WindowAdapter 
{ 
  public void windowClosing( WindowEvent e ) 
  { 
    event.getWindow().dispose(); 
  } 
  public void windowClosed( WindowEvent e ) 
  { 
    // Das Fenster ist geschlossen, und jetzt können wir hier 
    // weitermachen, etwa mit System.exit(), wenn alles 
    // vorbei sein soll. 
  } 
}

setDefaultCloseOperation() und der WindowListener

Die Anweisung setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE) ist eigentlich nur zu Testzwecken nützlich, denn in ausgewachsenen GUI-Anwendungen sollte sich die Applikation nicht einfach schließen, sondern mit einem Dialog über das Ende informieren. Hier werden nun die Konstanten HIDE_ON_CLOSE und DISPOSE_ON_CLOSE für die setDefaultCloseOperation() interessant. Sie kennzeichnen zum einen, ob das Fenster automatisch verdeckt werden soll, nachdem die WindowListener aufgerufen wurden (dies ist der Standard), und zum anderen, ob alle Listener abgearbeitet werden sollen und das Fenster geschlossen werden soll. HIDE_ON_CLOSE ist die Standardeinstellung.

16.5.8 Innere Mitgliedsklassen und innere anonyme Klassen

Wir haben für die Adapterklasse eine externe Klasse benutzt, weil das Erweitern wegen der Einfachvererbung schnell an seine Grenzen stößt. Mit inneren Klassen wird allerdings alles elegant, denn sie können leicht auf Zustände der äußeren Klasse zugreifen. Dabei lassen sich innere Klassen auf unterschiedliche Weise verwenden. Zum einen als Mitgliedsklasse; das heißt, die Klasse, die bisher als externe Klasse vorgelegen hat, wird in eine andere Klasse hineingenommen. Im vorigen Beispiel bedeutet dies: Wir nehmen CloseWindowAction in die Klasse CloseWindowWithAdapter auf und schreiben die Klassendeklaration nicht unter der anderen Klasse. Zum anderen kann die innere Klasse wie eine lokale Variablendeklaration noch in die Methode aufgenommen werden, die die addXXXListener()-Methode beinhaltet.

Der zweite Weg führt über innere anonyme Klassen. Dadurch wird das Programm zwar schön kurz, doch lange Ereignisbehandler führen schnell zu unübersichtlichem Quellcode. Implementieren wir unser Programm zum Schließen des Fensters mit einer inneren anonymen Klasse:

Listing 16.10 com/tutego/insel/ui/event/CloseWindowWithInnerClass.java

package com.tutego.insel.ui.event; 
 
import java.awt.event.*; 
import javax.swing.*; 
 
public class CloseWindowWithInnerClass extends JFrame 
{ 
  public CloseWindowWithInnerClass() 
  { 
    setSize( 400, 400 ); 
 
    addWindowListener( new WindowAdapter() { 
      @Override public void windowClosing( WindowEvent e ) { 
        System.exit( 0 ); 
      } 
    } ); 
  } 
 
  public static void main( String[] args ) 
  { 
    new CloseWindowWithInnerClass().setVisible( true ); 
  } 
}

Die Lösung hat den Vorteil, dass nicht extra eine eigene Klasse mit einem häufig überflüssigen Namen angelegt wird. Die Unterklasse von WindowAdapter ist nur hier sinnvoll und wird nur in diesem Kontext benötigt.

Ihr Kommentar