El éxito de los smartphones era más que un hecho, la tecnología avanzaba a pasos agigantados, cada vez se podía concentrar más potencia en menos espacio. Esto hizo a Google mirar más adelante de los smartphones e intentar integrar la potencia y utilidades que estos te ofrecían en otros dispositivos. Fue aquí donde nació la idea de las Google Glass, un elemento clave que impulsaría el uso de los tan de moda hoy en día weareables. Pero centrémonos en las metodologías de desarrollo.

Existen dos posibilidades para crear Glassware (aplicaciones ejecutables en las Google Glass), dos API: por un lado el que llamaremos “nativo” y por otro el Mirror API. Independientemente es posible emplear ambas al mismo tiempo, dando lugar a una solución híbrida que se explicará más adelante. Generalmente el tipo de API que se escoje depende de los patrones de diseños y la arquitectura concreta que se definida para la aplicación.gdk-glassware-android

GDK, acceso al hardware específico

La metodología nativa emplea como herramientas el lenguaje de programación al que ya nos tiene acostumbrados Android, Java, y el SDK tradicional utilizado para todos los desarrollos enfocados a este SO. Esta base facilita sin duda la rápida adaptación de los desarrolladores Java y Android a la creación de apps para la plataforma wereable.

Sin embargo, Google pone a nuestra disposición un conjunto de librerías enfocadas específicamente a las Glass. Es el llamado GDK (Glass Development Kit) y es un “add-on” para el SDK de Android que permite construir un Glasswere más enfocado. La ejecución de estas apps corre de cargo del procesador de las Google Glass y puede acceder al hardware de bajo nivel de estas, para proporcionar funcionalidades más específicas (GPS, sensores de movimiento, etc…).

sdk-gdk

Mirror API, glassware centralizado

La segunda opción es la que hace uso del denominado Mirror API. Es la primera vía que se posibilitó para la creación de Glassware, y se basa en la centralización de todo el procesamiento en un servidor web. Es por tanto este el que sirve la información estática en forma de “cards” al dispositivo portátil, para que el trabajo de las Glass se limite únicamente a mostrarla por pantalla.

Con este método y la ayuda de los servidores web de Google, que hacen el trabajo duro por ti, es sencillo sacar adelante aplicaciones simples. Estos proporcionan APIs REST fáciles de usar y que pueden englobar toda la funcionalidad desarrollada. Además es más flexible en cuestiones de lenguaje, siendo posible elegir entre Java, PHP y Phyton entre otros.

Al igual que en el caso de desarrollar con el GDK, para probar el Glassware que usa Mirror API existen emuladores que nos permiten prescindir del dispositivo físico en la mayoría de las fases del desarrollo. Un ejemplo de emulador en código abierto es Xenologer.

¿Con cuál nos quedamos?

Por supuesto, la respuesta a esta pregunta no podía ser otra: depende.

Al utilizar la SDK de Android y el GDK, se aprovecha la amplia gama de librerías que Android nos ofrece y a la vez podemos diseñar una aplicación que garantiza una experiencia extra con el acceso a las características del hardware de bajo nivel. Como desarrolladores trabajaremos en un entorno familiar, con el SDK de Android, pero para un dispositivo de forma única, totalmente nuevo en el mercado. Además garantizaremos el tiempo real y la autonomía del Glassware con respecto a la red (se posibilita el funcionamiento offline).google-glass

Si lo que queremos como resultado es una aplicación para diferentes plataformas, además de las Google Glass, con una infraestructura común y  funcionalidad unificada a grandes rasgos, entonces nuestra opción es el Mirror API. Además extraemos el procesamiento de las Glass y lo centralizamos en el lado del servidor, que puede alcanzar una potencia tal como n
osotros definamos, casi sin límites.

Si no logramos decidirnos siempre tenemos la opción de hacer Glassware híbrido, con ambos métodos. En las cards estáticas servidas por el Mirror API se puede invocar desde un ítem de menú código nativo, que usa el GDK. Con esta fusión podemos hacer uso de las ventajas de ambos métodos, pero debemos de controlar que la heterogeneidad en lenguajes y metodologías no afecten a la robustez de nuestro sistema.