Programmierung Java AWT und Swing

Transkript

1 Abstract Window Toolkit Einführung Mit Hilfe der Java-Klassenbibliothek können graphische Benutzerschnittstellen einfach realisiert werden, da eine umfangreiche Bibliothek an GUI-Klassen zur Verfügung steht, die für den Aufbau hierarchischer GUIs nach dem Composite- Pattern vorbereitet ist, und die Ereignisbehandlung (seit Java 1.1) übersichtlich und schulbuchmässig (MVC-Architektur) gelöst ist. Einige Ansätze des Window-Toolkits wurden aus der Klassenbibliothek von Smalltalk-80 übernommen, so zum Beispiel die Idee des MVC-Architekturpatterns, welches weiter unten noch beschrieben wird. Das folgende Codebeispiel erzeugt ein Fenster mit einem Label und einer einfachen Ereignisbehandlung. import java.awt.*; import Java.awt.event.*; public class HelloWorld extends Frame implements WindowListener { // Konstruktor public HelloWorld(){ { super("hello World"); setlayout(new BorderLayout()); add(new Label ("Hello World!!"), BorderLayout.CENTER); addwindowlistener(this); pack(); setvisible(true); // main - Methode public static void main(string argument[]){ Frame f = new HelloWorld(); // Applikation beenden public void windowclosing(windowevent wevent){ System.exit(0); // Ein WindowListener muss auch folgende Methoden implementiern public void windowactivated(windowevent wevent) { public void windowclosed(windowevent wevent) { public void windowdeactivated(windowevent wevent) { public void windowdeiconifled(windowevent wevent) { public void windowlconified(windowevent wevent) { public void windowopened(windowevent wevent) { Im Beispiel werden die zwei Packages java.awt und java.awt.event importiert. Die Klassen aus java.awt werden dazu verwendet, um Fenster und deren Inhalte darzustellen, während die Klassen aus java.awt.event dazu dienen, auf zuletzt überarbeitet: Pascal Joos : 1/21 HFU

2 1-2 Benutzeraktionen, die Events auslösen, zu reagieren Übersicht Bis Java 1.1 war der Abstract Window Toolkit (AWT) die alleinige Klassenbibliothek, um GUIs zu bauen. Der AWT beruht auf dem Konzept von Peer-Klassen: Sichtbare GUI- Klassen besitzen eine Peer-Klasse, welche auf jeder Plattform die entsprechende plattformspezifische GUI-Komponente (widget) kapselt. Mit diesem Konzept der Peer-Klassen ist man letztlich auf die auf jeder Plattform zur Verfügung stehenden GUI-Komponenten beschrankt. Zudem lassen sich ihre plattformspezifischen Eigenheiten durch die Wrapper nicht völlig gleichschalten. Die GUI- Komponenten mit Peer-Klassen zeigen immer das Look and Feel der entsprechenden Plattform. Aus diesen Gründen ist ein neues Window-Toolkit, die Swing-Klassen, entstanden, welches bis auf Main-Windows ohne die plattformspezifischen GUI-Komponenten arbeitet, d.h. vollständig in Java implementiert ist (sogenannte lightweight-komponenten). Dadurch wird ein viel reichhaltigeres Angebot von GUI-Elementen ermöglicht, und deren Look and Feel lässt sich unabhängig von der verwendeten Plattform einstellen. Swing- Komponenten verwenden zudem eine innere MVC-Struktur, welche die Programmierung bei komplexeren Komponenten wesentlich vereinfachen kann. Ab JDK 1.2 ist Swing ein Standard-Package des Java. Bis auf diese Unterschiede basieren aus Sicht des Anwendungs- Programmierers auf den gleichen Konzepten. Viele Swing-Klassen sind praktisch ein 1:1- Ersatz fur entsprechende AWT-Klassen. Das Event-Handling (nach JDK 1.1) wurde in Swing übernommen, in beiden Packages werden flexible Layouts durch Layoutmanager unterstützt. In diesem Kapitel wird die GUI-Programmierung anhand des AWT eingeführt, später werden die zusätzlichen Elemente und Möglichkeiten von Swing besprochen Klassenbibliotheken von AWT Ab Version 1.1 des JDK gibt es folgende Standard-Packages, die Klassen enthalten, welche zur Darstellung von GUIs verwendet werden: java.applet - fur Applets java.awt - die GUI-Elemente des AWT java.awt.image - fur Bildverarbeitung java.awt.event - fur die Ereignisbehandlung java.awt.datatransfer - fur Dateniibertragung zwischen Java-Applikationen via Clipboard). Von diesen Packages sind java.awt und java.awt.event die beiden wichtigsten. Das Package java.awt.applet besteht nur aus einer einzigen Klasse und drei Interfaces, welche für die Applet Konstruktion wichtig sind. zuletzt überarbeitet: Pascal Joos : 2/21 HFU

3 Die Model-View-Controller-Architektur in Java Die MVC Architektur stützt stark auf dem Observer Pattern der Software Pattern ab Observer Pattern Ein KonkretesSubject EinKonkreterObserver EinAndererKonkreterObserver notify() update() update() Subject attach (Observer) detach (Observer) notify() Observer update( ) KonkreterObserver KonkretesSubject update( ) Das ObserverPattern bietet die Möglichkeit in eine Klasse beobachten zu lassen. Dabei sind die Observer die Elemente die beobachten und die Subjects sind die Elemente die beobachtete werden. Dies ist sehr ideal für GUI Komponenten. Wenn man es folgendermassen definiert: Die GUI Komponenten sind Anzeigen, welche darstellen was in einer anderen Klasse enthalten ist. Die GUI Komponenten beobachten also ihre Modelle Wenn man dies nun auf das MVC Prinzip übertragen würde, wäre das Model gleich dem Subject. Die GUI Komponenten wären dabei die Observers. zuletzt überarbeitet: Pascal Joos : 3/21 HFU

4 Struktur Die Model-View-Controller-Architektur, ursprünglich in Smalltalk80 eingeführt, ist inzwischen eine verbreitetet Architektur für User-Interfaces. In der obigen Darstellung sieht man, wie die einzelnen Komponenten zusammenarbeiten. Das Model ist dabei das Subject des OberverPatterns. In Java werden sie auch als Observables bezeichnet. Diese bezeichnung kommt daher, da sie in Java vom Interface Observable abgeleitet werden müssen. Die View und der Controller übernehmen dabei die Rolle der Observers. Der View ist dabei für die Ausgabe und der Controller für die Eingabe zuständig. Würde man die obige Darstellung auf UML übertragen, ergibt sich folgendes Diagramm. zuletzt überarbeitet: Pascal Joos : 4/21 HFU

5 1-5 Der folgende Teil des wurde aus einem Buch koriert und absichtlich nicht übersetzt, um die Bedeutung der Worte nicht zu verfälschen Initialisierung der MVC-Architektur Scenarion II shows how the MVC triad is initialized. This code is usually located outside of the model, views and controllers, for example in a main program. The view and controller initialization occurs similarly for each view opened for the model. The following steps occur: The model instance is created, which then initializes its internal data structures. A view object is created. This takes a reference to the model as a parameter for its initialization. The view subscribes to the change-propagation mechanism of the model by calling the attach procedure. The view continues initialization by creating its controller. It passes references both to the model and to itself to the controller's initialization procedure. The controller also subscribes to the change-propagation mechanism by calling the attach procedure. After initialization, the application begins to process events. zuletzt überarbeitet: Pascal Joos : 5/21 HFU

6 1-6 Natiirlich registieren sich nur Controller als Observer beim Modell, deren Verhalten vom Zustand des Modelles abhängig sind (z.b. Deaktivierung von Menueinträgen). Die Umsetzung in Java folgt dieser Beschreibung praktisch 1:1. In Java ist es nicht nötig, dass die View ihr Modell erinnert. Bei einem update() wird eine Referenz des Modells als Parameter mitgegeben. Scenario I shows how user input that results in changes to the model triggers the change-propagation mechanism: The controller accepts user input in its event-handling procedure, interprets the event, and activates a service procedure of the model. The model performs the requested service. This results in a change to its internal data. The model notifies all views and controllers registered with the changepropagation mechanism of the change by calling their update procedures. Each view requests the changed data from the model and redisplays itself on the screen. Each registered controller retrieves data from the model to enable or disable certain user functions. For example, enabling the menu entry for saving data can be a consequence of modifications to the data of the model. The original controller regains control and returns from its event-handling procedure. zuletzt überarbeitet: Pascal Joos : 6/21 HFU

7 1-7 Die Umsetzung in Java ist auch hier wieder geradlinig. Das Observer-Pattern bildet die Grundlage für die Verbindung zwischen dem Model und der View. Es wird im Package java.util durch die Klasse Observable und dem Interface Observer bereitgestellt. Im AWT tragt die Controllerklasse den Namen EventListener und ist in Wirklichkeit ein Interface. Die Sortierung und Filterung der Events wird bereits durch die AWT- Klassen vorgenommen. Der Programmierer kann also davon ausgehen, dass sein Controller nur diejenigen Events bekommt, die er auch behandeln möchte Logische Bedeutung der MVC Komponenten Das MVC Prinzip ist die Grundlagen für alle heutigen UIs. Das ganze Interaktions Prozedere wird in die drei Elemente aufgeteilt. Wie wir oben schon gehört haben sind das Modell, View und Controller. Die Bedeutung der einzelnen Elementewerden wie folget beschrieben. Modell Das sind die zu bearbeitenden Daten View Ist die Darstellung dieser Daten Controller Ist für die Aktionen und Eingaben des Users zuständig zuletzt überarbeitet: Pascal Joos : 7/21 HFU

8 Beispiel Count Bin Beispiel für die Anwendung der MVC-Architektur ist der folgende Zähler. Er besteht aus einem Modell Count, einer View View, welche den Zählerstand als Beschriftung auf einem Button darstellt und einem Controller inclistener, welcher beim Drücken des Buttons den Zählerstand erhöht. // CountMain.java ******************************************* public class CountMain { public static void main(string[] args){ Count c = new Count(); View v = new View(c); // Count.java *********************************************** import java.util.observable; public class Count extends Observable { private int value; public void increment(){ value = value+1; setchanged(); notifyobservers(); public int getvalue() { return value; // View.java *********************************************** import java.util.observer; import java.util.observable; import java.awt.*; import java.awt.event.* ; public class View extends Frame implements Observer { Button btn; public View(Count model) { btn = new Button(""+model.getValue()); btn.addactionlistener(new IncListener(model)); add(btn); pack(); setvisible(true); model.addobserver(this); public void update(observable model, Object arg){ btn.setlabel(""+((count)model).getvalue()); // IncListener nava ******************************************* import java.awt.event.actionlistener; import java.awt.event.actionevent; public class IncListener implements ActionListener { Count model; public IncListener(Count m) {model=m; public void actionperformed(actionevent e){ model.increment(); zuletzt überarbeitet: Pascal Joos : 8/21 HFU

9 1-9 Wie man dem Sourcecode entnehmen kann, ist die Klasse Count von der Klasse java.util.observable abgeleitet. Dadurch erbt sie automatisch alle Methoden und Variablen, welche zur Benutzung des Observer-Mechanismus benötigt werden. Beim Inkrementieren der Variable value, werden die Methoden setchanged() und notifyobserver() aufgerufen. Das bewirkt, dass bei allen angemeldeten Views die Methode update() aufgerufen wird. Diese Methode ist im Interface java.util.observer definiert. In update() wird das Modell als Parameter übergeben. Die update()-methode aktualisiert die View mit den aktuellen Daten des Modells. Um auf Benutzeraktionen wie etwa das Anklicken des Buttons zu reagieren, müssen die entsprechenden GUI-Komponenten mit Controllern versehen werden. Dies geschieht bei der Initialisierung der View. Durch Aufruf der Methode addactionlistener() für den Button wird ein Controller an den Button gehängt, und zwar handelt es sich um einen Controller für Events vom Typ ActionEvent. Der Controller besitzt eine ständige Referenz auf das Modell. Damit ist es ihm möglich, direkten Einfluss auf die Daten zu nehmen, natürlich über die entsprechende Methode increment() der Klasse Count. Damit hat sich der Kreis geschlossen: Der Controller verändert die Daten im Model und das löst ein update () bei allen Views aus, womit gewährleistet ist, dass die Anzeigen in allen Views auf dem neuesten Stand sind. Zu den Events, die für das Applikationsfenster (Klasse Frame) bestimmt sind, zählt auch das Schliessen des Fensters. Wenn, wie in diesem einfachen Beispiel, kein windowlistener bei dem Fenster angemeldet ist, kann das Fenster nicht mehr direkt durch den Benutzer geschlossen werden! Event Handling Das Event Handling wurde von Version des JDK zu Version 1.1 völlig überarbeitet. Der markanteste Unterschied besteht darin, dass die AWT Klassen eine Filterung der eingehenden Ereignisse vornehmen. Das heisst, der Anwender kann die Events, welche er bearbeiten möchte, abonnieren und in einem separaten EventListener- Objekt bearbeiten (Event Delegation Model).Um das zu realisieren, muss er das entsprechende Interface in einer Klasse implementieren. In der folgenden Tabelle sind alle Eventtypen mit dem zugehorigen Interface aufgelistet: Eventtyp ActionEvent AdjustmentEvent*) ComponentEvent*) ContainerEvent*) FocusEvent**) ItemEvent KeyEvent Eventtyp MouseEvent**) TextEvent WindowEvent Interface ActionListener AdjustmentListener ComponentListener ContainerListener FocusListener ItemListener KeyListener Interface MouseListener MouseMotionListener TextListener WindowListener zuletzt überarbeitet: Pascal Joos : 9/21 HFU

10 1-10 Die mit *) markierten Events sind sogennante Low-Level-Events, sie werden in der Regel nicht im Applikationscode bearbeitet, sondern direkt innerhalb des AWT (Grössenänderungen von Komponenten usw.). Mit **) martierte Events nehmen eine Zwischenrolle ein. Manchmal möchte man in einer Applikation auf sie reagieren. Die nicht speziell gekennzeichneten Events sind sogenannte High-Level-Events, auf welche eine Applikation in der Regel reagieren, d.h. entsprechende Listener bereitstellen muss. Wenn ein Objekt vom Typ Button auf einen Mausklick reagieren soll, so reicht es, eine Klasse zu schreiben, welche das entsprechende Interface implementiert und in der Methode action-performed (ActionEvent) die gewünschten Aktionen auszuführen. Das folgende Codebeispiel zeigt einen Controller, der umgehend die Anwendung beendet: Import java.awt.event.actionlistener; public class ExitController implements ActionListener{ public void actionperformed(actionevent aevent){ System.exit( 0 ) ; Wird dieser EventListener nun mit der Methode addactionlistener() bei einem Element eingetragen, das ActionEvents produziert, so wird mit der Aktivierung des Elementes die Anwendung beendet. Manche Interfaces sind umfangreicher als nur gerade eine Methode. Zum Beispiel umfasst das Interface WindowListener sieben verschiedene Methoden, die alle implementiert werden müssen. Wird aber nur eine von all diesen Methoden effektiv gebraucht, so sieht es ungefähr so aus wie das Beispiel "HelloWorld". Bei dieser Klasse fungiert die Klasse sowohl als View wie auch als Controller. Damit reduziert sich das MVC-Pattern auf das Dokument-View Prinzip, bei dem View und Controller nicht getrennt werden. In der AWT existieren nun einige Klassen, die uns die Arbeit abnehmen, für jede nicht gebrauchte Methode eine Dummy-Methode einzufügen. Es handelt sich dabei um sogenannte Adapter-Klassen. Folgende Adapter-Klassen existieren: ComponentAdapter ContainerAdapter FocusAdapter MouseAdapter MouseMotionAdapter WindowAdapter KeyAdapter Wie man sieht, würde auch für das Interface windowlistener ein entsprechender Adapter existieren, doch da Java keine Mehrfachvererbung kennt, kann man im genannten Beispiel keinen Nutzen daraus ziehen. Was der Zweck der einzelnen Eventtypen ist und wo sie vorkommen, kann am besten in der Online-Hilfe des JDK nachgelesen werden. In diesem Dokument sind die möglichen Events zu finden, die ein bestimmtes AWT-Element produzieren kann. zuletzt überarbeitet: Pascal Joos : 10/21 HFU

11 Der Aufbau von hierarchisch strukturierten GUIs Composite Der Aufbau hierarchisch strukturierter GUIs folgt dem Composite-Pattern: Composite: Zusammenfügen von Objekten zu einer Baumstruktur mit dem Ziel, alle in der Struktur enthaltenen Objekte (Components und Container) gleich behandeln zu können. Beide Klassen sind abstrakt. Das heisst, dass ein Container oder eine Component niemals in dieser Form vorkommen können. Alle Dialogelemente des AWT sind von der Klasse Component abgeleitet und alle Elemente, auf denen Dialogelemente plaziert werden können, sind Unterklassen von Container. In unserem vorangegangenen Beispiel ist die Klasse java.awt.frame von Container abgeleitet und das Element java.awt.label von Component. Hier ein Beispiel für ein Composite. Dank dieser Struktur ist es dem Runtime-System möglich, mit dem Aufruf der Methode paint() das gesamte Fenster neu zu zeichnen. Ein Objekt vom Typ Component zeichnet tatsächlich etwas auf den Bildschirm und ein Objekt vom Typ Container wird von allen registrierten Components die Methode paint() aufrufen. zuletzt überarbeitet: Pascal Joos : 11/21 HFU

12 Container Ein Objekt der Klasse Container kann weitere Komponenten aufnehmen. Damit ist es möglich, hierarchische Strukturen aufzubauen. Zudem ist es möglich, komplexere Layouts mit den vorhandenen Layout-Managern zu realisieren. Jedem Container kann ein Layout-Manager zugewiesen werden, der die Anordnung der enthaltenen Komponenten auf dem Bildschirm festlegt. Auf die Möglichkeiten wird im nächsten Abschnitt noch genauer eingegangen. Die folgende Abbildung zeigt die Klassenhierarchie der Elemente, welche von Container abgeleitet sind. Alle Klassen sind im Package java.awt enthalten. Im Rahmen dieses s soil nur auf die wichtigsten drei Klassen eingegangen werden. Es sind dies: Panel, Applet und Frame Panel Das Panel stellt einen unsichtbaren Container für Elemente dar. Der Hauptzweck dieser Klasse ist die Gruppierung von Elementen oder die Zusammenfassung einiger Elemente, um diese in einer bestimmten Anordnung auf dem Bildschirm darstellen zu können. zuletzt überarbeitet: Pascal Joos : 12/21 HFU

13 1-13 Das folgende Beispiel benutzt ein Panel, um zwei Knöpfe nebeneinander darzustellen: public AppMain(){ super("composite"); setlayout(new GridLayout(3, 1)); add(new Label("Label", Label.CENTER)); add(new TextField("TextField", 30)); Panel p = new Panel(); p.setlayout(new GridLayout(1, 2)); p.add(new Button("Button")); p.add(new Button("Button")); add(p); addwindowlistener(this); pack(); setvisible(true); Wie aus dem Sourcecode hervorgeht, werden die beiden Button unten im Fenster zuerst in einem Panel plaziert und dieses dann in das Fenster eingefügt. Damit ist es möglich, ein aufwendigeres Layout zu realisieren, als dies mit einem einzigen Standard-Layout-Manager möglich wäre Applet Die bekannteste und am weitesten verbreitete Form eines Containers ist die Klasse Applet aus dem Package java.applet. Im Bezug auf ihre Anwendung als Container für AWT-Komponenten unterscheidet sie sich nicht von einem Panel. Aus dem Klassendiagramm geht hervor, dass sie von dieser Klasse abgeleitet ist. Durch diese Erweiterungen gegenüber der Klasse Panel können Applets nur einmal pro Anwendung instanziert werden, respektive werden vom Browser instanziert. Sollen weitere Unterteilungen innerhalb eines Applets gemacht werden, so werden dazu Panels verwendet. Der Benutzer hat keine Möglichkeit, die Lebensdauer eines Applets direkt zu beeinflussen, ausser natürlich der Browser wird geschlossen oder auf eine andere gewechselt. Solange die angezeigt wird, die das Applet enthalt, existiert ein Objekt der Klasse Applet Frame Was die Klasse Applet für ein Internet-Applet ist, ist die Klasse Frame für eine Applikation. Im Gegensatz zur Klasse Applet ist Frame von der Klasse window abgeleitet, die ihrerseits von Container abgeleitet ist. Damit erbt Frame alle Eigenschaften von Container und window.. Die Klasse Window erweitert Container, so dass der Container in einem eigenen Fenster dargestellt wird. Damit wird ein Rahmen um den Container gezeichnet und das Systemmenü entsprechend dem verwendeten Windowsystem hinzugefügt. Zusätzlich zu den genannten Eigenschaften können in einem Frame noch weitere Eigenschaften verändert werden. zuletzt überarbeitet: Pascal Joos : 13/21 HFU

14 1-14 Das folgende Beispiel erzeugt ein Fenster, dessen Grösse fest ist, einen bestimmten Titel aufweist und einen einfachen EventListener besitzt, um das Fenster zu schliessen. import java.awt.*; public class CounterWindow extends Frame implements Observer { // Konstruktoren public CounterWindow(Counter model){ settitle("counter"); setlayout(new BorderLayout()); setresizable(false); addwindowlistener(new CounterWindowListener()); pack(); setvisible(true); Im Fenster sind die mittleren drei Knopfe auf einem Panel angeordnet, welches in das Gesamtlayout eingefügt wird. Die Methode pack() stammt aus der Klasse window, setvisible(true) aus Component. pack () bewirkt, dass das Fenster auf seine optimale Grösse gebracht wird. Wobei die optimale Grösse durch die darin enthaltenen Komponenten bestimmt wird. Jede Komponente wird dabei gefragt, was seine minimale Grösse ist getminimumsize(), um noch richtig dargestellt zu werden. Nachdem das Frame erzeugt und die Grösse angepasst wurde, ist es noch nicht zu sehen. Das besorgt die Methode setvisible(true) aus der Klasse Component. Nach deren Aufruf wird das Fenster auf dem Bildschirm dargestellt und eingehende Events werden an den entsprechenden Eventhandler (XXXListener) weitergeleitet Wichtig ist, dass immer ein Eventhandler für ein Objekt der Klasse window definiert wird, sonst kann das Fenster nicht mehr geschlossen werden, da diese Aktion einen windowevent auslöst, auf den reagiert werden muss. Existiert kein windowlistener, so muss die Java Virtual Machine gestoppt werden. Je nach Betriebssystem ist das einfacher oder riskanter Layout-Manager Layout-Manager dienen dazu, GUI-Komponenten in einem Container automatisch, entsprechend dem zur Verfügung stehendem Platz, sinnvoll anzuordnen. LayoutManager ist ein Interface aus dem Package java.awt. Im AWT existieren einige konkrete Implementationen dieses oder des von ihm abgeleiteten Interfaces LayoutManager2. Der Unterschied zwischen diesen beiden Interfaces besteht darin, dass das Interface LayoutManager2 schon einige Methoden definiert, welche die Ausrichtung der Komponenten entlang der X bzw. Y Achse vorsieht. Die Interface- und Klassenhierarchie ist in der folgenden Abbildung dargestellt. In der Darstellung sind Interfaces mit dem Stereotyp «Interface» gekennzeichnet. Die Interfaces werden durch verschiedene LayoutManager implementiert, die nachfolgend kurz erläutert werden: zuletzt überarbeitet: Pascal Joos : 14/21 HFU

15 FlowLayout Der FlowLayout-Manager ordnet die Komponenten wie die Worter eines Fliesstextes nebeneinander an und bricht Komponenten, die auf einer Zeile nicht mehr Platz finden, auf die nächste Zeile um. Hier ein Beispiel, welches das Verhalten des FlowLayout-Managers zeigt. Dank dieser Eigenschaft eignet sich dieser Layout-Manager besonders gut, um in Applets eingesetzt zu werden GridLayout Nicht immer ist ein automatischer Zeilenumbruch erwünscht. Daher existieren weitere Layout-Manager, die eine genauere Positionierung der Elemente erlauben. Ein einfacher Layout-Manger ist der GridLayout-Manager. Er teilt den zur Verfügung stehende Platz in eine beliebige Anzahl gleich grosser Zellen ein. Wie die Einteilung gemacht wird, kann im Konstruktor angegeben werden. Eine nachträgliche Änderung der Zellenzahl ist nicht möglich. public GridLayout(int yzellen, int xzellen); Die erste Zahl gibt an, in wieviele Zeilen das Fenster geteilt wird und der zweite Parameter legt die Anzahl Spalten fest. In der folgenden Abbildung ist zu sehen, dass sich durch eine Veränderung der Fenstergrösse nur die Elementgrösse ändert, nicht aber deren Anordnung oder gar deren Reihenfolge. zuletzt überarbeitet: Pascal Joos : 15/21 HFU

16 Border-Layout Oft benötigt man eine Einteilung in unterschiedlich grosse Bereiche. Bei einem Texteditor zum Beispiel ist in der Mitte das Eingabefeld, welches die grosse Fläche im Fenster beansprucht und die Bedienungselemente wie Statuszeile, Scrollbars und Toolbar sind rund um diesen Bereich angeordnet. Dieser Fall der Fensteraufteilung wird häufig gebraucht, daher existiert dazu der BorderLayout-Manager. Das Fenster wir in fünf Bereiche aufgeteilt, welche mit den Himmelsrichtungen angesprochen werden. Die Mitte trägt die Bezeichnung CENTER. In der folgenden Abbildung ist das Resultat der Verwendung dieses Layout-Managers zu sehen. Wie beim GridLayout- Manager ändern auch hier die Elemente ihre Grösse, wenn die Grösse des Fensters verändert wird. public class AppMain extends Frame implements WindowListener { // Konstruktor public AppMain() { super("borderlayout"); setlayout(new BorderLayout() ) ; add(new Button("NORTH"), BorderLayout.NORTH); addfnew Button("WEST"), BorderLayout.WEST); add(new Button("CENTER"), BorderLayout.CENTER); add(new Button("EAST"), BorderLayout.EAST); add(new Button("SOUTH"), BorderLayout.SOUTH); addwindowlistener(this) ; pack(); setvisible(true); Wie man sieht, ist es bei diesem Layout-Manager irrelevant, in welcher Reihenfolge die Komponenten eingefügt werden. Bei allen vorangegangenen entscheidet die Reihenfolge der Components die Position im Fenster. Ist eine Fläche nicht durch eine Komponente belegt, so bekommt diese auch keinen eigenen Bereich im Fenster. Der Border-Layout eignet sich besonders gut zur Implementierung von Anwendungen, die einen grossen Bereich an Daten haben, mit denen der Benutzer arbeiten muss. zuletzt überarbeitet: Pascal Joos : 16/21 HFU

17 Card Layout Das CardLayout verwaltet mehrere Panels, die alle iibereinander liegen. Welches Panel zuvor-derst und somit auch sichtbar ist, kann durch einen Methodenaufruf verandert werden: public void show(container, String); Das folgende Beispiel ist ein einfaches Chat Programm, bei dem der Login-Screen anders aussieht als das eigentliche Chat-Panel. In Die folgenden Darstellungen zeigen den Loginscreen und das eigentliche Chat-Panel. Zu beachten ist, dass der CardLayout-Manager das Fenster immer so gross macht, dass das Panel mit der grössten benötigten Flache hineinpasst. Die Methode CardLayout.next() schaltet zwischen dem ersten Panel, dem Loginscreen, und dem zweiten, dem Chat Panel, hin und her GridBagLayout Der GridBagLayout-Manager ist mit dem GridLayout-Manager verwandt. Auch hier wird die verfügbare Fläche in gleich grosse Bereiche unterteilt. Beim GridBagLayout kann sich eine Komponente über mehrere solcher Teilflächen erstrecken, so können kompliziertere Layouts realisiert werden. In der Anwendung ist der GridBagLayout etwas komplizierter, er benötigt die Hilfsklasse GridBagConstraints. An dieser Stelle wird nicht weiter auf diesen Layout-Manager eingegangen Kombinierte Layouts Um ein umfangreicheres Layout zu realisieren, werden mehrere Container mit passenden Layout-Managern geschickt verschachtelt. zuletzt überarbeitet: Pascal Joos : 17/21 HFU

18 Swing Einführung Warum Swing wen es doch AWT gibt? Der Abstract Window Toolkit AWT ist in seinen Möglichkeiten begrenzt und genügt nicht, ein modernes, komplexes GUI zu implementieren. Der AWT stellt eigentlich nur eine Schnittstelle zwischen Java und dem Windowsystem zur Verfügung, auf dem die Java-Virtual-Machine läuft. Das Konzept der Peer-Klassen, d.h. jede GUI- Komponente auf die entsprechende GUI-Komponente der jeweiligen Plattform abzubilden, beschränkt die zur Verfügung stehenden Komponenten auf die Schnittmenge aller" GUI-Komponenten der plattformspezifischen Window-Systeme. Zudem zeigte es sich, dass völlig Plattform-unabhängiges Verhalten durch eine noch so gute Kapselung der plattformspezifischen GUI-Komponenten nicht völlig zu erreichen ist. Aus diesem Grund kündigte JavaSoft im April 1997 die Java Foundation Classes JFC an, deren Hauptbestandteil Swing" eine umfassende und konzeptionell gut durchdachte Klassenbibliothek ist. Swing basiert und umfasst zwar den AWT, aber es verwendet nur für Top-Level-Windows dessen Peers. Die anderen GUI- Komponenten sind vollständig in Java implementiert, sogenannte Lightweight- Komponenten. Swing übernimmt aus dem AWT das JDK l. l Eventhandling und verfügt über eine Vielzahl neuer GUI-Komponenten. Beim JDK 1.1 musste Swing als separate Bibliothek verwendet werden. Der JDK 1.2 integriert die Java Foundation Classes und damit Swing Java Foundation Classes und Swing Neben den GUI-Bibliotheken umfassen die Java Foundation Classes noch drei weitere APIs,auf diese wird hier nicht näher eingegangen: Java 2D: Verbessert und erweitert die Möglichkeiten der Graphikprogrammierung des AWT. Drag and Drop: Erlaubt Drag and Drop mit anderen (Native-)Applikationen auf der jeweiligen Plattform. Accessibility: Erlaubt GUIs mit zusätzlichen Interaktionsmöglichkeiten zu versehen, wie z.b. Spracheingabe oder Bildschirmlupen", die physisch behinderte Personen in der Benutzung der Userinterfaces unterstützen. zuletzt überarbeitet: Pascal Joos : 18/21 HFU

19 Konvertierung von AWT zu Swing Die 1:1-Konversion einer Applikation von AWT auf Swing ist einfach zu bewerkstelligen: 1. Für alle AWT-Komponenten den entsprechenden Swing-Ersatz verwenden. Meist gibt es eine entsprechende Swing-Komponente mit vorangestelltem J: Button JButton. 2. Einige Swing-Container wie JFrame nehmen ihre Komponenten nicht direkt auf, sondern besitzen dafür eine ContentPane. Also werden hier die Komponenten der ContentPane hinzugefügt: add() getcontentpane().add(). Im folgenden Beispiel sehen wir, durch Fettdruck hervorgehoben, den 1:1-Upgrade unseres minimalen MVC-Counters auf Swing. Es muss nur die View-Klasse geändert werden MVC bei Swing Die grundlegenste Eigenschaft von Swing ist die konsequente Verwendung einer vereinfachten Model-View-Controller-Architektur. Die meisten sichtbaren GUI-Komponenten von Swing, selbst ein Button, besitzen ein Modell, welches die dargestellten Daten und den Zustand der sichtbaren View beinhaltet. Da ein Controller sehr eng mit einer View zuletzt überarbeitet: Pascal Joos : 19/21 HFU

20 1-20 zusammenarbeitet, wird er in Swing mit der View zu einem sogenannten UI-Delegate zusammengefasst. Die MVC-Architektur ist also in Swing zu einer M-UI-Architektur vereinfacht. Eine sichtbare Swing-Komponente besteht aus dem eigentlichen Repräsentanten der Komponente, einem UI-Delegate und in der Regel aus einem Modell. Ursprünglich wird die MVC-Architektur auf ganze Applikationen angewendet: Das Modell besteht dann im wesentlichen aus dem Domainmodell der Applikation. In Swing besitzt aber jede einzelne, sichtbare GUI-Komponente ein Modell. Swing-Komponenten kann man im Prinzip wie AWT-Komponenten verwenden, ohne ihre innere MVC-Architektur zu berücksichtigen. Da wo Swing-Komponenten aber Domaindaten darstellen, gelangt man durch Einbezug des Swing-Modells in das Domainmodell zu einer sehr einfachen und eleganten Lösung Lightweight-versus Heavyweight-Komponenten Als Heavyweight-Komponenten werden sichtbare GUI-Komponenten bezeichnet, die einen Peer besitzen. Der Peer bindet die Java-GUI-Komponente an eine Native-GUI- Komponente des jeweiligen Windowsystems an. Heavyweight-Komponenten bzw. deren Peer werden so direkt vom Windowsystem verwaltet. Sie entziehen sich dadurch einer vollständigen Kontrolle durch Java. Alle sichtbaren AWT-GUI- Komponenten sind heavyweight. Swing besteht aus Lightweight-Komponenten. Diese sind vollständig in Java geschrieben und besitzen keinen Peer. Lightweight-Komponenten werden von ihrem Container kontrolliert. Ein GUI kann nicht vollständig aus Lightweight-Komponenten bestehen. Alle Top- Level-Windows müssen vom Windowsystem direkt verwaltet werden, das ja die Top- Level-Windows verschiedener Applikationen (Java- und Native-Applikationen) koordinieren muss. Nur innerhalb eines Top-Level-Windows kann eine Applikation tun, was ihr beliebt, d.h. im Falle von Swing, ihre eigenen Lightweight-Komponenten darstellen und manipulieren. Sobald eine GUI-Komponente über den Rand ihres Top-Level-Windows herausragt, muss es sich um eine Heavyweight-Komponente handeln. Beim Mischen von Heavyweight- und Lightweight-Komponenten innerhalb von Top- Level-Windows ist Vorsicht geboten, es können sogenannte Clipping-Fehler (falsches Überlagern) auftreten Pluggable-Look-and-Feel PLAF Der AWT verwendet mit seinen Peers das Look-and-Feel (L&F) der jeweiligen Plattform, also Motif auf Unix-Plattformen, Windows-L&F auf Windows95/98/NT und Mac-L&F auf Macintosh. In Swing macht es die Verwendung von Lightweight-Komponenten einfach, sich vom L&F der jeweiligen Plattform zu lösen. Swing erlaubt das L&F zur Laufzeit zu wechseln, sogenanntes Pluggable-Look-and-Feel (PLAF). Java besitzt sein eigenes L&F: Metal, das per Default verwendet wird. Daneben sind Windows-, Motif- und Mac-L&F (noch unvollendet) vorhanden. Anwender können auch ihr eigenes L&F implementieren. zuletzt überarbeitet: Pascal Joos : 20/21 HFU

21 1-21 Ermöglich wird PLAF durch die konsequente MVC-Architektur. Beim Wechseln des L&F wird jeweils das UI-Delegate jeder sichtbaren GUI-Komponente ausgetauscht Eigenschaften von Swing Neben MVC-Architektur, Lightweight-Komponenten und PLAF besitzt Swing eine Reihe weiterer Eigenschaften, die es vom AWT abhebt: Swing enthält eine Vielzahl neuer, mächtiger Komponenten wie Tabellen (JTable), Baumstrukturen (JTree), Schieberegler (JSlider), Progress-Bars (JProgressBar) und interne Frames (JInternalFrame). Swingkomponenten können mit ausgefeilten Rahmen umgeben werden, die auch Beschriftungen erlauben. Swingkomponenten können Tooltips aufweisen, die in einem Pop-Up-Menu automatisch erscheinen, wenn die Maus eine gewisse Zeit über der Komponente verweilt. Swingkomponenten implementieren das Accessible-Interface, so dass sie mit Bedinungshilfen versehen werden können wie z.b. Audio-Ausgabe, Spracheingabe. zuletzt überarbeitet: Pascal Joos : 21/21 HFU