Modern Android development stands on the shoulders of many architectural patterns. Each one emerged to address problems of the previous approach, especially around coupling between UI and logic and managing state across lifecycle events. This article traces that evolution step-by-step, illustrating how Android developers moved from “everything in the Activity” to more decoupled, testable patterns.

1. The Early Days: UI-Centric (God Activity)

What It Is

Early Android apps often threw all logic — business logic, UI updates, and state management — into one Activity or Fragment. This was sometimes erroneously labeled “MVC,” but in practice, there was no separate Controller file. Everything lived in the same UI class, leading to “God Activities.”

Example (Counter App)

class MainActivity : AppCompatActivity() {
    private var count = 0
    private lateinit var countTextView: TextView

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)

        countTextView = findViewById(R.id.countTextView)

        findViewById<Button>(R.id.incrementButton).setOnClickListener {
            // Business logic + UI in the same place
            count++
            updateView()
        }
    }

    private fun updateView() {
        countTextView.text = count.toString()
    }
}

Shortcomings

• Tight Coupling: The UI class owns everything — difficult to expand or test.
• Difficult Testing: All logic is in an Activity that depends on Android framework code.
• State Loss: Rotations recreate the Activity, losing the count unless you manually handle it.
• No Separation of Concerns: Business logic and UI code are interwoven.

2. Classic MVC: Introducing a Separate Controller

Model–View–Controller (MVC) is the next step. Instead of dumping everything in the Activity, we introduce a dedicated controller class that sits between the UI and the data Model. The Activity (or Fragment) still represents the View, but we now have:

• A Model (e.g., CounterModel) to hold data and operations.
• A Controller that orchestrates data retrieval/updates.
• The View (the Activity) that renders the data and forwards user input.

The Activity serves as the View, while a distinct Controller class references both the View and the Model. This is a step up from the UI-centric approach: at least we have a separate logic class.

Base MVC Example (Without Loaders)

// Model
class CounterModel {
    private var count = 0
    fun increment() { count++ }
    fun getCount(): Int = count
}

// The "Controller" references a concrete Activity as the View
class CounterController(
    private val view: MainActivity, // Direct link to Activity (the View)
    private val model: CounterModel
) {
    fun onIncrementClicked() {
        model.increment()
        view.updateCounter(model.getCount())
    }
}

// The Activity as "View"
class MainActivity : AppCompatActivity() {
    private lateinit var controller: CounterController
    private lateinit var model: CounterModel
    private lateinit var countTextView: TextView

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)

        countTextView = findViewById(R.id.countTextView)

        model = CounterModel()
        controller = CounterController(this, model)

        findViewById<Button>(R.id.incrementButton).setOnClickListener {
            controller.onIncrementClicked()
        }
    }

    fun updateCounter(count: Int) {
        countTextView.text = count.toString()
    }
}

Adding a Loader to Retain the Controller (Legacy Approach)

Before ViewModel existed, developers commonly used LoaderManager or retained Fragments to keep the Controller alive across rotations.

However, today’s ViewModel is a simpler approach, which we’ll cover in the MVVM section.

Below is an example of how we’d keep our controller instance around.

// 1) Create a Loader to hold the Controller
class ControllerLoader(
    context: Context,
    private val initialView: MainActivity
) : Loader<CounterController>(context) {

    private var controller: CounterController? = null

    override fun onStartLoading() {
        if (controller == null) {
            // Create a fresh Model and Controller the first time
            val model = CounterModel()
            controller = CounterController(initialView, model)
        }
        // Deliver the existing controller (if any)
        controller?.let { deliverResult(it) }
    }
}

// 2) Activity: Using the Loader to persist Controller
class MainActivity : AppCompatActivity() {
    companion object {
        private const val LOADER_ID = 1001
    }

    private var controller: CounterController? = null
    private lateinit var countTextView: TextView

    private val loaderCallbacks = object : LoaderManager.LoaderCallbacks<CounterController> {
        override fun onCreateLoader(id: Int, args: Bundle?): Loader<CounterController> {
            return ControllerLoader(this@MainActivity, this@MainActivity)
        }
        override fun onLoadFinished(loader: Loader<CounterController>, data: CounterController?) {
            // We have our controller (could be newly created or retained)
            controller = data
        }
        override fun onLoaderReset(loader: Loader<CounterController>) {
            // Called if the Loader is reset or destroyed
            controller = null
        }
    }

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)

        countTextView = findViewById(R.id.countTextView)

        // Init or reattach the Loader that holds our Controller
        loaderManager.initLoader(LOADER_ID, null, loaderCallbacks)

        findViewById<Button>(R.id.incrementButton).setOnClickListener {
            controller?.onIncrementClicked()
        }
    }

    fun updateCounter(count: Int) {
        countTextView.text = count.toString()
    }
}

How It Works:

• ControllerLoader is responsible for creating and holding onto the CounterController.
• On rotation, LoaderManager reattaches the same loader, so the same CounterController instance is retained.
• The result is an MVC setup that can survive rotations — albeit with extra boilerplate.

Why MVC Is Still Limited

1. Strong Coupling: The Controller knows about MainActivity by name.
2. Testing Challenges: The Controller depends on a real Android class (MainActivity).
3. Loader Boilerplate: Even with Loaders, you still have more manual code to handle rotations.

3. MVP: Breaking the Direct Coupling with a View Interface

What It Is

Model–View–Presenter (MVP) emerged as a response to the coupling issue in classic MVC. Instead of referencing the concrete Activity or Fragment as the View, the Presenter only knows a View interface. That interface is then implemented by the Activity. This effectively breaks the direct link between the Presenter and an Android class.

Base MVP Example (Without Loaders)

// Model
class CounterModel {
    private var count = 0
    fun increment() { count++ }
    fun getCount(): Int = count
}

// View Interface
interface CounterView {
    fun updateCount(count: Int)
    fun showError(message: String)
}

// Presenter
class CounterPresenter(private val model: CounterModel) {
    private var view: CounterView? = null

    fun attachView(view: CounterView) {
        this.view = view
        view.updateCount(model.getCount())
    }

    fun detachView() {
        this.view = null
    }

    fun onIncrementClicked() {
        model.increment()
        view?.updateCount(model.getCount())
    }
}

// Activity implementing the View interface
class MainActivity : AppCompatActivity(), CounterView {
    private lateinit var presenter: CounterPresenter

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)

        presenter = CounterPresenter(CounterModel())
        presenter.attachView(this)

        findViewById<Button>(R.id.incrementButton).setOnClickListener {
            presenter.onIncrementClicked()
        }
    }

    override fun updateCount(count: Int) {
        findViewById<TextView>(R.id.countTextView).text = count.toString()
    }

    override fun showError(message: String) {
        Toast.makeText(this, message, Toast.LENGTH_SHORT).show()
    }

    override fun onDestroy() {
        super.onDestroy()
        presenter.detachView()
    }
}

Presenter -> View (interface) <- MainActivity

// ViewModel
class CounterViewModel : ViewModel() {
    private val _counter = MutableStateFlow(0)
    val counter: StateFlow<Int> = _counter.asStateFlow()

    fun increment() {
        _counter.value++
    }
}

@Composable
fun CounterScreen(viewModel: CounterViewModel = viewModel()) {
    val count by viewModel.counter.collectAsState()

    Column(
        modifier = Modifier.fillMaxSize(),
        horizontalAlignment = Alignment.CenterHorizontally,
        verticalArrangement = Arrangement.Center
    ) {
        Text(text = count.toString())
        Button(onClick = { viewModel.increment() }) {
            Text("Increment")
        }
    }
}

// 1) State: Single source of truth for the UI
data class CounterState(
    val count: Int = 0,
    val error: String? = null
)

// 2) Intents: All possible user actions
sealed interface CounterIntent {
    object Increment : CounterIntent
    object Reset : CounterIntent
    data class SetCount(val value: Int) : CounterIntent
}

// 3) ViewModel in MVI style
class CounterMviViewModel : ViewModel() {

    // Internal MutableStateFlow
    private val _state = MutableStateFlow(CounterState())
    // Exposed as a read-only StateFlow
    val state: StateFlow<CounterState> = _state.asStateFlow()

    /**
     * The "Reducer": We can define it inline here, or as a separate function.
     * 
     * In simpler MVI, the reducer is simply the logic inside 'processIntent'
     * that takes the current state and returns a new state. For clarity,
     * you could extract the below `when` branches into a smaller reduce(...) function.
     */
    fun processIntent(intent: CounterIntent) {
        _state.update { oldState ->
            when (intent) {
                is CounterIntent.Increment -> oldState.copy(count = oldState.count + 1, error = null)
                is CounterIntent.Reset     -> oldState.copy(count = 0, error = null)
                is CounterIntent.SetCount  -> {
                    if (intent.value >= 0) {
                        oldState.copy(count = intent.value, error = null)
                    } else {
                        oldState.copy(error = "Negative counts not allowed")
                    }
                }
            }
        }
    }
}

// 4) Composable "View" observing the StateFlow
@Composable
fun CounterMviScreen(viewModel: CounterMviViewModel = viewModel()) {
    // Collect the current state from our MVI ViewModel
    val uiState by viewModel.state.collectAsState()

    Column(
        modifier = Modifier.fillMaxSize(),
        horizontalAlignment = Alignment.CenterHorizontally,
        verticalArrangement = Arrangement.Center
    ) {
        Text(text = uiState.count.toString())

        // Show an error if any
        uiState.error?.let { error ->
            Text(
                text = error,
                color = Color.Red
            )
        }

        Spacer(modifier = Modifier.height(16.dp))

        Row(horizontalArrangement = Arrangement.spacedBy(8.dp)) {
            Button(onClick = { viewModel.processIntent(CounterIntent.Increment) }) {
                Text("Increment")
            }
            Button(onClick = { viewModel.processIntent(CounterIntent.Reset) }) {
                Text("Reset")
            }
        }

        Spacer(modifier = Modifier.height(16.dp))

        // Example: Setting a specific count
        Button(onClick = { viewModel.processIntent(CounterIntent.SetCount(5)) }) {
            Text("Set Count to 5")
        }
    }
}

5.2 A Redux-like MVI Flavor with BaseViewModel Approach

Traditional MVVM already keeps business logic in the ViewModel, but MVI goes a step further by:

• Enforcing Unidirectional Flow: All updates come in as Intents, pass through a Reducer, and yield a new State.
• Centralizing State: You have one “source of truth” for the screen’s data.
• Explicit Intent Handling: Each user interaction is modeled explicitly.
• Pure Reducer: The function that updates State is a pure function — great for testing.

If you’ve worked with Redux in JavaScript, you’ll notice parallels. Even if not, think of it as a clear pipeline for user actions → state changes.

Why Go “Redux-Like”?

• Explicit Intent Handling: Each user action is a typed Intent, making it easy to track.
• Single Source of Truth: The State object is the one authoritative representation of the screen’s data.
• Predictable: By funneling changes through a single Reducer, you can systematically track state changes over time.
• Scalable: As your app grows, it’s easier to add advanced features (e.g., side effects, asynchronous data loading) because the pattern remains consistent.

5.2.1 Structuring the Code with a Base ViewModel

In more complex apps, each screen can define its own State, Intent, and optional Effect. To avoid duplicating code for flows and handlers, you can create a BaseMviViewModel that holds:

1. A StateFlow for the screen’s state.
2. A SharedFlow for ephemeral effects (e.g., Toasts, navigation).
3. A reduce function you override in each child ViewModel.

/**
 * A generic base for Redux-like MVI in Android.
 * @param S The screen's State type
 * @param I The screen's Intent type
 * @param E One-off Effects that the UI handles exactly once
 */
abstract class BaseMviViewModel<S, I, E>(
    initialState: S
) : ViewModel() {

    // The current immutable State
    private val _viewState = MutableStateFlow(initialState)
    val viewState: StateFlow<S> = _viewState.asStateFlow()

    // For ephemeral effects like Toasts or navigation
    private val _viewEffect = MutableSharedFlow<E>(replay = 0)
    val viewEffect: SharedFlow<E> = _viewEffect

    // Convenient way to read the latest state
    protected val currentState: S
        get() = _viewState.value

    /**
     * Called by the UI (or internal code) whenever an Intent occurs.
     *  1) We run the 'reduce' function with (oldState + intent).
     *  2) We update the StateFlow with the new State.
     *  3) If there's an effect, we emit it for the UI to consume.
     */
    fun processIntent(intent: I) {
        val (newState, effect) = reduce(currentState, intent)
        setState(newState)
        effect?.let { postEffect(it) }
    }

    /**
     * The child ViewModel implements how to combine oldState + Intent.
     * The result is (newState, optionalEffect).
     */
    protected abstract fun reduce(
        oldState: S,
        intent: I
    ): Pair<S, E?>

    /**
     * Updates our StateFlow with a fresh state.
     */
    protected fun setState(newState: S) {
        _viewState.value = newState
    }

    /**
     * Emits a single effect that the UI will handle once.
     */
    protected fun postEffect(effect: E) {
        viewModelScope.launch {
            _viewEffect.emit(effect)
        }
    }
}

How It Works

1. Key Points

• viewState is our single “source of truth.”
• viewEffect handles ephemeral events that do not belong in persistent state.
• processIntent(...) is the single funnel for user actions.
• reduce(...) merges (oldState + intent) -> (newState, effect?).

5.2.2 Defining State, Intents, and Effects

Let’s adapt our lightweight MVI counter into a Redux-like version using BaseMviViewModel. We’ll define:

• CounterState for screen data
• CounterIntent for user actions
• CounterEffect for ephemeral events like toasts

// 1) State: Single source of truth
data class CounterState(
    val count: Int = 0,
    val error: String? = null
)

// 2) Intents: All possible user actions
sealed class CounterIntent {
    object Increment : CounterIntent()
    object Reset : CounterIntent()
    data class SetCount(val value: Int) : CounterIntent()
}

// 3) Effects: One-off events
sealed class CounterEffect {
    data class ShowToast(val message: String) : CounterEffect()
    // e.g., object NavigateToDetail : CounterEffect()
}

5.2.3 The Redux-Like ViewModel

Now, create the actual ViewModel:

class CounterReduxViewModel : BaseMviViewModel<
    CounterState, 
    CounterIntent, 
    CounterEffect
>(
    initialState = CounterState()
) {

    override fun reduce(
        oldState: CounterState, 
        intent: CounterIntent
    ): Pair<CounterState, CounterEffect?> {
        return when (intent) {
            is CounterIntent.Increment -> {
                val newState = oldState.copy(
                    count = oldState.count + 1,
                    error = null
                )
                newState to null
            }
            is CounterIntent.Reset -> {
                val newState = oldState.copy(
                    count = 0,
                    error = null
                )
                newState to null
            }
            is CounterIntent.SetCount -> {
                if (intent.value < 0) {
                    val newState = oldState.copy(
                        error = "Negative counts not allowed"
                    )
                    newState to CounterEffect.ShowToast("Invalid count!")
                } else {
                    val newState = oldState.copy(
                        count = intent.value,
                        error = null
                    )
                    newState to null
                }
            }
        }
    }
}

Whenever you call processIntent(...) with a CounterIntent, the reduce function calculates a new CounterState and an optional CounterEffect.

5.2.4 Consuming the Redux-Like ViewModel in Compose

In Jetpack Compose, you’d collect both viewState and viewEffect:

@Composable
fun CounterReduxScreen(viewModel: CounterReduxViewModel = viewModel()) {
    // Observe the state
    val uiState by viewModel.viewState.collectAsStateWithLifecycle()

    // Observe one-off effects
    val context = LocalContext.current
    LaunchedEffect(Unit) {
        viewModel.viewEffect.collect { effect ->
            when (effect) {
                is CounterEffect.ShowToast -> {
                    Toast.makeText(context, effect.message, Toast.LENGTH_SHORT).show()
                }
            }
        }
    }

    Column(
        modifier = Modifier.fillMaxSize(),
        horizontalAlignment = Alignment.CenterHorizontally,
        verticalArrangement = Arrangement.Center
    ) {
        Text(text = "Count: ${uiState.count}")
        uiState.error?.let { errorMsg ->
            Text(text = errorMsg, color = Color.Red)
        }
        Spacer(modifier = Modifier.height(16.dp))

        Row(horizontalArrangement = Arrangement.spacedBy(8.dp)) {
            Button(onClick = { viewModel.processIntent(CounterIntent.Increment) }) {
                Text("Increment")
            }
            Button(onClick = { viewModel.processIntent(CounterIntent.Reset) }) {
                Text("Reset")
            }
        }

        Spacer(modifier = Modifier.height(16.dp))
        Button(onClick = { viewModel.processIntent(CounterIntent.SetCount(5)) }) {
            Text("Set Count to 5")
        }
    }
}

• uiState re-composes automatically when the state changes.
• processIntent(...) is the single path to mutate the state.
• Ephemeral effects like ShowToast are consumed once in the LaunchedEffect block.

This article is previously published on proandroiddev.com.