La première version alpha de Room 3.0 est disponible. Room 3.0 est une version majeure de la bibliothèque qui se concentre sur Kotlin Multiplatform (KMP) et ajoute la compatibilité avec JavaScript et WebAssembly (WASM) en plus de la compatibilité existante avec Android, iOS et le bureau JVM. 

Dans cet article de blog, nous présentons les modifications destructives, les raisons qui ont motivé la création de Room 3.0 et les différentes étapes à suivre pour migrer depuis Room 2.0.

Modifications importantes

Room 3.0 inclut les modifications destructives suivantes apportées à l'API : 

• Abandon des API SupportSQLite : Room 3.0 est entièrement compatible avec les API de pilote androidx.sqlite. Les API SQLiteDriver sont compatibles avec KMP. La suppression de la dépendance de Room sur l'API d'Android simplifie la surface de l'API pour Android, car elle évite d'avoir deux backends possibles.
• Fin de la génération de code Java : Room 3.0 génère exclusivement du code Kotlin. Cela s'inscrit dans le nouveau paradigme "Kotlin-first", mais simplifie également le codebase et le processus de développement, ce qui permet des itérations plus rapides.
• Concentration sur KSP : nous abandonnons également la compatibilité avec le traitement des annotations Java (AP) et KAPT. Room 3.0 est uniquement un processeur KSP (Kotlin Symbol Processing), ce qui permet un meilleur traitement des bases de code Kotlin sans être limité par le langage Java.
• Priorité aux coroutines  : Room 3.0 adopte les coroutines Kotlin, ce qui fait de ses API des API axées sur les coroutines. Les coroutines sont le framework asynchrone compatible avec KMP. Rendre Room asynchrone par nature est une exigence essentielle pour prendre en charge les plates-formes Web.

Un nouveau package

Pour éviter les problèmes de compatibilité avec les implémentations Room 2.x existantes et pour les bibliothèques avec des dépendances transitives à Room (par exemple, WorkManager), Room 3.0 réside dans un nouveau package, ce qui signifie qu'il possède également un nouveau groupe Maven et de nouveaux ID d'artefact. Par exemple, androidx.room:room-runtime est devenu androidx.room3:room3-runtime et les cours tels que androidx.room.RoomDatabase se trouvent désormais à l'adresse androidx.room3.RoomDatabase.

Kotlin et les coroutines en premier

Comme Room 3.0 ne génère plus de code Java, il nécessite également KSP et le compilateur Kotlin, même si la base de code interagissant avec Room est en Java. Il est recommandé d'avoir un projet multimode dans lequel l'utilisation de Room est concentrée et où le plug-in Kotlin Gradle et KSP peuvent être appliqués sans affecter le reste du code.

Room 3.0 nécessite également que les coroutines et, plus précisément, les fonctions DAO soient suspendues, sauf si elles renvoient un type réactif, tel qu'un Flow. Room 3.0 interdit les fonctions DAO bloquantes. Consultez la documentation sur les coroutines sur Android pour savoir comment intégrer les coroutines à votre application.

Migration vers les API SQLiteDriver

Avec l'abandon de SupportSQLite, les applications devront migrer vers les API SQLiteDriver. Cette migration est essentielle pour profiter pleinement des avantages de Room 3.0, y compris l'utilisation de la bibliothèque SQLite groupée via BundledSQLiteDriver. Vous pouvez commencer à migrer vers les API de pilote dès aujourd'hui avec Room 2.7.0 et versions ultérieures. Nous vous recommandons vivement d'éviter toute utilisation ultérieure de SupportSQLite. Si vous migrez vos intégrations Room vers les API SQLiteDriver, la transition vers Room 3.0 sera plus facile, car la modification du package implique principalement la mise à jour des références de symboles (importations) et peut nécessiter des modifications minimes des sites d'appel.

Pour obtenir un bref aperçu des API SQLiteDriver, consultez la documentation sur les API SQLiteDriver.

Pour savoir comment migrer Room afin d'utiliser les API SQLiteDriver, consultez la documentation officielle sur la migration depuis SupportSQLite.

Wrapper Room SupportSQLite

Nous comprenons qu'il ne soit pas toujours possible de supprimer complètement SupportSQLite immédiatement pour tous les projets. Pour faciliter cette transition, Room 2.8.0, la dernière version de la série Room 2.0, a introduit un nouvel artefact appelé androidx.room:room-sqlite-wrapper. Cet artefact propose une API de compatibilité qui vous permet de convertir un RoomDatabase en SupportSQLiteDatabase, même si les API SupportSQLite de la base de données ont été désactivées en raison de l'installation d'un SQLiteDriver. Cela offre une solution temporaire aux développeurs qui ont besoin de plus de temps pour migrer complètement leur codebase. Cet artefact continue d'exister dans Room 3.0 en tant que androidx.room3:room3-sqlite-wrapper pour permettre la migration vers Room 3.0 tout en continuant à prendre en charge l'utilisation critique de SupportSQLite.

Par exemple, les appels de roomDatabase.openHelper.writableDatabase peuvent être remplacés par roomDatabase.getSupportWrapper(), et un wrapper est fourni même si setDriver() est appelé sur le générateur de Room.

Pour en savoir plus, consultez la documentation sur room-sqlite-wrapper.

Compatibilité de Room et SQLite avec le Web

La prise en charge des cibles Kotlin Multiplatform JS et WasmJS entraîne certaines des modifications d'API les plus importantes. Plus précisément, de nombreuses API de Room 3.0 sont des fonctions de suspension, car la prise en charge appropriée du stockage Web est asynchrone. Les API SQLiteDriver ont également été mises à jour pour prendre en charge le Web. Un nouveau pilote asynchrone Web est disponible dans androidx.sqlite:sqlite-web. Il s'agit d'un pilote basé sur Web Worker qui permet de rendre la base de données persistante dans le système de fichiers privé d'origine (OPFS).

Pour savoir comment configurer Room pour le Web, consultez les notes de version de Room 3.0.

Types de retours de DAO personnalisés

Room 3.0 permet d'ajouter des intégrations personnalisées à Room, comme RxJava et Paging. Grâce à une nouvelle API d'annotation appelée @DaoReturnTypeConverter, vous pouvez créer votre propre intégration afin que le code généré par Room devienne accessible au moment de l'exécution. Cela permet aux fonctions @Dao d'avoir leurs propres types de retour personnalisés sans avoir à attendre que l'équipe Room ajoute la prise en charge. Les intégrations existantes sont migrées pour utiliser cette fonctionnalité. Par conséquent, les utilisateurs qui s'appuient dessus devront désormais ajouter les convertisseurs aux définitions @Database ou @Dao.

Par exemple, le convertisseur de pagination se trouve dans l'artefact androidx.room3:room3-paging et s'appelle PagingSourceDaoReturnTypeConverter. Pour LiveData, le convertisseur se trouve dans androidx.room3:room3-livedata et s'appelle LiveDataDaoReturnTypeConverter.

Pour en savoir plus, consultez la section "Convertisseurs de type de retour DAO" dans les notes de version de Room 3.0.

Mode maintenance de Room 2.x

Étant donné que le développement de Room sera axé sur Room 3, la version actuelle de Room 2.x passe en mode maintenance. Cela signifie qu'aucune fonctionnalité majeure ne sera développée, mais que des versions correctives (2.8.1, 2.8.2, etc.) seront toujours publiées avec des corrections de bugs et des mises à jour de dépendances. L'équipe s'engage à poursuivre ce travail jusqu'à ce que Room 3 devienne stable.

Conclusions

Nous sommes très enthousiastes quant au potentiel de Room 3.0 et aux opportunités qu'il offre à l'écosystème Kotlin. Nous vous communiquerons prochainement plus d'informations à ce sujet.