Devolver resultados entre pantallas sin romper el modelo

El día que una pantalla necesita preguntarle algo a otra, la arquitectura enseña los dientes. La solución que primero se le ocurre a todo el mundo es pasar una función de vuelta al destino, y funciona en el emulador durante toda la tarde: el selector recibe la lambda, el usuario elige, la lambda se ejecuta y el filtro se aplica. Luego el usuario deja el selector abierto, se va a responder un mensaje, el sistema mata el proceso, vuelve diez minutos después y elige un valor que nadie recibirá jamás, porque la lambda vivía en un montón de memoria que ya no existe. El problema de devolver resultados no es de ergonomía sino de supervivencia: el canal de vuelta tiene que atravesar la muerte del proceso, y eso descarta de golpe todo lo que no se puede serializar.

Por qué la lambda no vale

La navegación en Android no es una llamada a función. Cuando abres un selector no estás invocando código que devolverá un valor: estás apilando un destino que el sistema puede destruir, restaurar y volver a crear sin avisarte. Entre la pregunta y la respuesta puede caber una rotación, un cambio de tema, una salida al segundo plano y la aniquilación completa del proceso. Cualquier canal que dependa de que un objeto siga vivo en memoria durante ese intervalo es, por construcción, un canal roto.

De ahí se sigue la exigencia mínima del canal de vuelta: debe sobrevivir a la muerte del proceso y por tanto debe ser serializable. Eso descarta las lambdas, las referencias a modelos de vista, los objetos de dominio con estado interno y cualquier registro estático de escuchas. Y deja exactamente el mismo tipo de canal que ya usábamos para los argumentos de ida: un contenedor de valores serializables asociado a una entrada de la pila.

sequenceDiagram
participant A as Pantalla Lista
participant P as Pila de retroceso
participant B as Pantalla Selector
A->>P: navigate al selector
P->>B: crea la entrada
Note over P: el sistema mata el proceso
P->>B: restaura la entrada desde el Bundle
B->>P: escribe el resultado en la entrada anterior
B->>P: popBackStack
P->>A: la entrada anterior vuelve a ser la cima
A->>A: lee el resultado y lo consume

Hay una variante del mismo error que sobrevive más tiempo y por eso es más peligrosa: el registro estático de escuchas, ese objeto singleton donde la pantalla que pregunta se apunta y la que responde publica. Sobrevive a la rotación, lo cual da la falsa impresión de que el problema está resuelto, pero no sobrevive al proceso y además introduce una fuga silenciosa cuando alguien se apunta y nunca se borra. Que un canal aguante la rotación no dice nada sobre si aguanta lo que de verdad importa.

Fíjate en que el resultado se escribe en la entrada anterior, no en la propia. Esa asimetría es deliberada y resuelve el problema de la vida útil: la entrada del selector va a destruirse en cuanto se cierre, así que dejar ahí el valor sería tirarlo. La entrada del llamante, en cambio, sigue en la pila durante todo el intervalo y va a ser la cima justo después.

El canal correcto y su forma tipada

Cada NavBackStackEntry posee su propio SavedStateHandle, el mismo que un modelo de vista de ese destino recibe por inyección. Ese contenedor se serializa con la pila y se restaura con ella, y sirve igual de bien para lo que la pantalla guarda de sí misma que para lo que otra pantalla le deja.

object ClavesResultado {
    const val FILTRO = "resultado_filtro"
}

// En el destino que responde
@Composable
fun SelectorRuta(nav: NavHostController) {
    SelectorPantalla(
        alElegir = { filtro ->
            nav.previousBackStackEntry
                ?.savedStateHandle
                ?.set(ClavesResultado.FILTRO, filtro.name)
            nav.popBackStack()
        },
    )
}

Dos detalles del fragmento importan más de lo que parecen. El primero es que se escribe antes de sacar el destino de la pila: al revés, la entrada anterior ya sería la cima y la escritura llegaría tarde para quien esté observando en el orden equivocado. El segundo es que lo que viaja es el nombre del enumerado, no el enumerado: el canal admite tipos serializables, y reducir el valor a una cadena o a un identificador evita sorpresas cuando el tipo evoluciona.

Consumir exactamente una vez

Aquí aparece el matiz que convierte este tema en una lección de MVI y no en una receta. El estado guardado es, por diseño, un almacén retentivo: su lectura observable entrega el último valor a cada nuevo suscriptor, igual que el flujo conflado del estado. Y un resultado de navegación no es un hecho permanente sino un suceso: aplicar el filtro elegido es una operación que debe ocurrir una vez, no cada vez que la pantalla vuelve del segundo plano.

Sin esa precaución reaparece intacto el bug del evento fosilizado, con un disfraz nuevo: el usuario elige un filtro, la lista lo aplica, el usuario se va a otra aplicación y al volver la lista aplica el filtro otra vez, deshaciendo cualquier cambio que hubiera hecho después. La corrección es borrar el valor en el mismo lugar donde se consume.

@Composable
fun ListaRuta(
    vm: ListaViewModel = hiltViewModel(),
    entrada: NavBackStackEntry,
    alAbrirSelector: () -> Unit,
) {
    val estado by vm.collectAsState()

    LaunchedEffect(entrada) {
        entrada.savedStateHandle
            .getStateFlow<String?>(ClavesResultado.FILTRO, null)
            .filterNotNull()
            .collect { nombre ->
                vm.aplicarFiltro(Filtro.valueOf(nombre))
                entrada.savedStateHandle.remove<String>(ClavesResultado.FILTRO)
            }
    }

    ListaPantalla(estado, onFiltrar = alAbrirSelector)
}

Que la clave del efecto sea la entrada de la pila, y no el modelo de vista ni un valor recreado, es lo que impide que la colección se reinicie sin motivo en cada recomposición. La entrada es estable mientras el destino siga en la pila, que es exactamente la vida útil que queremos para este buzón: nace cuando la pantalla entra, se restaura con ella tras la muerte del proceso y desaparece cuando el destino se desapila de verdad.

La secuencia importa: se consume el valor traduciéndolo a un intent del contenedor, y solo después se retira del almacén. Retirarlo primero abriría una ventana en la que una recreación perdería el resultado; retirarlo nunca lo convierte en un fantasma que resucita. Y traducirlo a un intent, en vez de tocar el estado directamente, mantiene la regla de oro del modelo: la lógica entra por una sola puerta y el resultado de navegación no es una excepción a esa puerta.

Cuándo el resultado no debe viajar por ahí

El canal del estado guardado es correcto para su caso, y su caso es concreto: un dato pequeño, serializable, que una pantalla le devuelve a la que la abrió, en una relación de dos. Fuera de ese perfil, hay opciones mejores y conviene reconocerlas.

Hay un caso frontera que conviene resolver de antemano porque genera discusiones largas: el resultado que consiste en no haber elegido nada. Si el usuario cierra el selector sin decidir, la ausencia de escritura es indistinguible de una cancelación, y hay pantallas donde esa diferencia importa —la que debe revertir un cambio provisional, por ejemplo—. La solución no es inventar un tercer canal sino modelar la cancelación como un valor más del tipo de resultado, con su propio caso explícito. Un resultado que solo sabe expresar el éxito obliga a deducir el fracaso del silencio, y deducir del silencio es siempre el principio de un fallo intermitente.

La regla que ordena las cuatro es preguntar quién es el dueño del dato. Si el dueño es el dominio, el canal es el repositorio y no hay nada que devolver. Si el dueño es el flujo, el canal es un contenedor compartido con el ámbito adecuado. Si el dueño es la pantalla que preguntó, y solo entonces, el canal es su estado guardado. Y si tu arquitectura ya posee la pila, la pregunta ni siquiera se plantea porque todo es una reducción.