Cache e sincronização de dados no desenvolvimento móvel: o que é, quais estratégias e como funciona

Manipulação de Dados em Aplicativos Móveis: Padrão Repository e Data Source

O padrão Repository é uma abordagem arquitetônica onde uma única classe de repositório gerencia todas as operações de dados, abstraindo APIs REST remotas e armazenamento local Room ou SwiftData. Esta forma de manipular dados permite que o aplicativo obtenha informações primeiro do Memory Cache ou Disk Cache, e depois da rede, reduzindo o tempo de resposta. No desenvolvimento móvel, o Repository tornou-se o padrão de fato graças às recomendações do Google e da Apple.

Remote Data Source e Local Data Source

O Remote Data Source fornece informações atualizadas do servidor por meio de solicitações HTTP. Local Data Source é o armazenamento local no dispositivo, implementado via Room no Android ou SwiftData no iOS. O repositório combina ambas as fontes: primeiro verifica o cache local e, quando não há dados, solicita da API remota. Esta organização de manipulação de dados permite que o aplicativo funcione em modo offline e reduz a carga do servidor.

Exemplo de Repository em 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
    }
}

Exemplo de Repository em 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
    }
}

Cache de Dados: LRU Cache, Disk Cache e Memory Cache

LRU Cache (Least Recently Used) é um algoritmo de cache onde, quando o limite é atingido, o elemento que não foi acessado por mais tempo é removido. Em aplicativos móveis, o LRU Cache é usado para imagens, respostas de API e objetos serializados. O cache adequado de dados reduz o número de solicitações de rede e acelera o carregamento de conteúdo. O cache em aplicativos móveis é um componente essencial para alto desempenho.

Memory Cache vs Disk Cache

O Memory Cache armazena dados na RAM — o acesso é extremamente rápido, mas a capacidade é limitada pelo tamanho do heap do aplicativo. Disk Cache salva informações no sistema de arquivos — é mais lento, mas pode armazenar mais e persiste entre sessões. A estratégia ideal no desenvolvimento móvel é um cache de dois níveis: Memory Cache para dados quentes e Disk Cache para dados frios. Ao manipular dados, o cache de primeiro nível na memória é verificado primeiro, seguido pelo cache de segundo nível no disco.

Exemplo de Implementação 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
    }
}

Estratégias de Invalidação de Cache

O cache TTL (Time To Live) remove automaticamente uma entrada após um intervalo de tempo especificado — adequado para dados de API. Invalidação baseada em eventos limpa o cache ao receber uma notificação push sobre alterações. Em aplicativos móveis, a escolha da estratégia de cache depende do tipo de dados: imagens são armazenadas em cache por muito tempo, enquanto um feed de notícias requer invalidação frequente. O Coil no Android e o Kingfisher no iOS já incorporaram LRU Cache para trabalhar com imagens.

Fila Offline: Offline Queue e Sync Manager

Offline Queue é uma estrutura de dados que armazena operações do usuário (criar, atualizar, excluir) em um banco de dados local quando o dispositivo está offline. Quando a conexão é restaurada, o Sync Manager aplica sequencialmente essas operações ao servidor. Este tipo de sincronização de dados garante que nenhuma alteração seja perdida durante uma perda temporária de rede. No desenvolvimento móvel, a Offline Queue é um componente crítico para aplicativos com conexões instáveis.

Arquitetura da Offline Queue

A fila é construída sobre uma tabela em Room ou SwiftData com campos: tipo de operação, corpo da solicitação JSON, timestamp e status. Sync Manager é um serviço em segundo plano que processa operações pendentes, as envia ao servidor, atualiza o status e remove entradas bem-sucedidas. A sincronização de dados via WorkManager no Android ou BGTaskScheduler no iOS continua mesmo após a reinicialização do dispositivo. Usar Offline Queue junto com a manipulação adequada de dados garante uma experiência de usuário perfeita.

Exemplo de Offline Queue em 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
            }
        }
    }
}

Política de Tentativas e Timeouts

Backoff exponencial entre tentativas (1s, 2s, 4s, 8s) protege o servidor de sobrecarga e evita tentativas infinitas. O limite de 5 tentativas evita o transbordamento da fila. A sincronização de dados em aplicativos móveis com suporte a idempotência no servidor permite tentativas seguras, evitando duplicatas. Isso é especialmente importante para transações financeiras e pedidos.

Sincronização de Dados: Conflict Resolution e Schema Migration

Conflict Resolution é um conjunto de estratégias para situações onde os mesmos dados são modificados em diferentes dispositivos simultaneamente. A sincronização básica de dados requer a escolha de uma abordagem: Last-Write-Wins (a última gravação vence), versionamento (versão mais alta vence) ou resolução manual. Em cenários complexos, são usados CRDT (Conflict-Free Replicated Data Types), que garantem a convergência matemática dos dados.

Estratégias de Resolução de Conflitos

Last-Write-Wins é a mais simples de implementar, mas pode perder alterações do usuário. Version Vector — cada registro armazena um número de versão e identificador do dispositivo; um conflito surge quando as versões não coincidem. CRDT é a estratégia mais confiável, porém complexa: os dados convergem matematicamente para um estado único sem um coordenador centralizado. A sincronização de dados em aplicativos móveis baseada em CRDT é usada na edição colaborativa no Google Docs e na sincronização de notas no Notion.

Schema Migration: Atualização Segura do Banco de Dados

Quando um aplicativo é atualizado, a estrutura do banco de dados local muda: colunas, tabelas, índices são adicionados. Schema Migration é o processo de transformar um banco de dados existente em um novo esquema sem perda de dados. O Room suporta migrações através da classe Migration com versões antiga e nova. O SwiftData usa VersionedSchema para descrever as alterações. A sincronização adequada de dados entre versões do aplicativo requer que as migrações sejam testadas de forma idempotente.

Exemplo de Schema Migration no 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
}

Exemplo de Conflict Resolution no 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 e SwiftData para Armazenamento Local

Room é uma biblioteca do Google para armazenamento local no Android, construída sobre o SQLite e que fornece anotações para descrições declarativas de consultas. SwiftData é um framework da Apple para iOS, macOS, watchOS e visionOS, sucessor do Core Data com uma sintaxe concisa de Swift Macro. Ambas as ferramentas resolvem a tarefa de manipular dados no dispositivo, mas com diferentes abordagens para organização de código. O cache em aplicativos móveis é frequentemente construído precisamente sobre essas tecnologias.

Room: DAO, Entities e Type Converters

Room usa anotações @Entity para tabelas e @Dao para consultas. DAO encapsula todas as operações SQL com verificação em tempo de compilação — erros de sintaxe SQL são detectados antes da execução. Type Converter converte tipos complexos (Date, List) em primitivos SQLite. A manipulação moderna de dados em aplicativos Android é construída em torno de Room + Flow, fornecendo atualizações reativas da interface quando o cache ou banco de dados local muda.

SwiftData: @Model e @Query

SwiftData usa o macro @Model para definir entidades e @Query para observar dados. O framework rastreia automaticamente as dependências e atualiza a interface conforme as mudanças. A migração de esquemas usa VersionedSchema descrevendo todas as versões. A sincronização de dados entre SwiftData e o servidor é implementada através de um Sync Manager personalizado inscrito em atualizações via @Query.

Exemplo de Modelo no 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ção Room vs SwiftData