Cache și sincronizarea datelor în dezvoltarea mobilă: ce este, ce strategii și cum funcționează

Gestionarea Datelor în Aplicații Mobile: Modelul Repository și Data Source

Modelul Repository este o abordare arhitecturală în care o singură clasă de depozit gestionează toate operațiile cu date, abstractizând API-urile REST la distanță și stocarea locală Room sau SwiftData. Acest mod de gestionare a datelor permite aplicației să obțină informații mai întâi din Memory Cache sau Disk Cache, apoi din rețea, reducând timpul de răspuns. În dezvoltarea mobilă, Repository a devenit standardul de facto datorită recomandărilor Google și Apple.

Remote Data Source și Local Data Source

Remote Data Source furnizează informații actualizate de la server prin cereri HTTP. Local Data Source este stocarea locală pe dispozitiv, implementată prin Room pe Android sau SwiftData pe iOS. Depozitul combină ambele surse: mai întâi verifică cache-ul local, iar în absența datelor, solicită de la API-ul la distanță. Această organizare a gestionării datelor permite aplicației să funcționeze în modul offline și reduce încărcarea serverului.

Exemplu de Repository în Kotlin

class UserRepository(
    private val remoteDataSource: UserRemoteDataSource,
    private val localDataSource: UserLocalDataSource
) {
    suspend fun getUsers(): List<User> {
        localDataSource.getCachedUsers()?.let { return it }
        val users = remoteDataSource.fetchUsers()
        localDataSource.cacheUsers(users)
        return users
    }
}

Exemplu de Repository în Swift

class UserRepository {
    private let remote: UserRemoteDataSource
    private let local: UserLocalDataSource
    
    func getUsers() async throws -> [User] {
        if let cached = await local.getCached() { return cached }
        let users = try await remote.fetch()
        await local.save(users)
        return users
    }
}

Stocarea în Cache a Datelor: LRU Cache, Disk Cache și Memory Cache

LRU Cache (Least Recently Used) este un algoritm de stocare în cache în care, când limita este atinsă, elementul care nu a fost accesat de cel mai mult timp este eliminat. În aplicațiile mobile, LRU Cache este utilizat pentru imagini, răspunsuri API și obiecte serializate. Stocarea corectă în cache a datelor reduce numărul de cereri de rețea și accelerează încărcarea conținutului. Cache-ul în aplicațiile mobile este o componentă esențială pentru performanță ridicată.

Memory Cache vs Disk Cache

Memory Cache stochează date în RAM — accesul este extrem de rapid, dar capacitatea este limitată de dimensiunea heap-ului aplicației. Disk Cache salvează informații pe sistemul de fișiere — mai lent, dar poate stoca mai mult și persistă între sesiuni. Strategia optimă în dezvoltarea mobilă este un cache pe două niveluri: Memory Cache pentru date fierbinți și Disk Cache pentru date reci. La gestionarea datelor, cache-ul de prim nivel din memorie este verificat mai întâi, urmat de cache-ul de al doilea nivel pe disc.

Exemplu de Implementare LRU Cache

class MemoryCache<K, V>(
    private val maxSize: Int = 100
) {
    private val cache = LinkedHashMap<K, V>(0, 0.75f, true)

    fun get(key: K): V? = cache[key]

    fun put(key: K, value: V) {
        if (cache.size >= maxSize) {
            cache.remove(cache.keys.first())
        }
        cache[key] = value
    }
}

Strategii de Invalidare a Cache-ului

Cache-ul TTL (Time To Live) elimină automat o intrare după un interval de timp specificat — potrivit pentru date API. Invalidarea bazată pe evenimente curăță cache-ul la primirea unei notificări push despre modificări. În aplicațiile mobile, alegerea strategiei de stocare în cache depinde de tipul de date: imaginile sunt stocate în cache mult timp, în timp ce un flux de știri necesită invalidare frecventă. Coil pe Android și Kingfisher pe iOS au integrat deja LRU Cache pentru lucrul cu imagini.

Coada Offline: Offline Queue și Sync Manager

Offline Queue este o structură de date care stochează operațiile utilizatorului (creare, actualizare, ștergere) într-o bază de date locală când dispozitivul este offline. Când conexiunea este restabilită, Sync Manager aplică secvențial aceste operații serverului. Acest tip de sincronizare a datelor asigură că nicio modificare nu se pierde în timpul unei pierderi temporare de rețea. În dezvoltarea mobilă, Offline Queue este o componentă critică pentru aplicațiile cu conexiuni instabile.

Arhitectura Offline Queue

Coada este construită pe un tabel în Room sau SwiftData cu câmpuri: tipul operației, corpul cererii JSON, timestamp și stare. Sync Manager este un serviciu de fundal care procesează operațiile în așteptare, le trimite la server, actualizează starea și elimină intrările reușite. Sincronizarea datelor prin WorkManager pe Android sau BGTaskScheduler pe iOS continuă chiar și după repornirea dispozitivului. Utilizarea Offline Queue împreună cu o gestionare corectă a datelor asigură o experiență de utilizare fără întreruperi.

Exemplu de Offline Queue în Kotlin

@Entity
data class SyncOperation(
    @PrimaryKey val id: Long,
    val endpoint: String,
    val method: String,
    val body: String,
    val createdAt: Long
)

class SyncManager(
    private val dao: SyncOperationDao,
    private val api: ApiService
) {
    suspend fun syncPending() {
        dao.getPendingOperations().forEach { op ->
            try {
                api.execute(op.endpoint, op.method, op.body)
                dao.delete(op.id)
            } catch (e: Exception) {
                // retry on next cycle
            }
        }
    }
}

Politica de Reîncercare și Timeout-uri

Backoff exponențial între reîncercări (1s, 2s, 4s, 8s) protejează serverul de suprasarcină și previne reîncercările infinite. Limita de 5 încercări previne depășirea cozii. Sincronizarea datelor în aplicațiile mobile cu suport pentru idempotență pe partea de server permite reîncercări sigure, evitând duplicatele. Acest lucru este deosebit de important pentru tranzacțiile financiare și comenzi.

Sincronizarea Datelor: Conflict Resolution și Schema Migration

Conflict Resolution este un set de strategii pentru situațiile în care aceleași date sunt modificate pe dispozitive diferite simultan. Sincronizarea de bază a datelor necesită alegerea unei abordări: Last-Write-Wins (ultima scriere câștigă), versionare (versiunea mai mare câștigă) sau rezolvare manuală. În scenarii complexe, se utilizează CRDT (Conflict-Free Replicated Data Types), care garantează convergența matematică a datelor.

Strategii de Rezolvare a Conflictelor

Last-Write-Wins este cel mai simplu de implementat, dar poate pierde modificările utilizatorului. Version Vector — fiecare înregistrare stochează un număr de versiune și un identificator de dispozitiv; un conflict apare când versiunile nu se potrivesc. CRDT este cea mai fiabilă, dar complexă strategie: datele converg matematic către o singură stare fără un coordonator centralizat. Sincronizarea datelor în aplicațiile mobile bazată pe CRDT este utilizată în editarea colaborativă în Google Docs și sincronizarea notelor în Notion.

Schema Migration: Actualizarea Sigură a Bazei de Date

Când o aplicație este actualizată, structura bazei de date locale se schimbă: se adaugă coloane, tabele, indexuri. Schema Migration este procesul de transformare a unei baze de date existente la o nouă schemă fără pierdere de date. Room suportă migrări prin clasa Migration cu versiunea veche și nouă. SwiftData utilizează VersionedSchema pentru a descrie modificările. Sincronizarea corectă a datelor între versiunile aplicației necesită ca migrările să fie testate idempotent.

Exemplu de Schema Migration în Room

val migration1to2 = object : Migration(1, 2) {
    override fun migrate(database: SupportSQLiteDatabase) {
        database.execSQL("ALTER TABLE users ADD COLUMN avatar_url TEXT")
    }
}

@Database(
    entities = [User::class],
    version = 2
)
abstract class AppDatabase : RoomDatabase() {
    abstract fun userDao(): UserDao
}

Exemplu de Conflict Resolution în Swift

enum ConflictStrategy {
    case lastWriteWins
    case versionVector
    case crdt
}

struct VersionedDocument {
    let id: String
    let version: Int
    let data: Data
    let editedBy: String
    
    func resolve(with remote: VersionedDocument) -> VersionedDocument {
        return version >= remote.version ? self : remote
    }
}

Room și SwiftData pentru Stocare Locală

Room este o bibliotecă Google pentru stocare locală pe Android, construită pe SQLite și care oferă adnotări pentru descrieri declarative de interogări. SwiftData este un framework Apple pentru iOS, macOS, watchOS și visionOS, succesorul Core Data cu o sintaxă concisă Swift Macro. Ambele instrumente rezolvă sarcina de gestionare a datelor pe dispozitiv, dar cu abordări diferite pentru organizarea codului. Cache-ul în aplicațiile mobile este adesea construit pe aceste tehnologii.

Room: DAO, Entities și Type Converters

Room utilizează adnotări @Entity pentru tabele și @Dao pentru interogări. DAO încapsulează toate operațiile SQL cu verificare la compilare — erorile de sintaxă SQL sunt detectate înainte de execuție. Type Converter convertește tipurile complexe (Date, List) în primitive SQLite. Gestionarea modernă a datelor în aplicațiile Android este construită în jurul Room + Flow, oferind actualizări reactive ale interfeței când cache-ul sau baza de date locală se modifică.

SwiftData: @Model și @Query

SwiftData utilizează macro-ul @Model pentru a defini entități și @Query pentru a observa datele. Framework-ul urmărește automat dependențele și actualizează interfața la modificări. Migrarea schemei utilizează VersionedSchema care descrie toate versiunile. Sincronizarea datelor între SwiftData și server este implementată printr-un Sync Manager personalizat abonat la actualizări prin @Query.

Exemplu de Model în SwiftData

@Model
final class UserModel {
    var id: String
    var name: String
    var email: String
    var updatedAt: Date
    
    init(id: String, name: String, email: String) {
        self.id = id
        self.name = name
        self.email = email
        self.updatedAt = Date()
    }
}

Comparație Room vs SwiftData