Am Donnerstag hatten wir die Gelegenheit im Rahmen der zweiten Sitzung unseres „Oberseminars Programmiersprachen“ von Frank mehr über JavaFX zu erfahren.
Interessant gleich zu Beginn die Genealogie der Programmiersprache, die unter dem Kürzel F³ („Form follows function“) aus der Taufe gehoben wurde. Grundsätzlich handelt es sich dabei um ein alternatives Konzept, um neben Swing eine elegantere Möglichkeit zur Gestaltung graphischer Oberflächen zu bekommen. Das Motto steht dabei für den Anspruch, dass bereits der Code die Struktur der später sichtbaren Elemente widerspiegelt.
Ursprünglich als Skriptsprache konzipiert, um zu Flash und Silverlight aufzuschließen, plant Oracle nach dem Kauf von Sun die Integration in Java mit Fokussierung auf den mobile und embedded Bereich. Erstes Resultat ist der Relaunch als JavaFX 2.0, bei dem auch die Kompatibilität mit 1.x geopfert wurde, die Integration in Java 7 und die Unterstützung in der nächsten NetBeans-Version (7.1, RC2). Das ist in der Tat schnell installiert:
http://netbeans.org/kb/docs/java/javafx-setup.html
Durch diese Integration steht JavaFX auch allen Programmiersprachen offen, die auf bytecode kompilieren.
Konzeptioneller Ansatz ist, dass jede Oberfläche aus einer Stage und Scenes besteht. Die Stage rollt dabei gewissermaßen die Leinwand aus, der eine Scene als root übergeben wird. Alle übrigen Komponenten sind über den Scene Graph, einem baumartigen gerichteten Graphen, einer Eltern-Komponente zugeordnet. Diese kapselt dann – frei von LayoutManagern – die Fähigkeit, die Kind-Elemente entsprechend anzuordnen. Natürlich lässt sich das Default-Verhalten anpassen. Ganz ähnlich verhält es sich mit graphischen Elementen. Es muss also nicht mehr mit irgendwelchen draw-Methoden auf einer Komponente herumgemalt werden. Statt dessen hängt einfach ein Circle-Element im SceneGraph – und das weiß am besten, wie es sich malt.
Die Idee, die so entstandene Struktur deklarativ abzubilden, liegt nahe, und so können die Komponenten – ähnlich zu Android – als xml-Dokument definiert werden. Anders als bei Android können die Komponenten dann nicht einfach mit findViewByID zugegriffen werden, sondern müssen vorher im Code deklariert werden. Per Java Annotations werden dann die per xml vordefinierten Komponenten referenziert.
Für ein weiteres Konzept bedarf es der Modifikation des klassischen Getter- und Setter-Konzepts. Gekapselt als Properties, denen typisierte Observable Values zugewiesen werden können, erlauben sie ein einfach zu realisierendes Binding. Und schon passt sich die Breite des Fensters an den aktuellen Slider-Value an o.ä. So lassen sich auch komplexe Komponenten synchron halten.
Hinter dem Konzept Scene verbirgt sich aber natürlich auch der Gedanke, dass es bewegte Bilder sein können. Hier gibt es ein klassisches Timeline-Konzept, mit dem der Zielwert einer Darstellung und die Dauer der Transformation angegeben werden. Verkettet entstehen animierte Szenen, die sich auseinander entwickeln. Hierbei unterstützen Effects, die alle möglichen Arten von Animationen unterstützen. Passend zum deklarativen Gedanken können auch ganze Erscheinungsmuster als Pseudo-CSS deklariert werden und dann en bloc Komponenten zugewiesen werden. Dies kann sogar zur Laufzeit geschehen – einfach neues Pseudo-CSS unterschieben und schon sieht alles anders aus…
Fazit: ein erster Eindruck begeistert mit einem stringenten Konzept, dass einfach zu handlen ist, gerade weil es mit der klassischen Java-Philosophie bricht, und so Swing doch schnell spröde und altbacken wirken lässt, wenn es an die Gestaltung von Oberflächen geht.
Mehr unter: fxexperience.com