Wear OS: Compose, tiles y complicaciones

Durante veintiocho niveles hemos dado por supuesto que el usuario mira la pantalla porque ha decidido mirarla: abre la aplicación, se queda, hace algo y se va. En la muñeca esa cadena se rompe por completo. El usuario no abre nada; levanta el brazo por un impulso de medio segundo, obtiene o no obtiene lo que buscaba y lo baja, y el gesto entero dura menos que el tiempo que tarda una pantalla de carga en resolverse. A esa asimetría se le suman restricciones que en un teléfono son molestias y aquí son leyes: una batería que se mide en horas y no en días, una pantalla que a menudo es redonda y siempre es diminuta, una sola mano libre porque la otra sostiene el brazo, y un modo ambiente en el que el sistema apaga casi todo y tu interfaz debe seguir siendo legible. Wear OS no premia a quien porta bien su aplicación de teléfono; premia a quien acepta que la aplicación completa es el último recurso y no el primero.

La muñeca impone su propia economía

La primera tentación al abordar el reloj es tratarlo como un teléfono muy estrecho y reutilizar el trabajo adaptativo del nivel trece. La tentación es comprensible y es errónea, porque lo que cambia no es la anchura disponible sino la naturaleza de la sesión. Una sesión de teléfono se mide en minutos y admite navegación, exploración y error. Una sesión de reloj se mide en segundos, ocurre con el brazo levantado contra la gravedad y compite con lo que el usuario estaba haciendo con las manos. Nadie navega en un reloj: se consulta o se actúa.

De esa premisa se derivan tres restricciones duras. La energética es la más obvia y la peor entendida: el presupuesto de batería de un reloj se agota en un día, y cualquier trabajo periódico que tu aplicación programe se paga en autonomía del dispositivo entero. Sondear una red cada minuto no es una decisión de ingeniería discutible, es un defecto. La física viene después: una pantalla redonda pierde las esquinas, de modo que cualquier disposición rectangular desperdicia área o recorta contenido, y el objetivo táctil mínimo no puede reducirse porque el dedo no encoge con la pantalla. Y la postural, que se olvida siempre: el brazo levantado se cansa, y esa fatiga fija un límite superior real al tiempo que el usuario tolerará delante de tu interfaz.

A eso se añade una entrada que no existe en ningún otro sitio: el giro. La corona rotatoria o el bisel giratorio permiten desplazar sin tapar la pantalla con el dedo, que es exactamente el problema que hace insoportable el desplazamiento táctil en una superficie de este tamaño. Soportar la entrada rotatoria no es un detalle de accesibilidad sino la diferencia entre una lista usable y una que no lo es, y se obtiene gratis si se usan los contenedores de la biblioteca en lugar de los genéricos.

Conviene además desactivar una suposición heredada de las primeras versiones de la plataforma: que el reloj es un accesorio del teléfono. Hace años lo era, y una aplicación de reloj sin teléfono emparejado no tenía sentido. Hoy los relojes son autónomos: tienen su propia conectividad, su propia sesión de usuario y su propia instalación desde la tienda, y una aplicación que exija la presencia del teléfono para funcionar falla precisamente en el escenario donde el reloj más brilla, que es cuando el usuario ha salido a correr sin él. La comunicación entre ambos dispositivos sigue existiendo y sigue siendo útil para sincronizar credenciales y preferencias, pero pasa de ser el cimiento a ser una optimización.

Hay una última asimetría que conviene tener presente porque condiciona el diseño de las notificaciones. Un aviso en el teléfono compite con una pantalla apagada en un bolsillo; un aviso en la muñeca es una vibración sobre la piel, con una tasa de percepción cercana al cien por cien y un coste de interrupción muy superior. La consecuencia es que el umbral de qué merece notificarse tiene que subir de forma drástica, y que replicar sin filtro las notificaciones del teléfono en el reloj es el camino más rápido para que el usuario desactive las tuyas por completo.

Compose para reloj no es el Compose que conoces

Compose para Wear OS comparte el compilador, el modelo de recomposición, el estado y los modificadores con el Compose que ya dominas. Lo que no comparte es la capa de materiales: existen artefactos propios de Wear OS que ofrecen componentes con nombres a menudo idénticos a los del catálogo de teléfono pero con comportamiento, métricas y tipografía calibrados para la muñeca. Mezclar ambos catálogos compila y produce una interfaz que parece correcta en el previsualizador y resulta inservible en el aparato, porque los tamaños de toque, los contrastes y los márgenes están pensados para otra distancia de lectura.

La consecuencia estructural más visible es el reemplazo del contenedor de lista. En lugar de una lista perezosa plana, la plataforma ofrece contenedores que escalan y desvanecen los elementos según su distancia al centro, de modo que el elemento enfocado se lee grande y nítido mientras los de los extremos se reducen para acompañar la curvatura del cristal. No es un adorno: es la respuesta al hecho de que en una pantalla redonda los extremos vertical superior e inferior tienen menos anchura útil que el centro.

@Composable
fun PantallaDeReloj(elementos: List<Resumen>) {
    AppScaffold {
        val estado = rememberTransformingLazyColumnState()
        ScreenScaffold(scrollState = estado) { relleno ->
            TransformingLazyColumn(state = estado, contentPadding = relleno) {
                items(elementos, key = { it.id }) { elemento ->
                    TitleCard(
                        onClick = { abrir(elemento.id) },
                        title = { Text(elemento.titulo, maxLines = 1) },
                    )
                }
            }
        }
    }
}

La segunda consecuencia estructural es tipográfica y de forma. En una pantalla circular, el texto que ocupa el ancho completo se corta en las esquinas, de modo que la plataforma ofrece texto curvo que sigue el borde y contenedores que reservan márgenes proporcionales al radio. Un botón que se extiende de lado a lado tampoco funciona igual: la convención propia del reloj es un botón que abraza el borde inferior con la curvatura del cristal, aprovechando la única franja que de otro modo quedaría vacía. Ninguna de estas piezas tiene equivalente en el catálogo de teléfono, y ese es el argumento definitivo de por qué son bibliotecas separadas y no un tema distinto de la misma.

Hay dos piezas de andamiaje que conviene no saltarse. El armazón de aplicación y el armazón de pantalla coordinan entre ellos la hora que se dibuja en el arco superior, el indicador de posición curvo del borde derecho y las transiciones entre pantallas; construirlos a mano significa reimplementar tres comportamientos que el usuario espera y que además cambian con la versión del sistema. Y el modo ambiente obliga a que cada pantalla tenga una versión de bajo consumo, sin animaciones, con menos píxeles encendidos y sin información que caduque, porque el reloj pasa la mayor parte del tiempo en ese estado y esa es la cara que tu aplicación enseña de verdad.

Tiles y complicaciones: tu aplicación fuera de tu aplicación

Aquí está el cambio conceptual que define la plataforma. En Wear OS tu aplicación tiene tres superficies con tres modelos de ejecución distintos, y la más usada casi nunca es la aplicación.

La tile es una pantalla completa que el usuario alcanza deslizando desde la esfera, sin abrir nada. No ejecuta Compose ni tiene bucle de recomposición: tu proceso construye una descripción declarativa de la disposición, se la entrega al sistema y termina. El sistema la dibuja cuando quiere y la conserva. La actualización no es continua sino por caducidad: declaras cada cuánto deja de ser fiable el contenido, o solicitas un refresco cuando ocurre algo relevante. Esa arquitectura es exactamente lo que hace viable la superficie desde el punto de vista energético, y es también lo que obliga a diseñarla como una instantánea que envejece con dignidad y no como una vista en vivo.

La complicación es más pequeña todavía: un dato tuyo dibujado dentro de la esfera del reloj, con la presentación decidida por la esfera y no por ti. Publicas un servicio que responde con un valor tipado —un texto breve, un rango con progreso, un icono monocromo— y el sistema lo pide cuando le conviene. No controlas ni el color, ni la fuente, ni la posición, y esa pérdida de control es el precio de estar en la única pantalla que el usuario mira decenas de veces al día.

flowchart TD
A[Datos de tu dominio] --> B[Complicacion en la esfera]
A --> C[Tile deslizando desde la esfera]
A --> D[Aplicacion completa]
B --> E[Un dato con formato del sistema]
C --> F[Instantanea declarativa con caducidad]
D --> G[Compose con interaccion completa]
E --> H[Coste de atencion casi nulo]
F --> I[Coste de atencion de un deslizamiento]
G --> J[Coste de atencion mas alto]
style E fill:#a6e3a1,color:#11111b
style J fill:#f38ba8,color:#11111b

class ComplicacionDePasos : SuspendingComplicationDataSourceService() {
    override suspend fun onComplicationRequest(request: ComplicationRequest): ComplicationData =
        RangedValueComplicationData.Builder(
            value = pasosDeHoy().toFloat(),
            min = 0f,
            max = objetivoDiario().toFloat(),
            contentDescription = PlainComplicationText.Builder("Pasos de hoy").build(),
        ).setText(PlainComplicationText.Builder("$pasos").build()).build()
}

La lección de arquitectura que se extrae de las tres es que el dato debe estar disponible sin arrancar tu interfaz. Una capa de datos que solo sabe entregar valores dentro de un modelo de vista, con su corrutina, su suscripción y su ciclo de vida, no sirve para responder a una petición de complicación que debe resolverse en milisegundos y desde un proceso que morirá inmediatamente después. La forma correcta es una fuente de verdad persistida y consultable en frío, con el último valor conocido siempre disponible y con su marca de tiempo, de modo que las tres superficies lean del mismo sitio y ninguna dependa de que otra esté viva.

Existe una cuarta superficie para el caso concreto de una tarea en curso —un entrenamiento, una ruta, un temporizador— que ocupa un lugar destacado mientras dura y desaparece al terminar. Es la respuesta correcta a la tentación de mantener la aplicación abierta en primer plano, que en un reloj es un modo muy caro de decir sigo aquí.

El presupuesto de tres segundos

La regla operativa que mejor ordena todas las decisiones anteriores es tratar el tiempo del usuario como un presupuesto explícito y no como un objetivo difuso. Tres segundos desde que el brazo sube hasta que baja. Dentro de ese presupuesto caben, con suerte, una lectura y un toque.

De ahí salen consecuencias muy concretas. Una tarea por pantalla, sin excepciones: si tu pantalla ofrece dos acciones de igual rango, ya has gastado el presupuesto en la decisión. Ninguna entrada de texto, porque escribir en la muñeca es un castigo; si tu flujo la exige, o se resuelve con dictado y respuestas prefabricadas, o se delega al teléfono. Sin pantallas de carga visibles: si el dato no está listo, se muestra el último conocido con su marca de antigüedad, que es infinitamente mejor que un indicador girando durante el único segundo que tenías. Y confirmación breve y automática, un símbolo que aparece medio segundo y se va, en lugar de un diálogo que exige un segundo toque para cerrarse.

El presupuesto energético se administra con la misma disciplina y con una regla equivalente: el trabajo se hace cuando el sistema lo permite, no cuando a ti te conviene. Las herramientas son las que ya conoces del nivel veinte —trabajo diferible con restricciones, alarmas exactas solo cuando están justificadas— pero los umbrales son mucho más severos y el sistema es mucho más agresivo al aplazar. Los sensores, por su parte, no se leen directamente sino a través de la capa de servicios de salud, que agrega, filtra y entrega en lotes precisamente para no despertar el procesador principal en cada muestra.

Queda una decisión de producto que conviene tomar pronto y explícitamente: qué parte del recorrido termina en el reloj y qué parte se delega al teléfono. Delegar no es una derrota; es reconocer que ciertas tareas exigen una superficie mayor y que ofrecer un salto limpio hacia ella es mejor experiencia que una versión mutilada en la muñeca. Lo que nunca funciona es la posición intermedia: un flujo que empieza en el reloj, se complica y deja al usuario sin salida ni continuación.

Conviene cerrar con la reordenación de prioridades que se deriva de todo lo anterior y que va contra el orden natural de trabajo. La primera entrega de una aplicación de reloj debería ser una complicación y una tile, sin aplicación completa o con una mínima, porque ahí está el noventa por ciento del valor y una fracción del coste. La aplicación completa se construye después, cuando ya se sabe, por el uso real, qué es lo que la gente quería ver en la muñeca.