Die erste Alphaversion von Room 3.0 ist da. 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 vorhandenen Unterstützung für Android, iOS und JVM-Desktop auch Unterstützung für JavaScript und WebAssembly (WASM). 

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

Nicht abwärtskompatible Änderungen

Room 3.0 enthält die folgenden funktionsgefährdenden API-Änderungen: 

• SupportSQLite-APIs werden nicht mehr unterstützt: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 zwei mögliche Back-Ends gibt.
• Keine Java-Codegenerierung mehr:In Room 3.0 wird ausschließlich Kotlin-Code generiert. Dies entspricht dem sich entwickelnden Kotlin-First-Paradigma, vereinfacht aber auch die Codebasis und den Entwicklungsprozess und ermöglicht so schnellere Iterationen.
• Fokus auf KSP:Wir stellen auch die Unterstützung für die Java-Annotationsverarbeitung (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 unterstützt Kotlin-Coroutinen und die APIs sind auf Coroutinen ausgerichtet. Coroutines ist das KMP-kompatible asynchrone Framework. Room von Natur aus asynchron zu machen, ist eine wichtige Voraussetzung für die Unterstützung von Webplattformen.

Ein neues Paket

Um Kompatibilitätsprobleme mit vorhandenen 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, dass es auch eine neue Maven-Gruppe und neue Artefakt-IDs hat. Beispiel: androidx.room:room-runtime ist jetzt androidx.room3:room3-runtime und Klassen wie androidx.room.RoomDatabase befinden sich jetzt unter androidx.room3.RoomDatabase.

Kotlin und Koroutinen im Fokus

Da kein Java-Code mehr generiert wird, sind für Room 3.0 auch KSP und der Kotlin-Compiler erforderlich, 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-Plugin und KSP angewendet werden können, ohne den Rest des Quellcodes zu beeinträchtigen.

Room 3.0 erfordert auch Coroutines. Insbesondere müssen DAO-Funktionen „suspending“ sein, es sei denn, sie geben einen reaktiven Typ wie einen Flow zurück. In Room 3.0 ist das Blockieren von DAO-Funktionen nicht zulässig. Informationen zu den ersten Schritten bei der Integration von Koroutinen in Ihre Anwendung finden Sie in der Dokumentation zu Koroutinen in Android.

Migration zu SQLiteDriver-APIs

Da SupportSQLite nicht mehr verwendet wird, müssen Apps zur SQLiteDriver API migriert werden. Diese Migration ist unerlässlich, um die Vorteile von Room 3.0 voll auszuschöpfen, einschließlich der Möglichkeit, die gebündelte SQLite-Bibliothek über BundledSQLiteDriver zu verwenden. Sie können jetzt mit Room 2.7.0+ mit der Migration zu den Treiber-APIs beginnen. 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 erforderlich sind.

Eine kurze Übersicht über die SQLiteDriver-APIs finden Sie in der Dokumentation zu 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 es nicht immer sofort möglich ist, SupportSQLite vollständig zu entfernen. Um diese Umstellung 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 ein RoomDatabase in ein 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 vorhanden, um die Migration zu Room 3.0 zu ermöglichen und gleichzeitig die kritische SupportSQLite-Nutzung zu unterstützen.

Aufrufe von roomDatabase.openHelper.writableDatabase können beispielsweise 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 zum 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 suspend-Funktionen, da die 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 for the Web finden Sie in den Versionshinweisen zu Room 3.0.

Benutzerdefinierte DAO-Rückgabetypen

Mit Room 3.0 können benutzerdefinierte Integrationen in Room hinzugefügt werden, ähnlich wie bei RxJava und Paging. Mit einer neuen Annotations-API namens @DaoReturnTypeConverter können Sie Ihre eigene Integration erstellen, sodass der von Room generierte Code zur Laufzeit zugänglich ist. Dadurch 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 nutzen. Nutzer, die darauf angewiesen sind, müssen die Konverter daher den @Database- oder @Dao-Definitionen hinzufügen.

Der Paging-Converter befindet sich beispielsweise im androidx.room3:room3-paging-Artefakt 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“ in den Versionshinweisen zu Room 3.0.

Wartungsmodus von Room 2.x

Da sich die Entwicklung von Room auf Room 3 konzentrieren wird, wird die aktuelle Room 2.x-Version in den Wartungsmodus versetzt. Das bedeutet, dass keine wichtigen 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 sich dieser Aufgabe widmen, bis Room 3 stabil ist.

Allgemeine Fragen

Wir sind unglaublich gespannt auf das Potenzial von Room 3.0 und die Möglichkeiten, die sich dadurch für das Kotlin-Ökosystem ergeben. Wir halten Sie auf dem Laufenden.