Paginación en el desarrollo móvil — qué es, tipos y principio de funcionamiento

¿Qué es la paginación?

La paginación (del latín pagination — división en páginas) es una técnica que divide un gran conjunto de datos en porciones secuenciales (páginas). En aplicaciones móviles, la paginación se utiliza al cargar listas de mensajes, feeds de noticias, catálogos de productos, historial de pedidos y cualquier otra colección con un número potencialmente ilimitado de registros.

Sin paginación, la aplicación se ve obligada a cargar todos los datos a la vez, lo que provoca largas esperas, alto consumo de tráfico y un rendimiento inestable en dispositivos débiles. Una solicitud a la API con paginación devuelve solo una porción de datos e información meta para cargar la siguiente — de este modo, la aplicación controla la cantidad de información que recibe.

Las métricas principales de la paginación son: tamaño de página (page size) — cantidad de registros por página (generalmente 10–50), y número de página o cursor — un indicador de la posición actual en el conjunto. La elección del tamaño de página depende del tipo de datos: para elementos compactos (nombres) bastan 20–30, para tarjetas con imágenes — 10–15.

¿Por qué se necesita la paginación en aplicaciones móviles?

Los dispositivos móviles tienen recursos limitados: memoria RAM, velocidad de procesador y límites de tráfico. La paginación resuelve tres tareas clave: reducción del consumo de memoria (solo se almacenan en memoria los elementos visibles), aceleración de la primera visualización (la primera porción se carga más rápido que todo el conjunto) y ahorro de tráfico (los datos se cargan solo cuando el usuario desplaza la lista).

Principales tipos de paginación

Existen cuatro tipos principales de paginación, cada uno resuelve tareas específicas. La elección del método depende de los requisitos de consistencia de datos, la arquitectura de la API, el tipo de almacenamiento y la complejidad aceptable de implementación en el cliente y el servidor.

Cuándo usar cada tipo

La paginación Offset es adecuada para conjuntos de datos estáticos o que se actualizan con poca frecuencia, cuando la implementación simple es importante. Cursor y Keyset son para datos dinámicos con inserciones frecuentes. Time-based es para feeds cronológicos donde los registros se ordenan por hora de creación. El estándar GraphQL Relay utiliza la paginación por cursor como el único método recomendado.

Paginación Offset: ventajas y desventajas

La paginación Offset es el tipo más simple de carga por páginas. El cliente envía los parámetros page y limit (u offset y limit), y el servidor aplica SQL OFFSET y LIMIT. Por ejemplo, page=2, limit=20 devuelve los registros del 21 al 40. Este método es intuitivo y fácil de implementar en cualquier stack.

from fastapi import FastAPI, Query

app = FastAPI()

@app.get("/items")
async def get_items(
    page: int = Query(default=1, ge=1),
    limit: int = Query(default=20, le=100)
):
    offset = (page - 1) * limit
    items = await fetch_items(offset, limit)
    total = await count_items()
    return {
        "items": items,
        "total": total,
        "page": page,
        "pages": (total + limit - 1) // limit
    }

El problema de inconsistencia de datos

El principal inconveniente de la paginación Offset es el problema de registros perdidos y duplicados. Si se añaden nuevos registros a la tabla entre dos solicitudes, el OFFSET se desplaza: el usuario puede ver el mismo registro dos veces o perderse uno nuevo. Esto es crítico para feeds de noticias y chats donde la consistencia es importante.

Otro problema es la degradación del rendimiento con OFFSET grandes. La base de datos tiene que escanear y saltarse los primeros offset registros antes de devolver el resultado. Con offset=100000 incluso con LIMIT 20, el servidor dedicará un tiempo notable al escaneo. PostgreSQL y MySQL muestran una caída lineal de velocidad a medida que crece OFFSET.

Cuándo Offset sigue siendo bueno

La paginación Offset sigue siendo la mejor opción para: paneles de administración (los datos cambian raramente, se necesita navegación por páginas), informes y registros históricos (instantánea fija de datos), catálogos con filtros (se puede ir a cualquier página). Offset también es el más simple de implementar en el cliente — RecyclerView con Paging 3 lo soporta de serie.

Paginación Keyset y basada en tiempo

La paginación Keyset utiliza una clave única (generalmente la clave primaria) para filtrar registros. En lugar de OFFSET, la consulta usa WHERE id > last_seen_id. Esto garantiza un rendimiento estable independientemente del número de registros y ausencia de duplicados en las inserciones, ya que los nuevos registros siempre tienen un id mayor.

-- Paginación Offset (problemática)
SELECT * FROM posts
ORDER BY id
LIMIT 20 OFFSET 100;

-- Paginación Keyset (estable)
SELECT * FROM posts
WHERE id > 100
ORDER BY id
LIMIT 20;

Paginación basada en tiempo

La paginación basada en tiempo (o cursor por tiempo) utiliza la marca de tiempo created_at para la navegación. El cliente envía la marca de tiempo del último registro cargado, y el servidor devuelve los registros creados antes o después de esa marca. Este método es popular en redes sociales y feeds de noticias donde el orden de los registros se determina por la hora de publicación.

Una característica de la paginación basada en tiempo es la posible aparición de duplicados si dos registros se crean en el mismo milisegundo. Para eliminar este problema, se combina una clave basada en tiempo con un id único: WHERE (created_at, id) < (last_time, last_id). Este cursor compuesto garantiza la unicidad de cada registro y un orden preciso.

Comparación de Keyset y basada en tiempo

La paginación Keyset requiere una columna con un valor único y monótonamente creciente (id autoincremental, UUID v7). La basada en tiempo es adecuada para cualquier tabla con created_at, pero requiere un manejo adicional de duplicados. La diferencia principal: Keyset funciona de forma estable ante cualquier operación de inserción, mientras que la basada en tiempo es sensible a marcas de tiempo idénticas.

Cómo elegir el tipo de paginación para tu proyecto

La elección del tipo de paginación depende de la naturaleza de los datos y los requisitos de experiencia de usuario. A continuación se presentan recomendaciones para escenarios típicos en el desarrollo móvil. No existe una solución universal — cada método tiene un ámbito donde es óptimo.

• Chat / Mensajería — Paginación Cursor (por id de mensaje). Los nuevos mensajes aparecen arriba, el cursor no se desvía.
• Feed de noticias — Paginación basada en tiempo (por created_at). Los registros se ordenan por tiempo, la cronología es importante.
• Catálogo de productos — Paginación Offset. El usuario puede ir a una página específica, los datos cambian raramente.
• Historial de pedidos — Paginación Cursor. La estabilidad es importante porque se añaden nuevos pedidos entre cargas.
• Comentarios — Paginación Keyset. Cada comentario tiene un id único, grandes volúmenes sin duplicados.

Implementación en Android con Paging 3

La biblioteca Android Paging 3 soporta todos los tipos de paginación a través de PagingSource. Para Offset — PagingSource con clave Int (page), para Cursor — con clave String o Long (cursor). PagingSource gestiona automáticamente la carga, el almacenamiento en caché y los reintentos en caso de error.

class PostPagingSource(
    private val api: PostApi
) : PagingSource<Long, Post>() {

    override suspend fun load(
        params: LoadParams<Long>
    ): LoadResult<Long, Post> {
        val cursor = params.key ?: Long.MAX_VALUE
        return try {
            val response = api.getPosts(cursor, params.loadSize)
            LoadResult.Page(
                data = response.items,
                prevKey = null,
                nextKey = response.items.lastOrNull()?.id
            )
        } catch (e: Exception) {
            LoadResult.Error(e)
        }
    }

    override fun getRefreshKey(state: PagingState<Long, Post>): Long? {
        return state.anchorPosition?.let {
            state.closestItemToPosition(it)?.id
        }
    }
}

Recomendaciones sobre el tamaño de página

El tamaño de página afecta la velocidad de carga y la percepción del rendimiento. Para aplicaciones móviles, el rango óptimo es 10–25 elementos por página. Menos de 10 genera demasiadas solicitudes a la API y un scroll entrecortado. Más de 25 provoca una carga lenta de la primera porción en redes lentas.

Para imágenes y vídeos, el tamaño de página se reduce a 5–10, ya que cada elemento requiere tiempo adicional para cargar el contenido multimedia. Para listas de texto (comentarios, registros), el tamaño puede aumentarse a 30–50 registros. Se recomienda hacer que el tamaño de página sea configurable a través de la API para que el cliente pueda adaptarse a diferentes condiciones de red.