Model-View-Intent en el mundo Android: Orbit, coroutines y Flow, estado inmutable en Compose, side effects de una sola vez y Kotlin Multiplatform.
Cada nivel construye sobre el anterior. Sin saltos, sin huecos.
La visión aérea: Model-View-Intent en el mundo Kotlin/Android, Orbit, coroutines y Compose; el flujo unidireccional nativo.
Model-View-Intent: la intención del usuario como entrada, un modelo inmutable como salida, y el ciclo unidireccional.
Orbit (Kotlin): el container que reduce intents a estado, los side effects de una sola vez, y su ergonomía sobre coroutines.
Las piezas del lenguaje: data classes para el estado inmutable, sealed classes/interfaces para intents y efectos, y `when` exhaustivo.
Coroutines: suspend, scopes, structured concurrency, y por qué el ciclo de vida de una corrutina encaja con el de una pantalla.
Flow: streams fríos y calientes, `StateFlow` como estado observable, `SharedFlow` para eventos, y los operadores clave.
El ViewModel de Android: sobrevivir a cambios de configuración, `viewModelScope`, y por qué es el lugar natural del container.
Jetpack Compose: `collectAsStateWithLifecycle`, recomposición, y renderizar la UI como función del estado.
Por qué Compose recompone de más: estabilidad de tipos, clases inmutables, y cómo el estado inmutable de MVI ayuda.
Modelar los intents del usuario y reducirlos a estado: funciones puras, validación, y el orden de las transiciones.
Lo que no es estado: navegar, mostrar un snackbar, vibrar; por qué mezclarlos con el estado provoca bugs al rotar la pantalla.
El container de Orbit: `intent`, `reduce`, `postSideEffect`, el `stateFlow` y el `sideEffectFlow`; su modelo de concurrencia.
Testear con orbit-test: afirmar la secuencia de estados y efectos, y controlar el tiempo y las dependencias.
Implementar MVI con solo Kotlin: un `StateFlow` privado, una función `reduce`, y un `Channel` para los efectos.
Navegación en Android moderno: Navigation Compose, la navegación como efecto o como estado, y el deep linking.
Debajo del ViewModel: repositorios, fuentes locales (Room) y remotas, y exponer los datos como Flow.
DI en Android: Hilt (compile-time) y Koin (runtime); inyectar el container y hacer testeable la capa de presentación.
KMP: compartir la lógica MVI entre Android e iOS, exponerla a Swift, y qué se comparte y qué no.
Testear la capa de presentación: unit tests del reducer, tests del ViewModel con turbine, y tests de UI en Compose.
Las arquitecturas de Android comparadas: qué añade el flujo unidireccional estricto y qué cuesta en ceremonia.
Los tropiezos típicos: estado gigante, efectos tratados como estado, fugas de scope, y recomposiciones descontroladas.
La síntesis: arquitectar una app Android completa con MVI, decidir librería o no, y el futuro del estado en Compose.
Empieza por los fundamentos y sube nivel a nivel hasta el dominio total.
Comenzar el camino →