Posted by Daniel Santiago Rivera, Software program Engineer
The primary alpha of Room 3.0 has been launched! Room 3.0 is a significant breaking model of the library that focuses on Kotlin Multiplatform (KMP) and provides assist for JavaScript and WebAssembly (WASM) on prime of the prevailing Android, iOS and JVM desktop assist.
On this weblog we define the breaking adjustments, the reasoning behind Room 3.0, and the varied issues you are able to do emigrate from Room 2.0.
Room 3.0 contains the next breaking API adjustments:
- Dropping SupportSQLite APIs: Room 3.0 is totally backed by the androidx.sqlite driver APIs. The SQLiteDriver APIs are KMP-compatible and eradicating Room’s dependency on Android’s API simplifies the API floor for Android because it avoids having two doable backends.
- No extra Java code era: Room 3.0 solely generates Kotlin code. This aligns with the evolving Kotlin-first paradigm but in addition simplifies the codebase and growth course of, enabling quicker iterations.
- Give attention to KSP: We’re additionally dropping assist for Java Annotation Processing (AP) and KAPT. Room 3.0 is solely a KSP (Kotlin Image Processing) processor, permitting for higher processing of Kotlin codebases with out being restricted by the Java language.
- Coroutines first: Room 3.0 embraces Kotlin coroutines, making its APIs coroutine-first. Coroutines is the KMP-compatible asynchronous framework and making Room be asynchronous by nature is a important requirement for supporting internet platforms.
To stop compatibility points with present Room 2.x implementations and for libraries with transitive dependencies to Room (for instance, WorkManager), Room 3.0 resides in a brand new bundle which implies it additionally has a brand new maven group and artifact ids. For instance, androidx.room:room-runtime has turn into androidx.room3:room3-runtime and courses similar to androidx.room.RoomDatabase will now be situated at android.room3.RoomDatabase.
With no extra Java code era, Room 3.0 additionally requires KSP and the Kotlin compiler even when the codebase interacting with Room is in Java. It’s endorsed to have a multi-module mission the place Room utilization is concentrated and the Kotlin Gradle Plugin and KSP may be utilized with out affecting the remainder of the codebase.
Room 3.0 additionally requires Coroutines and extra particularly DAO features must be suspending until they’re returning a reactive kind, similar to a Circulation. Room 3.0 disallows blocking DAO features. See the Coroutines on Android documentation on getting began integrating Coroutines into your utility.
With the shift away from SupportSQLite, apps might want to migrate to the SQLiteDriver APIs. This migration is crucial to leveraging the complete advantages of Room 3.0, together with permitting the usage of the bundled SQLite library through the BundledSQLiteDriver. You can begin migrating to the driving force APIs at this time with Room 2.7.0+. We strongly encourage you to keep away from any additional utilization of SupportSQLite. Should you migrate your Room integrations to SQLiteDriver APIs, then the transition to Room 3.0 is less complicated for the reason that bundle change largely includes updating image references (imports) and would possibly require minimal adjustments to call-sites.
We perceive fully eradicating SupportSQLite won’t be instantly possible for all tasks. To ease this transition, Room 2.8.0, the most recent model of the Room 2.0 collection, launched a brand new artifact known as androidx.room:room-sqlite-wrapper. This artifact provides a compatibility API that means that you can convert a RoomDatabase right into a SupportSQLiteDatabase, even when the SupportSQLite APIs within the database have been disabled attributable to a SQLiteDriver being put in. This offers a brief bridge for builders who want extra time to completely migrate their codebase. This artifact continues to exist in Room 3.0 as androidx.room3:room3-sqlite-wrapper to allow the migration to Room 3.0 whereas nonetheless supporting important SupportSQLite utilization.
For instance, invocations of Database.openHelper.writableDatabase may be changed by roomDatabase.getSupportWrapper() and a wrapper can be offered even when setDriver() is known as on Room’s builder.
Help for the Kotlin Multiplatform targets JS and WasmJS and brings a few of the most important API adjustments. Particularly, many APIs in Room 3.0 are droop features since correct assist for internet storage is asynchronous. The SQLiteDriver APIs have additionally been up to date to assist the Internet and a brand new internet asynchronous driver is offered in androidx.sqlite:sqlite-web. It’s a Internet Employee based mostly driver that allows persisting the database within the Origin personal file system (OPFS).
Room 3.0 introduces the power so as to add customized integrations to Room much like RxJava and Paging. Via a brand new annotation API known as @DaoReturnTypeConverter you’ll be able to create your individual integration such that Room’s generated code turns into accessible at runtime, this permits @Dao features having their customized return sorts with out having to attend for the Room group so as to add the assist. Present integrations are migrated to make use of this performance and thus will now require for many who depend on it so as to add the converters to the @Database or @Dao definitions.
For instance, the Paging converter will likely be situated within the android.room3:room3-paging artifact and it is known as PagingSourceDaoReturnTypeConverter. In the meantime for LiveData the converter is in android.room3:room3-livedata and is known as LiveDataReturnTypeConverter.
Because the growth of Room will likely be targeted on Room 3, the present Room 2.x model enters upkeep mode. Because of this no main options will likely be developed however patch releases (2.8.1, 2.8.2, and so on.) will nonetheless happen with bug fixes and dependency updates. The group is dedicated to this work till Room 3 turns into secure.
We’re extremely excited concerning the potential of Room 3.0 and the alternatives it unlocks for the Kotlin ecosystem. Keep tuned for extra updates as we proceed this journey!