Plegables: posturas, bisagra y continuidad

Los plegables obligan a añadir una dimensión que ninguna otra clase de dispositivo exige. Con una tablet basta con saber cuánto espacio hay; con un plegable hace falta saber además qué forma tiene ese espacio y en qué ángulo está, porque el aparato puede estar completamente abierto, completamente cerrado o detenido a medio camino sobre una mesa, y porque en ese estado intermedio la superficie deja de ser un plano continuo para convertirse en dos regiones separadas por una arista física. A eso se suma la transición: plegar y desplegar es un cambio de configuración que ocurre en mitad de una tarea, con el vídeo reproduciéndose, el formulario a medio rellenar y el mapa centrado en un punto. La calidad percibida de una aplicación en un plegable se decide casi por completo en ese medio segundo. Esta lección trata la postura como un estado de primera clase, la bisagra como una restricción de colocación y la continuidad como un requisito funcional.

La postura como estado observable

La información sobre el plegado no llega por consulta puntual sino por flujo: el sistema publica un objeto que describe la disposición de la ventana cada vez que cambia, y la aplicación se suscribe. Ese objeto contiene una lista de características de la pantalla, de las cuales la relevante aquí es la característica de plegado, que aparece únicamente cuando existe una y cuando afecta a la ventana de tu aplicación.

Esa característica tiene tres atributos que hay que leer juntos, porque por separado no dicen nada útil. El estado distingue entre plano y medio abierto: plano significa que la superficie es continua a efectos prácticos, medio abierto que el aparato está detenido en un ángulo intermedio. La orientación indica si el pliegue recorre la pantalla horizontal o verticalmente, y determina si el espacio queda partido en arriba y abajo o en izquierda y derecha. Y la capacidad de separación es una síntesis que el propio sistema calcula y que responde a la única pregunta que de verdad importa para el diseño: si esa característica parte la superficie en dos áreas lógicas que deben tratarse por separado.

class ObservadorDePostura(private val actividad: ComponentActivity) {
    val postura = WindowInfoTracker.getOrCreate(actividad)
        .windowLayoutInfo(actividad)
        .map { info ->
            val plegado = info.displayFeatures.filterIsInstance<FoldingFeature>().firstOrNull()
            when {
                plegado == null -> Postura.Plana
                !plegado.isSeparating -> Postura.Plana
                plegado.orientation == FoldingFeature.Orientation.HORIZONTAL -> Postura.Mesa(plegado.bounds)
                else -> Postura.Libro(plegado.bounds)
            }
        }
}

Dos advertencias sobre el consumo de ese flujo. La primera es que debe recogerse de forma consciente del ciclo de vida, para no seguir procesando actualizaciones con la actividad en segundo plano; el patrón de recolección que se detiene y reanuda con el estado de la actividad es el correcto y no hay ninguna razón para desviarse de él. La segunda es que el flujo describe la disposición de tu ventana, no la del aparato: si tu aplicación ocupa solo una mitad de la pantalla en multiventana y el pliegue cae fuera de ella, no recibirás característica alguna, y eso es exactamente lo que se quiere.

La modelación importa más que la lectura. Convertir tres atributos crudos en un tipo cerrado con tres casos hace que el resto de la aplicación razone sobre conceptos de diseño —mesa, libro, plano— en lugar de sobre banderas, y que la exhaustividad de las decisiones sea comprobable por el compilador. Es el mismo movimiento de cuantización que se hizo con el tamaño, aplicado a otra dimensión.

La bisagra como restricción de colocación

Colocar contenido a caballo de un pliegue produce tres problemas distintos que conviene separar. Uno visual: un texto o una imagen partidos por una arista se leen mal o no se leen. Uno de interacción: un botón situado sobre la bisagra es difícil de pulsar y su respuesta táctil es incoherente. Y uno de comprensión: cuando el aparato está medio abierto, las dos mitades apuntan en direcciones distintas y el usuario percibe dos superficies, no una, de modo que un elemento partido se lee como dos elementos.

La respuesta más simple es tratar la banda del pliegue como una zona prohibida y repartir el contenido a sus lados. En Compose esto encaja de forma natural con los patrones canónicos: la banda se convierte en la separación entre paneles, y cada panel ocupa una mitad. Las estructuras adaptativas del nivel anterior ya lo hacen por su cuenta, porque la directiva que las gobierna incorpora la característica de plegado y decide en consecuencia; ese es uno de los argumentos más fuertes para usarlas en lugar de construir dos columnas a mano.

flowchart TD
A[Flujo de informacion de disposicion] --> B[Hay caracteristica de plegado]
B --> C[No hay o no separa]
B --> D[Separa la superficie]
C --> E[Postura plana con superficie continua]
D --> F[Orientacion horizontal]
D --> G[Orientacion vertical]
F --> H[Modo mesa con contenido arriba y control abajo]
G --> I[Modo libro con dos paneles]
E --> J[Directiva sin separacion]
H --> K[Directiva con separacion horizontal]
I --> L[Directiva con separacion vertical]
style D fill:#f9e2af,color:#11111b

// La banda del pliegue se convierte en separacion, nunca en una fraccion inventada
@Composable
fun ContenidoConPliegue(postura: Postura, contenido: @Composable (PaddingValues) -> Unit) {
    val densidad = LocalDensity.current
    val separacion = when (postura) {
        is Postura.Mesa -> with(densidad) { postura.limites.height().toDp() }
        is Postura.Libro -> with(densidad) { postura.limites.width().toDp() }
        Postura.Plana -> 0.dp
    }
    contenido(PaddingValues(vertical = separacion / 2))
}

Cuando la disposición no se presta a dos paneles, la alternativa es reservar la banda como margen. La tentación de calcular ese margen como una fracción fija de la altura debe resistirse: la posición del pliegue no está centrada en todos los dispositivos, cambia con el modelo y puede cambiar con la orientación. Se lee de los límites que publica el sistema, se traduce a unidades independientes de densidad y se aplica como separación.

Mesa y libro como oportunidades de diseño

El modo mesa aparece cuando el aparato está medio abierto con el pliegue horizontal, apoyado sobre una superficie. Es la postura más interesante porque no es una versión degradada de nada: es una configuración que ningún otro dispositivo ofrece, con una mitad superior orientada hacia la vista y una mitad inferior orientada hacia las manos. Esa asimetría tiene una lectura de diseño inmediata y muy productiva: arriba lo que se mira, abajo lo que se toca.

De ahí salen aplicaciones evidentes. Un reproductor de vídeo pone la imagen arriba y los controles con la lista de reproducción abajo, y logra sin trípode lo que en un teléfono plano exige sostenerlo. Una cámara sitúa el visor arriba y los ajustes abajo, y permite el autorretrato con manos libres. Una videollamada coloca a los interlocutores arriba y el teclado o los controles abajo. Un mapa muestra el trazado arriba y la lista de indicaciones abajo. En todos los casos, el cambio de disposición no añade funciones: reorganiza las existentes según el eje mirar y tocar.

Conviene notar que ninguna de esas aplicaciones exige contenido nuevo ni pantallas nuevas, y ese es el argumento decisivo para abordar el modo mesa antes que cualquier otra mejora de plegables: el trabajo consiste en redistribuir piezas que ya existen a lo largo de un eje que el usuario acaba de crear con las manos.

El modo libro aparece con el pliegue vertical y el aparato medio abierto, sostenido como un volumen impreso. Su lectura es distinta y menos espectacular pero igual de útil: dos páginas de igual rango. Encaja con lectores, con galerías de dos imágenes, con documentos a doble página y con cualquier lista y detalle donde ambos lados tengan peso comparable.

Hay una tercera postura que suele olvidarse y que da más valor por menos trabajo que las dos anteriores: la pantalla exterior con el aparato cerrado. En muchos plegables es una superficie plenamente funcional, y a menudo con proporciones inusuales que rompen suposiciones de diseño. Además, el sistema ofrece la posibilidad de mover una sesión a esa pantalla exterior, lo que habilita casos como el autorretrato con la cámara principal usando la pantalla externa como visor. Requiere pedir el cambio de área de visualización y estar preparado para que el contenido aterrice en un rectángulo muy distinto.

Continuidad: el medio segundo que decide todo

Plegar o desplegar es un cambio de configuración, y por defecto el sistema destruye y recrea la actividad. Todo lo que no esté preparado desaparece: la posición del desplazamiento, el texto a medio escribir, el fotograma del vídeo, la selección, el estado del formulario, la posición de la cámara del mapa. El usuario no interpreta eso como una limitación del hardware sino como un fallo de la aplicación, y con razón.

La solución tiene tres capas y conviene aplicarlas en orden. La primera es el estado de larga vida, que pertenece a un contenedor que sobrevive a la recreación —el modelo de vista— y que debe albergar todo lo que sea datos, selección y navegación. La segunda es el estado efímero de la interfaz, que se conserva con los mecanismos de guardado de la composición y que cubre desplazamientos, expansiones y campos de texto. La tercera son los recursos con posición propia, como un reproductor multimedia o una sesión de cámara, que no se guardan copiando un valor sino gestionando su ciclo de vida por encima del de la actividad y restaurando la posición exacta.

// Lo que debe sobrevivir a plegar y desplegar, por capas
class ModeloDeVista : ViewModel() {
    val seleccionado = MutableStateFlow<Long?>(null)     // capa uno
    val posicionMedia = MutableStateFlow(0L)             // capa tres, valor a restaurar
}

@Composable
fun Contenido(modelo: ModeloDeVista) {
    val estadoLista = rememberLazyListState()            // capa dos
    var borrador by rememberSaveable { mutableStateOf("") }
}

Hay una cuarta capa que no es de estado sino de percepción y que decide buena parte de la calidad percibida: la transición visual. Aunque el estado sobreviva íntegro, un cambio brusco de disposición se lee como un parpadeo y hace dudar al usuario de si algo se ha perdido. Animar el paso de una columna a dos, conservar la posición del elemento seleccionado durante el movimiento y evitar el fotograma en blanco cuestan poco cuando se usan las estructuras adaptativas —que ya traen las animaciones calibradas— y muchísimo cuando se construyen a mano.

Queda una decisión de diseño que se plantea siempre y que conviene resolver con criterio: si conviene declarar en el manifiesto que la actividad gestiona por su cuenta los cambios de tamaño y de orientación para evitar la recreación. La respuesta honesta es que esa declaración resuelve el síntoma y esconde el problema. Una aplicación que solo funciona porque nunca se recrea sigue perdiendo el estado cuando el sistema mata el proceso por presión de memoria, que es un escenario mucho más frecuente en tablets con varias aplicaciones abiertas. Manejar el cambio puede ser legítimo por rendimiento en casos concretos, pero nunca sustituye a la gestión correcta del estado.