Seguro que te ha pasado: entras en una aplicación que tiene miles de productos o imágenes y, al hacer scroll, todo fluye como la seda, sin cortes ni pantallas de carga infinitas. No es magia, es la paginación bien implementada. Cuando manejamos volúmenes de datos bestiales, intentar cargar todo de golpe es antojarse que la app explote, llevándonos directos al temido OutOfMemory (OOM), ya que saturamos la RAM del dispositivo con objetos que el usuario ni siquiera está viendo.
Para solucionar este marrón, Google nos ha regalado la librería Paging 3 de Jetpack. Esta herramienta no solo se encarga de trocear la información en páginas manejables, sino que está pensada desde cero para jugar bien con Kotlin, las corrutinas y Flow. Básicamente, nos permite servir los datos justo a tiempo, optimizando los recursos del sistema y haciendo que la navegación sea sumamente fluida y natural para cualquiera que use la app.
¿Cómo funciona la arquitectura de Paging 3?
Para que esto no sea un caos, Paging 3 se organiza en tres niveles muy claros que encajan a la perfección con la Clean Architecture. En primer lugar tenemos la capa del repositorio, donde el protagonista es el PagingSource. Este componente es el que sabe de dónde vienen los datos, ya sea de una base de datos de Room o de una API RESTful, y define cómo se recupera cada trozo de información.
Si queremos subir de nivel y crear una app que funcione offline, entra en juego el RemoteMediator. Este actúa como un director de orquesta que gestiona una fuente de datos en capas: descarga los datos de la red y los guarda en una caché local, asegurando que el usuario siempre vea algo aunque no tenga internet.
Subiendo hacia la capa de presentación, encontramos el Pager. Este componente es el que crea el flujo de PagingData basándose en una configuración específica (PagingConfig), donde decidimos cuántos elementos cargar por página y cuánto tiempo antes debe empezar a cargar la siguiente página (el famoso prefetch) para que el usuario no note la transición.
Llevando los datos a la interfaz de usuario
Cuando llegamos a la UI, la cosa se pone interesante. Si usas Jetpack Compose, la herramienta estrella es la función collectAsLazyPagingItems(). Esta convierte el flujo de datos en un objeto que los componentes de diseño diferido, como LazyColumn o LazyRow, pueden consumir sin despeinarse, eliminando la necesidad de escribir adaptadores complicados o lógica de diferenciación manual.
Para quienes siguen usando el sistema de vistas tradicional, el PagingDataAdapter es la solución. Es un adaptador especializado que hereda las ventajas de ListAdapter, utilizando DiffUtil para actualizar solo los elementos que han cambiado y solicitando nuevas páginas automáticamente al usar RecyclerView en Android cuando el scroll se acerca al final de la lista.
Gestión de estados y errores
Una de las mayores ventajas de esta librería es que no te deja tirado con el manejo de errores. Paging expone el estado de carga (LoadState) en tres puntos críticos: la carga inicial (refresh), la carga hacia arriba (prepend) y la carga hacia abajo (append). Esto nos permite poner indicadores de carga o botones de reintento justo donde el usuario los necesita.
Si queremos que la lista se vea profesional, podemos añadir un LoadStateAdapter. Este componente crea un pie de página dinámico que muestra un spinner de carga mientras se traen más datos o un mensaje de error con un botón de «Reintentar» si la conexión ha fallado, todo esto sin interferir con la lista de datos principal.
Estrategias de paginación en el Backend
Para que el frontend vuele, el backend también tiene que estar a la altura. Existen varias formas de servir estos datos. La más clásica es la de offset y limit, donde pedimos la página 2 con 10 elementos, aunque puede ser lenta en bases de datos gigantescas. Por otro lado, la paginación basada en cursores es la preferida por gigantes como Twitter o Facebook; en lugar de un número de página, usamos un marcador (como el ID del último elemento) para pedir los siguientes, lo que garantiza que no se repitan datos si se insertan nuevos registros mientras navegamos.
También existe la variante basada en timestamps, ideal para logs o feeds de noticias, donde solicitamos todo lo creado después de una fecha y hora concreta. Independientemente de la técnica, es vital implementar filtros y ordenamientos en la API para que el cliente no tenga que procesar miles de registros en memoria, delegando esa carga al servidor.
Consejos avanzados y optimización
Si estás migrando desde Paging 2, notarás que ahora todo es más sencillo gracias a que las antiguas clases DataSource se han unificado en PagingSource. Además, ahora podemos insertar separadores personalizados entre los elementos de la lista, como poner la letra del abecedario antes de un grupo de nombres, usando la función insertSeparators en el flujo de datos.
En cuanto al testeo, no hace falta que lances la app cada vez. La librería paging-testing nos ofrece el TestPager, que permite simular el scroll y verificar que el PagingSource devuelve las páginas correctas y que las claves de navegación (nextKey y prevKey) están bien calculadas, asegurando que la experiencia final sea robusta. Comparte esta información para que más personas conozcan del tema