Cache et synchronisation des données dans le développement mobile : ce que c'est, quelles stratégies et comment ça marche

Gestion des Données dans les Applications Mobiles : Modèle Repository et Data Source

Le modèle Repository est une approche architecturale où une seule classe de référentiel gère toutes les opérations de données, en abstrayant les API REST distantes et le stockage local Room ou SwiftData. Cette façon de gérer les données permet à l'application de récupérer d'abord les informations depuis Memory Cache ou Disk Cache, puis depuis le réseau, réduisant ainsi le temps de réponse. Dans le développement mobile, Repository est devenu le standard de facto grâce aux recommandations de Google et Apple.

Remote Data Source et Local Data Source

Remote Data Source fournit des informations à jour depuis le serveur via des requêtes HTTP. Local Data Source est le stockage local sur l'appareil, implémenté via Room sur Android ou SwiftData sur iOS. Le référentiel combine les deux sources : il vérifie d'abord le cache local, et en l'absence de données, demande à l'API distante. Cette organisation de la gestion des données permet à l'application de fonctionner en mode hors ligne et réduit la charge du serveur.

Exemple de Repository en 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
    }
}

Exemple de Repository en 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
    }
}

Mise en Cache des Données : LRU Cache, Disk Cache et Memory Cache

LRU Cache (Least Recently Used) est un algorithme de mise en cache où, lorsque la limite est atteinte, l'élément qui n'a pas été accédé depuis le plus longtemps est supprimé. Dans les applications mobiles, LRU Cache est utilisé pour les images, les réponses API et les objets sérialisés. Une mise en cache appropriée des données réduit le nombre de requêtes réseau et accélère le chargement du contenu. Le cache dans les applications mobiles est un composant essentiel pour des performances élevées.

Memory Cache vs Disk Cache

Memory Cache stocke les données dans la RAM — l'accès est extrêmement rapide, mais la capacité est limitée par la taille du tas de l'application. Disk Cache sauvegarde les informations sur le système de fichiers — plus lent mais peut contenir plus et persiste entre les sessions. La stratégie optimale dans le développement mobile est un cache à deux niveaux : Memory Cache pour les données chaudes et Disk Cache pour les données froides. Lors de la gestion des données, le cache de premier niveau en mémoire est vérifié en premier, suivi du cache de second niveau sur le disque.

Exemple d'Implémentation de 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
    }
}

Stratégies d'Invalidation du Cache

Le cache TTL (Time To Live) supprime automatiquement une entrée après un intervalle de temps spécifié — adapté aux données API. L'invalidation basée sur les événements vide le cache lors de la réception d'une notification push concernant des modifications. Dans les applications mobiles, le choix de la stratégie de mise en cache dépend du type de données : les images sont mises en cache longtemps, tandis qu'un fil d'actualités nécessite une invalidation fréquente. Coil sur Android et Kingfisher sur iOS ont déjà intégré LRU Cache pour travailler avec les images.

File d'Attente Hors Ligne : Offline Queue et Sync Manager

Offline Queue est une structure de données qui stocke les opérations utilisateur (création, mise à jour, suppression) dans une base de données locale lorsque l'appareil est hors ligne. Lorsque la connexion est rétablie, le Sync Manager applique séquentiellement ces opérations au serveur. Ce type de synchronisation des données garantit qu'aucune modification n'est perdue lors d'une perte de réseau temporaire. Dans le développement mobile, Offline Queue est un composant critique pour les applications avec des connexions instables.

Architecture de la Offline Queue

La file d'attente est construite sur une table dans Room ou SwiftData avec des champs : type d'opération, corps de la requête JSON, horodatage et statut. Sync Manager est un service d'arrière-plan qui traite les opérations en attente, les envoie au serveur, met à jour le statut et supprime les entrées réussies. La synchronisation des données via WorkManager sur Android ou BGTaskScheduler sur iOS se poursuit même après le redémarrage de l'appareil. L'utilisation d'Offline Queue avec une gestion appropriée des données garantit une expérience utilisateur fluide.

Exemple de Offline Queue en 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
            }
        }
    }
}

Politique de Tentatives et Délais d'Attente

Backoff exponentiel entre les tentatives (1s, 2s, 4s, 8s) protège le serveur contre les surcharges soudaines et évite les tentatives infinies. La limite de 5 tentatives empêche le débordement de la file d'attente. La synchronisation des données dans les applications mobiles avec prise en charge de l'idempotence côté serveur permet des tentatives sécurisées, évitant les doublons. Ceci est particulièrement important pour les transactions financières et les commandes.

Synchronisation des Données : Conflict Resolution et Schema Migration

Conflict Resolution est un ensemble de stratégies pour les situations où les mêmes données sont modifiées sur différents appareils simultanément. La synchronisation de base des données nécessite le choix d'une approche : Last-Write-Wins (la dernière écriture gagne), le versionnage (la version la plus élevée gagne) ou la résolution manuelle. Dans les scénarios complexes, les CRDT (Conflict-Free Replicated Data Types) sont utilisés, garantissant la convergence mathématique des données.

Stratégies de Résolution des Conflits

Last-Write-Wins est la plus simple à implémenter mais peut perdre les modifications de l'utilisateur. Version Vector — chaque enregistrement stocke un numéro de version et un identifiant d'appareil ; un conflit survient lorsque les versions ne correspondent pas. CRDT est la stratégie la plus fiable mais complexe : les données convergent mathématiquement vers un état unique sans coordinateur centralisé. La synchronisation des données dans les applications mobiles basée sur CRDT est utilisée dans l'édition collaborative dans Google Docs et la synchronisation de notes dans Notion.

Schema Migration : Mise à Jour Sécurisée de la Base de Données

Lorsqu'une application est mise à jour, la structure de la base de données locale change : des colonnes, des tables, des index sont ajoutés. Schema Migration est le processus de transformation d'une base de données existante vers un nouveau schéma sans perte de données. Room prend en charge les migrations via la classe Migration avec les versions ancienne et nouvelle. SwiftData utilise VersionedSchema pour décrire les changements. Une synchronisation appropriée des données entre les versions de l'application nécessite que les migrations soient testées de manière idempotente.

Exemple de Schema Migration dans 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
}

Exemple de Conflict Resolution en 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 et SwiftData pour le Stockage Local

Room est une bibliothèque Google pour le stockage local sur Android, construite sur SQLite et fournissant des annotations pour des descriptions de requêtes déclaratives. SwiftData est un framework Apple pour iOS, macOS, watchOS et visionOS, successeur de Core Data avec une syntaxe concise de Swift Macro. Les deux outils résolvent la tâche de gestion des données sur l'appareil, mais avec des approches différentes pour l'organisation du code. Le cache dans les applications mobiles est souvent construit précisément sur ces technologies.

Room : DAO, Entities et Type Converters

Room utilise les annotations @Entity pour les tables et @Dao pour les requêtes. DAO encapsule toutes les opérations SQL avec une vérification à la compilation — les erreurs de syntaxe SQL sont détectées avant l'exécution. Type Converter convertit les types complexes (Date, List) en primitifs SQLite. La gestion moderne des données dans les applications Android est construite autour de Room + Flow, fournissant des mises à jour réactives de l'interface lorsque le cache ou la base de données locale change.

SwiftData : @Model et @Query

SwiftData utilise la macro @Model pour définir les entités et @Query pour observer les données. Le framework suit automatiquement les dépendances et met à jour l'interface lors des changements. La migration de schéma utilise VersionedSchema décrivant toutes les versions. La synchronisation des données entre SwiftData et le serveur est implémentée via un Sync Manager personnalisé abonné aux mises à jour via @Query.

Exemple de Modèle en 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()
    }
}

Comparaison Room vs SwiftData