Android XR: ventanas espaciales y volumenes

Cada superficie de este nivel ha exigido reescribir la interfaz: el reloj obligó a destilar, el televisor a materializar el foco y el coche a renunciar al lienzo. Android XR rompe esa pauta y lo hace de una forma que conviene entender antes que ninguna otra cosa: una aplicación adaptativa correcta ya se ejecuta en un visor, sin cambios, sin artefactos nuevos y sin declaraciones adicionales, porque el sistema la trata como lo que es —una ventana redimensionable— y le concede un rectángulo flotante en el espacio del usuario. Todo lo que se hizo en el nivel trece para sobrevivir a tablets y plegables se cobra aquí por segunda vez y sin trabajo adicional. Lo que sí es nuevo empieza donde termina esa herencia: el momento en que la aplicación decide dejar de ser un rectángulo. Entonces aparecen los paneles múltiples colocados en el espacio, los controles que flotan fuera del marco, el contenido con profundidad real y un entorno que la aplicación puede sustituir por completo. Este es el territorio menos asentado del ecosistema y el que más recompensa a quien llega con los fundamentos hechos.

Dos modos, dos contratos

El sistema ofrece dos modos de ejecución y la diferencia entre ambos gobierna todo lo demás. En el modo compartido, varias aplicaciones conviven a la vez en el espacio del usuario, cada una en su ventana flotante, exactamente igual que en un escritorio con ventanas libres pero sin las paredes de un monitor. Es el modo por defecto, es donde aterriza cualquier aplicación existente y es donde el usuario pasa la mayor parte del tiempo, porque es el que permite consultar el correo mientras se ve un vídeo y se sigue una receta.

Vale la pena detenerse en lo que significa que ese sea el modo por defecto. Significa que la plataforma ha decidido que su escenario principal es la productividad multiventana y no la experiencia inmersiva de un solo título, que es exactamente la apuesta contraria a la que hicieron las plataformas de realidad virtual orientadas al juego. Esa decisión estratégica explica por qué el sistema ejecuta aplicaciones Android sin modificar, por qué la biblioteca espacial se construyó sobre Compose en lugar de sobre un motor gráfico, y por qué el trabajo que este nivel recomienda es tan barato para quien ya tiene la base hecha.

En el modo inmersivo, una sola aplicación ocupa el espacio entero. Las demás se ocultan, el entorno puede reemplazarse por uno propio y la aplicación obtiene acceso a las capacidades que exigen exclusividad. Es un modo que se solicita y que el usuario concede, no un estado que se declara en el manifiesto, y del que se puede salir en cualquier momento. Entrar y salir es, a todos los efectos, un cambio de configuración más de los que ya sabemos gestionar: si el estado de tu aplicación no sobrevive a una rotación, tampoco sobrevivirá aquí.

flowchart TD
A[Aplicacion adaptativa existente] --> B[Modo compartido]
B --> C[Ventana flotante redimensionable]
C --> D[Solicitud de modo inmersivo]
D --> E[El usuario concede]
D --> F[El usuario deniega]
E --> G[Espacio exclusivo con entorno propio]
G --> H[Paneles multiples y volumenes]
F --> C
G --> I[Salida al modo compartido]
I --> C
style C fill:#a6e3a1,color:#11111b
style G fill:#89b4fa,color:#11111b

Conviene subrayar que el modo compartido no es un modo de compatibilidad ni un premio de consolación para aplicaciones no adaptadas. Es el escenario dominante y probablemente lo seguirá siendo, por la misma razón por la que el escritorio no se convirtió en una sucesión de aplicaciones a pantalla completa: la utilidad de un espacio de trabajo crece con el número de cosas que se pueden mirar a la vez. Diseñar pensando exclusivamente en la experiencia inmersiva es el equivalente de diseñar una aplicación de ordenador que solo funcione maximizada.

La consecuencia arquitectónica es que el modo no puede tratarse como una bifurcación de código sino como un estado observable más, del mismo rango que la clase de tamaño de ventana. Una aplicación que construye dos árboles de interfaz completamente separados, uno plano y otro espacial, duplica su superficie de defectos y su coste de mantenimiento. Lo correcto es un único árbol cuya estructura de nivel superior consulta si hay capacidades espaciales disponibles y, en caso afirmativo, reparte el mismo contenido entre varios paneles en lugar de apilarlo en uno.

Hay una tercera variable que acompaña al modo y que conviene no confundir con él: el grado de inmersión visual. Un visor puede mostrar el entorno real capturado por sus cámaras, puede sustituirlo por completo por uno sintético, o puede mezclar ambos en proporción variable. Esa elección pertenece en parte al usuario y en parte a la aplicación cuando tiene el espacio en exclusiva, y tiene consecuencias que van más allá de lo estético: sustituir el entorno real aísla, y aislar a alguien que está sentado en su salón con otras personas es una decisión de producto con implicaciones sociales, no un ajuste de fondo de pantalla.

El panel espacial y el orbitador

El panel espacial es la unidad básica y su definición es deliberadamente conservadora: una superficie plana con contenido de Compose corriente, colocada en un punto del espacio, con su tamaño y su orientación. Dentro de un panel todo funciona como siempre —los mismos componentes, los mismos modificadores, el mismo estado— y esa continuidad es intencionada, porque la apuesta de la plataforma es que la interfaz de una aplicación productiva seguirá siendo mayoritariamente plana durante mucho tiempo. Lo que cambia es que ahora puede haber varios paneles a la vez y que su disposición relativa se expresa con contenedores propios que colocan en las tres dimensiones.

@Composable
fun EspacioDeTrabajo(hayEspacio: Boolean, modelo: Modelo) {
    if (!hayEspacio) {
        PanelUnico(modelo)
        return
    }
    SpatialRow {
        SpatialPanel(SubspaceModifier.width(640.dp).height(720.dp)) {
            ListaDeConversaciones(modelo)
        }
        SpatialPanel(SubspaceModifier.width(900.dp).height(720.dp)) {
            DetalleDeConversacion(modelo)
            Orbiter(position = OrbiterEdge.Bottom) { BarraDeAcciones(modelo) }
        }
    }
}

Ese conservadurismo tiene una justificación que conviene explicitar porque contradice la expectativa popular sobre la realidad extendida. El texto, las listas, los formularios y las tablas son planos por buenas razones y no por limitación tecnológica: la lectura es una actividad bidimensional, y una superficie plana perpendicular a la mirada es la disposición óptima para ella. Un visor no mejora un correo electrónico dándole profundidad; lo mejora permitiendo tener abiertos el correo, el calendario y el documento a la vez, sin que ninguno tape a los otros y sin el límite de un monitor. La ganancia está en el número y la colocación de las superficies planas, no en dejar de serlo.

El orbitador es la pieza genuinamente nueva y la más fácil de infravalorar. Es un fragmento de interfaz anclado a un panel pero situado fuera de su superficie, flotando junto a uno de sus bordes. Resuelve un problema viejo que en dos dimensiones no tiene solución limpia: los controles siempre han competido por espacio con el contenido, y toda barra de herramientas es contenido que no se ve. En el espacio, esa competencia desaparece porque el contorno del panel deja de ser el límite del mundo. Las barras de navegación, los controles de reproducción y las acciones contextuales son candidatos naturales, y el criterio para decidir qué se orbita es simple: aquello que acompaña permanentemente al contenido sin formar parte de él.

La disposición de varios paneles obliga además a una decisión que en dos dimensiones no existía: dónde termina el espacio de trabajo. Un usuario sentado tiene un campo cómodo que abarca poco más de lo que puede ver sin girar el cuello, y cualquier panel colocado fuera de él se convierte en un elemento que existe pero que nadie usará. La regla práctica es tratar ese campo como el equivalente del área segura del televisor: lo importante dentro, lo prescindible en los flancos y nada en la espalda. Y como el usuario puede moverse, esa disposición debe poder recentrarse a petición en lugar de quedar clavada al punto donde estaba al arrancar.

Hay una tercera diferencia estructural que se olvida y que degrada la experiencia mucho antes que cualquier detalle visual: el audio espacial. En un visor, un sonido que no procede de la posición del panel que lo genera se percibe como un fallo, porque el usuario ya ha localizado ese panel en su mapa mental del espacio. Situar el sonido es barato y su ausencia es muy cara.

El volumen: el primer contenedor con profundidad

Un volumen es una región tridimensional acotada dentro de la cual la aplicación coloca contenido con geometría real: un modelo, una escena, una representación de datos con altura además de anchura. Es el punto donde el desarrollo deja de parecerse al desarrollo de interfaces y empieza a parecerse al gráfico tridimensional, con sus mallas, sus materiales, sus transformaciones y sus anclajes al mundo físico.

El criterio para usar un volumen debe ser exigente, porque el coste de producción del contenido tridimensional es de otro orden de magnitud y su beneficio es muy desigual. La pregunta correcta es si la tercera dimensión transporta información que en un plano se pierde: la forma real de un producto antes de comprarlo, la relación espacial de las piezas de un ensamblaje, el relieve de un terreno, la trayectoria de un cuerpo. Cuando la respuesta es sí, el volumen es insustituible. Cuando la respuesta es que queda espectacular, se está pagando un coste alto por una novedad que caduca en la segunda sesión.

Por debajo del volumen hay una capa de escena con entidades, modelos y sesión, y por debajo aún, las capacidades de comprensión del entorno: detección de superficies, seguimiento de manos, anclajes que fijan contenido a un punto del mundo real. Esa capa es la que convierte una aplicación espacial en una aplicación de realidad aumentada propiamente dicha, y es también la que introduce consideraciones de privacidad severas, porque los datos que describen la habitación de alguien son de una intimidad que ningún permiso anterior había tocado.

Conviene detenerse un instante en esa cuestión porque marca un salto cualitativo respecto a todo el modelo de permisos que estudiamos en el nivel veintidós. La ubicación revela dónde está alguien; la cámara revela lo que apunta. La comprensión del entorno de un visor revela la geometría del interior de una vivienda, la posición de sus muebles, cuántas personas hay en la sala y hacia dónde está mirando el usuario en cada instante. La dirección de la mirada, en particular, es un dato de una capacidad inferencial notable, porque delata atención, duda e interés con una precisión que ningún registro de toques alcanza. La consecuencia de diseño es que el acceso debe pedirse tarde, con propósito visible y por la mínima capacidad suficiente, y que la mirada en concreto conviene tratarla como una señal de entrada que el sistema resuelve por ti y no como un dato que tu aplicación registra.

Cuando el volumen sí está justificado, hay una decisión previa que condiciona todo el proyecto y que es de producción y no de programación: de dónde salen los modelos. Un catálogo tridimensional de un producto real exige capturarlo, limpiarlo, optimizarlo para un dispositivo con presupuesto térmico ajustado y mantenerlo actualizado cuando el catálogo cambie. Ese trabajo es continuo, no puntual, y suele exceder con mucho al de escribir el código que lo muestra. Los equipos que subestiman esta partida acaban con tres modelos impecables y un catálogo de miles de referencias sin representación.

Lo que se hereda y lo que no

Esta última sección es, en términos prácticos, la más rentable del nivel, porque convierte una superficie que parece exótica en una consecuencia de trabajo ya hecho. Conviene recorrerla con una lista en la mano y marcar cada punto, porque la diferencia entre un equipo que estima este proyecto en meses y otro que lo estima en días suele estar exclusivamente en cuánto de esta lista tenía resuelto de antemano.

La lista de lo heredado es larga y merece explicitarse porque es el argumento con el que se financia el trabajo. Se hereda la arquitectura entera: capa de datos, casos de uso, modelos de vista y estado. Se hereda el catálogo de componentes, porque dentro de un panel el Compose es el mismo. Se hereda todo el diseño adaptativo, y de la forma más literal posible: las clases de tamaño de ventana siguen siendo la señal correcta, los patrones canónicos de lista y detalle siguen siendo los patrones correctos, y los paneles múltiples no son más que el caso extremo del panel expandido. Se hereda la continuidad de estado, y su ausencia se castiga igual que antes. Y se hereda la semántica de accesibilidad, que aquí gana importancia porque el usuario puede navegar por mirada.

Conviene señalar además que se hereda la cadena de herramientas casi completa: el mismo proyecto, el mismo Gradle, los mismos artefactos de Jetpack, el mismo depurador y un emulador de visor que se instala como cualquier otra imagen de dispositivo. No hay un ecosistema paralelo, no hay un motor separado y no hay un lenguaje distinto. Esa continuidad es la apuesta central de la plataforma y explica por qué el punto de partida razonable no es un prototipo desde cero sino la aplicación que ya tienes.

Se hereda incluso algo que sorprende y que conviene señalar porque es un argumento de venta interna muy eficaz: la tipografía adaptativa. La lección del televisor introdujo el tamaño angular como unidad real de legibilidad, y en el visor esa unidad se vuelve literal, porque un panel puede estar a medio metro o a tres y el sistema escala en consecuencia. Un equipo que ya expresó su escala tipográfica en términos relativos y que ya probó su interfaz a distintas densidades y tamaños de ventana no tiene aquí nada que rehacer.

Lo que no se hereda es más corto pero no trivial. La colocación en el espacio no tiene equivalente plano y exige decidir dónde está cada cosa respecto al cuerpo del usuario, teniendo en cuenta que girar el cuello cansa y que nada debería quedar detrás. La entrada cambia de naturaleza: la combinación de mirada y pellizco significa que el elemento apuntado es aquel al que el usuario está mirando, lo que hace de los estados de resaltado algo tan crítico como el foco en televisión y hace de los objetivos pequeños y contiguos un problema serio. El confort aparece como requisito nuevo y sin precedente: el movimiento no solicitado, el contenido demasiado cercano y el texto que sigue la cabeza producen fatiga o malestar físico. Y la profundidad tipográfica obliga a revisar tamaños, porque un texto legible se define aquí por su tamaño angular y no por su tamaño en puntos.

De todas ellas, la del confort es la única que no tiene precedente en ninguna superficie anterior y la que conviene tratar con más respeto, porque sus fallos no producen frustración sino malestar corporal. Las reglas prácticas son pocas y muy firmes: nada de movimiento de la escena que el usuario no haya provocado, nada de contenido a menos de la distancia mínima cómoda, nada de elementos clavados al campo visual que sigan la cabeza como una mosca, y transiciones cortas y suaves en lugar de saltos. Un defecto de esta clase no se reporta como error: el usuario se quita el visor y no vuelve.

Queda una advertencia de madurez que sería deshonesto omitir. Este es el territorio menos asentado de todo el ecosistema: el hardware disponible es escaso, la base instalada es pequeña, las bibliotecas siguen moviéndose y las convenciones de diseño no han tenido tiempo de decantarse como las del televisor o las del reloj. Eso no desaconseja el trabajo, pero sí aconseja invertirlo en el orden correcto. Todo lo que se haga en la base adaptativa conserva su valor pase lo que pase con la plataforma; todo lo que se haga en volúmenes y comprensión del entorno es una apuesta cuyo horizonte de amortización es incierto y debe presupuestarse como tal.