5. November 2015
Stefan Saring
0

SportsTracker goes JavaFX

Heutzutage kennt sicherlich jeder Freizeit- oder auch Leistungssportler eine der vielen Apps oder Portale zur Planung und Auswertung seiner sportlichen Aktivitäten. Den Ursprung hatten diese Anwendungen in Kombination mit Herzfrequenz-Uhren, später erweitert durch Höhenmesser, GPS und vielem mehr. Aktuell kommt zu diesem Zweck auch oft das Smartphone zum Einsatz.

SportsTracker – was ist das?

SportsTracker ist eine Desktop-Anwendung für die Auswertung und Planung der Aktivitäten im Ausdauerbereich. Der große Unterschied zu neueren Apps und Portalen ist die ausschließlich lokale Speicherung aller – zum Teil sehr persönlicher – Daten, sowie die Unabhängigkeit vom Hersteller der Herzfrequenz- bzw. GPS-Uhren. Das Open Source-Projekt wurde bereits 2002 gestartet, basiert auf der Java-Plattform und benutzte bislang das Swing-Toolkit. Die Anwendung wurde mittlerweile mehr als 100.000 mal heruntergeladen und in insgesamt 10 Sprachen übersetzt, darunter auch Koreanisch oder gar Baskisch.

In den beiden folgenden Abbildungen ist die Auswertung des Höhenprofils einer Trainingseinheit zu sehen. Dabei zeigt Abbildung 1 die neue JavaFX-Version und Abbildung 2 die alte Swing-Version.

 

In den Abbildungen 3 und 4 ist die neue bzw. alte Version der Anzeige der Strecke einer Trainingseinheit zu sehen.

 

JavaFX – muss das sein?

Blickt man zurück auf die Geschichte von JavaFX, zeigen sich leider einige missglückte Starts dieser neuen UI-Technologie durch Sun oder später Oracle. Schon 2008 sollte JavaFX 1.0 eigentlich Swing ablösen, eine eigene neue Script-Sprache nur für die Oberflächen fand jedoch kaum Akzeptanz bei den Entwicklern. Daher wurde 2011 mit JavaFX 2.0 vollständig auf Java gesetzt, leider fehlten noch wichtige, oft unverzichtbare UI-Komponenten. Diese Mankos wurden aber erkannt und behoben, seit Version 8 kann JavaFX ohne Bedenken für die Umsetzung von Business- und RIA-Anwendungen eingesetzt werden. JavaFX bietet eine Vielzahl an Vorteilen gegenüber Swing, die wichtigsten Features sind:

  • Trennung der UI-Definition (FXML-Datei) und des UI-Codes (Java)
  • Visuelle Erstellung der UI in FXML durch den SceneBuilder
  • Styling und Customizing der UI durch CSS
  • Properties und Bindings
  • Web-Integration und Media-Support
  • Erstellung von nativen Installern für Windows, Mac OS X und Linux

 

Oracle empfiehlt seit geraumer Zeit den Einsatz von JavaFX für alle neuen Desktop-Anwendungen, in Swing wird kaum noch Aufwand investiert. Auch in der Community ist der Wandel sehr gut zu beobachten. Swing-Projekte werden kaum noch weiterentwickelt, stattdessen entstehen zahlreiche neue und nützliche JavaFX-Bibliotheken und Frameworks (z.B. ControlsFX und mvvmFX). In Anbetracht der vielen Vorteile war daher eine Umstellung von SportsTracker von Swing auf JavaFX unumgänglich, zudem wird dadurch die langfristige Weiterentwicklung des Projekts erleichtert und gesichert.

OK, Migration – aber wie?

Die einfachste Möglichkeit ist natürlich die vollständige Neuentwicklung der Applikation. Dies hat aber zur Folge, dass wirklich die gesamte Anwendung neu implementiert werden muss. Zudem sind während der gesamten Umstellung keine neuen Releases für z.B. dringend benötigte Features möglich.
Diese Risiken können umgangen werden, wenn stattdessen sukzessive einzelne Bestandteile auf JavaFX umgestellt werden, die restliche Anwendung aber weiterhin Swing benutzt. Neue Features und Oberflächen werden stets mit JavaFX umgesetzt, je nach verfügbarer Zeit und Budget werden auch die bereits vorhandenen Oberflächen umgestellt. Diese Strategie wurde bei SportsTracker gewählt. Im Zuge der Migration wurden nach und nach einzelne Fenster und Dialoge auf JavaFX migriert, die gesamte Anwendung war während der Migration stets benutzbar. Erst zuletzt erfolgte die Umstellung des recht komplexen Hauptfensters (interaktiver Kalender usw.).

Von den Entwicklern der JavaFX-Plattform wurden bereits die Szenarien einer Migration bedacht, so ermöglicht die neue Swing-Klasse JFXPanel die Integration von JavaFX-Steuerelementen in Swing-Oberflächen. Die JavaFX-Klasse SwingNode unterstützt die umgekehrte Richtung. Dennoch ist eine Migration mit einigen Hindernissen verbunden, die es zu beachten gilt. Am wichtigsten ist die saubere Trennung der UI-Threads von Swing und JavaFX beim Zugriff auf die Steuerelemente der jeweiligen Plattform. Zwar stehen dafür entsprechende Hilfsklassen bereit, jedoch werden diese oft nicht oder falsch eingesetzt. Die Folgen sind für den Entwickler nicht direkt ersichtlich, die Fehler treten oft erst später in Form von schwer nachvollziehbaren Darstellungproblemen auf.

Ein weiteres Manko ist die fehlende Möglichkeit für die Integration von Swing- und JavaFX-Fenstern. Der Workaround für dieses Problem und andere Besonderheiten wurden im Rahmen unseres Migrations-Artikels im JavaMagazin 09/2015 (Online-Version) vorgestellt. Zudem kann der Quellcode der gesamten Migration des SportsTracker-Projekts auf GitHub eingesehen werden.

Fazit

Klar, die Migration des gesamten Projekts auf JavaFX war aufwendig – die Arbeit hat sich aber gelohnt. Durch moderne Konzepte wird der Quellcode kompakter und ist besser strukturiert, dies erleichtert die Wartung und die Umsetzung neuer Anforderungen. Verbindet man die Migration mit der Einführung von Java 8 Features wie z.B. Lambdas und der Streaming-API, werden die Vorteile umso deutlicher.

Stefan Saring arbeitet als Softwarearchitekt und Entwickler bei der Saxonia Systems AG in Dresden. Seit mehr als 15 Jahren ist er in Projekten der Java Standard- und Enterprise-Umgebung tätig.

Google+ 

TeilenTweet about this on TwitterShare on Facebook0Share on Google+0Share on LinkedIn0