15.2 Varianten, das Fenster zu schließen 

Bei dem ersten AWT-Programm mit Fenstern haben wir das Problem, dass das Fenster nicht sauber geschlossen werden kann. Dies liegt ganz einfach daran, dass spezielle Fensterereignisse ausgelöst werden, die von uns abgefangen werden müssen, was wir aber nicht getan haben. Doch nur dann ist ein sauberes Beenden möglich, denn bei den vielen Ereignissen, die das Fenstersystem sendet, ist auch die Aufforderung zum Schließen des Fensters dabei. Unter Swing reagiert ein JFrame auf WindowEvents und reagiert in der protected-Methode processWindowEvent() auf das WINDOW_CLOSING und kann das Fenster so auch ohne hinzugefügten Ereignisbehandler schließen.

Um ein Fenster korrekt zu schließen, müssen wir das WindowListener-Interface implementieren. WindowListener definiert eine Anzahl von Funktionen, die mit addWindowListener() an ein Fenster gebunden werden. Immer dann, wenn ein Event ausgelöst wird, kümmert sich diese jeweilige Funktion um die Abarbeitung.

Wir wollen im Folgenden einige populäre Möglichkeiten zum Schließen eines Fensters aufzeigen.

15.2.1 Eine Klasse implementiert die Schnittstelle WindowListener 

Die erste Möglichkeit, Ereignisbehandlung zu implementieren, besteht in der Implementierung aller vorgeschriebenen Methoden der Listener-Schnittstelle. Dazu bieten sich zwei Klassen an: Zum einen die Hauptklasse, die auch das Fenster öffnet, und zum anderen eine externe Klasse, die nichts anderes macht, als die Listener-Schnittstelle zu implementieren. Wir wollen im folgenden Beispiel unser Hauptprogramm die Schnittstelle WindowListener implementieren lassen.

Listing 15.1   FensterWegImplementsAll.java

import javax.swing.*;

import java.awt.event.*;

class FensterWegImplementsAll extends JFrame implements WindowListener
{
  public FensterWegImplementsAll()
  {
    setSize( 400, 400 );

    addWindowListener( this );

    show();
  }

  // Implementiere WindowListener

  public void windowClosing( WindowEvent event ) {
    System.exit( 0 );
  }

  public void windowClosed( WindowEvent event ) {}

  public void windowDeiconified( WindowEvent event ) {}

  public void windowIconified( WindowEvent event ) {}

  public void windowActivated( WindowEvent event ) {}

  public void windowDeactivated( WindowEvent event ) {}

  public void windowOpened( WindowEvent event ) {}

  public static void main( String args[] )
  {
    new FensterWegImplementsAll();
  }
}

Die anderen Funktionen sind hier nicht implementiert, aber die Funktion lässt sich leicht am Namen ablesen. Das Fenster wird geschlossen, wenn der Anwender auf das X drückt

interface java.awt.event.WindowListener

extends EventListener

void windowOpened( WindowEvent e ) Aufgerufen, wenn Fenster geöffnet wurde.

void windowClosing( WindowEvent e ) Aufgerufen, wenn das Fenster geschlossen wird.

void windowClosed( WindowEvent e ) Aufgerufen, wenn das Fenster mit dispose() geschlossen wurde.

windowIconified( WindowEvent e ) Aufgerufen, wenn das Fenster zum Icon verkleinert wird.

windowDeiconified( WindowEvent e ) Aufgerufen, wenn das Fenster wieder hochgeholt wird.

windowActivated( WindowEvent e ) Aufgerufen, wenn das Fenster aktiviert wird.

windowDeactivated( WindowEvent e ) Aufgerufen, wenn das Fenster deaktiviert wird.

Der Unterschied zwischen windowClosing() und windowClosed()

Die Schnittstelle WindowListener schreibt zwei Methoden vor, die 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 und den folgenden Programmen, setzen wir in die windowClosing()-Methode einfach ein System.exit() ein, um die Applikation zu beenden. Denn windowClosing() wird immer dann aufgerufen, wenn die Applikation mit dem X am Fenster beendet wird. Was allerdings leicht vergessen wird ist, dass nicht nur der Benutzer über das X 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 so allerdings noch nicht beendet. Damit wir das Schließen mit dem X und durch dispose() unterscheiden können, kümmert sich windowClosing() um das X und windowClosed() um das dispose(). Wenn wir lediglich mit dem X das Fenster schließen und die Applikation soll beendet werden, muss nicht noch extra dispose() schön brav die Ressourcen freigeben. Daher reicht oft ein System.exit(). Soll das Fenster jedoch mit X und dispose() einfach nur geschlossen werden oder ist eine gemeinsame Behandlung gewünscht, so ist es sinnvoll, in windowClosing() mit dispose() indirekt windowClosed() aufzurufen. Das sieht dann so 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.
  }
}

15.2.2 Adapterklassen nutzen 

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

Listing 15.2   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 kommen, sondern noch von zwei weiteren Schnittstellen, die in 1.4 hinzugekommen sind.

import java.awt.event.*;

import javax.swing.*;

public class FensterWegExternerAdapter
{
  public static void main( String args[] )
  {
    JFrame f = new JFrame();
    f.setSize( 400, 400 );
    f.setVisible( true );

    f.addWindowListener( new FensterWegAdapter() );
  }
}

class FensterWegAdapter extends WindowAdapter
{
  public void windowClosing( WindowEvent e ) { System.exit(0); }
}

15.2.3 Innere Mitgliedsklassen und innere anonyme Klassen 

Wir haben für die Adapterklasse eine externe Klasse benutzt, denn das Erweitern stößt wegen der Einfachvererbung schnell an seine Grenzen. Mit inneren Klassen wird das Ganze allerdings elegant. Dabei lassen sich innere Klassen auf unterschiedliche Weise verwenden. Einmal als Mitgliedsklasse, das heißt, die Klasse, die bisher als externe Klasse vorlag, wird in eine andere Klasse hineingenommen. In dem gerade gezeigten Beispiel heißt das, wir nehmen FensterWegAdapter in die Klasse FensterWegExternerAdapter auf und schreiben die Klassendefinition nicht unter der anderen Klasse. Dann kann die innere Klasse, wie eine lokale Variablendeklaration, noch in der Methode aufgenommen werden, die die addXXXListener()-Funktion 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.

Listing 15.4   FensterWegInnerAnonym.java

import java.awt.event.*;

import javax.swing.*;

public class FensterWegInnerAnonym extends JFrame
{
  public FensterWeg()

  {
    setSize( 400, 400 );

    addWindowListener( new WindowAdapter() {

      public void windowClosing ( WindowEvent e ) {

        System.exit(0);

      }

    });

  }

  public static void main( String args[] )
  {
    new FensterWegInnerAnonym().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 macht nur hier Sinn und wird nur in diesem Kontext benötigt.

15.2.4 Generic Listener 

Eine recht neue Methode haben die Entwickler ab Version 1.3 hinzugefügt: die Generic Listener. Sie ist noch nicht sehr verbreitet, dennoch sollte sie erwähnt werden. Der Unterschied zu den bisher vorgestellten Möglichkeiten liegt darin, einem Verwalter die Ereignisquelle und das Ereignisziel vorzugeben. Das Ziel ist dabei eine beliebige Methode. Beim Auftreten eines Ereignisses findet das System automatisch mittels Reflection die von uns angegebene Methode und ruft sie auf. Bisher sind Generic Listener eine einfache Erweiterung der Proxy-Klassen und sind noch nicht in die Java-Standardbibliothek eingeflossen. Die Implementierung fasst jedoch mit Kommentaren nur zweihundert Zeilen. Wir werden auf Generic Listener zurückkommen, wenn wir Ereignisse von Schaltflächen kennen gelernt haben. Informationen zu den Generic Listenern gibt es auf der Webseite von Sun unter:

>http://java.sun.com/products/jfc/tsc/articles/generic-listener2/index.html

>http://java.sun.com/products/jfc/tsc/articles/generic-listener/index.html

Von dort kann auch die allgemeine Implementierung für eine Klasse GenericListener bezogen werden.