5 Reasons to consider MVI Architecture in your android projects

Madhan — Sat, 07 Dec 2024 11:18:05 +0000

As Android developers, many of us are well aware with MVVM (Model-View-ViewModel), a tried-and-true architecture that simplifies state management and UI interaction. But what if there’s an architecture that can take predictability, scalability, and state management to the next level?

Yes, MVI (Model-View-Intent) — an architecture gaining traction for its unidirectional data flow and predictable state management.

You may heard about MVI before but hesitated to use it, you’re not alone. Even I hesitated to switch to MVI while MVVM is working fine for me.

However, MVI addresses several limitations of MVVM, especially in scenarios involving complex UI interactions, state restoration, clear Code separation, and much more.

In this blog, I aim to break down some of the advantages that impress me to make a switch.

I hope I will convince you to consider MVI architecture for your next Android projects. Whether you're managing intricate UI states for a cleaner separation of concerns, MVI provides a structured, scalable approach that minimizes side effects and maximizes maintainability.

So I made a list of common pain points for most of the android developers who uses MVVM.

And it might be the architectural upgrade to your project's need.

By the end of this blog, I'll walk you through how to set up MVI architecture in your project. You can use it as a reference and build your project around it.

Okay Let’s start,

1. Predictable State Management

MVI enforces a single source of truth for UI state, represented as an immutable data class. In Jetpack Compose, this works well because the UI automatically recomposes whenever the state changes.

In MVVM, the state is often scattered across multiple LiveData or StateFlow objects, increasing the complexity of managing consistency.

Managing State with `StateFlow` with MVI

// State: Immutable representation of the UI
data class UiState(
    val isLoading: Boolean = false,
    val data: List<String> = emptyList(),
    val error: String? = null
)

// ViewModel: Holds and updates the state
class MyViewModel : ViewModel() {
    private val _state = MutableStateFlow(UiState())
    val state: StateFlow<UiState> = _state

    fun fetchData() {
        viewModelScope.launch {
            _state.value = _state.value.copy(isLoading = true)
            try {
                val data = repository.getData()
                _state.value = _state.value.copy(isLoading = false, data = data)
            } catch (e: Exception) {
                _state.value = _state.value.copy(isLoading = false, error = e.message)
            }
        }
    }
}

// UI: Composable rendering of the state
@Composable
fun MyScreen(viewModel: MyViewModel) {
    val state by viewModel.state.collectAsState()

    when {
        state.isLoading -> CircularProgressIndicator()
        state.error != null -> Text("Error: ${state.error}")
        else -> LazyColumn {
            items(state.data) { item ->
                Text(item)
            }
        }
    }
}

This ensures a single source of truth for the UI, making debugging easier.

2. Unidirectional Data Flow

In MVI, data flows in a single, predictable direction:

Intent (user action) → ViewModel (logic) → State → Composable UI.

This clear separation eliminates issues found in MVVM, such as bidirectional bindings causing unexpected state changes or infinite loops.

Handling User Intents for Unidirectional

sealed class UiIntent {
    object LoadData : UiIntent()
    data class Search(val query: String) : UiIntent()
}

class MyViewModel : ViewModel() {
    private val _state = MutableStateFlow(UiState())
    val state: StateFlow<UiState> = _state

    fun handleIntent(intent: UiIntent) {
        when (intent) {
            is UiIntent.LoadData -> fetchData()
            is UiIntent.Search -> search(intent.query)
        }
    }

    private fun fetchData() { /* Logic to fetch data */ }
    private fun search(query: String) { /* Logic to filter data */ }
}

@Composable
fun MyScreen(viewModel: MyViewModel) {
    val state by viewModel.state.collectAsState()

    Column {
        TextField(
            value = "",
            onValueChange = { viewModel.handleIntent(UiIntent.Search(it)) },
            placeholder = { Text("Search...") }
        )
        LazyColumn {
            items(state.data) { item -> Text(item) }
        }
    }
}

By encapsulating user actions as intents, the data flow remains predictable and avoids issues like race conditions or unintended UI states.

4. Simplified State Restoration

In MVI, restoring the UI state during configuration changes or process death is straightforward. Since the entire UI state is stored in a single data object, it can be saved and restored easily. MVVM requires handling multiple variables or states individually, which adds complexity.

5. Clear Separation of Concerns

MVI naturally separates concerns into:

Intent: The user initiates an action (e.g., clicking a button).
ViewModel (Logic): Receives the intent, processes it, and emits a new state.
State: The updated state is sent to the UI.
UI: Reacts to the new state by recomposing and rendering the updated view.

This separation ensures:

Predictability: UI behavior is tied directly to a single source of truth (state).
Testability: You can test each component (intents, state updates, UI) independently.
Maintainability: Each concern has a well-defined responsibility, reducing coupling and improving clarity.

Here is the complete code overview of MVI architecture for your next Android project.

// State
data class UiState(val isLoading: Boolean, val items: List<String>, val error: String?)

// Intent
sealed class UiIntent {
    object LoadData : UiIntent()
    data class DeleteItem(val id: String) : UiIntent()
}

// ViewModel
class MyViewModel : ViewModel() {
    private val _state = MutableStateFlow(UiState(isLoading = false, items = emptyList(), error = null))
    val state: StateFlow<UiState> = _state

    fun handleIntent(intent: UiIntent) {
        when (intent) {
            is UiIntent.LoadData -> loadData()
            is UiIntent.DeleteItem -> deleteItem(intent.id)
        }
    }

    private fun loadData() { /* logic */ }
    private fun deleteItem(id: String) { /* logic */ }
}

// Composable UI
@Composable
fun MyScreen(viewModel: MyViewModel) {
    val state by viewModel.state.collectAsState()

    if (state.isLoading) {
        CircularProgressIndicator()
    } else {
        LazyColumn {
            items(state.items) { item ->
                Row {
                    Text(item)
                    IconButton(onClick = { viewModel.handleIntent(UiIntent.DeleteItem(item)) }) {
                        Icon(Icons.Default.Delete, contentDescription = "Delete")
                    }
                }
            }
        }
    }
}

This clear separation ensures the UI is solely responsible for rendering, the ViewModel handles all logic, and the state remains predictable and centralized.

Conclusion

As we learned the importance of MVI architecture, I hope now you know why you need to learn and switch to MVI. But one thing you need to consider while considering the MVI architecture is that if you are working with smaller projects, you may stick with MVVM because of its simplicity, but MVI suits your larger projects. As we discussed, all the limitations will be addressed by MVI.

I believe you found value in this blog post. If so follow me for more content based on Android development and Productivity Hacks.

Forem: Madhan