Android-Kotlin: Offline-First-Felddatenerfassungsmodul mit Karte, Tracks und Synchronisierung in eine bestehende Anwendung

Ausgangssituation – es gibt eine funktionierende Android-Anwendung für Außendiensttechniker (Kotlin, Android 12+, minSdk 26) mit Autorisierung und grundlegender Navigation. Derzeit werden Daten zu Besuchen und Inspektionen auf Papierformularen erfasst und dann manuell in das System eingegeben, wodurch Koordinaten, Fotos und Zeit verloren gehen. Sie müssen der Anwendung ein vollwertiges Offline-First-Modul hinzufügen – eine Aufgabe erstellen, Daten an einem Punkt sammeln, einen Track aufzeichnen, Fotos und Notizen anhängen sowie eine zuverlässige Synchronisierung mit dem Server, wenn das Netzwerk erscheint.

Technische Umgebung – Android Studio, Kotlin, Jetpack (ViewModel, Room, WorkManager), Coroutines/Flow, Hilt, Retrofit/OkHttp. Eine Karte – Mapbox SDK oder Google Maps SDK – kann ausgewählt werden, die Entscheidung muss jedoch auf den unten aufgeführten Einschränkungen basieren. Der Server existiert bereits und kann nicht geändert werden. API – REST, JSON, HTTPS, Bearer-Token. Es wird eine API-Dokumentation bereitgestellt, die jedoch keine Offline-Skripte enthält.

Was Sie erhalten sollten, ist ein Release-Modul als Teil des aktuellen Projekts, das Ihnen Folgendes ermöglicht:
1) Öffnen Sie die Aufgabenliste, laden Sie Aufgaben auf das Gerät herunter und speichern Sie sie lokal
2) Füllen Sie innerhalb der Aufgabe das Inspektionsformular mit Feldvalidierung aus und speichern Sie den Entwurf lokal ohne Netzwerk
3) Während der Abfahrt einen GPS-Track aufzeichnen und mit der Aufgabe verknüpfen – lokal speichern und auf der Karte anzeigen
4) Bis zu 10 Fotos pro Aufgabe aufnehmen, komprimieren und lokal speichern, Vorschau und Zeit-/Koordinatenbezug anzeigen
5) Synchronisieren Sie Änderungen und Anhänge über eine Warteschlange mit dem Server – mit Wiederholungsversuchen, Deduplizierung und Schutz vor Duplikaten beim erneuten Senden

Einschränkungen – Die Anwendung funktioniert auch bei schlechter Verbindung und begrenzter Leistung, daher muss bei Hintergrundaufgaben vorsichtig vorgegangen werden. Sie können außer dem Standard-Jetpack und der ausgewählten SDK-Karte keine umfangreichen Bibliotheken von Drittanbietern hinzufügen. Sie können keine ständige Geolokalisierung im Hintergrund verlangen – die Trackaufzeichnung muss im Vordergrunddienst mit Benachrichtigung korrekt funktionieren und darf beim Stoppen der Aufzeichnung keine Ressourcen beanspruchen. Die Daten sollten Anwendungsneustarts und Geräteneustarts überstehen.

Messbare Akzeptanzkriterien – Funktionalität muss auf 2 Geräten reproduzierbar sein – Android 10 und Android 14:
- Ohne Netzwerk können Sie 3 Aufgaben erstellen/bearbeiten, eine Strecke von mindestens 2 km aufzeichnen und jeweils 10 Fotos machen – nach dem Neustart der Anwendung bleibt alles an seinem Platz
- Wenn das Netzwerk erscheint, wird die Synchronisierung über WorkManager gestartet, alle Änderungen und Fotos werden geladen und nach erfolgreichem Senden werden lokale Einträge als synchronisiert markiert
- Durch die erneute Synchronisierung werden keine Duplikate auf dem Server erstellt, wenn der Versand gestartet wurde, das Netzwerk verschwunden ist und der Benutzer den Versand wiederholt hat
- Die durchschnittliche Zeit zum Öffnen eines Aufgabenbildschirms mit 10 Fotos beträgt auf einem durchschnittlichen Gerät (Pixel 4a-Stufe oder gleichwertig) nicht mehr als 2 Sekunden.
- Synchronisierungsfehler werden in einer für Menschen lesbaren Meldung angezeigt und bleiben für mindestens die letzten 50 Vorgänge im Protokoll innerhalb der Anwendung

Ausführungsphasen – Analyse der aktuellen Architektur und der Integrationspunkte, Entwurf der Raumschaltung und des Konfliktmodells, Implementierung der Benutzeroberfläche und des Speichers, Implementierung des Trackers und der Karte, Implementierung der Synchronisierungswarteschlange und der Retrays, Abdeckung wichtiger Teile mit Tests (Mindesteinheitentests für Zuordnung und Warteschlange), Endmontage und Anweisungen zum Ausführen von Abnahmeskripten.

Das Ergebnis ist eine PR oder eine Reihe von Commits in Git mit einem funktionierenden Modul, einer kurzen README-Datei zum Einrichten von Kartenschlüsseln und Testskripten, einer Liste akzeptierter Annahmen bezüglich der API und Offline-Konflikten.