Swing Application Framework #

Es gibt ein paar Themen und Probleme, die bei der Erstellung von GUI-Applikationen immer wieder auftreten. Um hier das Rad nicht immer wieder neu erfinden zu müssen, bietet es sich an, solche Probleme in Standard-Bibliotheken auszulagern. Die Erstellung einer Applikation wird dadurch beschleunigt und vereinheitlicht.

Diese Seite soll die vorhandenen Lösungen hierfür aufzählen, soweit möglich vergleichen und festhalten, was ein solches Framework überhaupt können soll.

vorhandene Frameworks #

Zur Erstellung einer Desktop-Applikation in Java kenne ich folgende Ansätze:

• Eclipse Platform, Basis der EclipseIDE, basiert auf SWT
• Netbeans Platform, Basis der NetbeansIDE, basiert auf Swing
• Java Application Framework, basiert auf Swing
• JGoodies
• Griffon - Grails-ähnlicher Baukasten für Desktop-Applikationen mit Swing-Application Framework
• Apache Pivot Interessantes Framework, um Rich Internet Applications in Java (als Applet) zu bauen, Alternative zu JavaFX

Die beiden ersten Ansätze sind relativ gut dokumentiert und dürften auch recht verbreitet sein. Allerdings dürfte man sich damit eine Menge Monster-Bibliotheken einfangen. Die Zeit, die man vielleicht spart, weil einiges bereits fertig programmiert ist, benötigt man dann stattdessen dazu, sich durch die Anleitung zu graben.

Das JAF ist eine Implementation von JSR-296 und soll so eine Art leichtgewichtige Version der Netbeans-Plattform sein. Laut http://tech.puredanger.com/java7/ sollte es in Java7 integriert werden, laut http://openjdk.java.net/projects/jdk7/features/#f650 ist da aber vorerst nichts draus geworden.

JGoodies legt den Haupt-Focus auf das Design der Oberfläche.

Swing oder SWT #

Es ist zu erwähnen, daß die Eclipse-Plattform auf SWT aufbaut, Netbeans und SAF auf Swing.

Der Swing-SWT-Krieg ist ja nun nach einigen Jahren immer noch nicht entschieden. Ich war sehr gespannt, als es hieß, das IBM Sun kaufen wolle, aber da ist ja nun nichts draus geworden. Ich war bisher im Swing-Lager, bin da eigentlich recht zufrieden mit und bringe vor allem einige Erfahrung und meinen alten Code mit, weshalb ich hier zuerstmal Swing-Lösungen bevorzugen möchte. Wer SWT-Erfahrung hat, kann hier aber gerne ergänzen!

Erfahrung mit SAF #

Ich habe einige Projekte mit dem SAF erstellt. Was in der einführenden Dokumentation vorgestellt wird, funktioniert alles gut. Das SAF scheint in erster Linie mit dem GUI-Editor "Matisse", der Teil der Netbeans-Entwicklungsumgebung ist, entwickelt worden zu sein. Dabei ist es wohl grob der Netbeans-Platform ähnlich, so daß der von Matisse erzeugte Code später in beiden Frameworks laufen kann.

Allerdings sind mir auch ein paar Dinge aufgefallen, die mich stören. Eine lästige Eigenschaft ist, daß alle Elemente der GUI über Properties-Dateien konfiguriert werden müssen. Man muss z.B. für die kleinste "Hello-World" Applikation nicht nur eine Applikations-Klasse, sondern immer noch eine Properties-Datei erzeugen, die z.B. den Fenstertitel enthält. Ich finde Properties zur Konfiguration ja sehr praktisch (und aus Sicht von Matisse sind sie sicherlich eine wunderbare Sache) - aber es sollte für alle Einstellungen immer einen Standard-Wert geben, der sich aus dem Klassen-Code ergibt.

Ein weiterer Nachteil ist die Verwendung von Actions, die zwar innerhalb des Frameworks gut funktionieren und denen einige nette Eigenschaften mitgegeben wurden, die allerdings nun nicht mehr ganz kompatibel zu normalen Actions und nicht mehr so erweiterbar wie diese sind. Da ich eigene, auf SAM aufbauende JavaActions benutze, ist das etwas ärgerlich.

Obwohl es angeblich Teil von Java7 werden soll hat sich am veröffentlichen Code schon lange nichts mehr getan. Auf der Netbeans-Seite (für Matisse) gibt es eine etwas aktuellere Version, deren API sich wundersamerweise wesentlich verändert hat, allerdings keine echte Dokumentation dazu. Neuerdings soll es aber wieder leben Ich zweifle, daß das mit Java7 was gibt, bevor die eigentliche API nicht festgezurrt, dokumentiert und von der Community getestet ist, aber vielleicht reicht Sun ja auch ein interner Review.

Was macht ein Framework alles? #

Die eigentlich interessante Frage ist, was mein Lieblings-Framework alles können soll und was es eben nicht können soll. Deshalb möchte ich hier eine Aufstellung angeben, was alles denkbar ist. Letztlich ist es jedoch wünschenswert, wenn man jede einzelne dieser Eigenschaften getrennt sieht und durch eine eigene Bibliothek implementiert. Das Beispiel der Actions im SAF sei hier genannt: Zum Thema Actions gibt es ganz tolle Ideen (z.B. das "Swing Action Framework" SAM). Diese funktionieren aber nicht mit dem SAF zusammen.

Diese Eigenschaften werden in der SAF-Dokumentation genannt:

Verwaltung eines Applikations-Lebenszyklus #

eine logische Aufteilung mit startup, shutdown, Verwaltung mehrerer Fenster, etc.

Property-Injection - zentrale Verwaltung von Resourcen für die Applikation #

erlaubt Konfiguration der GUI, Skins, Lokalisation, etc. z.B. über einen ResourceManager und Properties-Dateien

ActionManager #

die Actions der normalen Swing-API sind noch lange nicht zuende gedacht

SessionStorage - Persistenter Session-Status #

Speichern von Fenstergröße und Position u.a.

LocalStorage - lokaler Speicherbereich für Programmdaten #

automatisierte Erstellung von "~/.applikationsname" bzw. anderer Mechanismen z.B. für Applets

TaskService #

Verwaltung von Hintergrundtasks

Folgende Eigenschaften fallen mir selber darüber hinaus noch ein:

MenuManager #

Erstellung und Verwaltung eines Menüs (ggf. unter Zuhilfenahme der vorhandenen Actions)

DocumentManager #

Verwaltung verschiedener Dokumente mit Standard-GUI-Elementen, um diese zu wechseln, zu Laden, zu Speichern, etc.

UserManager #

Benutzer-Verwaltung braucht man eigentlich auch recht häufig

ExceptionHandler #

einheitlicher Umgang mit Exceptions, z.B. Ausgabe im Dialogfenster

GUI-Generation #

Einige GUI-Elemente wie das Menü oder eine Statusleiste fallen sicherlich mit in den Fokus eines Application Framework (oder ist das die Aufgabe des Action Frameworks wie auf JavaActions beschrieben?). Es ergeben sich auf jeden Fall Überschneidungen und Schnittstellen zu dem Code, der letztlich die eingentliche Nutz-GUI darstellt. Daher ist auf die Zusammenarbeit mit GUI-Generatoren (z.B. XUL-Generatoren wie Swixml oder CookSwing oder der YAML-Generator SwingJavaBuilder), Formulargeneratoren, etc. zu achten. Die Verknüpfung sollte jedoch nicht zu stark sein, da hier jeder Programmierer seinen eigenen Lieblings-Weg haben wird...

Auf der Swixml-Homepage gibt es übrigens über die guten Beispiele hinaus sehr wenig Doku. Ich empfehle, folgendes zu lesen: deutscher Artikel mit guter Beispiel-Sammlung, Artikel auf java.net, Artikel auf devarticles.com.

Und nicht vergessen: Auf eine generierte GUI folgt zumeist ein anständiges Binding wie BeansBinding oder JGoodies Binding.

Standard-Dialoge #

Einfache Erstellung von häufig gebrauchten einfachen Dialogen über JOptionPane hinaus. (siehe unten, Arbeitstitel "JDialog")

eigenes Framework / eigene Zusammenstellung #

Nach meinen Erfahrungen wäre es sinnvoll, ein Framework zu haben, das wirklich "leightweight" ist und sonst nichts. Ich benutze dann lieber mehrere, (evtl. aufeinander abgestimmte) Komponenten, die ich mir aussuchen oder es auch lassen kann, als mir von meinem Framework alles vorschreiben zu lassen.

Im Grunde geht es also weniger darum, alles neu zu erfinden, als darum, bereits vorhandene Lösungen anzupassen, sinnvoll zu kombinieren und einheitlich zu dokumentieren.

Hat jemand Lust, sowas mitzuerarbeiten? Unser Projekt findet Ihr auf der Seite LugFramework.

--ThomasBayen

eine grundlegende Swing-Applikation #

Auf dem LUG-Treffen am 15.6.09 haben ThomasThiessen und ThomasBayen überlegt, welche Komponenten man für eine Basis-Anwendung bräuchte, die in Richtung Datenbank bzw. WarenWirtschaft (oder auch VereinsVerwaltung) geht. Dabei ist die folgende Auflistung entstanden. Wir haben überlegt, die dort angesprochenen Themen zu den nächsten LUG-Treffen zu bearbeiten, zu besprechen und ggf. Empfehlungen auszusprechen. Für das nächste Treffen schlage ich vor, daß wir uns dem Thema "Projektumgebung" widmen, um eine gemeinsame Basis zu schaffen. Vielleicht wird ja eine Artikelserie daraus...

• SwingApplikation.Projektumgebung

GUI #

• Erstellung der GUI in Java und/oder in XML und/oder mit Groovys SwingBuilder
• Menüs, Toolbars und Actions
  • verschiedene Befehlssammlungen ineinander schachteln
  • Rechteverwaltung
• Sessionmanagement (Fenster öffnet in der bekannten Größe an der alten Stelle)
• Tabellen sortier- und filterbar und mit Sessionmanagement

Benutzerverwaltung #

• Ablage der Benutzerdaten wie und wo

Datenbankverbindungen #

• Verwaltung in einer Art Datenbank ohne Datenbank
  SQLite bzw. in Java besser HSQLDB oder Derby oder lieber serialisiert als XML-Datei?
• Wechsel zwischen mehreren vorkonfigurierten Einstellungen
• Speichern in lokaler Datei
  Will man Webstart- und Applet-fähig sein, muss man ein LocalStorage in Form eines einzelnen Dateistreams benutzen. Das spricht gegen gängige Datenbanken und für XML. Denkbar wäre auch eine "hsqldb:mem"-Datenbank im Speicher, die man dann mit dem TransferTool dumpt bzw. restored.
  • Wieviele Datenbankverbindungen braucht Ihr denn?
  • Was spricht gegen eine ganz normale Properties-Datei? --Peter

Wir haben uns für die Speicherung serialisiert als XML-Datei entschlossen. Zum einen gibt es dafür bereits fertige Lese- und Schreib-Methoden in der Standardbibliothek. Zum anderen erlaubt das die leichte Erweiterung, indem das serialisierte Objekt erweitert oder abgeleitet wird.

Datenbank #

• [JDBC]] oder JPA (JavaHibernate)
• Einrichten der Datenbank durch das Programm

Applikationsumgebung #

• API für lokale Dateien (LocalStorage des Java Application Framework)
• standardisiertes Fenster mit Menü, Toolbar, Statusleiste, Sessionmanagement
• einheitliches Look & Feel
• Hilfesystem

Formulare #

• Plausibilitätsprüfungen
• automatische Erstellung von Formularen

Benamung von Klassen, Methoden und Variablen #

• einheitliches System
• deutsche Schreibweise von Fall zu Fall?

Dokumentation #

Wir haben uns entschlossen, für die Dokumentation des Projektes als Basis JavaDoc zu nehmen und für den Rest direkt eine Website zu erstellen, auf der dann weitere Artikel (wie Tutorials, etc) direkt als HTML-Dokumente eingebunden sind. Diese Seite findet man unter http://lugframework.javaproject.de . Sie wird mit Hilfe von ApacheAnt durch ein automatisiertes Ant-Skript erzeugt, das ich FlyingAnt getauft habe.

Splash-Screen #

Seit Java6 gibt es eine ordentliche Unterstützung für Splashscreens. Die Einführung ist unter http://java.sun.com/developer/technicalArticles/J2SE/Desktop/javase6/splashscreen/ zu finden und die API-Dokumentation unter http://java.sun.com/javase/6/docs/api/java/awt/SplashScreen.html.

Diese originale Implementation hat gegenüber allen anderen den grossen Vorteil, daß sie schon _vor_ dem Starten der Java VM den Splashscreen anzeigt. Damit dürfte Sie eine halbe Sekunde schneller als andere sein. Wie in der Einführung kann man diesen dann als erste Amtshandlung übermalen oder auch durch ein Swing-Fenster ersetzen, wenn man selber Einfluss nehmen will, um z.B. den Fortschritt der Programminitialisierung anzuzeigen.

Erinnerung #

• Parameter für GridbagLayout

---