MVI en Android: la misma idea con otro nombre

Que la misma arquitectura aparezca tres veces en tres plataformas distintas, con tres nombres distintos y con genealogías que solo se cruzan en parte, dice algo que ninguna de las tres apariciones dice por separado. En Android, la idea llegó envuelta en el vocabulario de la programación reactiva y con un acrónimo que confunde a quien lo lee por primera vez: MVI, modelo, vista e intención, que suena a variación de MVC y no lo es en absoluto. La intención no es una capa; es el mensaje. El modelo no es un objeto de dominio con métodos; es el estado completo e inmutable de la pantalla. Y la vista no es una clase que se actualiza a trozos; es una función que recibe ese estado y lo pinta entero. Puestos en fila, los tres elementos son el bucle de Elm sin una sola pieza de sobra. Lo notable es que en Android esa disciplina no llegó como refinamiento estético sino como respuesta a una presión del sistema operativo: los procesos mueren, las pantallas se recrean al rotar, el estado hay que poder guardarlo y restaurarlo, y todo eso resulta trivial si el estado es un único valor serializable y prácticamente imposible si está repartido en campos mutables de una jerarquía de vistas. La plataforma que peor trataba a sus programadores fue, por eso mismo, la que más rápido entendió para qué servía la disciplina.

El mismo bucle con otro vocabulario

La traducción es directa y conviene fijarla antes de seguir, porque buena parte de la confusión que rodea a este acrónimo se disuelve al hacerla. La intención es el mensaje que produce la interfaz cuando el usuario hace algo, y en Kotlin se modela con una interfaz sellada cuyas implementaciones son los casos posibles. El modelo es una clase de datos inmutable que describe la pantalla entera, incluidos los estados de carga y de error, y se transforma con el método de copia que el lenguaje genera. El reductor es una función de estado e intención a estado. La vista observa el estado y lo pinta. Kotlin aporta a esta arquitectura dos herramientas que Elm tenía desde el principio y Java no tenía: las jerarquías selladas, que permiten al compilador comprobar que una expresión de selección cubre todos los casos, y las clases de datos con copia, que dan a la actualización inmutable una sintaxis soportable.

sealed interface Intencion {
    data object Incrementar : Intencion
    data object PedirDato : Intencion
    data class DatoRecibido(val texto: String) : Intencion
    data class Fallo(val causa: String) : Intencion
}

data class Estado(
    val cuenta: Int = 0,
    val cargando: Boolean = false,
    val hecho: String? = null,
    val error: String? = null,
)

fun reducir(estado: Estado, intencion: Intencion): Estado = when (intencion) {
    is Intencion.Incrementar -> estado.copy(cuenta = estado.cuenta + 1)
    is Intencion.PedirDato -> estado.copy(cargando = true, error = null)
    is Intencion.DatoRecibido -> estado.copy(cargando = false, hecho = intencion.texto)
    is Intencion.Fallo -> estado.copy(cargando = false, error = intencion.causa)
}

Quien haya leído las lecciones anteriores reconocerá la forma sin necesidad de que se la señalen. Y quien venga de Elm notará también la ausencia: reducir devuelve estado y solo estado, igual que el reducer de Redux, con lo cual la petición al servidor tendrá que ocurrir en otro sitio. La diferencia respecto al caso de JavaScript es que aquí ese otro sitio estaba ya construido y era razonablemente bueno, porque el ecosistema Android había adoptado la programación reactiva años antes y disponía de operadores de composición asíncrona bien probados.

El operador que ya era un reducer

El hallazgo de los primeros artículos de MVI en Android fue notar que la biblioteca reactiva ya contenía la mitad del patrón sin saberlo. El operador de pliegue acumulativo toma un valor inicial y una función de acumulación y produce un flujo de estados sucesivos a partir de un flujo de eventos; puesto de otro modo, es la Arquitectura Elm expresada como una sola llamada. Sustituyendo el flujo antiguo por los flujos de la biblioteca de corrutinas, la formulación es prácticamente idéntica y el estado observable se expone como un flujo con valor actual, que la interfaz recoge respetando el ciclo de vida.

class ContadorViewModel(
    private val api: Api,
    private val scope: CoroutineScope,
) {
    private val intenciones = MutableSharedFlow<Intencion>()

    val estado: StateFlow<Estado> =
        intenciones
            .scan(Estado()) { acc, intencion -> reducir(acc, intencion) }
            .stateIn(scope, SharingStarted.WhileSubscribed(5_000), Estado())

    fun enviar(intencion: Intencion) {
        scope.launch { intenciones.emit(intencion) }
        if (intencion is Intencion.PedirDato) {
            scope.launch {
                val resultado = runCatching { api.hecho() }
                intenciones.emit(
                    resultado.fold(
                        onSuccess = { Intencion.DatoRecibido(it) },
                        onFailure = { Intencion.Fallo(it.message ?: "error") },
                    )
                )
            }
        }
    }
}

Ese if dentro de enviar es la cicatriz. Alguien tiene que decidir que la intención de pedir datos provoca una llamada a la red, y como el reductor no puede decirlo, lo dice el objeto que lo rodea, fuera de la función pura y fuera del alcance de un test que solo pruebe el reductor. Las bibliotecas del ecosistema difieren precisamente en cómo resuelven este punto, y esa diferencia ordena el linaje mejor que ninguna otra.

// La variante fiel: la transicion devuelve modelo y efectos, como la tupla de Elm
sealed interface Efecto {
    data object PedirHecho : Efecto
}

fun actualizar(modelo: Estado, evento: Intencion): Next<Estado, Efecto> = when (evento) {
    is Intencion.Incrementar ->
        Next.next(modelo.copy(cuenta = modelo.cuenta + 1))

    is Intencion.PedirDato ->
        Next.next(modelo.copy(cargando = true), setOf(Efecto.PedirHecho))

    is Intencion.DatoRecibido ->
        Next.next(modelo.copy(cargando = false, hecho = evento.texto))

    is Intencion.Fallo ->
        Next.next(modelo.copy(cargando = false, error = evento.causa))
}

La diferencia con el ejemplo anterior es de una línea y de una categoría entera. Aquí el efecto forma parte de lo que la función devuelve, con lo cual un test del reductor puede afirmar no solo qué estado resulta sino qué se pidió al mundo, y el manejador que ejecuta esos efectos es una pieza sustituible que en las pruebas no existe. Es la Arquitectura Elm sin traducción y en un lenguaje que en su día ni siquiera tenía tipos suma cómodos.

flowchart LR
U[Usuario] -->|Intent| VM[ViewModel]
VM --> R[reducir estado intencion]
R --> S[StateFlow de estado unico]
S -->|render| C[Compose]
C --> U
VM -.->|efecto fuera del tipo| N[Red o base de datos]
N -.->|nueva intencion| VM
style R fill:#a6e3a1,color:#11111b
style S fill:#89b4fa,color:#11111b
style N fill:#f38ba8,color:#11111b

La costura: los eventos de una sola vez

Queda un residuo que no encaja y que ha generado más discusión que ninguna otra parte del patrón. Hay cosas que la aplicación debe hacer una sola vez y que no son estado: navegar a otra pantalla, mostrar un aviso efímero, cerrar el teclado, lanzar una vibración. Si se modelan como campos del estado, aparece el problema de consumirlos, porque tras rotar la pantalla el estado se vuelve a entregar y el aviso se muestra dos veces; y si se modelan como un canal aparte de sucesos, se ha abierto una segunda vía que escapa al modelo y que puede perder mensajes cuando no hay nadie escuchando. La solución habitual, un canal de efectos laterales separado del estado, funciona en la práctica y es lo que ofrecen casi todas las bibliotecas, pero tiene un precio conceptual que conviene nombrar: a partir de ese momento, el estado ya no describe la pantalla entera y la reproducción a partir del estado deja de ser fiel.