Model-View-Intent: el flujo unidireccional de Android

MVI es lo que ocurre cuando el flujo unidireccional que ya conoces —Flux en el navegador, Redux en React, la Elm Architecture en el mundo funcional— cruza la frontera de Android y se reescribe en Kotlin sobre Jetpack Compose. No trae ninguna idea nueva: trae una traduccion. Las tres iniciales significan Model, View e Intent, pero lo que de verdad las une no es la lista de piezas, sino una inversion que cuesta ver la primera vez. La intencion del usuario —eso que en la programacion imperativa de toda la vida era una llamada a un metodo que hacia algo— aqui se convierte en un dato inerte que entra por un unico sitio y recorre un circuito cerrado antes de que la pantalla cambie. Compose vuelve esta idea casi inevitable, porque ya describe la interfaz como una funcion del estado; MVI se limita a cerrar el bucle por el otro extremo.

La inversión que define MVI

Detente en cómo se maneja un clic en el Android imperativo clásico. Dentro del OnClickListener llamas a un repositorio, recibes un resultado y, acto seguido, tú mismo tocas la pantalla: textView.text = ..., progressBar.visibility = .... El manejador es a la vez quien decide qué pasa y quien pinta el resultado. Esa fusión —decisión y efecto en el mismo sitio, repartida por decenas de callbacks— es la raíz del desorden que ya diagnosticaste en el MVC del nivel 17: demasiados caminos por los que el estado puede cambiar sin dejar rastro.

MVI corta ese nudo con un solo gesto: el clic ya no hace nada, emite. Lo único que produce la interacción del usuario es un valor —un Intent— que describe qué quiso hacer, nunca cómo llevarlo a cabo. Ese valor entra al sistema por un único punto, se combina con el estado actual para producir un estado nuevo, y solo entonces la pantalla se redibuja. La intención se ha cosificado: ha pasado de ser un verbo que se ejecuta a ser un sustantivo que viaja.

// El Model: una unica foto inmutable de la pantalla
data class ContadorState(val cuenta: Int = 0)

// El Intent: la intencion del usuario, modelada como dato
sealed interface ContadorIntent {
    data object Incrementar : ContadorIntent
    data object Decrementar : ContadorIntent
}

class ContadorViewModel : ViewModel() {
    private val _state = MutableStateFlow(ContadorState())
    val state: StateFlow<ContadorState> = _state.asStateFlow()

    // Punto de entrada unico: la intencion entra, el estado nuevo sale
    fun onIntent(intent: ContadorIntent) = _state.update { s ->
        when (intent) {
            ContadorIntent.Incrementar -> s.copy(cuenta = s.cuenta + 1)
            ContadorIntent.Decrementar -> s.copy(cuenta = s.cuenta - 1)
        }
    }
}

Las tres piezas sobre Compose y StateFlow

Cada inicial corresponde a una pieza concreta del Android de 2026. El Model es una data class inmutable que contiene todo lo que la pantalla necesita para dibujarse: una única fuente de la verdad, no un puñado de campos sueltos. La View es un @Composable que recibe ese estado y lo pinta, sin lógica ni decisiones propias. El Intent es un tipo sellado —casi siempre un sealed interface— que enumera todas las acciones que el usuario puede realizar. Entre las tres media el ViewModel, que guarda el estado en un StateFlow y expone un único método de entrada, onIntent.

flowchart LR
I[Intent del usuario] --> VM[ViewModel]
VM --> R[reduce]
R --> S[UiState inmutable]
S --> V[Compose UI]
V -->|nueva interaccion emite un Intent| I
style I fill:#89b4fa,color:#11111b
style R fill:#f9e2af,color:#11111b
style S fill:#a6e3a1,color:#11111b
style V fill:#cba6f7,color:#11111b

En la vista, la conexión con el estado se hace con collectAsStateWithLifecycle, que observa el StateFlow respetando el ciclo de vida —deja de recolectar cuando la pantalla no está visible— y provoca la recomposición cuando el estado cambia. Fíjate en que la vista solo hace dos cosas: lee state y emite intents. Nunca decide.

@Composable
fun ContadorScreen(vm: ContadorViewModel = viewModel()) {
    val state by vm.state.collectAsStateWithLifecycle()
    Column {
        Text("Cuenta: ${state.cuenta}")
        Button(onClick = { vm.onIntent(ContadorIntent.Incrementar) }) { Text("+") }
        Button(onClick = { vm.onIntent(ContadorIntent.Decrementar) }) { Text("-") }
    }
}

El mismo circuito bajo un nombre nuevo

Nada de esto es original, y reconocerlo te ahorra confusión. El término lo acuñó Hannes Dorfmann en 2016 para Android, inspirándose en el cycle.js de André Staltz, con dos ecuaciones que resumen el patrón entero: el modelo es función de la intención y la vista es función del modelo. Es, palabra por palabra, la Elm Architecture —update : Msg -> Model -> Model, view : Model -> Html— vestida de Kotlin, y es el mismo circuito de sentido único de Redux que recorriste en el nivel 18. En 2026 conviven varias encarnaciones: Orbit MVI y MVIKotlin como librerías dedicadas, y sobre todo Circuit de Slack y Molecule de Cash App, que llevan la idea a su extremo escribiendo el propio presentador como una función @Composable que devuelve estado.