Rheinwerk Computing < openbook > Rheinwerk Computing - Professionelle Bücher. Auch für Einsteiger.
Professionelle Bücher. Auch für Einsteiger. 
Inhaltsverzeichnis
Vorwort
1 Java ist auch eine Sprache
2 Imperative Sprachkonzepte
3 Klassen und Objekte
4 Der Umgang mit Zeichenketten
5 Eigene Klassen schreiben
6 Objektorientierte Beziehungsfragen
7 Ausnahmen müssen sein
8 Äußere.innere Klassen
9 Besondere Typen der Java SE
10 Generics<T>
11 Lambda-Ausdrücke und funktionale Programmierung
12 Architektur, Design und angewandte Objektorientierung
13 Komponenten, JavaBeans und Module
14 Die Klassenbibliothek
15 Einführung in die nebenläufige Programmierung
16 Einführung in Datenstrukturen und Algorithmen
17 Einführung in grafische Oberflächen
18 Einführung in Dateien und Datenströme
19 Einführung ins Datenbankmanagement mit JDBC
20 Einführung in <XML>
21 Testen mit JUnit
22 Bits und Bytes und Mathematisches
23 Die Werkzeuge des JDK
A Java SE-Paketübersicht
Stichwortverzeichnis


Download:

- Beispielprogramme, ca. 35,4 MB


Buch bestellen
Ihre Meinung?



Spacer
<< zurück
Java ist auch eine Insel von Christian Ullenboom

Einführung, Ausbildung, Praxis
Buch: Java ist auch eine Insel


Java ist auch eine Insel

Pfeil 17 Einführung in grafische Oberflächen
Pfeil 17.1 GUI-Frameworks
Pfeil 17.1.1 Kommandozeile
Pfeil 17.1.2 Grafische Benutzeroberfläche
Pfeil 17.1.3 Abstract Window Toolkit (AWT)
Pfeil 17.1.4 Java Foundation Classes und Swing
Pfeil 17.1.5 JavaFX
Pfeil 17.1.6 SWT (Standard Widget Toolkit) *
Pfeil 17.2 Deklarative und programmierte Oberflächen
Pfeil 17.2.1 GUI-Beschreibungen in JavaFX
Pfeil 17.2.2 Deklarative GUI-Beschreibungen für Swing?
Pfeil 17.3 GUI-Builder
Pfeil 17.3.1 GUI-Builder für JavaFX
Pfeil 17.3.2 GUI-Builder für Swing
Pfeil 17.4 Aller Swing-Anfang – Fenster zur Welt
Pfeil 17.4.1 Eine Uhr, bei der die Zeit nie vergeht
Pfeil 17.4.2 Swing-Fenster mit javax.swing.JFrame darstellen
Pfeil 17.4.3 Mit add(…) auf den Container
Pfeil 17.4.4 Fenster schließbar machen – setDefaultCloseOperation(int)
Pfeil 17.4.5 Sichtbarkeit des Fensters
Pfeil 17.4.6 Größe und Position des Fensters verändern
Pfeil 17.5 Beschriftungen (JLabel)
Pfeil 17.5.1 Mehrzeiliger Text, HTML in der Darstellung
Pfeil 17.6 Es tut sich was – Ereignisse beim AWT
Pfeil 17.6.1 Die Ereignisquellen und Horcher (Listener) von Swing
Pfeil 17.6.2 Listener implementieren
Pfeil 17.6.3 Listener bei dem Ereignisauslöser anmelden/abmelden
Pfeil 17.6.4 Adapterklassen nutzen
Pfeil 17.6.5 Innere Mitgliedsklassen und innere anonyme Klassen
Pfeil 17.6.6 Aufrufen der Listener im AWT-Event-Thread
Pfeil 17.7 Schaltflächen
Pfeil 17.7.1 Normale Schaltflächen (JButton)
Pfeil 17.7.2 Der aufmerksame ActionListener
Pfeil 17.7.3 Schaltflächen-Ereignisse vom Typ ActionEvent
Pfeil 17.7.4 Basisklasse AbstractButton
Pfeil 17.7.5 Wechselknopf (JToggleButton)
Pfeil 17.8 Alles Auslegungssache – die Layoutmanager
Pfeil 17.8.1 Übersicht über Layoutmanager
Pfeil 17.8.2 Zuweisen eines Layoutmanagers
Pfeil 17.8.3 Im Fluss mit FlowLayout
Pfeil 17.8.4 BoxLayout
Pfeil 17.8.5 Mit BorderLayout in alle Himmelsrichtungen
Pfeil 17.8.6 Rasteranordnung mit GridLayout
Pfeil 17.8.7 Weitere Layoutmanager
Pfeil 17.9 Textkomponenten
Pfeil 17.9.1 Text in einer Eingabezeile
Pfeil 17.9.2 Die Oberklasse der Textkomponenten (JTextComponent)
Pfeil 17.9.3 Geschützte Eingaben (JPasswordField)
Pfeil 17.9.4 Validierende Eingabefelder (JFormattedTextField)
Pfeil 17.9.5 Einfache mehrzeilige Textfelder (JTextArea)
Pfeil 17.10 Grundlegendes zum Zeichnen
Pfeil 17.10.1 Die paint(Graphics)-Methode für den AWT-Frame
Pfeil 17.10.2 Die ereignisorientierte Programmierung ändert Fensterinhalte
Pfeil 17.10.3 Zeichnen von Inhalten auf einen JFrame
Pfeil 17.10.4 Auffordern zum Neuzeichnen mit repaint(…)
Pfeil 17.10.5 Java 2D-API
Pfeil 17.11 Zum Weiterlesen
 

Zum Seitenanfang

17Einführung in grafische Oberflächen Zur vorigen ÜberschriftZur nächsten Überschrift

»Wenn die Reklame keinen Erfolg hat, muss man die Ware ändern.«

– Edgar Faure (1908–1988)

 

Zum Seitenanfang

17.1GUI-Frameworks Zur vorigen ÜberschriftZur nächsten Überschrift

Benutzeroberfläche oder User Interface, kurz UI, nennen wir die Schnittstelle zwischen Mensch und Anwendung.

 

Zum Seitenanfang

17.1.1Kommandozeile Zur vorigen ÜberschriftZur nächsten Überschrift

Am Anfang stand die Interaktion mit der Kommandozeile (engl. command line interface, kurz CLI). Java bietet hierfür nur rudimentäre Unterstützung:

  • Die Ausgaben auf der Kommandozeile/Shell laufen über Sytem.out und Sytem.err, die Eingaben über System.in.

  • Einige Shells bieten Positionierungen eines Cursors oder Farben, doch da dies nicht plattformunabhängig ist, bietet Java keine Unterstützung an. Das kann durch quelloffene Erweiterungen jedoch ermöglicht werden.

  • Die an das Java-Programm übergebenen Kommandozeilenargumente landen bei der Methode main(String[] args) in der Parametervariablen args.

  • Rückgaben vom Java-Programm an die Shell sind über einen Methodenaufruf System.exit(int) möglich.

  • Es fehlen das komfortable Parsen der Programmargumente und Auswerten der Optionen. Quelloffene Bibliotheken schaffen hier Abhilfe.

 

Zum Seitenanfang

17.1.2Grafische Benutzeroberfläche Zur vorigen ÜberschriftZur nächsten Überschrift

Das Aufkommen von grafischen Benutzeroberflächen oder Graphical User Interfaces, kurz GUI, ab den 1970er Jahren verdrängte immer mehr die Kommandozeile, und Benutzer konnten die Anwendungen mit Fenstern, Symbolen und Interaktionskomponenten bedienen.

Die Programmiersprache Java, die sich das Ziel gesetzt hat, plattformunabhängige Softwareentwicklung zu unterstützen, muss auch eine Bibliothek anbieten, um grafische Oberflächen zu gestalten. Eine Bibliothek sollte dabei im Wesentlichen die folgenden Bereiche abdecken:

  • Sie beherrscht das Zeichnen grafischer Grundelemente wie Linien und Polygone, setzt performant Grafiken, ermöglicht das Setzen von Farben und bietet eine ordentliche Darstellung von Text.

  • Sie bietet grafische Komponenten (GUI-Komponenten), auch Steuerelemente oder Widgets genannt, wie zum Beispiel Fenster, Schaltflächen, Textfelder und Menüs.

  • Sie definiert ein Modell zur Behandlung von Ereignissen, wie etwa Mausbewegungen.

Zur GUI-Entwicklung in Java gibt es Frameworks, also Bibliotheken, mit denen sich grafische Oberflächen programmieren lassen. Drei Frameworks bringt Java gleich mit.

 

Zum Seitenanfang

17.1.3Abstract Window Toolkit (AWT) Zur vorigen ÜberschriftZur nächsten Überschrift

Als Sun Java 1985 veröffentlichte, gehörte ein Framework zur Gestaltung (einfacher) grafischer Oberflächen schon gleich mit zur Standard-API: das Abstract Window Toolkit (AWT). Es bietet Methoden für Primitivoperationen zum Zeichnen, zur Ereignisbehandlung und einen einfachen Satz von GUI-Komponenten, wie Beschriftungen, Schaltflächen, Textfelder. Das AWT ist eine portable GUI-Bibliothek, die auf nativen Komponenten des Betriebssystems basiert und folglich auch hervorragende Performance und im Grunde gute Portabilität bietet.

 

Zum Seitenanfang

17.1.4Java Foundation Classes und Swing Zur vorigen ÜberschriftZur nächsten Überschrift

Das AWT bietet nur lächerliche acht Komponenten,[ 235 ](Button, Checkbox, Choice, Label, List, Scrollbar, TextArea, TextField, die Container und eine generische Zeichenfläche Canvas einmal außen vor gelassen. ) und anspruchsvolle Oberflächen sind damit nur mit viel Handarbeit möglich. Sun entschloss sich daher schon früh, das AWT zu erneuen, und so flossen neue Komponenten – die so genannten Swing-Komponenten – sowie eine neue Java 2D-API und weitere Dienste fest in Java 1.2 ein (zur Erinnerung, das war Ende 1998). Die Gesamtheit von AWT und Swing bilden die Java Foundation Classes, kurz JFC. Sie sind bis heute Teil der Java SE, wobei für Java 9 zur Diskussion steht, ob die JFC nicht zu Gunsten von JavaFX als Modul herausgelöst werden.

 

Zum Seitenanfang

17.1.5JavaFX Zur vorigen ÜberschriftZur nächsten Überschrift

Seit etwa 15 Jahren realisieren Swing bzw. die Java Foundation Classes grafische Anwendungen unter Java. Zwar sind die Java Foundation Classes mächtig, aber sie haben sich in den letzten Jahren nicht großartig weiterentwickelt. Insbesondere gibt es Lücken im Bereich ausgereifter Komponenten sowie Medienunterstützung und Animation, etwas, was bei modernen grafischen Oberflächen heutzutage gefragt ist. Anstatt in die Weiterentwicklung der JFC zu investieren, hat sich Sun/Oracle für eine komplette Neuentwicklung der GUI-Ebene entschieden, die nichts mehr mit Swing/AWT gemeinsam hat – herausgekommen ist JavaFX.

JavaFX ist eine Komplettlösung mit einer API für:

  • GUI-Komponenten

  • HTML/CSS/JavaScript mit eingebettetem Webbrowser

  • Animationen

  • Video

  • Audio

  • 2D und 3D

Da JavaFX komplett alle APIs für moderne Oberflächen anbietet und auch nicht von AWT/Swing abhängig ist, bildet JavaFX einen kompletten Media-Stack. Die Betonung liegt auf »Media«, denn die Java Foundation Classes können keine Videos einbinden oder abspielen. Anders als AWT ist die JavaFX-Implementierung auf der Höhe der Zeit und greift direkt auf alle 2D-/3D-Fähigkeiten moderner Grafikkarten zurück. So kann mit JavaFX alles das programmiert werden, was bisher eher mit Flash gemacht wurde, wohl aber fehlen noch die tollen Entwicklertools. Es gibt Plugins für Adobe Photoshop und Illustrator, mit denen Grafiken und Pfade exportiert werden können, aber eben keine ganzen Animationen, die etwa mit Adobe Flash erzeugt wurden.

Geschichte von JavaFX: JavaFX 1, JavaFX 2, JavaFX 8

Ursprünglich wollte Sun/Oracle JavaFX als Flash-Ersatz im Internet positionieren, doch dafür ist die Kombination HTML5 + CSS3 + JavaScript zu attraktiv. JavaFX ist in erster Linie eine großartige GUI-Bibliothek für klassische Client-Anwendungen, die langsam auch auf mobile Endgeräte vorrückt. So nahm die Entwicklung auch unterschiedliche Richtungen.

JavaFX ist schon sehr lange in Entwicklung, und viele interne Swing-Entwickler wurden bei Sun/Oracle auf das Projekt angesetzt – umgekehrt passierte bei den Java Foundation Classes nicht mehr viel, Bugfixes kommen aber immer noch brav. Im Jahr 2007 wurde JavaFX auf der SunOne-Konferenz vorgestellt, Ende 2008 erschien das Release JavaFX 1.0 zusammen mit der Programmiersprache JavaFX Script. Die besondere Sprache machte es möglich, auf einfache Weise hierarchische Objektgraphen aufzubauen, und bot eine nette Syntax für Object-Binding, sodass Zustände synchronisiert werden konnten.

Im Oktober 2011 erschien JavaFX 2.0 mit vielen Neuerungen und auch Änderungen. So wurde JavaFX Script entfernt, denn Oracle wollte keine weitere Programmiersprache aufbauen, sondern eine pure Java-API, die Entwickler dann von unterschiedlichen existierenden Skriptsprachen aus ansprechen können. Das ist sicherlich eine gute Entscheidung, denn unter JavaScript und Groovy sieht das sehr schlank aus, fast wie mit JavaFX Script. Mit dem Update auf JavaFX 2.0 änderte sich auch die API, sodass alter Code angefasst werden musste. Heute ist JavaFX 1 veraltet, genauso wie die Literatur.

JavaFX entwickelte sich immer mehr zur Alternative zu Swing/AWT, und so integrierte Oracle im August 2012 das Java FX 2.2 SDK und die Runtime in das JRE/JDK 7 Update 6. Der Schritt war ungewöhnlich, denn so große Ergänzungen waren bisher als Update im JRE/JDK noch nie gemacht worden. Neben der Integration bewegte sich auch das ehemals geschlossene JavaFX in Richtung Open Source und mündete in der Implementierung OpenJFX. Mit dem OpenJDK und OpenJFX lässt sich ein komplett freies Java-System mit GUI-Stack unter der GPL bauen, was strikte Linux-Distributionen freuen wird. Die Offenheit führte schon zu sehr spannenden Experimenten, etwa einer Java-Version für iOS.

Mit Java 8 zieht auch JavaFX 8 ein, der nächste Sprung mit 3D-Unterstützung.

 

Zum Seitenanfang

17.1.6SWT (Standard Widget Toolkit) * Zur vorigen ÜberschriftZur nächsten Überschrift

Es gibt Anwendungsfälle, in denen weder AWT noch Swing noch JavaFX passen. Swing ist zwar sehr mächtig, doch kostet es auch einige Ressourcen. AWT ist schlank und recht schnell, bietet aber wenige Komponenten. Das AWT ist bei Geräten mit wenig Speicher, etwa Handheld-Geräten, noch eine interessante Variante, aber alles sieht so aus, als ob die Entwicklung bei JavaFX weitergeht.

Im Jahr 1998 begann IBM mit der Entwicklung des Nachfolgers von VisualAge for Java (das in Smalltalk geschrieben war). Für die neue Entwicklungsumgebung – aus der später Eclipse wurde – benötigte das Entwicklerteam Oberflächenelemente. Swing war weit davon entfernt, zügig, speichereffizient und korrekt zu sein, und Sun führte schon damals die AWT-Entwicklung nicht erkennbar weiter. So entschied IBM, mit dem SWT (Standard Widget Toolkit) eine Alternative zum AWT zu entwickeln, die Möglichkeiten eines nativen grafischen Systems nutzen kann. Dazu zählen neben Komponenten wie Schaltflächen und Tabellen auch integrierte Fähigkeiten wie Drag & Drop, Zwischenablage, Drucken und ActiveX-Integration (unter Windows). Dabei nutzt SWT keinen Anteil von AWT, nicht einmal die grafischen Primitivoperationen oder Java 2D. Wegen dieser engen Kopplung an das System müssen die SWT-Applikationen mit einer dynamischen Bibliothek (DLL unter Windows) ausgeliefert werden. Eine Umsetzung gibt es heute außer für Windows (auch Windows CE) und Mac OS X etwa auf diversen Motif-Plattformen, GTK (kein Qt) und QNX/Photon. (Wer nur unter GNOME und GTK+ programmiert, der sollte einen Blick auf Java-GNOME unter http://java-gnome.sourceforge.net werfen.)

Ursprünglich war das SWT (http://www.eclipse.org/swt) ausschließlich für die neue Entwicklungsumgebung gedacht. Mittlerweile erfreut sich die Swing-Alternative aber größerer Beliebtheit und ist inzwischen von der Entwicklungsumgebung losgelöst. Insbesondere für mobile Endgeräte (Windows CE) ist das SWT sehr performant, da die Bibliothek auf einem kleinen nativen Kern aufbaut und recht leichtgewichtig ist. Die Eclipse Rich Client Platform (RCP) ist ein großes Framework für komplexe grafische Oberflächen auf der Basis von SWT, das Aufgaben wie Konfigurationen für Benutzer oder Verteilung und Aktualisierung von Haus aus realisiert.

Das immer wieder vorgebrachte Argument, dass mit SWT die Java-Oberflächen genauso aussehen wie native Oberflächen der jeweiligen Plattform, ist fragwürdig. SWT-Oberflächen sehen anders aus, etwa bei den Reitern oder Menüs, und Swing kommt dem nativen Aussehen – insbesondere ab Java Version 6 unter Windows – eigentlich näher. Dem Anwender ist das ziemlich egal. Selbst für konservativere Bereiche wie Office haben sich Anwender daran gewöhnt, dass Microsoft in jeder Produktversion die Optik anpasst. Microsoft Office 2007 sieht völlig anders aus als Office 2003, das sieht wieder anders aus als Office 2016 und der Windows Media Player folgt auch nicht der Design-Sprache. Die Avantgarde der Anwender passte schon immer die Oberflächen an; das »Skinning« unterstützen heute bereits viele Anwendungen.

Ob die IBM-Entwickler mit dem mittlerweile schnellen Swing-Framework die gleiche Entscheidung treffen werden, wird immer wieder diskutiert – ebenso wie die Frage, ob JavaFX irgendwann einmal Eclipse realisiert, ein Prototyp existiert schon. Von der Geschwindigkeit und dem Speicherverbrauch her wäre es denkbar, aber sehr unwahrscheinlich, dass die Entwickler Mühe in eine komplette Umstellung investieren, zumal in SWT auch Swing-Applikationen und Java 2D ans Laufen gebracht werden können.

 


Ihr Kommentar

Wie hat Ihnen das <openbook> gefallen? Wir freuen uns immer über Ihre freundlichen und kritischen Rückmeldungen.

>> Zum Feedback-Formular
<< zurück

 

 


Copyright © Rheinwerk Verlag GmbH 2017

Für Ihren privaten Gebrauch dürfen Sie die Online-Version natürlich ausdrucken. Ansonsten unterliegt das <openbook> denselben Bestimmungen, wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.

 

[Rheinwerk Computing]



Rheinwerk Verlag GmbH, Rheinwerkallee 4, 53227 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, service@rheinwerk-verlag.de