Se lanzó la primera versión alfa de Room 3.0. Room 3.0 es una versión de la biblioteca que introduce cambios rotundos y se centra en Kotlin Multiplataforma (KMP) y agrega compatibilidad con JavaScript y WebAssembly (WASM) además de la compatibilidad existente con Android, iOS y JVM para computadoras de escritorio. 

En este blog, describimos los cambios rotundos, el razonamiento detrás de Room 3.0 y las diversas acciones que puedes realizar para migrar desde Room 2.0.

Cambios rotundos

Room 3.0 incluye los siguientes cambios rotundos en la API: 

• Se quitaron las APIs de SupportSQLite: Room 3.0 está completamente respaldado por las APIs del controlador androidx.sqlite. Las APIs de SQLiteDriver son compatibles con KMP, y quitar la dependencia de Room en la API de Android simplifica la superficie de la API para Android, ya que evita tener dos backends posibles.
• Ya no se genera código Java: Room 3.0 genera exclusivamente código Kotlin. Esto se alinea con el paradigma en evolución que prioriza a Kotlin, pero también simplifica la base de código y el proceso de desarrollo, lo que permite iteraciones más rápidas.
• Enfoque en KSP: También quitaremos la compatibilidad con el procesamiento de anotaciones (AP) de Java y KAPT. Room 3.0 es solo un procesador KSP (procesamiento de símbolos de Kotlin), lo que permite un mejor procesamiento de las bases de código de Kotlin sin estar limitado por el lenguaje Java.
• Prioridad a las corrutinas: Room 3.0 adopta las corrutinas de Kotlin, lo que hace que sus APIs sean prioritarias para las 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 paquete nuevo

Para evitar problemas de compatibilidad con las implementaciones existentes de Room 2.x y para las bibliotecas con dependencias transitivas de Room (por ejemplo, WorkManager), Room 3.0 reside en un paquete nuevo, lo que significa que también tiene un nuevo grupo de Maven y IDs de artefactos. Por ejemplo, androidx.room:room-runtime se convirtió en androidx.room3:room3-runtime, y las clases como androidx.room.RoomDatabase ahora se ubicarán en androidx.room3.RoomDatabase.

Prioridad a Kotlin y las corrutinas

Como ya no se genera código Java, Room 3.0 también requiere KSP y el compilador de Kotlin, incluso si la base de código que interactúa con Room está en Java. Se recomienda tener un proyecto de varios módulos en el que se concentre el uso de Room y se puedan aplicar el complemento de Gradle de Kotlin y KSP sin afectar el resto de la base de código.

Room 3.0 también requiere corrutinas y, más específicamente, las funciones DAO deben suspenderse, a menos que muestren un tipo reactivo, como un flujo. Room 3.0 no permite bloquear funciones DAO. Consulta la documentación sobre corrutinas en Android para comenzar a integrar corrutinas en tu aplicación.

Migración a las APIs de SQLiteDriver

Con el cambio de SupportSQLite, las apps deberán migrar a las APIs de SQLiteDriver. Esta migración es esencial para aprovechar todos los beneficios de Room 3.0, incluido el uso de la biblioteca SQLite agrupada a través de BundledSQLiteDriver. Puedes comenzar a migrar a las APIs del controlador hoy mismo con Room 2.7.0 o versiones posteriores. Te recomendamos que evites cualquier uso adicional de 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 podría requerir cambios mínimos en los sitios de llamadas.

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 detalles sobre cómo migrar Room para usar las APIs de SQLiteDriver, consulta la documentación oficial para migrar desde SupportSQLite.

Wrapper de SupportSQLite de Room

Entendemos que quitar SupportSQLite por completo podría no ser factible de inmediato para todos los proyectos. Para facilitar esta transición, Room 2.8.0, la versión más reciente de la serie Room 2.0, introdujo 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, incluso si las APIs de SupportSQLite de la base de datos se inhabilitaron debido a que se instaló un SQLiteDriver. Esto proporciona un puente temporal para los desarrolladores que necesitan más tiempo para migrar por completo su base de código. 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, admitir el uso crítico de SupportSQLite.

Por ejemplo, las invocaciones de roomDatabase.openHelper.writableDatabase se pueden reemplazar por roomDatabase.getSupportWrapper(), y se proporcionaría un wrapper incluso si se llama a setDriver() en el compilador de Room.

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

Compatibilidad web de Room y SQLite

La compatibilidad con los objetivos de Kotlin Multiplataforma JS y WasmJS trae algunos de los cambios más significativos en la API. En particular, 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 actualizaron para admitir la Web, y un nuevo controlador asíncrono web está 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 de origen (OPFS).

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

Tipos de datos que se devuelven de DAO personalizados

Room 3.0 introduce la capacidad de agregar integraciones personalizadas a Room de manera similar a RxJava y Paging. A través de una nueva API de anotación llamada @DaoReturnTypeConverter, puedes crear tu propia integración de modo que se pueda acceder al código generado de Room en el tiempo de ejecución. Esto permite que las funciones @Dao tengan sus tipos de datos que se devuelven personalizados sin tener que esperar a que el equipo de Room agregue la compatibilidad. Las integraciones existentes se migran para usar esta funcionalidad y, por lo tanto, ahora requerirán que quienes dependan de ella agreguen los convertidores a las definiciones @Database o @Dao.

Por ejemplo, el convertidor de Paging se ubicará en el artefacto androidx.room3:room3-paging y se llamará PagingSourceDaoReturnTypeConverter. Mientras tanto, para LiveData, el convertidor está en androidx.room3:room3-livedata y se llama LiveDataDaoReturnTypeConverter.

Para obtener más detalles, consulta la sección DAO Return Type Converters en las notas de la versión de Room 3.0.

Modo de mantenimiento de Room 2.x

Dado que el desarrollo de Room se centrará en Room 3, la versión actual de Room 2.x entra en modo de mantenimiento. Esto significa que no se desarrollarán funciones importantes, pero se seguirán lanzando versiones de parches (2.8.1, 2.8.2, etcétera) con correcciones de errores y actualizaciones de dependencias. El equipo se compromete a este trabajo hasta que Room 3 se vuelva estable.

Conclusiones

Estamos muy entusiasmados con el potencial de Room 3.0 y las oportunidades que ofrece para el ecosistema de Kotlin. Mantente atento para recibir más actualizaciones a medida que continuamos este recorrido.