Room 3.0 : moderniser Room

La première version alpha de Room 3.0 est disponible. Room 3.0 est une version majeure de la bibliothèque qui introduit des modifications destructives. Elle 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 JVM pour ordinateur. 

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 : 

• Abandon des API SupportSQLite : Room 3.0 est entièrement compatible avec les API du pilote androidx.sqlite. Les API SQLiteDriver sont compatibles avec KMP. Supprimer la dépendance de Room à l'API Android simplifie la surface de l'API pour Android, car cela évite d'avoir deux backends possibles.
• Plus de génération de code Java : Room 3.0 génère exclusivement du code Kotlin. Cela s'aligne sur l'évolution du paradigme Kotlin-first, mais simplifie également la codebase et le processus de développement, ce qui permet des itérations plus rapides.
• Focus 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 codebases Kotlin sans être limité par le langage Java.
• Priorité aux coroutines  : Room 3.0 adopte les coroutines Kotlin, ce qui donne la priorité aux coroutines dans ses API. 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 ayant des dépendances transitives vers 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.

Kotlin et les coroutines d'abord

Comme il n'y a plus de génération de code Java, Room 3.0 nécessite également KSP et le compilateur Kotlin, même si la codebase interagissant avec Room est en Java. Il est recommandé d'avoir un projet multimodule 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 du codebase.

Room 3.0 nécessite également des coroutines. Plus précisément, les fonctions DAO doivent être des fonctions de suspension, sauf si elles renvoient un type réactif, comme un Flow. Room 3.0 n'autorise pas les fonctions DAO bloquantes. Consultez la documentation sur les coroutines sur Android pour savoir comment intégrer des coroutines dans 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 d'utiliser SupportSQLite. Si vous migrez vos intégrations Room vers les API SQLiteDriver, la transition vers Room 3.0 est plus facile, car le changement de 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 une présentation rapide des API SQLiteDriver, consultez la documentation de l'API SQLiteDriver.

Pour en savoir plus sur la migration de Room vers les API SQLiteDriver, consultez la documentation officielle sur la migration depuis SupportSQLite.

Wrapper SupportSQLite de Room

Nous sommes conscients que la suppression complète de SupportSQLite n'est peut-être pas possible 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 fournit 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 de 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é de Room et SQLite avec le Web

La compatibilité avec les cibles Kotlin Multiplatform JS et WasmJS apporte 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, et un nouveau pilote Web asynchrone est disponible dans androidx.sqlite:sqlite-web. Il s'agit d'un pilote basé sur un Web Worker qui permet de conserver la base de données 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, comme RxJava et Paging. Grâce à une nouvelle API d'annotation appelée @DaoReturnTypeConverter, vous pouvez créer votre propre intégration de sorte que le code généré par Room soit accessible au moment de l'exécution. Cela permet aux fonctions @Dao d'avoir leurs types renvoyés personnalisés sans avoir à attendre que l'équipe Room ajoute la compatibilité. Les intégrations existantes sont migrées pour utiliser cette fonctionnalité. Par conséquent, les utilisateurs qui s'en servent 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 types renvoyés DAO" dans les notes de version de Room 3.0.

Mode maintenance de Room 2.x

Comme le développement de Room se concentrera 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.

Conclusions

Nous sommes ravis du potentiel de Room 3.0 et des opportunités qu'il offre à l'écosystème Kotlin. Nous vous communiquerons prochainement plus d'informations à ce sujet.