Android – Implementierung des Offline-Modus mit Diff-Synchronisierung und Verschlüsselung für die Anwendung zur Feldinventur

Für die Feldinventur von Geräten in Lagerhallen und auf Baustellen gibt es eine interne Android-Anwendung. Jetzt funktioniert es nur noch online: QR-/Barcodes scannen, Karten anzeigen, Akte erstellen und Fotos machen. Standorte verfügen häufig nicht über ein Netzwerk, sodass Mitarbeiter Notizen in Notizen Dritter machen und die Daten dann manuell übertragen müssen. Wir müssen einen vollwertigen Offline-Modus mit zuverlässiger Synchronisierung hinzufügen, wenn das Internet erscheint.

Technische Umgebung: Kotlin, Android 10+, MVVM, Retrofit, Room ist bereits teilweise genutzt, die Server-API kann nicht geändert werden. Autorisierung über OAuth2, Zugriffstoken dauert 30 Minuten, Aktualisierungstoken ist verfügbar. Das Backend bietet REST-Endpunkte: GET /items?updatedSince=timestamp, POST /acts, PATCH /items/{id}, Hochladen von Fotos als separater Endpunkt. Der Server verfügt über ein Versionsfeld (int) und ein aktualisiertes At-Feld (ISO) für die Entitäten „Item“ und „Act“, auf dem Server liegt jedoch kein Lösungskonflikt vor.

Was muss umgesetzt werden:
- Lokaler Speicher: Erweitern Sie das Raumschema für Elemente, Akte, Anhänge sowie ausstehende Operationstabellen und Synchronisierungsmetadaten. Daten (einschließlich sensibler Felder und Anhangspfade) müssen verschlüsselt auf dem Gerät gespeichert werden. Es ist akzeptabel, Jetpack Security (EncryptedFile/EncryptedSharedPreferences) und/oder SQLCipher für Android zu verwenden; Begründen Sie Ihre Wahl in einem Kommentar zur PR.
- Änderungswarteschlange: Alle Offline-Benutzeraktionen sollten als idempotente Vorgänge aufgezeichnet werden (Vorgänge erstellen, Status ändern, Fotos verknüpfen, Felder bearbeiten), mit der Möglichkeit, sie ohne Duplikate erneut zu senden. Für jede Operation sind eine clientOperationId (UUID) und deterministische Regeln für die erneute Übermittlung erforderlich.
- Synchronisierung im Hintergrund: über WorkManager (Einschränkungen: Netzwerk verbunden, Batterie nicht schwach). Implementieren Sie eine bidirektionale Synchronisierung: Ziehen Sie Aktualisierungen über „updateSince“ vom Server und übertragen Sie dann lokale Vorgänge. Unterstützt Backoff, Teilfehler, Netzwerk-Timeouts und Token-Aktualisierung.
- Konfliktlösung auf dem Client: Wenn das Element lokal geändert wurde und es sich auch auf dem Server geändert hat (version/updatedAt), müssen Sie eine Strategie anwenden: Die lokale Änderung hat Priorität für einen bestimmten Satz von Feldern (Liste korrigieren), aber wenn es einen Konflikt nach Status/Verantwortlichem gibt, zeigen Sie dem Benutzer einen Vergleichsbildschirm mit der Auswahl einer Option und der Protokollierung der Lösung. Der Bildschirm sollte nur für Entitäten angezeigt werden, die tatsächlich in Konflikt stehen.
- Anhänge (Fotos): Speichern Sie Fotos lokal mit einer Download-Warteschlange und überstehen Sie Anwendungsneustarts. Einschränkung: insgesamt nicht mehr als 50 MB in der Warteschlange; Bei Überschreitung wird eine deutliche Benachrichtigung angezeigt und das Hinzufügen neuer Anhänge bis zur Synchronisierung/Löschung blockiert.
- Telemetrie: Fügen Sie ein lokales Synchronisationsprotokoll (zu einer Datei) mit Ebenen hinzu, ohne es nach außen zu senden. Das Protokoll sollte die Anzahl der Vorgänge, die Synchronisierungszeit, die Anzahl der Konflikte und API-Fehler enthalten.

Spezifisches Ergebnis: PR in ein Repository mit funktionierendem Offline-Modus, Datenbankmigrationen, Tests und kurze Anweisungen zur Überprüfung auf dem Gerät.

Einschränkungen: Ändern Sie die Server-API nicht, fügen Sie neue Bibliotheken nur bei Bedarf und mit minimalem Platzbedarf hinzu, unterstützen Sie Android 10-14, die Anwendung muss ohne Google Play Services ordnungsgemäß funktionieren.

Akzeptanzkriterien (messbar):
1) Im Flugzeugmodus können Sie: 30 Positionen scannen, mindestens 20 Felder für verschiedene Elemente ändern, 5 Akte erstellen und 10 Fotos anhängen – alle Daten werden lokal gespeichert und nach dem Neustart der Anwendung angezeigt.
2) Nach dem Einschalten des Internets ist die Synchronisierung ohne Duplikate abgeschlossen: Es erscheinen genau 5 neue Acts auf dem Server, der Artikel weist keine doppelten Änderungen auf, alle 10 Fotos sind verlinkt.
3) Im Falle eines künstlich erzeugten Konflikts (Element wird nach dem letzten Pull auf dem Server geändert, und dasselbe Element wird lokal geändert), erkennt die Anwendung den Konflikt und zeigt einen Vergleichsbildschirm an; Nachdem der Benutzer ausgewählt hat, dass das Ergebnis mit der ausgewählten Version übereinstimmt, verschwindet der Konflikt mit der nächsten Synchronisierung.
4) Die Hintergrundsynchronisierung über WorkManager wird höchstens alle 15 Minuten durchgeführt, aber der manuelle Start über den Einstellungsbildschirm initiiert die Synchronisierung sofort.
5) Lokale Daten sind wirklich verschlüsselt: Es ist unmöglich, den Inhalt der Datenbank/Anhangsdateien im Klartext zu lesen, wenn sie vom Gerät kopiert werden (es reicht aus, die Überprüfungsmethode anzugeben).

Erwartete Phasen: Prüfung der aktuellen Architektur und des Datenschemas, Entwurf eines Synchronisierungs- und Konfliktmodells, Implementierung von Speicher/Warteschlange, Implementierung der Synchronisierungs-Engine, UI-Konflikte, Tests und Stabilisierung.

Ich biete Zugriff auf: Android-Quellen, Swagger/Request-Sammlung, API-Testbank, mehrere Testkonten und Feldbenutzerszenarien.