Situația inițială - există o aplicație Android funcțională pentru inginerii de teren (Kotlin, Android 12+, minSdk 26) cu autorizare și navigare de bază. În prezent, datele privind vizitele și inspecțiile sunt înregistrate pe formulare de hârtie și apoi introduse manual în sistem, motiv pentru care se pierd coordonatele, fotografiile și timpul. Trebuie să adăugați un modul offline cu drepturi depline la aplicație - crearea unei sarcini, colectarea datelor la un moment dat, înregistrarea unei piese, atașarea fotografiilor și a notelor, precum și sincronizarea fiabilă la server atunci când apare rețeaua. Mediu tehnic - Android Studio, Kotlin, Jetpack (ViewModel, Room, WorkManager), Coroutines/Flow, Hilt, Retrofit/OkHttp. O hartă - Mapbox SDK sau Google Maps SDK - poate fi aleasă, dar decizia trebuie să se bazeze pe restricțiile de mai jos. Serverul există deja și nu poate fi schimbat. API - REST, JSON, HTTPS, simbol purtător. Documentația API va fi furnizată, dar nu include scripturi offline. Ceea ce ar trebui să obțineți este un modul de lansare ca parte a proiectului actual, care vă permite să: 1) Deschideți lista de sarcini, descărcați sarcini pe dispozitiv și stocați local 2) În interiorul sarcinii, completați formularul de inspecție cu validare pe teren, salvați proiectul local fără rețea 3) Înregistrați un traseu GPS în timpul plecării și legați-l la sarcină - stocați-l local și afișați-l pe hartă 4) Faceți până la 10 fotografii per sarcină, comprimați și salvați local, afișați previzualizarea și referința la timp/coordonate 5) Sincronizați modificările și atașamentele la server printr-o coadă - cu reîncercări, deduplicare și protecție împotriva duplicatelor la retrimitere Limitări - Aplicația funcționează în condiții de conexiune slabă și putere limitată, așa că sarcinile de fundal trebuie să fie atent. Nu puteți adăuga biblioteci grele terțe, altele decât Jetpack standard și cardul SDK selectat. Nu puteți solicita geolocalizare constantă în fundal - înregistrarea piesei trebuie să funcționeze corect în serviciul de prim-plan cu notificare, iar atunci când înregistrarea se oprește, nu trebuie să rețină resurse. Datele ar trebui să supraviețuiască repornirilor aplicației și repornirilor dispozitivului. Criterii de acceptare măsurabile - funcționalitatea trebuie să fie reproductibilă pe 2 dispozitive - Android 10 și Android 14: - Fără o rețea, puteți crea/editați 3 sarcini, înregistrați un traseu de cel puțin 2 km și faceți 10 fotografii pentru fiecare - după repornirea aplicației totul rămâne pe loc - Când apare rețeaua, sincronizarea este lansată prin WorkManager, toate modificările și fotografiile sunt încărcate, iar după trimiterea cu succes, intrările locale sunt marcate sincronizate - Resincronizarea nu creează duplicate pe server în scenariu - trimiterea a început, rețeaua a dispărut, utilizatorul a repetat trimiterea - Timpul mediu pentru a deschide un ecran de activitate cu 10 fotografii nu este mai mare de 2 secunde pe un dispozitiv mediu (nivel Pixel 4a sau echivalent) - Erorile de sincronizare sunt afișate într-un mesaj care poate fi citit de om și rămân în jurnalul în interiorul aplicației pentru cel puțin ultimele 50 de operațiuni Etape de execuție - analiza arhitecturii curente și a punctelor de integrare, proiectarea circuitului și modelului de conflict Room, implementarea interfeței de utilizare și stocare, implementarea trackerului și hărții, implementarea cozii de sincronizare și retrayuri, acoperirea părților cheie cu teste (testuri unitare minime pentru mapare și coadă), asamblare finală și instrucțiuni privind rularea scripturilor de acceptare. Rezultatul este un PR sau un set de commit-uri în Git cu un modul de lucru, un scurt README despre configurarea cheilor de hărți și a scripturilor de testare, o listă de ipoteze acceptate privind API-ul și conflictele offline.