Domina la conversión de flujos fríos a calientes con stateIn y sharedIn en Kotlin

En el desarrollo moderno de aplicaciones Android con Kotlin, el manejo eficiente de flujos de datos asíncronos es fundamental. La biblioteca de Flow de Kotlin ofrece dos categorías principales: Cold Flows y Hot Flows. Mientras que los primeros se crean bajo demanda y comienzan a emitir datos solo cuando un colector se suscribe, los segundos permanecen activos independientemente de los suscriptores. Para migrar de un comportamiento frío a uno caliente, Kotlin nos brinda dos operadores clave: stateIn y sharedIn. Este artículo te guiará a través de su uso, ventajas y buenas prácticas para optimizar tu app.

¿Qué son los Cold Flows y por qué convertirlos?

Un Cold Flow (flujo frío) es perezoso: no ejecuta su lógica de producción hasta que alguien lo recolecta. Cada suscriptor recibe una secuencia independiente de valores. Esto es útil para operaciones costosas que no deben replicarse, pero puede generar problemas cuando múltiples consumidores necesitan compartir el mismo estado o cuando se quiere evitar reinicializar cálculos cada vez que un nuevo observador se conecta.

Por el contrario, un Hot Flow (flujo caliente) emite datos de forma continua, sin importar si hay suscriptores. Ejemplos comunes son StateFlow y SharedFlow. Convertir un Cold Flow en un Hot Flow permite:

• Compartir datos entre múltiples observadores sin duplicar trabajo.
• Mantener estado incluso cuando no hay suscriptores activos.
• Eficientizar recursos en operaciones como lecturas de sensores, bases de datos o conexiones de red.

“Un Hot Flow no tiene que esperar a que un colectore se suscriba; puede estar emitiendo valores desde el inicio, y los nuevos suscriptores reciben solo los valores emitidos después de su llegada (o el último valor si es un StateFlow).”

stateIn: cuando necesitas un valor actualizable

El operador stateIn convierte un Cold Flow en un StateFlow. Un StateFlow siempre tiene un valor actual (el último emitido) y es ideal para representar estado de la interfaz. Al usar stateIn, debes especificar:

• Un CoroutineScope donde se lanzará la recolección del flujo frío.
• Un valor inicial (initialValue) que se usará hasta que se emita el primer valor real.
• Opcionalmente, una política de sharingStarted (por ejemplo WhileSubscribed() o Eagerly) que controla cuándo comienza y termina la recolección.

Ejemplo práctico:

val coldFlow: Flow = flow { 
    emit(1); delay(1000); emit(2) 
}
val hotStateFlow: StateFlow = coldFlow
    .stateIn(viewModelScope, SharingStarted.WhileSubscribed(), initialValue = 0)

Este patrón es muy habitual en ViewModels de Android, donde se expone un StateFlow que los fragmentos o actividades observan. La ventaja es que el flujo frío (por ejemplo, de una base de datos Room) se recolecta una sola vez y todos los observadores comparten el mismo estado.

sharedIn: cuando necesitas replicar eventos sin estado fijo

El operador sharedIn convierte un Cold Flow en un SharedFlow. A diferencia de StateFlow, un SharedFlow no guarda un valor actual; simplemente retransmite los valores emitidos a todos los suscriptores activos. Es perfecto para eventos "dispara y olvida", como notificaciones, toasts o navegaciones.

Al igual que stateIn, acepta un CoroutineScope y una configuración de sharingStarted. Además, puedes configurar:

• replay: número de valores emitidos previamente que se reenviarán a nuevos suscriptores.
• extraBufferCapacity: espacio adicional para valores no consumidos en caso de que los suscriptores estén saturados.
• onBufferOverflow: estrategia (DROP_OLDEST, DROP_LATEST o SUSPEND).

Ejemplo:

val coldEventFlow: Flow = flow { 
    emit("Evento 1"); delay(500); emit("Evento 2") 
}
val hotSharedFlow: SharedFlow = coldEventFlow
    .sharedIn(viewModelScope, SharingStarted.WhileSubscribed(), replay = 1)

Diferencias clave entre stateIn y sharedIn

Para elegir correctamente, considera estas diferencias:

• StateFlow tiene un valor actual siempre accesible (propiedad .value). Ideal para campos de UI como contadores, textos, estados de carga.
• SharedFlow no expone un valor actual; solo emite eventos. Útil para acciones que no deben repetirse al rotar la pantalla (por ejemplo, navegar a una pantalla solo una vez).
• Eficiencia: stateIn solo guarda el último valor; sharedIn puede almacenar varios valores pasados según el parámetro replay.