Intent: modelar cada acción del usuario como un dato

Si el flujo unidireccional es la columna vertebral de MVI, el Intent es la puerta por la que todo entra. La palabra desconcierta al principio porque en Android ya existe android.content.Intent, el mensajero que arranca actividades y servicios; el Intent de este patrón no tiene nada que ver con aquel. Aquí un intent es la intención del usuario capturada como un dato: no la acción de guardar, sino el hecho “el usuario pulsó guardar”; no el efecto de escribir, sino el hecho “el usuario cambió el texto a esto”. Modelar cada interacción posible como un valor de un tipo cerrado es el primer acto de disciplina que exige MVI, y de él se siguen casi todas sus virtudes: el registro, la reproducción, la comprobación y, sobre todo, la certeza de que no hay ninguna acción del usuario que el sistema no haya previsto por escrito.

La intención como tipo suma

En Kotlin, el conjunto de todo lo que el usuario puede hacer en una pantalla se expresa con un sealed interface: un tipo cuyas únicas implementaciones son las que declaras en el mismo módulo. Cada acción es una de esas implementaciones. Cuando la acción no lleva datos —un botón de reintentar— basta un data object, un valor único sin estado. Cuando lleva información —el texto que se escribió, el identificador de la fila que se tocó— usas una data class que la transporta.

// OJO: no es android.content.Intent. Aqui Intent es dato de dominio.
sealed interface TareasIntent {
    data class TextoCambiado(val texto: String) : TareasIntent
    data object AnadirPulsado : TareasIntent
    data class TareaAlternada(val id: String) : TareasIntent
    data class TareaBorrada(val id: String) : TareasIntent
    data object ReintentarPulsado : TareasIntent
}

Esta declaración es, leída con atención, una especificación completa de la superficie de interacción de la pantalla: cinco cosas, ni una más, puede hacer el usuario. No hay acción escondida en un callback perdido ni intención implícita en un flag. La lista es la verdad, y está en un solo sitio.

El when exhaustivo: el compilador como aliado

Aquí se cobra el primer dividendo de modelar la intención como tipo suma. Como el sealed interface conoce todas sus implementaciones, un when sobre un intent puede ser exhaustivo: si te dejas un caso sin cubrir y no pones rama else, el código no compila. El conjunto de acciones del usuario deja de ser una lista mental que se te puede olvidar y pasa a ser una obligación que la máquina verifica en cada build.

fun onIntent(intent: TareasIntent) {
    when (intent) {
        is TareasIntent.TextoCambiado  -> _state.update { it.copy(borrador = intent.texto) }
        TareasIntent.AnadirPulsado     -> anadirTarea()
        is TareasIntent.TareaAlternada -> alternar(intent.id)
        is TareasIntent.TareaBorrada   -> borrar(intent.id)
        TareasIntent.ReintentarPulsado -> cargar()
        // sin rama else: si anades un intent y olvidas su caso, no compila
    }
}

flowchart LR
A[TextoCambiado] --> OI[onIntent]
B[AnadirPulsado] --> OI
C[TareaAlternada] --> OI
D[TareaBorrada] --> OI
E[ReintentarPulsado] --> OI
OI --> VM[el ViewModel decide que hacer con cada uno]
style OI fill:#f9e2af,color:#11111b
style VM fill:#a6e3a1,color:#11111b

El día que añadas un sexto intent —OrdenCambiado, digamos—, el compilador recorrerá cada when que consume TareasIntent y te obligará a decidir qué hacer con él. Esa es la diferencia entre una interfaz que crece con seguridad y una que acumula agujeros: en MVI, ampliar el conjunto de acciones es una operación que el tipo hace visible y verificable, no un olvido latente.

Un único punto de entrada

Todos los intents entran por la misma puerta: fun onIntent(intent: TareasIntent). Esta unicidad no es estética; es la que hace posible todo lo que el patrón promete. Como cada acción del usuario pasa por el mismo canal, basta un Log en onIntent para obtener la crónica exacta y ordenada de todo lo que se hizo en la sesión —la caja negra del nivel 17, ahora en Kotlin—. Como los intents son datos inertes y no llamadas, puedes grabarlos, serializarlos, reenviarlos en un test o reproducirlos para recrear un bug que un usuario reportó.