Neuigkeiten

Die Entwicklung der Transporter-App: mobile Transportabläufe mit konsequentem Offline-Betrieb

Wenn die Verbindung unzuverlässig ist und Fahrer unter Zeitdruck stehen, darf eine mobile App nicht auf eine Serverantwort warten müssen. So haben wir Transporter entwickelt — eine robuste C#-Anwendung für den mobilen Einsatz auf Zebra-Geräten, die unter allen Bedingungen weiterarbeitet.

Die Entwicklung der Transporter-App: mobile Transportabläufe mit konsequentem Offline-Betrieb

Als TST Terschelling uns beauftragte, den papierbasierten Arbeitsablauf seiner Fahrer abzulösen, war die Aufgabenstellung klar: schneller, digital und zuverlässig sollte er werden. Daraus entstand eines der technisch anspruchsvollsten Projekte, die wir bisher umgesetzt haben.

Die Vorgabe, die alles bestimmte

Auf den Watteninseln ist die Mobilfunkabdeckung lückenhaft. Die Fähren verkehren zweimal täglich. Ein Fahrer, der um 6 Uhr morgens am Hafen Waren verlädt, kann nicht nach jedem gescannten Barcode auf die Antwort des Servers warten. Die App musste vollständig offline funktionieren — als regulärer Betriebsmodus, nicht nur als Notlösung.

Diese eine Vorgabe beeinflusste jede unserer Architekturentscheidungen.

Was Transporter leistet

Transporter begleitet die Fahrer durch ihren gesamten Arbeitstag. Die App unterstützt:

  • Fahreranmeldung und Tourenzuweisung
  • Lkw-Beladung mit Barcode-Scanning und Mengenprüfung
  • Die Auslieferung von Stopp zu Stopp, einschließlich der Behandlung von Sonderfällen
  • Digitale Zustellnachweise mit Unterschriftenerfassung
  • Den Tourenabschluss am Tagesende und die Synchronisierung mit dem Backend

Jede Aktion wird zuerst lokal ausgeführt. Das Gerät speichert den Zustand, reiht Ereignisse in eine Warteschlange ein und synchronisiert sie, sobald eine Verbindung verfügbar ist. Kein entscheidender Arbeitsschritt wird durch eine Netzwerkanfrage blockiert.

Die technische Grundlage

Wir haben Transporter als native C#-Anwendung für Zebra-Android-Geräte entwickelt. Zebra-Handhelds sind der Branchenstandard für das Scanning in Lager und Logistik: Sie überstehen Stürze, Staub, Temperaturschwankungen und den Dauereinsatz über viele Schichten hinweg. Ihre integrierten Barcodescanner sind um eine Größenordnung schneller als kamerabasiertes Scanning auf handelsüblichen Smartphones.

Das Backend besteht aus einer REST-API in PHP mit einer MySQL-Datenbank. Der Zustandsabgleich erfolgt über ein Synchronisierungsmodell auf Basis von Event Sourcing: Das Gerät führt ein Protokoll aller Vorgänge, der Server wendet sie der Reihe nach an, und Konflikte werden nach eindeutigen Regeln aufgelöst. Im entscheidenden Moment sieht der Fahrer niemals eine Ladeanzeige.

Was wir gelernt haben

Ein konsequenter Offline-Ansatz klingt einfach, bis man ihn verlässlich umsetzen muss. Jeder Sonderfall, der in einer ständig verbundenen App trivial wäre, wird zu einer Entwurfsfrage: Was passiert, wenn ein Fahrer denselben Artikel zweimal auf unterschiedlichen Geräten scannt? Was, wenn die Tourendaten auf dem Server seit der letzten Synchronisierung geändert wurden? Was, wenn die Geräteuhr falsch geht?

Wir haben viel Zeit in das Synchronisierungsprotokoll und die Rückmeldungen der Benutzeroberfläche investiert. Der Fahrer muss jederzeit wissen, welcher Stand seiner Tour maßgeblich ist — selbst wenn dieser zuletzt vor drei Stunden während einer Fährüberfahrt aktualisiert wurde.

Das Ergebnis ist eine App, die seit ihrer Einführung täglich Touren begleitet, ohne dass ein einziger Fehler bei der Datenintegrität aufgetreten ist.

Das Ergebnis

TST Terschelling hat einen jahrelang genutzten Ablauf mit Klemmbrett und Papier abgelöst. Die Beladezeit pro Lkw sank deutlich. Streitfälle rund um Zustellnachweise entfielen, weil zu jeder Lieferung nun ein digitaler Nachweis mit Zeitstempel und Unterschrift vorliegt. Und das Dispositionsteam kann den Tourenfortschritt im Büro live verfolgen, statt auf Anrufe der Fahrer warten zu müssen.

Solche Projekte erinnern uns daran, wofür Software da ist: Sie soll wichtige Arbeit erleichtern.

Zurück zu den Neuigkeiten

Mehr

Ähnliche Beiträge

01.11.2025

Die Entwicklung von DataBridge: 20 eigenständige 4D-Systeme mit einem zentralen MySQL-Backend synchronisieren

Wir entwickeln unsere DataBridge-Schicht derzeit weiter: eine Synchronisierungs-Engine, die rund 20 unabhängige 4D-Installationen mit einem zentralen MySQL-Backend für die Website und zugehörige Onlinedienste verbindet. Die Herausforderung besteht nicht einfach darin, Daten von A nach B zu übertragen. Entscheidend ist, dies sicher, wiederholbar und vorhersehbar im laufenden Produktionsbetrieb zu tun: während Anwender arbeiten, Datensätze sich ändern, Verbindungen abbrechen können und kein einzelner Rechner Unordnung in das Gesamtsystem bringen darf.

Möchten Sie mit uns zusammenarbeiten?

Nehmen Sie Kontakt mit uns auf, damit wir Ihr Projekt besprechen können.