Buildinga Reactive Data Layer with Android Room and Kotlin Flow

Android apps are only as fast as their data layer. If you’re still using LiveData or manual threading, you’re leaving performance on the table.

Context
For the past decade I’ve shipped 22+ apps from Bangkok, and I’ve seen the same pattern repeat: a Room database built for CRUD, a ViewModel exposing LiveData, and UI components that observe that LiveData. The result is tight coupling, hard‑to‑test code, and UI jitter when data changes. Kotlin Flow gives us a clean, cold‑stream approach that pairs naturally with Room’s suspend APIs. In this post I’ll show you how to wire Room directly into a Flow‑based repository, expose it from a ViewModel, and consume it in Jetpack Compose without any boilerplate. You’ll walk away with a production‑ready reactive data layer you can drop into any Android project today.

Why Reactive Data Layers Matter

Traditional Android architectures rely on LiveData or RxJava to push UI updates. While functional, they introduce several pain points:

[!TIP] Use Flow when you need fine‑grained control over data emission and want to avoid unnecessary recompositions.

[!NOTE] Flow works best when the underlying data source is already suspend‑capable, which is exactly what Room provides.

The real benefit appears when you combine Room’s

@Query

Integrating Room with Kotlin Flow

First, define a DAO that returns a Flow. Room can turn any

suspend

List<Entity>

@Dao
interface UserDao {
    @Query("SELECT * FROM user")
    fun getAllUsers(): Flow<List<User>>
    
    @Insert(onConflict = OnConflictStrategy.REPLACE)
    suspend fun insert(user: User)
    
    @Delete
    suspend fun delete(user: User)
}

Next, create a Repository that exposes the DAO’s Flow as the single source of truth.

class UserRepository(private val dao: UserDao) {
    // Public Flow that UI will collect
    val allUsers: Flow<List<User>> = dao.getAllUsers()
        .flowOn(Dispatchers.IO)          // Ensure DB work runs off the main thread
        .catch { throw it }               // Propagate errors downstream
}

Now, the ViewModel simply exposes the repository’s Flow as

StateFlow

@HiltViewModel
class UserViewModel @Inject constructor(
    private val repository: UserRepository
) : ViewModel() {

    // Transform the cold Flow into a hot StateFlow
    val users: StateFlow<List<User>> = repository.allUsers
        .stateIn(viewModelScope, SharingStarted.WhileSubscribed(5000), emptyList())
}

[!IMPORTANT]

code Copy

stateIn

is the key operator that turns a Flow into a StateFlow while respecting the ViewModel’s lifecycle.

Persisting and Updating Data

Because the DAO methods are

suspend

fun addUser(name: String, age: Int) {
    viewModelScope.launch {
        repository.insert(User(name = name, age = age))
    }
}

If you need to combine streams — say, fetch users and also listen to a sync flag — use

zip

combine

val usersWithSync: Flow<List<User>> = repository.allUsers
    .combine(latestSyncFlag) { users, sync -> /* combine logic */ }

[!WARNING] Never collect a Flow on the main thread; always use

code Copy

Dispatchers.IO

or

code Copy

viewModelScope

to keep UI responsive.

Consuming Flow in Compose UI

Jetpack Compose loves StateFlow. The UI layer simply collects the flow as state, which triggers recomposition only when the list actually changes.

@Composable
fun UserScreen(viewModel: UserViewModel = hiltViewModel()) {
    val users by viewModel.users.collectAsState()

    LazyColumn {
        items(users) { user ->
            UserRow(user = user)
        }
    }
}

If you want to react to a single item update, you can expose a separate Flow from the repository (e.g.,

Flow<User>

[!NOTE]

code Copy

collectAsState()

automatically manages the coroutine scope and cancels collection when the composable leaves the composition, preventing leaks.

Real‑World Example: Syncing with a Remote API

A common pattern is to keep a local cache (Room) and periodically refresh it from a network layer. Here’s a concise example:

class SyncRepository(
    private val dao: UserDao,
    private val api: UserApi
) {
    val freshUsers: Flow<List<User>> = flow {
        // 1️⃣ Refresh from network
        val remote = api.getUsers()
        // 2️⃣ Insert into Room (suspend)
        dao.insertAll(remote.toEntityList())
        // 3️⃣ Emit the updated list
        emit(dao.getAllUsers())
    }
        .flowOn(Dispatchers.IO)
        .catch { /* handle network errors */ }
}

The UI can observe

freshUsers

Testing the Flow Layer

Testing Flow‑based code is straightforward with the

runTest

@Test
fun `repository emits updated list after insert`() = runTest {
    // Given
    val dao = mockk<UserDao>()
    val repo = UserRepository(dao)
    val mutableList = mutableListOf<User>()
    coEvery { dao.getAllUsers() } returns flowOf(mutableList)

    // When
    repo.insert(User(name = "Alice", age = 30))

    // Then
    val emitted = advanceUntilIdle()
    assertThat(emitted).hasSize(1)
    assertThat(emitted.first()).containsExactly(User(name = "Alice", age = 30))
}

[!TIP] Use

code Copy

advanceUntilIdle()

to let all pending flow emissions complete before asserting.

Key Takeaways

• Leverage Flow for cold, lifecycle‑aware streams – it eliminates the need for manual observer management.
• Convert Flow to StateFlow with
  code Copy

  stateIn

  to expose a UI‑friendly observable state from a Repository.
• Collect Flow in Compose via
  code Copy

  collectAsState()

  – the UI updates only when the underlying data actually changes.
• Keep DB operations on
  code Copy

  Dispatchers.IO

  and use
  code Copy

  viewModelScope

  for coroutine execution to maintain responsiveness.
• Test Flow logic with
  code Copy

  runTest

  – the same tools you use for regular coroutines work seamlessly with Room’s Flow.

By adopting Kotlin Flow alongside Android Room, you gain a reactive, testable, and performant data layer that scales with the complexity of modern Android applications. Start integrating Flow today, and watch your apps become faster, more reliable, and easier to maintain.