Android-Kotlin : module de collecte de données de terrain hors ligne avec carte, traces et synchronisation dans une application existante

Situation initiale - il existe une application Android fonctionnelle pour les ingénieurs de terrain (Kotlin, Android 12+, minSdk 26) avec autorisation et navigation de base. Actuellement, les données sur les visites et les inspections sont enregistrées sur des formulaires papier puis saisies manuellement dans le système, ce qui entraîne une perte de coordonnées, de photos et de temps. Vous devez ajouter un module hors ligne à part entière à l'application - créer une tâche, collecter des données à un moment donné, enregistrer une piste, joindre des photos et des notes, ainsi qu'une synchronisation fiable avec le serveur lorsque le réseau apparaît.

Environnement technique - Android Studio, Kotlin, Jetpack (ViewModel, Room, WorkManager), Coroutines/Flow, Hilt, Retrofit/OkHttp. Une carte - Mapbox SDK ou Google Maps SDK - peut être choisie, mais la décision doit être basée sur les restrictions ci-dessous. Le serveur existe déjà et ne peut pas être modifié. API - REST, JSON, HTTPS, jeton Bearer. La documentation de l'API sera fournie, mais n'inclut pas les scripts hors ligne.

Ce que vous devriez obtenir, c'est un module de version dans le cadre du projet en cours, qui vous permet de :
1) Ouvrez la liste des tâches, téléchargez les tâches sur l'appareil et stockez-les localement
2) A l'intérieur de la tâche, remplissez le formulaire d'inspection avec validation sur le terrain, enregistrez le brouillon localement sans réseau
3) Enregistrez une trace GPS pendant le départ et associez-la à la tâche - stockez-la localement et affichez-la sur la carte
4) Prenez jusqu'à 10 photos par tâche, compressez et enregistrez localement, affichez l'aperçu et la référence à l'heure/aux coordonnées
5) Synchronisez les modifications et les pièces jointes sur le serveur via une file d'attente - avec tentatives, déduplication et protection contre les doublons lors du renvoi

Limitations - L'application fonctionne dans des conditions de mauvaise connexion et de puissance limitée, les tâches en arrière-plan doivent donc être prudentes. Vous ne pouvez pas ajouter de bibliothèques tierces lourdes autres que le Jetpack standard et la carte SDK sélectionnée. Vous ne pouvez pas exiger une géolocalisation constante en arrière-plan - l'enregistrement des pistes doit fonctionner correctement dans le service de premier plan avec notification, et lorsque l'enregistrement s'arrête, il ne doit pas retenir les ressources. Les données doivent survivre aux redémarrages des applications et des appareils.

Critères d'acceptation mesurables - la fonctionnalité doit être reproductible sur 2 appareils - Android 10 et Android 14 :
- Sans réseau, vous pouvez créer/éditer 3 tâches, enregistrer une trace d'au moins 2 km et prendre 10 photos pour chacune - après avoir redémarré l'application tout reste en place
- Lorsque le réseau apparaît, la synchronisation est lancée via WorkManager, toutes les modifications et photos sont chargées, et après un envoi réussi, les entrées locales sont marquées synchronisées
- La resynchronisation ne crée pas de doublons sur le serveur dans le scénario - l'envoi a démarré, le réseau a disparu, l'utilisateur a répété l'envoi
- Le temps moyen d'ouverture d'un écran de tâches avec 10 photos n'est pas supérieur à 2 secondes sur un appareil moyen (niveau Pixel 4a ou équivalent)
- Les erreurs de synchronisation sont affichées dans un message lisible par l'homme et restent dans le journal de l'application pendant au moins les 50 dernières opérations

Étapes d'exécution - analyse de l'architecture actuelle et des points d'intégration, conception du circuit de la salle et du modèle de conflit, implémentation de l'interface utilisateur et du stockage, implémentation du tracker et de la carte, implémentation de la file d'attente de synchronisation et des retrays, couvrant les parties clés avec des tests (tests unitaires minimum pour le mappage et la file d'attente), assemblage final et instructions sur la façon d'exécuter les scripts d'acceptation.

Le résultat est un PR ou un ensemble de commits dans Git avec un module de travail, un court README sur la configuration des clés de carte et des scripts de test, une liste d'hypothèses acceptées concernant l'API et les conflits hors ligne.