Eine Desktop-App mit JavaFX: das Mitfahrlabor für Fahrer*innen und Verwaltung

Eine Desktop-App mit JavaFX: das Mitfahrlabor für Fahrer*innen und Verwaltung

https://bildung.social/@oerinformatik/

https://oer-informatik.de/javafx-mitfahrlabor-projekt

JavaFX, Desktop-Anwendung, Kanban, MVVM, REST-API, Keycloak, Java, GUI-Test, TestFX, Mitfahr-App

tl/dr; (ca. 19 min Lesezeit): In zwölf Artikeln entsteht mit JavaFX eine Desktop-App für das Mitfahrlabor: Fahrer*innen verwalten ihre Angebote und Buchungen, die Verwaltung pflegt Haltepunkte und sieht die Auslastung. Die App spricht mit der REST-API des Spring-Boot-Backends, die Anmeldung läuft über Keycloak, und organisiert wird die Arbeit mit Kanban. Hier findest Du den Fahrplan, die Architektur, die Voraussetzungen und den Vergleich von Desktop- und Web-Oberflächen [AI-Assisted]. (Zuletzt geändert am 11.11.2026)

Dieser Artikel ist Teil einer Artikelreihe über eine Desktop-App mit JavaFX: Übersicht / Kanban-Projektstart / Projekt anlegen / FXML, Layouts und CSS / Properties, Bindings und MVVM / Backend anbinden / TableView für Buchungen / Formulare und Dialoge / Anmeldung mit Keycloak / Verwaltung und Diagramme / GUI-Tests mit TestFX / Abnahmetest und Kanban-Metriken / Paketieren mit jpackage

Schon fit in diesem Thema? Nutze die Kann-Liste und die Leitfragen unter dem Artikel als Checkliste, ob Du die relevanten Kompetenzen bereits hast. Hier klicken, um Kann-Liste ein- oder auszublenden

Wer mit dem Auto zur Schule fährt und Plätze anbietet, muss sich um einiges kümmern: Angebote anlegen, Anfragen bestätigen oder ablehnen, eine Fahrt absagen, wenn das Auto in der Werkstatt steht. Und wer die App betreut, will wissen, welche Haltepunkte genutzt werden und wie voll die Autos sind. Für diese Arbeit am Schreibtisch baust Du in dieser Artikelreihe eine Desktop-App mit JavaFX, dem Oberflächen-Framework für Java.

Die App ist die dritte Oberfläche für das Projekt Mitfahrlabor. Das Backend dazu ist in der Reihe Ein REST-Backend mit Spring Boot entstanden; die Flurmonitore mit Thymeleaf und die Web-App zum Suchen und Buchen mit Vue folgen in eigenen Reihen. Diese Reihe nutzt dieselbe REST-API, dieselben Daten und dieselbe Anmeldung über Keycloak, arbeitet aber mit einem anderen Vorgehensmodell: Statt in Sprints oder Iterationen fließen die Aufgaben über ein Kanban-Board.

Stand auf dem Board

Jeder Artikel der Reihe beginnt mit einem Blick auf das Kanban-Board: Welche Tickets sind in Arbeit, welche warten, wo staut es sich? Zu Beginn gibt es noch kein Board, sondern nur eine Sammlung von Wünschen der Nutzenden. Die erste Aufgabe ist deshalb, das Board einzurichten und die Wünsche als Tickets zu formulieren. Das passiert im nächsten Artikel.

Worum es geht: zwei Sichten auf dieselben Daten

Am DBH-Berufskolleg organisieren Auszubildende mit der App Mitfahrlabor Fahrgemeinschaften. Bisher können Fahrer*innen ihre Fahrten nur über die REST-API anlegen, und die Verwaltung hat gar keine eigene Oberfläche. Die Desktop-App schließt diese Lücke mit zwei Sichten:

• Die Fahrer-Sicht ist für Personen wie Ben Richter, der ab Gütersloh fährt, oder Niklas Fischer, der mit dem Kleinbus seines Sportvereins bis zu sieben Plätze ab Bad Salzuflen anbietet. Sie legen Angebote an, ändern oder sagen sie ab und bestätigen oder lehnen Anfragen ab. Gerade bei vielen Anfragen hilft eine Tabelle, die man sortieren und filtern kann.

• Die Verwaltungssicht ist für Andrea Wolf, die Administratorin der App, und ihre Vertretung im Sekretariat. Sie pflegen die Haltepunkte, sagen im Notfall jede Fahrt ab und sehen in Diagrammen, wie stark die Haltepunkte genutzt werden und wie voll die Fahrten sind.

Beide Sichten arbeiten mit denselben Ressourcen der REST-API. Welche Rolle eine Person hat, entscheidet Keycloak: Das Token enthält die Rolle NUTZER oder ORGA, und die App blendet danach die passende Sicht ein.

Nicht alles, was die App braucht, bietet die REST-API schon an. Haltepunkte etwa lassen sich bisher nur lesen. Solche Lücken sind Absicht: Sie zeigen, wie ein Team eine eilige Erweiterung des Backends über das Kanban-Board schleust, ohne dass die übrige Arbeit liegen bleibt.

Desktop oder Web: Wann lohnt sich eine Desktop-App?

Heute laufen die meisten Anwendungen im Browser. Warum also eine Desktop-App? Ein Vergleich zeigt, dass beide Wege ihre Stärken haben:

Für Mitfahrende, die unterwegs eine Fahrt suchen, ist die Web-App die bessere Wahl. Für Arbeit am Schreibtisch mit vielen Tabellen, Formularen und Auswertungen ist eine Desktop-App dagegen angenehm: Sie startet schnell, lässt sich mit der Tastatur bedienen und kann zum Beispiel Auswertungen direkt als Datei speichern. In Unternehmen begegnen Dir Desktop-Anwendungen deshalb noch oft, etwa in der Warenwirtschaft, in der Buchhaltung oder als Werkzeuge für Administratorinnen und Administratoren.

JavaFX ist dabei der Nachfolger von Swing. Es wird als freies Projekt OpenJFX entwickelt und nicht mehr mit dem JDK ausgeliefert, sondern wie jede andere Bibliothek über Gradle oder Maven eingebunden. So sieht eine minimale JavaFX-App aus, die zwei Fahrtangebote von Ben Richter in einer Liste zeigt:

package de.dbh.mitfahrlabor.desktop;

import javafx.application.Application;
import javafx.scene.Scene;
import javafx.scene.control.Label;
import javafx.scene.control.ListView;
import javafx.scene.layout.VBox;
import javafx.stage.Stage;

public class MitfahrlaborApp extends Application {

    @Override
    public void start(Stage stage) {
        Label ueberschrift = new Label("Meine Fahrtangebote");
        ListView<String> angebote = new ListView<>();
        angebote.getItems().addAll(
                "19.10.2026 07:00 ab Gütersloh, zur Schule, 2 Plätze frei",
                "19.10.2026 14:20 ab Gütersloh, nach Hause, 3 Plätze frei");

        VBox wurzel = new VBox(10, ueberschrift, angebote);
        stage.setTitle("Mitfahrlabor Desktop");
        stage.setScene(new Scene(wurzel, 480, 200));
        stage.show();
    }

    public static void main(String[] args) {
        launch(args);
    }
}

Das Fenster heißt in JavaFX Stage (Bühne), sein Inhalt Scene (Szene), und die Bedienelemente darin sind Nodes (Knoten) in einem Baum. Wie das Projekt dazu angelegt wird und was beim Start einer JavaFX-App genau passiert, zeigt Artikel 02. Die fest eingetragenen Texte ersetzt die App später durch echte Daten aus der REST-API.

Die Architektur: JavaFX-App, REST-API und Keycloak

Das Titelbild oben zeigt, wie die Teile zusammenspielen. Innerhalb der App trennen wir drei Aufgaben nach dem Muster MVVM (Model-View-ViewModel):

• Die View beschreibt, was man sieht: Fenster, Tabellen, Formulare. Sie entsteht in FXML, einer XML-Beschreibung der Oberfläche, und wird mit JavaFX-CSS gestaltet.

• Das ViewModel hält den Zustand der Oberfläche in Properties, also beobachtbaren Werten. Die View ist per Binding daran gekoppelt: Ändert sich ein Wert im ViewModel, zeigt die View ihn sofort an, und umgekehrt. Weil das ViewModel keine Bedienelemente kennt, lässt es sich ohne Fenster mit JUnit testen.

• Der API-Client spricht mit dem Backend. Er wird aus dem OpenAPI-Vertrag openapi.yaml des Backends erzeugt, sodass Klassennamen wie Angebot, Buchung und Haltepunkt in App und Backend übereinstimmen. Anfragen laufen in einem Hintergrund-Task, damit die Oberfläche während des Wartens bedienbar bleibt.

Zur Anmeldung öffnet die App den Systembrowser mit der Anmeldeseite von Keycloak. Nach der Anmeldung schickt Keycloak einen Code an einen kleinen Empfänger, den die App auf 127.0.0.1 öffnet; die App tauscht ihn gegen Tokens. Dieses Vorgehen für native Apps beschreibt RFC 8252, abgesichert mit PKCE (Proof Key for Code Exchange, RFC 7636). Bei jeder Anfrage schickt der API-Client das Access Token mit, und die REST-API prüft dessen Signatur. Ein Passwort sieht die App dabei nie.

Kanban im Überblick

Die drei Frontend-Reihen nutzen drei verschiedene Vorgehensmodelle: Der Flurmonitor entsteht mit Scrum in Sprints, die Web-App mit Extreme Programming in kurzen Iterationen. Diese Reihe arbeitet mit Kanban. Kanban kennt keine festen Zeitabschnitte. Die Arbeit fließt als einzelne Tickets über ein Board, und das Team holt sich neue Arbeit, sobald es Kapazität frei hat. Das passt gut zu einer Anwendung, die schon läuft und laufend Wünsche, Fehlermeldungen und eilige Anfragen bekommt.

Vier Ideen tragen Kanban:

• Arbeit sichtbar machen: Jede Aufgabe ist ein Ticket, jede Bearbeitungsstufe eine Spalte des Boards.

• Angefangene Arbeit begrenzen: Jede Spalte hat ein WIP-Limit (Work in Progress). Ist es erreicht, wird nichts Neues begonnen, sondern erst etwas fertiggestellt.

• Ziehen statt schieben: Wer frei ist, zieht das nächste Ticket aus der Spalte davor (Pull-Prinzip). Niemand bekommt Arbeit zugeteilt, die er gerade nicht aufnehmen kann.

• Regeln ausdrücklich machen: Wann ein Ticket „bereit“ oder „fertig“ ist, steht als Regel an der Spalte.

Für die Reihe schlagen wir dieses Board vor; im nächsten Artikel richtest Du es ein und passt es an:

Nicht jedes Ticket ist gleich dringend. Kanban unterscheidet deshalb Serviceklassen. Ein Expedite-Ticket (etwa eine dringend gebrauchte Erweiterung der REST-API) darf am WIP-Limit vorbei, aber immer nur eines zur Zeit. Tickets mit festem Termin (Fixed Date) werden so eingeplant, dass sie rechtzeitig fertig sind. Die meisten Tickets sind Standard, und Aufräumarbeiten ohne sichtbaren Nutzen (Intangible) laufen mit, wenn Luft ist. Statt Velocity misst Kanban den Fluss: Wie lange braucht ein Ticket vom Ziehen bis „fertig“ (Durchlaufzeit), und wie verteilen sich die Tickets über die Zeit auf die Spalten (Cumulative Flow Diagram)? Diese Kennzahlen wertest Du in Artikel 11 aus.

Der Fahrplan: zwölf Artikel in vier Etappen

Die Reihe hat zwölf Artikel, die Du in vier Etappen durcharbeitest. Zuerst entsteht die Oberfläche mit Beispieldaten, dann wird das Backend angebunden, danach kommen Anmeldung und Verwaltung, zum Schluss Tests und Auslieferung. Unterwegs prüfst Du jede Testebene des V-Modells einmal.

Zu jedem Artikel gibt es einen eigenen Übungsartikel. In den Artikeln arbeitest Du mit Fahrtangeboten; die Übungen führen den Strang der Mitfahrgesuche aus den Backend-Übungen weiter. Für einen Artikel solltest Du mit Ausprobieren höchstens 40 Minuten einplanen, für die Übungen etwa eine Stunde. Am Ende hast Du eine installierbare Desktop-App mit Fahrer- und Verwaltungssicht, die sich über Keycloak anmeldet, mit Tests auf allen Ebenen und einer Pipeline, die bei jedem Push baut, testet und ein Installationspaket erzeugt.

Varianten in den Tabs

Wie in der Backend-Reihe gibt es manche Codebeispiele in mehreren Varianten. Du wählst sie über Tabs aus, und die Website merkt sich Deine Wahl für alle Artikel.

Voraussetzungen und Code zum Mitmachen

Du solltest objektorientiert in Java programmieren können: Klassen, Interfaces, Vererbung, Collections und Lambdas. Hilfreich ist, wenn Du die Backend-Reihe kennst oder zumindest weißt, was eine REST-API ist; die Grundlagen stehen in den REST-Grundlagen. Für die Arbeit brauchst Du:

• ein JDK 25 (Java mit Langzeitunterstützung), weil JavaFX 27 mindestens diese Version voraussetzt, siehe Grundlagen für Java-Framework-Projekte installieren,

• eine Entwicklungsumgebung mit Java- und Gradle-Unterstützung (etwa IntelliJ IDEA, Eclipse oder VSCodium mit Java-Erweiterungen),

• ab Artikel 05 das laufende Backend aus dem letzten Stand der Backend-Reihe und ab Artikel 08 Keycloak (Download als ZIP oder per Docker),

• Git und ein Konto bei GitLab für die Pipeline.

Bis Artikel 04 kommt die App ohne Backend aus und arbeitet mit Beispieldaten aus dem Szenario. Den Code jedes Artikels findest Du als eigenen Zwischenstand im Ordner src des Repositorys, ein Unterordner je Artikel (src/01-…, src/02-…). Hängst Du einmal fest, machst Du mit dem Stand des vorigen Artikels weiter.

Nächster Schritt: das Board einrichten

Im nächsten Artikel, dem Kanban-Projektstart, sammelst Du mit dem Projektteam die Wünsche von Fahrer*innen und Verwaltung, schreibst sie als Tickets mit Akzeptanzkriterien, legst die Spalten und WIP-Limits fest und ziehst das erste Ticket: das JavaFX-Projekt anlegen.

Leitfragen

1. Welche Aufgaben übernehmen die Fahrer-Sicht und die Verwaltungssicht der Desktop-App? Antwort

In der Fahrer-Sicht legst Du Angebote an, änderst oder sagst sie ab und bestätigst oder lehnst Buchungen ab; die Verwaltungssicht pflegt Haltepunkte, kann jede Fahrt absagen und zeigt die Auslastung als Diagramm. Welche Sicht erscheint, hängt von der Rolle NUTZER oder ORGA im Token ab. siehe Abschnitt „Worum es geht: zwei Sichten auf dieselben Daten“

2. Nenne zwei Vorteile und zwei Nachteile einer Desktop-App gegenüber einer Web-App. Antwort

Vorteile: reichhaltige Bedienung mit Tastatur und mehreren Fenstern, direkter Zugriff auf Dateien und Drucker, dieselbe Sprache wie das Backend. Nachteile: Sie muss installiert und bei jeder neuen Version neu verteilt werden und ist nur auf Rechnern erreichbar, auf denen sie installiert ist. siehe Abschnitt „Desktop oder Web: Wann lohnt sich eine Desktop-App?“

3. Welche Aufgaben haben View, ViewModel und API-Client in der App? Antwort

Die View (FXML und CSS) zeigt die Oberfläche, das ViewModel hält ihren Zustand in Properties und ist per Binding mit der View gekoppelt, der API-Client ist aus openapi.yaml erzeugt und ruft die REST-API in einem Hintergrund-Task auf. siehe Abschnitt „Die Architektur: JavaFX-App, REST-API und Keycloak“

4. Wie meldet sich eine Desktop-App bei Keycloak an, ohne das Passwort selbst zu sehen? Antwort

Die App öffnet den Systembrowser mit der Anmeldeseite von Keycloak; nach der Anmeldung schickt Keycloak einen Code an einen Empfänger der App auf 127.0.0.1, den die App mit PKCE gegen Tokens tauscht (RFC 8252). siehe Abschnitt „Die Architektur: JavaFX-App, REST-API und Keycloak“

5. Was bewirken WIP-Limits und das Pull-Prinzip in Kanban? Antwort

WIP-Limits begrenzen, wie viele Tickets gleichzeitig in einer Spalte sein dürfen; ist das Limit erreicht, wird erst etwas fertiggestellt, bevor Neues beginnt. Beim Pull-Prinzip zieht sich jede Person das nächste Ticket selbst, sobald sie Kapazität frei hat. siehe Abschnitt „Kanban im Überblick“

6. Welche Serviceklasse bekommt eine dringend gebrauchte Erweiterung der REST-API, und was gilt für sie? Antwort

Das ist ein Expedite-Ticket: Es darf am WIP-Limit vorbei bearbeitet werden, aber es darf immer nur ein Expedite-Ticket zur Zeit geben. siehe Abschnitt „Kanban im Überblick“

7. Warum passt Kanban besser zu dieser Reihe als feste Sprints? Antwort

Die App erweitert ein laufendes System, zu dem laufend Wünsche und eilige Anfragen kommen; Kanban nimmt sie ohne Wartezeit bis zum nächsten Sprint auf und steuert über WIP-Limits und Serviceklassen, was zuerst fertig wird. siehe Abschnitt „Kanban im Überblick“

8. Welche Artikel der Reihe gehören zu welcher Testebene? Antwort

Smoke-Test in 02, Komponententest des ViewModels in 04, Integrationstest gegen eine nachgebildete REST-API (WireMock) in 05, GUI-Systemtest mit TestFX in 10 und Abnahmetest in 11. siehe Abschnitt „Der Fahrplan: zwölf Artikel in vier Etappen“

Links und weitere Informationen

• für den Einstieg: Szenario Mitfahrlabor mit Personas und Regeln

• für den Einstieg: Ein REST-Backend mit Spring Boot: das Projekt Mitfahrlabor

• als Hintergrund: Kanban und Vorgehensmodelle im Überblick

• als Hintergrund: Das V-Modell und Teststrategie

• als Nachschlagewerk: OpenJFX, Dokumentation und Einstieg

• als Nachschlagewerk: RFC 8252: OAuth 2.0 for Native Apps

• als Nachschlagewerk: Keycloak-Dokumentation

Hinweis zur Nachnutzung als Open Educational Resource (OER)

Dieser Artikel und seine Texte, Bilder, Grafiken, Code und sonstiger Inhalt sind - sofern nicht anders angegeben - lizenziert unter CC BY 4.0. Nennung gemäß TULLU-Regel bitte wie folgt: “Eine Desktop-App mit JavaFX: das Mitfahrlabor für Fahrer*innen und Verwaltung” von oer-informatik.de (H. Stein), Lizenz: CC BY 4.0. Der Artikel wurde unter https://oer-informatik.de/javafx-mitfahrlabor-projekt veröffentlicht, die Quelltexte sind in weiterverarbeitbarer Form verfügbar im Repository unter https://gitlab.com/oer-informatik/javafx/javafx-einstieg. Erstellt mit KI-Assistenz; von mir umfassend redaktionell überarbeitet, geprüft und freigegeben. Stand: 11.11.2026.

[Kommentare zum Artikel lesen, schreiben] / [Artikel teilen] / [gitlab-Issue zum Artikel schreiben]