Die erste Alphaversion von Room 3.0 wurde veröffentlicht. Room 3.0 ist eine wichtige Version der Bibliothek, die nicht abwärtskompatibel ist. Sie konzentriert sich auf Kotlin Multiplatform (KMP) und bietet zusätzlich zur bestehenden Android-, iOS- und JVM-Desktopunterstützung auch Unterstützung für JavaScript und WebAssembly (WASM).

In diesem Blogbeitrag werden die nicht abwärtskompatiblen Änderungen, die Gründe für Room 3.0 und die verschiedenen Möglichkeiten zur Migration von Room 2.0 beschrieben.

Nicht abwärtskompatible Änderungen

Room 3.0 enthält die folgenden nicht abwärtskompatiblen API-Änderungen: 

• SupportSQLite-APIs werden eingestellt:Room 3.0 wird vollständig von den androidx.sqlite-Treiber-APIs unterstützt. Die SQLiteDriver-APIs sind KMP-kompatibel. Durch das Entfernen der Abhängigkeit von Room von der Android-API wird die API-Oberfläche für Android vereinfacht, da es nicht mehr zwei mögliche Back-Ends gibt.
• Keine Java-Codegenerierung mehr:Room 3.0 generiert ausschließlich Kotlin-Code. Dies entspricht dem sich entwickelnden Kotlin-First-Paradigma, vereinfacht aber auch die Codebasis und den Entwicklungsprozess und ermöglicht schnellere Iterationen.
• Fokus auf KSP:Wir stellen auch die Unterstützung für die Java-Annotation Processing (AP) und KAPT ein. Room 3.0 ist ausschließlich ein KSP-Prozessor (Kotlin Symbol Processing), der eine bessere Verarbeitung von Kotlin-Codebasen ermöglicht, ohne durch die Java-Sprache eingeschränkt zu sein.
• Coroutinen zuerst: Room 3.0 nutzt Kotlin-Coroutinen und macht seine APIs zu Coroutinen-First-APIs. Coroutinen sind das KMP-kompatible asynchrone Framework. Room von Natur aus asynchron zu machen, ist eine wichtige Voraussetzung für die Unterstützung von Webplattformen.

Neues Paket

Um Kompatibilitätsprobleme mit bestehenden Room 2.x-Implementierungen und Bibliotheken mit transitiven Abhängigkeiten von Room (z. B. WorkManager) zu vermeiden, befindet sich Room 3.0 in einem neuen Paket. Das bedeutet auch, dass es eine neue Maven-Gruppe und neue Artefakt-IDs hat. Beispielsweise wurde androidx.room:room-runtime zu androidx.room3:room3-runtime und Klassen wie androidx.room.RoomDatabase befinden sich jetzt unter androidx.room3.RoomDatabase.

Kotlin und Coroutinen zuerst

Da kein Java-Code mehr generiert wird, erfordert Room 3.0 auch KSP und den Kotlin-Compiler, selbst wenn die Codebasis, die mit Room interagiert, in Java geschrieben ist. Es wird empfohlen, ein Projekt mit mehreren Modulen zu verwenden, in dem die Room-Nutzung konzentriert ist und das Kotlin-Gradle-Plug-in und KSP angewendet werden können, ohne den Rest der Codebasis zu beeinträchtigen.

Room 3.0 erfordert auch Coroutinen. Insbesondere müssen DAO-Funktionen ausgesetzt werden, es sei denn, sie geben einen reaktiven Typ wie einen Flow zurück. Room 3.0 lässt keine blockierenden DAO-Funktionen zu. In der Dokumentation zu Coroutinen unter Android finden Sie eine Anleitung zum Einbinden von Coroutinen in Ihre Anwendung.

Migration zu SQLiteDriver-APIs

Mit der Umstellung von SupportSQLite müssen Apps zu den SQLiteDriver-APIs migriert werden. Diese Migration ist unerlässlich, um die Vorteile von Room 3.0 voll auszuschöpfen, einschließlich der Verwendung der gebündelten SQLite-Bibliothek über BundledSQLiteDriver. Sie können jetzt mit Room 2.7.0+ zu den Treiber-APIs migrieren. Wir empfehlen dringend, SupportSQLite nicht mehr zu verwenden. Wenn Sie Ihre Room-Integrationen zu SQLiteDriver-APIs migrieren, ist der Übergang zu Room 3.0 einfacher, da die Paketänderung hauptsächlich die Aktualisierung von Symbolreferenzen (Importe) umfasst und möglicherweise nur minimale Änderungen an den Aufrufstellen erfordert.

Eine kurze Übersicht über die SQLiteDriver-APIs finden Sie in der Dokumentation zu den SQLiteDriver-APIs.

Weitere Informationen zur Migration von Room zur Verwendung von SQLiteDriver-APIs finden Sie in der offiziellen Dokumentation zur Migration von SupportSQLite.

Room-SupportSQLite-Wrapper

Wir wissen, dass die vollständige Entfernung von SupportSQLite für alle Projekte möglicherweise nicht sofort möglich ist. Um diesen Übergang zu erleichtern, wurde in Room 2.8.0, der neuesten Version der Room 2.0-Reihe, ein neues Artefakt namens androidx.room:room-sqlite-wrapper eingeführt. Dieses Artefakt bietet eine Kompatibilitäts-API, mit der Sie eine RoomDatabase in eine SupportSQLiteDatabase konvertieren können, auch wenn die SupportSQLite-APIs in der Datenbank aufgrund der Installation eines SQLiteDriver deaktiviert wurden. Dies bietet eine vorübergehende Lösung für Entwickler, die mehr Zeit für die vollständige Migration ihrer Codebasis benötigen. Dieses Artefakt ist in Room 3.0 weiterhin als androidx.room3:room3-sqlite-wrapper verfügbar, um die Migration zu Room 3.0 zu ermöglichen und gleichzeitig die kritische SupportSQLite-Nutzung zu unterstützen.

Beispielsweise können Aufrufe von roomDatabase.openHelper.writableDatabase durch roomDatabase.getSupportWrapper() ersetzt werden. Ein Wrapper wird auch dann bereitgestellt, wenn setDriver() für den Builder von Room aufgerufen wird.

Weitere Informationen finden Sie in der Dokumentation zu room-sqlite-wrapper.

Room- und SQLite-Webunterstützung

Die Unterstützung für die Kotlin Multiplatform-Ziele JS und WasmJS bringt einige der wichtigsten API-Änderungen mit sich. Viele APIs in Room 3.0 sind ausgesetzte Funktionen, da die ordnungsgemäße Unterstützung für Webspeicher asynchron ist. Die SQLiteDriver-APIs wurden ebenfalls aktualisiert, um das Web zu unterstützen. Ein neuer asynchroner Web-Treiber ist in androidx.sqlite:sqlite-web verfügbar. Es handelt sich um einen auf _Web Worker_ basierenden Treiber, mit dem die Datenbank im privaten Dateisystem des Ursprungs (Origin Private File System, OPFS) gespeichert werden kann.

Weitere Informationen zum Einrichten von Room für das Web finden Sie in den Versionshinweisen zu Room 3.0.

Benutzerdefinierte DAO-Rückgabetypen

Room 3.0 bietet die Möglichkeit, benutzerdefinierte Integrationen zu Room hinzuzufügen, ähnlich wie bei RxJava und Paging. Mit einer neuen Annotation-API namens @DaoReturnTypeConverter können Sie Ihre eigene Integration erstellen, sodass der generierte Code von Room zur Laufzeit zugänglich ist. So können @Dao Funktionen benutzerdefinierte Rückgabetypen haben, ohne dass das Room-Team die Unterstützung hinzufügen muss. Bestehende Integrationen werden migriert, um diese Funktion zu verwenden. Daher müssen Nutzer, die darauf angewiesen sind, die Konverter jetzt den Definitionen @Database oder @Dao hinzufügen.

Der Paging-Konverter befindet sich beispielsweise im Artefakt androidx.room3:room3-paging und heißt PagingSourceDaoReturnTypeConverter. Für LiveData befindet sich der Konverter in androidx.room3:room3-livedata und heißt LiveDataDaoReturnTypeConverter.

Weitere Informationen finden Sie im Abschnitt „DAO Return Type Converters“ (Konverter für DAO-Rückgabetypen) in den Versionshinweisen zu Room 3.0.

Wartungsmodus von Room 2.x

Da sich die Entwicklung von Room auf Room 3 konzentrieren wird, wechselt die aktuelle Version von Room 2.x in den Wartungsmodus. Das bedeutet, dass keine größeren Funktionen mehr entwickelt werden, aber Patch-Releases (2.8.1, 2.8.2 usw.) mit Fehlerkorrekturen und Abhängigkeitsupdates werden weiterhin veröffentlicht. Das Team wird diese Arbeit fortsetzen, bis Room 3 stabil ist.

Allgemeine Fragen

Wir sind unglaublich gespannt auf das Potenzial von Room 3.0 und die Möglichkeiten, die es für das Kotlin-Ökosystem bietet. Weitere Informationen folgen.