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 décrivons les modifications destructives, les raisons qui ont motivé la création de Room 3.0 et les différentes actions que vous pouvez effectuer pour migrer depuis Room 2.0.

Modifications destructives

Room 3.0 inclut les modifications destructives suivantes de l'API :

• Suppression des API SupportSQLite : Room 3.0 est entièrement compatible avec les API de pilote androidx.sqlite. Les API SQLiteDriver sont compatibles avec KMP, et la suppression de la dépendance de Room vis-à-vis de l'API Android simplifie la surface de l'API pour Android, car elle évite d'avoir deux backends possibles.
• Suppression de la génération de code Java : Room 3.0 génère exclusivement du code Kotlin. Cela correspond au paradigme Kotlin-first en évolution, mais simplifie également la base de code et le processus de développement, ce qui permet des itérations plus rapides.
• Concentration sur KSP : nous supprimons é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 en fait la priorité de ses API. Les coroutines sont le framework asynchrone compatible avec KMP, et le fait que Room soit asynchrone par nature est une exigence essentielle pour la compatibilité avec les plates-formes Web.

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 classes telles que androidx.room.RoomDatabase se trouvent désormais dans androidx.room3.RoomDatabase.

Priorité à Kotlin et aux coroutines

Sans génération de code Java, Room 3.0 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 multi-modules où l'utilisation de Room est concentrée et où le plug-in Kotlin Gradle et KSP peuvent être appliqués sans affecter le reste de la base de code.

Room 3.0 nécessite également des coroutines, et plus précisément des fonctions DAO qui doivent être suspendues, sauf si elles renvoient un type réactif, tel qu'un flux. Room 3.0 n'autorise pas le blocage des fonctions DAO. Consultez la documentation sur les coroutines sur Android pour savoir comment intégrer des 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 ou version ultérieure. Nous vous recommandons vivement d'éviter toute utilisation supplémentaire de SupportSQLite. Si vous migrez vos intégrations Room vers les API SQLiteDriver, la transition vers Room 3.0 est 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 minimales des sites d'appel.

Pour une brève présentation des API SQLiteDriver, consultez la documentation sur les API SQLiteDriver.

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

Wrapper SupportSQLite de Room

Nous comprenons que la suppression complète de SupportSQLite n'est peut-être pas immédiatement réalisable 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 offre 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 fournit un pont temporaire aux développeurs qui ont besoin de plus de temps pour migrer complètement leur base de code. Cet artefact continue d'exister dans Room 3.0 sous le nom 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 compilateur de Room.

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

Compatibilité Web de Room et SQLite

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

Pour en savoir plus sur la configuration de Room pour le Web, consultez les notes de version de Room 3.0.

Types de retour DAO personnalisés

Room 3.0 permet d'ajouter des intégrations personnalisées à Room, semblables à 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 compatibilité. Les intégrations existantes sont migrées pour utiliser cette fonctionnalité et nécessitent donc désormais que les utilisateurs qui en dépendent ajoutent les convertisseurs aux définitions @Database ou @Dao.

Par exemple, le convertisseur Paging 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 types 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 de correctifs (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.

Conclusion

Nous sommes très enthousiastes quant au potentiel de Room 3.0 et aux opportunités qu'il offre à l'écosystème Kotlin. Restez à l'écoute pour en savoir plus sur la suite de ce projet.