Hola, queridos míos. En esta entrada os voy a contar sobre mis recientemente adquiridos conocimientos sobre el desarrollo de una aplicación para el Apple Watch. No os preocupéis porque no voy a ser nada técnico, de hecho la entrada está concebida como un desahogo más que otra cosa.

Ah, está permitido reírse.

La primera en la frente. El modelo de aplicación del reloj se concibe en tres partes. Una de ellas es la aplicación padre, que no es más que la clásica del teléfono.

Es decir, para desarrollar para el reloj lo primero que tienes que hacer es crear una aplicación para el iPhone. Creo que las de tipo universal iPhone/iPad también son válidas.

Luego creas el proyecto para el reloj, que a su vez se compone de dos aplicaciones. La más importante de ellas es lo que se llama WatchKit Extension y que se ejecutará en el teléfono. Sí, lo habéis leído bien: en el teléfono.

La segunda es la que se conoce como WatchKit App y que se ejecutará en el reloj.

Es decir, cuando lanzamos una aplicación en el reloj, se está ejecutando en dos lugares a la vez: en tu teléfono y en tu reloj, y ese es uno de los motivos por los cuales la batería de los iPhone baja más rápido si tiene asociado un reloj. Lo que está haciendo es usar tiempo de cómputo en el teléfono para, supongo ahorrar batería en el reloj.

—

La parte que está en el reloj únicamente contiene dos ficheros: lo que se llama el storyboard, que es un fichero de texto (en XCode) que es interpretado como todas y cada una de las pantallas que se van a mostrar en el reloj, y el fichero de recursos que contiene los iconos y las imágenes. También hay un tercer fichero que no viene al caso, que es info.plist, donde se guardan ciertos metadatos de la aplicación.

Ahora viene lo kafkiano

¿Qué pasa cuando lanzas una aplicación desde el reloj? Pues que se carga desde el teléfono en la memoria del reloj. Es decir, el programa se mueve, a través del canal Bluetooth, entre tu terminal y tu watch, ejecutándose con posterioridad.

Esa es la teoría.

En la práctica, gran parte del programa sigue residiendo en el teléfono, de modo que los eventos generados en un lado, se ejecutan en el otro.

Es decir, supongamos por ejemplo que pulsamos un botón en la pantalla de nuestro reloj. El evento se redirecciona del reloj al iPhone, que ejecutará el código y devolverá el resultado al reloj, resultado que podría ser abrir una nueva pantalla.

Eso mismo ocurre con todos y cada uno de los aspectos de la interactuación con el usuario. Los toques en la pantalla, los cambios de texto, cualquier cosa que hagas en el reloj, va al teléfono, se ejecuta en él, y retorna. Por ejemplo, mover un slider (ese control con un más y un menos que incrementa una barrita central) es lento, pero lento de cojones. Puedes dar dos o tres taps seguidos y ver cómo se mueve paso a paso.

Esperad, esperad, que todavía hay más

Pero la cosa no termina aquí. ¿Dónde están los sensores de salud? En el reloj, ¿verdad? ¿De dónde se leen?

Efectivamente, ¡¡del teléfono!! Es decir, una aplicación en el reloj no puede leer los propios sensores del reloj. No solo eso, sino que la extensión tampoco. Es decir, la parte del programa del reloj que se ejecuta en el teléfono tampoco puede leerlos. Es la aplicación del teléfono la que tiene que hacerlo.

Pero aun hay más, no se vayan todavía, amigos, parafraseando a un personaje de dibujos animados. No se pueden leer en tiempo real. Lo que te digo. Si quieres las pulsaciones, tienes que leer la última vez que se midieron.

De hecho, hasta donde yo sé, nada del HealthKit se puede leer en tiempo real. Ni siquiera puedes iniciar tu un ejercicio (que se llama Workout en el argot) y luego leer los cambios. Eso está reservado a las aplicaciones de Apple, que por cierto sí se ejecutan completamente dentro del reloj.

Lo que sí puedes hacer es añadir datos a la base de datos de salud, lo que está bien para los que quieran integrar pulseras y otras cosas, pero muy mal para los que quieran beber de los datos en tiempo real.

Seguimos con las escarilotropías gmmnésicas

Vamos a suponer que, ya que hay muchas cosas que se tienen que ejecutar no solo en el teléfono, sino en la aplicación nativa del iPhone y no en la extensión, Apple habrá implementado algún tipo de potentísimo mecanismo de comunicación entre la extensión y la aplicación, ¿verdad?

Pues no. Básicamente el reloj puede hablar con el teléfono mediante un sistema de paso de mensajes bastante chapucero. Resumiendo un poco, el reloj tiene una llamada a la que le puede pasar un diccionario (pares de llave/valor) y la aplicación principal devuelve la llamada de forma asíncrona con otro diccionario.

¿Y si la aplicación principal necesita decirle algo al reloj? Pues como no pregunte el reloj a través de la extensión…

(Esto no es técnicamente cierto, porque se habla de un paso de mensajes a través de no sé qué cola de mensajes que tiene Darwin, pero no he visto ningún ejemplo ni documentación alguna más allá de comentarios insustanciales en foros).

Podríamos añadir otras cosicas, como que el reloj suspende las aplicaciones casi en cuanto dejas de mirar la pantalla, y que tiene dos modos de suspensión que están profusamente documentados (léase de forma irónica). En el primero si vuelves a mirar la pantalla todo sigue igual porque ha estado funcionando con la pantalla apagada, pero en el otro cuando recuperas, unos datos están, los otros no, otros están a medias…

—

¿Os habéis divertido? Yo también, dándome cabezazos contra la pared. Y no os cuento las cosicas de Swift, ni de XCode, ni del depurador, ni de lo gráficos y expresivos que son los errores del compilador y de tiempo de ejecución. Todo eso lo dejo para otro momento. En fin, sed buenos.