Caché y sincronización de datos en el desarrollo móvil: qué es, estrategias y cómo funciona

Manejo de Datos en Aplicaciones Móviles: Patrón Repository y Data Source

El patrón Repository es un enfoque arquitectónico donde una sola clase repositorio gestiona todas las operaciones de datos, abstrayendo las API REST remotas y el almacenamiento local Room o SwiftData. Esta forma de manejar los datos permite que la aplicación obtenga información primero desde Memory Cache o Disk Cache, y luego desde la red, reduciendo el tiempo de respuesta. En el desarrollo móvil, Repository se ha convertido en el estándar de facto gracias a las recomendaciones de Google y Apple.

Remote Data Source y Local Data Source

Remote Data Source proporciona información actualizada del servidor a través de solicitudes HTTP. Local Data Source es el almacenamiento local en el dispositivo, implementado mediante Room en Android o SwiftData en iOS. El repositorio combina ambas fuentes: primero verifica el caché local y, cuando no hay datos, solicita desde la API remota. Esta organización del manejo de datos permite que la aplicación funcione en modo offline y reduce la carga del servidor.

Ejemplo 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
    }
}

Ejemplo 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
    }
}

Almacenamiento en Caché: LRU Cache, Disk Cache y Memory Cache

LRU Cache (Least Recently Used) es un algoritmo de almacenamiento en caché donde, al alcanzar el límite, se elimina el elemento que no ha sido accedido por más tiempo. En aplicaciones móviles, LRU Cache se usa para imágenes, respuestas API y objetos serializados. Un almacenamiento en caché adecuado reduce la cantidad de solicitudes de red y acelera la carga de contenido. El caché en aplicaciones móviles es un componente esencial para un alto rendimiento.

Memory Cache vs Disk Cache

Memory Cache almacena datos en RAM — el acceso es extremadamente rápido, pero la capacidad está limitada por el tamaño del heap de la aplicación. Disk Cache guarda información en el sistema de archivos — es más lento pero puede contener más y persiste entre sesiones. La estrategia óptima en el desarrollo móvil es un caché de dos niveles: Memory Cache para datos calientes y Disk Cache para datos fríos. Al manejar datos, primero se verifica el caché de primer nivel en memoria, luego el caché de segundo nivel en disco.

Ejemplo de Implementación 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
    }
}

Estrategias de Invalidación de Caché

El caché TTL (Time To Live) elimina automáticamente una entrada después de un intervalo de tiempo especificado — adecuado para datos API. Invalidación basada en eventos limpia el caché al recibir una notificación push sobre cambios. En aplicaciones móviles, la elección de la estrategia de almacenamiento en caché depende del tipo de datos: las imágenes se almacenan en caché por mucho tiempo, mientras que un feed de noticias requiere invalidación frecuente. Coil en Android y Kingfisher en iOS ya han incorporado LRU Cache para trabajar con imágenes.

Cola Offline: Offline Queue y Sync Manager

Offline Queue es una estructura de datos que almacena las operaciones del usuario (crear, actualizar, eliminar) en una base de datos local cuando el dispositivo está offline. Cuando se restaura la conexión, el Sync Manager aplica estas operaciones secuencialmente al servidor. Este tipo de sincronización de datos garantiza que ningún cambio se pierda durante una pérdida temporal de red. En el desarrollo móvil, Offline Queue es un componente crítico para aplicaciones con conexiones inestables.

Arquitectura de Offline Queue

La cola se construye sobre una tabla en Room o SwiftData con campos: tipo de operación, cuerpo JSON de la solicitud, marca de tiempo y estado. Sync Manager es un servicio en segundo plano que procesa las operaciones pendientes, las envía al servidor, actualiza el estado y elimina las entradas exitosas. La sincronización de datos a través de WorkManager en Android o BGTaskScheduler en iOS continúa incluso después de reiniciar el dispositivo. El uso de Offline Queue junto con un manejo adecuado de datos garantiza una experiencia de usuario fluida.

Ejemplo 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
            }
        }
    }
}

Política de Reintentos y Tiempos de Espera

Retroceso exponencial entre reintentos (1s, 2s, 4s, 8s) protege al servidor de avalanchas de solicitudes y previene reintentos infinitos. El límite de 5 reintentos evita el desbordamiento de la cola. La sincronización de datos en aplicaciones móviles con soporte de idempotencia en el servidor permite reintentos seguros, evitando duplicados. Esto es especialmente importante para transacciones financieras y pedidos.

Sincronización de Datos: Conflict Resolution y Schema Migration

Conflict Resolution es un conjunto de estrategias para situaciones donde los mismos datos se modifican en diferentes dispositivos simultáneamente. La sincronización básica de datos requiere elegir un enfoque: Last-Write-Wins (gana la última escritura), versionado (gana la versión más alta) o resolución manual. En escenarios complejos, se utilizan CRDT (Conflict-Free Replicated Data Types), que garantizan la convergencia matemática de los datos.

Estrategias de Resolución de Conflictos

Last-Write-Wins es la más simple de implementar pero puede perder cambios del usuario. Version Vector — cada registro almacena un número de versión y un identificador de dispositivo; surge un conflicto cuando las versiones no coinciden. CRDT es la estrategia más fiable pero compleja: los datos convergen matemáticamente a un estado único sin un coordinador centralizado. La sincronización de datos en aplicaciones móviles basada en CRDT se usa en la edición colaborativa en Google Docs y la sincronización de notas en Notion.

Schema Migration: Actualización Segura de la Base de Datos

Cuando se actualiza una aplicación, la estructura de la base de datos local cambia: se añaden columnas, tablas, índices. Schema Migration es el proceso de transformar una base de datos existente a un nuevo esquema sin pérdida de datos. Room admite migraciones a través de la clase Migration con versiones antigua y nueva. SwiftData usa VersionedSchema para describir los cambios. La sincronización adecuada de datos entre versiones de la aplicación requiere que las migraciones se prueben de forma idempotente.

Ejemplo de Schema Migration en 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
}

Ejemplo 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 y SwiftData para Almacenamiento Local

Room es una biblioteca de Google para almacenamiento local en Android, construida sobre SQLite y que proporciona anotaciones para descripciones declarativas de consultas. SwiftData es un marco de trabajo de Apple para iOS, macOS, watchOS y visionOS, sucesor de Core Data con una sintaxis concisa de Swift Macro. Ambas herramientas resuelven la tarea de manejar datos en el dispositivo, pero con diferentes enfoques para la organización del código. El caché en aplicaciones móviles a menudo se construye precisamente sobre estas tecnologías.

Room: DAO, Entities y Type Converters

Room usa anotaciones @Entity para tablas y @Dao para consultas. DAO encapsula todas las operaciones SQL con verificación en tiempo de compilación — los errores de sintaxis SQL se detectan antes de la ejecución. Type Converter convierte tipos complejos (Date, List) en primitivos de SQLite. El manejo moderno de datos en aplicaciones Android se construye alrededor de Room + Flow, proporcionando actualizaciones reactivas de la interfaz cuando cambian el caché o la base de datos local.

SwiftData: @Model y @Query

SwiftData usa el macro @Model para definir entidades y @Query para observar datos. El marco de trabajo rastrea automáticamente las dependencias y actualiza la interfaz ante cambios. La migración de esquemas usa VersionedSchema que describe todas las versiones. La sincronización de datos entre SwiftData y el servidor se implementa a través de un Sync Manager personalizado suscrito a actualizaciones mediante @Query.

Ejemplo de Modelo 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()
    }
}

Comparación Room vs SwiftData