El back stack: dar forma a la pila

Toda aplicación mediocre comparte un mismo defecto y casi nadie lo formula en voz alta: navega bien hacia adelante y desastrosamente hacia atrás. El usuario alterna tres veces entre dos pestañas y necesita seis gestos para salir; inicia sesión y el botón de volver lo devuelve a la pantalla de credenciales que acaba de superar; completa un formulario de cinco pasos y al pulsar atrás desde la confirmación reaparece el paso cinco con los datos ya enviados. Ninguno de esos fallos es un error de programación en el sentido habitual: cada llamada individual hizo exactamente lo que se le pidió. El fallo está en no haber decidido nunca qué debía quedar detrás, y en confiar en que apilar sin criterio produciría por acumulación una historia coherente. La pila no se gestiona sola porque no puede: la pregunta de qué significa volver desde aquí es una pregunta de producto, no de biblioteca, y solo tiene una respuesta correcta cuando alguien la formula explícitamente.

Apilar, desapilar y las opciones que dan forma

La pila es una lista de entradas de la que solo se ve la última. Navegar apila; volver desapila y destruye lo desapilado, con todo lo que colgaba de ello: su estado guardado, sus vistas-modelo y sus efectos. Esa destrucción es el motivo de que la forma de la pila importe tanto, porque decide qué se pierde y cuándo.

Sobre esas dos operaciones básicas se aplican unas opciones que se pasan en la llamada y que conviene entender por separado antes de combinarlas.

navController.navigate(Detalle(id)) {
    popUpTo(Catalogo) { inclusive = false; saveState = true }
    launchSingleTop = true
    restoreState = true
}

popUpTo desapila antes de apilar el destino nuevo, hasta encontrar el destino indicado. inclusive decide si ese destino límite también se desapila o si se conserva. launchSingleTop evita apilar un duplicado si el destino pedido ya está en la cima: en lugar de crear una entrada nueva, reutiliza la existente. Y la pareja saveState con restoreState archiva el estado de lo que se desapila y lo devuelve si esa rama se vuelve a visitar.

Esa última pareja merece precisión porque su asimetría desconcierta. saveState es una opción del recorte: dice que lo desapilado no se tire, sino que se guarde asociado a su destino. restoreState es una opción del apilado: dice que si existe un archivo para el destino que se va a apilar, se recupere en lugar de empezar de cero. Son independientes, y usar una sin la otra produce exactamente la mitad del efecto, que es el motivo habitual de que alguien concluya que la restauración de pestañas no funciona.

Conviene además distinguir las dos formas de retroceder, porque no son sinónimas. Desapilar quita la última entrada sin más. Subir un nivel consulta la relación jerárquica declarada y puede saltar varias entradas de golpe, lo que importa cuando el usuario entró por un enlace profundo y no hay historia real detrás. Para el gesto del sistema la primera es la correcta; para una flecha de la barra superior, la segunda suele serlo.

flowchart TD
START[Llamada a navigate con opciones] --> P{Hay popUpTo}
P -->|Si| POP[Desapila hasta el destino limite]
P -->|No| SINGLE
POP --> SAVE{saveState activo}
SAVE -->|Si| ARCH[Archiva el estado de lo desapilado]
SAVE -->|No| SINGLE
ARCH --> SINGLE{launchSingleTop y ya esta en la cima}
SINGLE -->|Si| REUSA[Reutiliza la entrada existente]
SINGLE -->|No| PUSH[Apila una entrada nueva]
PUSH --> REST{restoreState activo}
REST -->|Si| RECUP[Recupera el estado archivado]
REST -->|No| FIN[La pila queda con su forma nueva]
style ARCH fill:#a6e3a1,color:#11111b
style RECUP fill:#a6e3a1,color:#11111b

El orden del diagrama no es un detalle de implementación: es lo que explica los resultados que parecen contradictorios. Como el desapilado ocurre antes que el apilado, launchSingleTop se evalúa contra la pila ya recortada, no contra la original. Quien razona en el orden inverso predice mal cada vez que combina ambas opciones, y suele concluir que una de las dos no funciona.

Los tres patrones que resuelven casi todo

El patrón de pestañas merece verse escrito porque concentra las cuatro opciones a la vez y porque es el que más se copia sin entender.

fun NavController.irAPestana(destino: Any) {
    navigate(destino) {
        popUpTo(graph.findStartDestination().id) { saveState = true }
        launchSingleTop = true
        restoreState = true
    }
}

Sin saveState y restoreState cada cambio de pestaña destruiría la rama abandonada y la reconstruiría desde cero: el desplazamiento vuelve al principio y los datos se recargan. Sin launchSingleTop, pulsar dos veces la misma pestaña apila un duplicado. Y sin popUpTo, la pila crece indefinidamente y salir de la aplicación exige deshacer todo el recorrido histórico.

Los otros dos patrones comparten una intuición y conviene enunciarla porque generaliza: hay pantallas que existen para ser abandonadas. Un vestíbulo de sesión, una bienvenida, un formulario ya enviado, una pantalla de carga inicial. Volver a ellas no es una posibilidad razonable sino un fallo, y la forma de decirlo es desapilarlas de forma inclusiva en el mismo momento en que se superan.

// Salir de un vestibulo: el destino de partida deja de existir.
navController.navigate(Inicio) {
    popUpTo(Vestibulo) { inclusive = true }
}

Existe una prueba mental barata que decide entre inclusivo y no inclusivo sin tener que recordar la semántica: pregúntate si el destino límite es un lugar al que quedaría alguna decisión por tomar. Si la respuesta es sí —el catálogo desde el que se abrió un detalle, la lista desde la que se entró en un elemento—, se conserva. Si es no —una pantalla superada, un formulario enviado, una carga terminada—, se desapila también.

Merece la pena señalar además un límite de estos patrones que rara vez se documenta: la forma de la pila corrige la historia, no las condiciones de entrada. Recortar el flujo de compra al confirmar evita que el usuario regrese al pago, pero no impide que un enlace profundo lo deposite ahí mañana sin haber pasado por el carrito. Lo primero es diseño de navegación; lo segundo es una comprobación de estado dentro del destino, y ninguna opción de la llamada la sustituye.

Hay un cuarto caso que no llega a patrón pero que aparece en cuanto la aplicación tiene enlaces profundos: el regreso masivo. Un usuario que ha bajado seis niveles y pulsa un botón de volver al inicio no debe deshacer seis veces; lo correcto es desapilar hasta el destino inicial de una sola operación, conservándolo. La diferencia con encadenar retrocesos no es de rendimiento sino de significado: se está afirmando que todo lo intermedio deja de ser un lugar al que regresar.

El gesto atrás predictivo

Hasta Android 13 el sistema no sabía qué iba a pasar al volver hasta que la aplicación se lo decía, y por eso el gesto era instantáneo y opaco: el usuario lo completaba y descubría después a dónde había ido a parar. El modelo predictivo invierte ese orden. Mientras el dedo se desliza, el sistema muestra una vista previa animada de lo que hay detrás, y el gesto se puede cancelar a mitad devolviendo la pantalla a su sitio.

Para poder anticipar, el sistema necesita saber antes de que el gesto empiece si alguien va a interceptarlo. De ahí el cambio de contrato: la intercepción se declara de forma anticipada y con estado, en lugar de resolverse en el momento con una llamada que decide sobre la marcha. Una aplicación que captura el retroceso a la manera antigua no puede participar en la animación, porque el sistema no tiene forma de saber qué dibujar al otro lado.

var hayCambiosSinGuardar by remember { mutableStateOf(false) }
var mostrarDialogo by remember { mutableStateOf(false) }

BackHandler(enabled = hayCambiosSinGuardar) {
    mostrarDialogo = true
}

La clave está en el parámetro que habilita la intercepción: cuando vale falso, la aplicación no participa y el sistema anima la salida con total libertad; cuando vale verdadero, el sistema sabe de antemano que habrá una interrupción y ajusta lo que muestra. Interceptar siempre y decidir dentro es precisamente lo que rompe el modelo, porque convierte cada retroceso en impredecible para quien tiene que dibujarlo.

Hay un segundo nivel de participación, más ambicioso, para los casos en que la propia aplicación quiere animarse durante el gesto en lugar de limitarse a reaccionar al final. En ese modo la intercepción recibe un flujo de eventos con el progreso del deslizamiento, y el contenido puede interpolar su salida a medida que el dedo avanza, replegarse si el gesto se cancela y completarse si llega al final. Es el mecanismo con el que un panel lateral se cierra siguiendo el dedo en lugar de desaparecer de golpe.

Conviene resistir la tentación de usarlo en todas partes. La transición entre destinos ya la anima el anfitrión, y competir con ella produce movimientos que se estorban. El progreso del gesto sirve para elementos que la navegación no gobierna: paneles, hojas inferiores, modos de edición dentro de una misma pantalla.