Room 3.0 – Modernisierung von Room

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

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

Funktionsgefährdende Ä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 zwei mögliche Back-Ends vermieden werden.
• Keine Java-Codegenerierung mehr:Room 3.0 generiert ausschließlich Kotlin-Code. Dies entspricht dem sich weiterentwickelnden Kotlin-First-Paradigma, vereinfacht aber auch die Codebasis und den Entwicklungsprozess, was schnellere Iterationen ermöglicht.
• Fokus auf KSP: Wir stellen auch die Unterstützung für Java Annotation Processing (AP) und KAPT ein. Room 3.0 ist ein reiner KSP-Prozessor (Kotlin Symbol Processing), der eine bessere Verarbeitung von Kotlin-Codebasen ermöglicht, ohne durch die Java-Sprache eingeschränkt zu sein.
• Coroutinen im Fokus: Room 3.0 setzt auf Kotlin-Coroutinen und macht seine APIs coroutinenorientiert. Koroutinen sind das KMP-kompatible asynchrone Framework. Die asynchrone Natur von Room ist eine wichtige Voraussetzung für die Unterstützung von Webplattformen.

Ein neues Paket

Um Kompatibilitätsprobleme mit vorhandenen Room 2.x-Implementierungen und für Bibliotheken mit transitiven Abhängigkeiten zu 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 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 Koroutinen zuerst

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-Plug-in und KSP angewendet werden können, ohne den Rest der Codebasis zu beeinträchtigen.

Room 3.0 erfordert außerdem Koroutinen. Genauer gesagt müssen DAO-Funktionen ausgesetzt werden, es sei denn, sie geben einen reaktiven Typ wie einen Flow zurück. Room 3.0 lässt das Blockieren von DAO-Funktionen nicht zu. Informationen zum Einbinden von Koroutinen in Ihre Anwendung finden Sie in der Dokumentation zu Koroutinen unter Android.

Migration zu SQLiteDriver APIs

Aufgrund der Abkehr von SupportSQLite müssen Apps zu den SQLiteDriver APIs migriert werden. Diese Migration ist wichtig, 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 ab sofort mit der Migration zu den Treiber-APIs beginnen, wenn Sie Room 2.7.0 oder höher verwenden. 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 Aufrufstellen erfordert.

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

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

Room SupportSQLite-Wrapper

Uns ist bewusst, dass es nicht für alle Projekte sofort möglich ist, SupportSQLite vollständig zu entfernen. 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 einer SQLiteDriver deaktiviert wurden. Dies ist 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 wichtige 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() im Builder von Room aufgerufen wird.

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

Room- und SQLite-Webunterstützung

Unterstützung für die Kotlin Multiplatform-Ziele JS und WasmJS und einige der wichtigsten API-Änderungen. Insbesondere sind viele APIs in Room 3.0 Sperrfunktionen, da die ordnungsgemäße Unterstützung für Webspeicher asynchron ist. Die SQLiteDriver APIs wurden ebenfalls aktualisiert, um das Web zu unterstützen. In androidx.sqlite:sqlite-web ist ein neuer asynchroner Webtreiber verfügbar. Es handelt sich um einen Web Worker-basierten Treiber, mit dem die Datenbank im 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

Mit Room 3.0 können Sie Room benutzerdefinierte Integrationen hinzufügen, ähnlich wie bei RxJava und Paging. Über eine neue Annotations-API namens @DaoReturnTypeConverter können Sie eine eigene Integration erstellen, sodass der von Room generierte Code zur Laufzeit zugänglich wird. Dadurch können @Dao-Funktionen ihre benutzerdefinierten Rückgabetypen haben, ohne dass Sie darauf warten müssen, dass das Room-Team die Unterstützung hinzufügt. Vorhandene Integrationen werden migriert, um diese Funktion zu verwenden. Daher müssen diejenigen, die sie verwenden, die Konverter den @Database- oder @Dao-Definitionen 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-Rückgabetyp-Konverter“ in den Versionshinweisen zu Room 3.0.

Wartungsmodus von Room 2.x

Da sich die Entwicklung von Room auf Room 3 konzentriert, wird die aktuelle Room 2.x-Version in den Wartungsmodus versetzt. Das bedeutet, dass keine wichtigen Funktionen entwickelt werden, aber Patch-Releases (2.8.1, 2.8.2 usw.) mit Fehlerkorrekturen und Abhängigkeitsupdates weiterhin veröffentlicht werden. Das Team wird so lange an diesem Problem arbeiten, bis Raum 3 stabil ist.

Schlussgedanken

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