Photo by Andreas Gücklhorn on Unsplash

In this article, we’ll explore the recommended approach for implementing Room in Kotlin Multiplatform (KMP) with Koin for dependency injection and the motivations behind each decision.

To visualise the Room implementation, we’ll build a screen using Compose Multiplatform (CMP) and launch the app on Android and iOS.

Getting started

To begin, we add the required dependencies to our libs.versions.toml file.

We then use these dependencies in our build.gradle.kts file, alongside using the Room plugin to declare the database schema directory.

Room setup

In common code, we create an entity to define the structure of the database table. In this article, we’re storing a list of movies.

Next, we set up a MovieDao to interact with the database. Using Flow makes the movie list reactive, and suspend functions ensure we don’t block the UI thread during database operations.

Still in common code, we create an abstract class that extends RoomDatabase and incorporates the entity and DAO. We also define a database constructor and link this to the database using the @ConstructedBy annotation.

The Room compiler will generate the actual implementations of the database constructor for us, so we add a @Suppress annotation to ignore any warnings related to this.

Database builder

The database requires a builder, and this is the only component in Room for KMP that requires platform-specific logic.

In androidMain, we create a function that takes in an Android Context to define a database path and uses this to return a database builder.

Similarly, in iosMain we create a function that uses NSFileManager and NSDocumentDirectory to define a database path and return a database builder.

Database creation

Back in commonMain, we define a function that takes in the platform-specific database builders and creates the database. For the database driver, we use the BundledSQLiteDriver — this is the recommended driver for Room KMP as it provides the most consistent and up-to-date version of SQLite across all platforms. The BundledSQLiteDriver also has the benefit of being usable in common code, which means we don’t have to specify a driver for each platform.

We also configure the database to use Dispatchers.IO for executing asynchronous queries, which is the recommended Dispatcher for database IO operations and ensures the queries won’t block the UI thread.

Koin setup

The final part of this Room KMP setup is using Koin to tie everything together. To start, we create a commonModule in commonMain to manage shared dependencies.

For platform-specific dependencies, we create a platformModule in commonMain using the expect / actual mechanism.

We implement this platformModule in androidMain using a provided Context value to create the database.

Implementing the platformModule in iosMain is simpler since it does not require a Context value.

Initialising Koin

Next, we define functions to initialise Koin on both platforms in our common code. As seen above, our Android platformModule requires a Context for the database builder. To provide this, we add a KoinAppDeclaration parameter to our initKoin function. We use this inside the startKoin function, which gives Koin modules access to the Context value.

We then create a new class in androidMain that extends Application and calls the initKoin function, passing the Android Context in.

To use this new MainApplication class, we are required to update the AndroidManifest.xml file.

Now we can define a function to initialise Koin for iOS, which doesn’t require a Context value. We encounter a quirk in KMP here, as function default values do not work in native iOS code, so we can’t simply call the initKoin function. To solve this, we define an initKoinIos function that passes in an empty lambda value for the appDeclaration parameter.

The initKoinIos function has to be called in native Swift code. To do this, we use the file name of the function and the function name with the do value prepended. We also import ComposeApp to give the Swift code access to the function.

Next, we create a MovieViewModel and inject our MovieDao in. The MovieDao is injected straight into the ViewModel here to keep things simple for this article. In production code, the app layering would be more robust, and the MovieDao would be injected into a repository or a data source.

We also add a private MutableStateFlow backing field to store the movie name value.

State production

To produce the UI state, we combine the Flow list of movies with the MutableStateFlow movie name field.

The stateIn operator is the recommended way to produce UI state from reactive streams. A key reason for this is because it allows state production to start only when collection begins in the UI, instead of occurring as soon as the ViewModel is created if the init{} function is used. This gives you more control over the ViewModel and uiState, making it easier to test.

The stateIn operator also gives us finer-grained control over the state production behaviour through the started parameter. This can be set to either SharingStarted.WhileSubscribed if the state should only be active when the UI is visible, or SharingStarted.Lazily if the state should be active as long as the user may return to the UI.

Finalising the ViewModel

To complete the ViewModel, we provide three functions to update the state.

We also add the ViewModel to our Koin commonModule, allowing us to inject it into our screen.

Movie screen

With the ViewModel set up, the next step is to create the screen. It is recommended practice to create both a stateful and a stateless version of each screen in your app, as it makes them more reusable, easier to test, and simpler to preview.

We first create the stateful screen by injecting the ViewModel using Koin and collecting the UI state. We then pass the UI state and the state updating functions into the stateless screen.

We then create the stateless screen, using a Scaffold to ensure proper inset padding.

Inside the Column, we add two Composables that enable the user to add a movie to the Room database.

To display the movies, we define a MovieItem and use this within a LazyColumn to create a scrollable list of movies.

To clear the movies list, we create a button and hook this up to the onDeleteMovies function.

To make the MovieScreen reachable within the app, we simply add it to the base App Composable. In a production app, you would instead integrate this MovieScreen into your existing navigation logic.

App deployment

We can now deploy the finished app to both platforms, starting with Android.

Running the app on iOS produces the same behaviour, and validates that the Room implementation is functioning correctly on both platforms! 🎉

This article is previously published on proandroiddev.com.