Se ha lanzado la primera versión alfa de Room 3.0. Room 3.0 es una versión de la biblioteca que introduce cambios importantes y se centra en Kotlin Multiplatform (KMP). Además, añade compatibilidad con JavaScript y WebAssembly (WASM) a la compatibilidad con Android, iOS y JVM para ordenadores. 

En esta entrada de blog, describimos los puntos de ruptura, los motivos de Room 3.0 y las distintas acciones que puedes llevar a cabo para migrar de Room 2.0.

Cambios incompatibles

Room 3.0 incluye los siguientes cambios en la API que suponen un punto de ruptura: 

• Eliminación de las APIs de SupportSQLite: Room 3.0 se basa por completo en las APIs del controlador androidx.sqlite. Las APIs de SQLiteDriver son compatibles con KMP y, al eliminar la dependencia de Room de la API de Android, se simplifica la superficie de la API para Android, ya que se evitan dos posibles back-ends.
• No se genera más código Java: Room 3.0 genera exclusivamente código Kotlin. Esto se ajusta al paradigma de Kotlin primero, pero también simplifica la base de código y el proceso de desarrollo, lo que permite realizar iteraciones más rápidas.
• Centrarse en KSP: también vamos a dejar de ofrecer asistencia para el procesamiento de anotaciones (AP) de Java y KAPT. Room 3.0 es únicamente un procesador KSP (procesamiento de símbolos de Kotlin), lo que permite procesar mejor las bases de código de Kotlin sin estar limitado por el lenguaje Java.
• Prioridad de las corrutinas:  Room 3.0 incorpora las corrutinas de Kotlin, lo que hace que sus APIs tengan prioridad de corrutinas. Las corrutinas son el framework asíncrono compatible con KMP, y hacer que Room sea asíncrono por naturaleza es un requisito fundamental para admitir plataformas web.

Un nuevo paquete

Para evitar problemas de compatibilidad con las implementaciones de Room 2.x y con las bibliotecas con dependencias transitivas de Room (por ejemplo, WorkManager), Room 3.0 se encuentra en un nuevo paquete, lo que significa que también tiene un nuevo grupo de Maven y nuevos IDs de artefacto. Por ejemplo, androidx.room:room-runtime ahora es androidx.room3:room3-runtime y las clases como androidx.room.RoomDatabase ahora se encuentran en androidx.room3.RoomDatabase.

Kotlin y corrutinas primero

Como ya no se genera código Java, Room 3.0 también requiere KSP y el compilador de Kotlin, aunque la base de código que interactúa con Room esté en Java. Te recomendamos que tengas un proyecto de varios módulos en el que se concentre el uso de Room y se puedan aplicar el complemento Kotlin Gradle y KSP sin que afecten al resto del código base.

Room 3.0 también requiere corrutinas y, más concretamente, las funciones DAO deben suspenderse a menos que devuelvan un tipo reactivo, como un flujo. Room 3.0 no permite bloquear funciones de DAO. Consulta la documentación sobre corrutinas en Android para saber cómo empezar a integrar corrutinas en tu aplicación.

Migración a las APIs de SQLiteDriver

Con el cambio de SupportSQLite, las aplicaciones tendrán que migrar a las APIs de SQLiteDriver. Esta migración es esencial para aprovechar todas las ventajas de Room 3.0, incluido el uso de la biblioteca SQLite incluida a través de BundledSQLiteDriver. Puedes empezar a migrar a las APIs del controlador hoy mismo con Room 2.7.0 o una versión posterior. Te recomendamos que evites usar SupportSQLite. Si migras tus integraciones de Room a las APIs de SQLiteDriver, la transición a Room 3.0 será más sencilla, ya que el cambio de paquete implica principalmente actualizar las referencias de símbolos (importaciones) y puede que requiera cambios mínimos en los sitios de llamada.

Para obtener una breve descripción general de las APIs de SQLiteDriver, consulta la documentación de las APIs de SQLiteDriver.

Para obtener más información sobre cómo migrar Room para usar las APIs de SQLiteDriver, consulta la documentación oficial para migrar desde SupportSQLite.

Envoltorio Room SupportSQLite

Entendemos que puede que no sea posible eliminar SupportSQLite por completo de inmediato en todos los proyectos. Para facilitar esta transición, Room 2.8.0, la versión más reciente de la serie Room 2.0, ha introducido un nuevo artefacto llamado androidx.room:room-sqlite-wrapper. Este artefacto ofrece una API de compatibilidad que te permite convertir un RoomDatabase en un SupportSQLiteDatabase, aunque las APIs de SupportSQLite de la base de datos se hayan inhabilitado porque se haya instalado un SQLiteDriver. Esto proporciona un puente temporal para los desarrolladores que necesiten más tiempo para migrar por completo su código base. Este artefacto sigue existiendo en Room 3.0 como androidx.room3:room3-sqlite-wrapper para permitir la migración a Room 3.0 y, al mismo tiempo, seguir admitiendo el uso crítico de SupportSQLite.

Por ejemplo, las invocaciones de roomDatabase.openHelper.writableDatabase se pueden sustituir por roomDatabase.getSupportWrapper() y se proporcionaría un envoltorio aunque se llamara a setDriver() en el compilador de Room.

Para obtener más información, consulta la documentación de room-sqlite-wrapper.

Compatibilidad con Room y SQLite en la Web

Se ha añadido compatibilidad con los objetivos de JavaScript y WasmJS de Kotlin Multiplatform, y se han implementado algunos de los cambios más significativos en las APIs. En concreto, muchas APIs de Room 3.0 son funciones de suspensión, ya que la compatibilidad adecuada con el almacenamiento web es asíncrona. Las APIs de SQLiteDriver también se han actualizado para admitir la Web y hay un nuevo controlador web asíncrono disponible en androidx.sqlite:sqlite-web. Es un controlador basado en Web Worker que permite conservar la base de datos en el sistema de archivos privado del origen (OPFS).

Para obtener más información sobre cómo configurar Room para la Web, consulta las notas de la versión 3.0 de Room.

Tipos de retorno de DAO personalizados

Room 3.0 introduce la posibilidad de añadir integraciones personalizadas a Room, de forma similar a RxJava y Paging. Con una nueva API de anotación llamada @DaoReturnTypeConverter, puedes crear tu propia integración para que el código generado de Room sea accesible en tiempo de ejecución. De esta forma, las funciones @Dao pueden tener sus tipos de retorno personalizados sin tener que esperar a que el equipo de Room añada la compatibilidad. Las integraciones actuales se migran para usar esta función, por lo que ahora los usuarios que dependan de ella deberán añadir los convertidores a las definiciones de @Database o @Dao.

Por ejemplo, el convertidor de paginación se encontrará en el artefacto androidx.room3:room3-paging y se llamará PagingSourceDaoReturnTypeConverter. Mientras tanto, en LiveData, el convertidor está en androidx.room3:room3-livedata y se llama LiveDataDaoReturnTypeConverter.

Para obtener más información, consulta la sección Convertidores de tipos de retorno de DAO de las notas de la versión 3.0 de Room.

Modo de mantenimiento de Room 2.x

Como el desarrollo de Room se centrará en Room 3, la versión actual de Room 2.x pasará al modo de mantenimiento. Esto significa que no se desarrollarán funciones importantes, pero sí se lanzarán parches (2.8.1, 2.8.2, etc.) con correcciones de errores y actualizaciones de dependencias. El equipo se compromete a seguir trabajando en ello hasta que Room 3 sea estable.

Reflexiones finales

Estamos muy ilusionados con el potencial de Room 3.0 y las oportunidades que ofrece al ecosistema de Kotlin. No te pierdas las próximas novedades a medida que avancemos en este proceso.