36.1 Eigenschaften und Architektur von Swing

• 36.1 Eigenschaften und Architektur von Swing
  • 36.1.1 Einleitung
  • 36.1.2 Eigenschaften von Swing
    • Leichtgewichtige Komponenten
    • Pluggable Look-and-Feel
    • Das Model-View-Controller-Prinzip
  • 36.1.3 Wie geht es weiter?

36.1.1 Einleitung

Bereits kurze Zeit nachdem mit dem JDK 1.0 das Abstract Windowing Toolkit eingeführt wurde, begannen die Entwickler bei SUN, über Möglichkeiten nachzudenken, die grafische Oberfläche von Java-Anwendungen zu verbessern. Als nachteilig sahen sie vor allem folgende Eigenschaften des AWT an:

• Da alle Fenster- und Dialogelemente von dem darunterliegenden Betriebssystem zur Verfügung gestellt wurden, war es sehr schwierig, plattformübergreifend ein einheitliches Look-and-Feel zu realisieren. Die Eigenarten jedes einzelnen Fenstersystems waren für den Anwender unmittelbar zu spüren.
• Durch die Abhängigkeit von den betriebssystemspezifischen Komponenten erwuchsen den JDK-Entwicklern erhebliche Portierungsprobleme. Dadurch musste teilweise viel Aufwand getrieben werden, um das Verhalten der Komponenten auf den unterschiedlichen Plattformen in hinreichendem Maße anzugleichen.
• Zudem gibt es im AWT nur eine Grundmenge an Dialogelementen, mit denen sich aufwändige grafische Benutzeroberflächen nicht oder nur mit sehr viel Zusatzaufwand realisieren ließen.

Erklärtes Ziel der JDK-Entwickler war es, diese Nachteile zu beseitigen und mit der Entwicklung der Java Foundation Classes (deren wichtigster Bestandteil die als Swing bezeichnete Sammlung grafischer Dialogelemente werden sollte) eine echte Alternative zum AWT zu schaffen.

36.1.2 Eigenschaften von Swing

Leichtgewichtige Komponenten

Im Gegensatz zum AWT benutzen Swing-Komponenten nur noch in sehr eingeschränkter Weise plattformspezifische GUI-Ressourcen. Abgesehen von Top-Level-Fenstern, Dialogen und grafischen Primitivoperationen werden alle GUI-Elemente von Swing selbst erzeugt. Ein Swing-Button unter Windows wird nicht mehr vom Windows-UI-Manager dargestellt, sondern von Swing selbst gezeichnet.

Diese Vorgehensweise bietet einige Vorteile:

• Erstens fallen die plattformspezifischen Besonderheiten weg und der Code zur Implementierung der Dialogelemente vereinfacht sich deutlich.
• Zweitens entfallen auch die Unterschiede in der Bedienung. Der Anwender findet auf allen Betriebssystemen dasselbe Aussehen und dieselbe Bedienung vor.
• Drittens ist Swing nicht mehr darauf angewiesen, Features auf der Basis des kleinsten gemeinsamen Nenners aller unterstützten Plattformen zu realisieren. Komplexe Dialogelemente wie Bäume, Tabellen oder Registerkarten können plattformunabhängig realisiert werden und stehen nach der Implementierung ohne Portierungsaufwand auf allen Systemen zur Verfügung. Tatsächlich stellt Swing eine sehr viel umfassendere und anspruchsvollere Menge an Dialogelementen als das AWT zur Verfügung.

Der Grundstein für Komponenten, die von Java selbst erzeugt und dargestellt werden können, wurde im JDK 1.1 mit der Einführung der Lightweight Components (»leichtgewichtige« Komponenten) gelegt. Dabei wird die paint-Methode eines Component-Objekts nicht mehr an die betriebssystemspezifische Klasse weitergeleitet, sondern in den Komponentenklassen überlagert und mit Hilfe grafischer Primitivoperationen selbst implementiert. Die im AWT vorhandenen Dialogelemente werden im Gegensatz dazu als Heavyweight Components bezeichnet (»schwergewichtige« Komponenten).

Mit Hilfe der leichtgewichtigen Komponenten, die für alle Aspekte der Darstellung selbst verantwortlich sind, konnten einige interessante Features realisiert werden. So können beispielsweise zu allen Komponenten Tooltips erzeugt werden (also kleine Hilfetexte, die beim Verweilen mit der Maus über der Komponente angezeigt werden), ohne dass dazu Unterstützung seitens des zugrunde liegenden Grafikbetriebssystems erforderlich wäre.

Eine andere Eigenschaft, die nur mit Hilfe leichtgewichtiger Komponenten realisiert werden konnte, wird als Debug-Grafik bezeichnet. Dabei wird der Darstellungsvorgang beim Zeichnen der Komponente künstlich so verlangsamt, dass er wie in einer Zeitlupeneinstellung Schritt für Schritt verfolgt werden kann. Das ist insbesondere während der Entwicklung eigener Komponenten nützlich, um den Bildaufbau studieren und auf Fehler hin untersuchen zu können.

Pluggable Look-and-Feel

Die Swing-Entwickler gingen aber noch einen Schritt weiter. Eine der auf den ersten Blick bemerkenswertesten Eigenschaften von Swing ist die Möglichkeit, das Look-and-Feel (also das Aussehen und die Bedienung einer Anwendung) zur Laufzeit umzuschalten. Dieses als Pluggable Look-and-Feel bezeichnete Feature ermöglicht es beispielsweise einem Windows-Anwender, zwischen unterschiedlichen vordefinierten Look-and-Feels zu wählen (z.B. Metal, Motif und Windows). Benutzer anderer Betriebssysteme können andere Auswahlmöglichkeiten haben; zudem ist es möglich, eigene Look-and-Feels zu schreiben.

Seit Version 7 des JDK gibt es ein viertes Standard-Look-and-Feel, das Nimbus-Look-and-Feel.

JDK6.0-7.0

Dabei muss die Entscheidung für oder gegen ein bestimmtes Look-and-Feel keineswegs bereits zum Design- oder Entwicklungszeitpunkt getroffen werden. Vielmehr wurden alle Swing-Komponenten so entworfen, dass es möglich ist, das Look-and-Feel einer Anwendung zur Laufzeit umzuschalten. Das Programm besitzt dazu typischerweise einen speziellen Menüpunkt oder eine Konfigurationsmöglichkeit, die es dem Anwender ermöglicht, ein Look-and-Feel nach seinem Geschmack auszuwählen. Das Programm selbst muss praktisch keinen zusätzlichen Aufwand treiben, denn das Umschalten wird nach einem einzigen Methodenaufruf von einem User-Interface-Manager erledigt, der alle nötigen Maßnahmen koordiniert ausführt.

Das Model-View-Controller-Prinzip

Neben den äußerlichen Qualitäten wurde auch die Architektur des Gesamtsystems verbessert. Wichtigste »Errungenschaft« ist dabei das Model-View-Controller-Prinzip (kurz MVC genannt), dessen Struktur sich wie ein roter Faden durch den Aufbau der Dialogelemente zieht. Anstatt den gesamten Code in eine einzelne Klasse zu packen, werden beim MVC-Konzept drei unterschiedliche Bestandteile eines grafischen Elements sorgsam unterschieden:

• Das Modell enthält die Daten des Dialogelements und speichert seinen Zustand.
• Der View ist für die grafische Darstellung der Komponente verantwortlich.
• Der Controller wirkt als Verbindungsglied zwischen beiden. Er empfängt Tastatur- und Mausereignisse und stößt die erforderlichen Maßnahmen zur Änderung von Model und View an.

Das Modell enthält praktisch die gesamte Verarbeitungslogik der Komponente. Ein wichtiger Aspekt ist dabei, dass ein Modell mehrere Views gleichzeitig haben kann. Damit Veränderungen des Modells in allen Views sichtbar werden, wird ein Benachrichtigungsmechanismus implementiert, mit dem das Modell die zugeordneten Views über Änderungen informiert. Diese Vorgehensweise entspricht dem Observer-Pattern, wie es in Abschnitt 11.4.9 erläutert wurde.

Bei den Swing-Dialogelementen wird eine vereinfachte Variante von MVC verwendet, die auch als Model-Delegate-Prinzip bezeichnet wird. Hierbei wird die Funktionalität von View und Controller in einem UI Delegate zusammengefasst. Dadurch wird einerseits die Komplexität reduziert (oft ist der Controller so einfach strukturiert, dass es sich nicht lohnt, ihn separat zu betrachten) und andererseits die in der Praxis mitunter unhandliche Trennung zwischen View und Controller aufgehoben. Es kann allerdings sein, dass ein Dialogelement mehr als ein Model besitzt. So haben beispielsweise Listen und Tabellen neben ihrem eigentlichen Datenmodell ein weiteres, das nur für die Selektion von Datenelementen zuständig ist.

36.1.3 Wie geht es weiter?

Wir wollen uns in diesem und den nächsten Kapiteln mit den grundlegenden Eigenschaften von Swing beschäftigen. Der Schwerpunkt der Darstellung liegt dabei auf der Beschreibung der einzelnen Komponenten - mit dem Anspruch, zumindest ihre jeweils wichtigsten Merkmale zu behandeln. Die meisten Themen können dabei allerdings nur angerissen werden, denn eine einigermaßen vollständige Beschreibung von Swing benötigt ein eigenes Buch.

Meist werden wir daher lediglich die wichtigsten Methoden einer Klasse vorstellen. Speziellere Eigenschaften müssen wir außer Acht lassen. Auch auf die übrigen Komponenten der Java Foundation Classes, die 2D- und Accessibility-APIs, das Input Method Framework und das Drag-and-Drop API werden wir allenfalls in Ansätzen eingehen.

Es empfiehlt sich daher, nach den ersten Experimenten weitere Literatur zu Rate zu ziehen. Swing-Bücher sind mittlerweile in großer Zahl erhältlich. Auch das frei erhältliche Java-Tutorial von Oracle (siehe Abschnitt 4.2.2) enthält einen Abschnitt »Creating a GUI with JFC/Swing«, der das Erstellen von Swing-Applikationen ausführlich beschreibt. Am wichtigsten ist jedoch die API-Dokumentation. Sie ist das Hilfsmittel zum Erforschen der verborgenen Möglichkeiten einzelner Swing-Bestandteile.

Bevor wir in den nächsten Kapiteln in die Beschreibung der Komponenten einsteigen, wollen wir in den beiden letzten Abschnitten dieses Kapitels noch etwas für die Ungeduldigen tun. Zunächst zeigen wir ein einfaches Beispiel, an dem die Grundstruktur eines Swing-Programms erläutert wird. Darin demonstrieren wir auch, wie das Look-and-Feel des Programms zur Laufzeit umgeschaltet werden kann. Anschließend geben wir einige Tipps zur Umstellung von AWT-Anwendungen auf Swing und zeigen wichtige Gemeinsamkeiten und Unterschiede zwischen den beiden Grafikbibliotheken auf.