Casa Techie: una app inclusiva con Realidad Aumentada
-
La iniciativa de volver nuestra casa más techie nace a partir de la mudanza de Flux IT a un nuevo espacio en La Plata. Como propuesta de acompañamiento al hito generado por este cambio, se generó una convocatoria por la red social interna de la empresa (RunRun) para participar en la ideación de propuestas que permitieran aplicar tecnologías innovadoras en las nuevas oficinas tales como Realidad Aumentada, IOT y Machine Learning.
Este encuentro tomó forma de un challenge en el que tres equipos de fluxers presentaron diferentes propuestas. Entre ellas estaba Casa Techie, una aplicación que, utilizando Realidad Aumentada, permite visualizar el calendario de ocupación de una sala de reuniones a partir de la lectura e identificación de una imagen. Ésta terminó siendo la propuesta elegida, y a partir de ese momento iniciamos el camino de desarrollo y nuestra incursión en el mundo de la Realidad Aumentada.
Descubriendo un nuevo mundo
En la primera etapa del proyecto se planificó la construcción de un prototipo con un objetivo de máxima: que permitiera a cualquier fluxer utilizar nuestra aplicación desde su celular. Esto no es un desafío para una aplicación móvil tradicional, aunque sí lo es para una aplicación que utiliza varios sensores del dispositivo para procesar y mostrar la información virtual 3D sobre la visión del mundo real.
Existen tecnologías nativas bien conocidas de Realidad Aumentada (y con un poder de rendering extraordinario) tales como ARKit (iOS) y ArCore (Android), pero el precio de utilizarlas es limitarse a dispositivos avanzados en cuanto a características tecnológicas, dejando fuera distintos modelos de celulares de nuestros colegas en Flux IT. Frente a esto, buscamos otras alternativas, y analizamos Wikitude, Vuforia, AR.js y Awe.js.
Wikitude y Vuforia son librerías privativas y por la naturaleza del proyecto (sumado a que no ofrecen mucho más que librerías open source como AR.js y Awe.js), no justificaban la adquisición de una licencia de uso.
Otro requerimiento importante a nivel tecnológico era la lectura de la imagen que representa a la sala. Este aspecto está muy desarrollado en las tecnologías nativas.No así en las librerías web, en las cuales encontraríamos algunas limitaciones.
Librerías web al frente
Las alternativas finalistas, luego del análisis y las decepciones, fueron AR.js y Awe.js. Ambas librerías están desarrolladas en HTML5 y Javascript, por lo que la aplicación empezaba a vislumbrarse, en principio, como una aplicación web. Además de tener un menor requerimiento de hardware, nos daban lugar a experimentar con Realidad Aumentada desde una aplicación web, un formato que no creíamos apto para un desarrollo con estas características.
Así comenzamos las pruebas de concepto sobre AR.js. Las primeras impresiones fueron muy buenas. Era muy sencillo dibujar un objeto virtual, ya que solo con un tag HTML y algunas propiedades podíamos plasmar un elemento sobre la imagen de la cámara del celular. Incluso la renderización era performante y fluida.
Todo era mágico hasta que un problema importante salió a la luz, cuando tuvimos la necesidad de ubicar un objeto por fuera del campo de visión directo de la cámara. Esta característica no es soportada por AR.js y era innegociable en los requerimientos funcionales definidos en la etapa de challenge.
Round dos. Las pruebas de concepto realizadas sobre la otra tecnología web (Awe.js) nos mostraban que era un poco menos directa en cuanto a la definición de componentes en comparación con AR.js. Estos debían ser objetos Javascript en los que se configuraban atributos tales como la forma del objeto, la dimensión, el posicionamiento, la rotación y demás aspectos de visualización.
Awe.js agrega el concepto de punto de interés (PoI) que define un anclaje relativo a un marcador, el cual utilizamos como punto inicial de referencia para dibujar los objetos en el espacio de visión que nos provee la cámara de un télefono móvil.
Sin embargo Awe.js cumplía con los requisitos mínimos e indispensables para el desarrollo de la aplicación, de acuerdo a los requerimientos de negocio planteados.
Tanto AR.js como Awe.js basan la experiencia de realidad aumentada en la lectura de un marcador que tiene la forma de un patrón (aunque en Awe.js no es exclusivo). La capacidad de reconocimiento de imagen se limita a un patrón de marcador. Esto restringe, de alguna manera, la experiencia en Realidad Aumentada, ya que requiere la incorporación de una imagen ajena al contexto que sirva como punto de entrada para dibujar la información virtual a incorporar.
PWA: AR enmarcada en una app
Una vez decidido cuál sería el soporte tecnológico, surgía cumplir con la necesidad funcional de dar marco y una base a los aspectos que se desprendían de la experiencia de realidad aumentada, tales como: la contextualización (se visualiza una retícula con la cual el usuario enfoca el marcador de la sala); la posibilidad de interactuar con el objeto virtual (un calendario en el cual, al hacer tap en un evento, nos muestra la información de reserva); y en conjunto darle forma de aplicación móvil. Este último punto (y dado las tecnologías web de base definidas) nos hizo optar por construir una aplicación web progresiva (PWA).
Ante estas necesidades, decidimos construir la aplicación bajo el framework VueJs, el cual brinda:
- Integración limpia con Awe.js
- Soporte para PWA
- Componentes web
Esta decisión se tomó luego de trabajar en una investigación comparativa entre frameworks web Javascript.
Autenticación y autorización: OpenID Connect
Hasta aquí les describí algunos desafíos que afrontamos en cuanto a la aplicación tangible, mediante la cual el fluxer interactúa en el celular. Voy a dedicar este apartado a otro aspecto también interesante de contar, que poco tiene que ver con realidad aumentada.
Esta aplicación, que corre en un dispositivo móvil, además necesita alimentarse de información real, como la disponibilidad de una sala o datos de identificación de las diferentes salas disponibles en la empresa. Por otro lado, los usuarios deben poder autenticarse.
Tanto las cuentas de usuarios como la información de reuniones y reservas de salas en la empresa es gestionada a través de Google Suite. Además la aplicación requiere de consultar datos internos gestionados por una aplicación backend y accesibles a través de una API REST.
La autenticación y autorización se realiza mediante los estándares OAuth2 y su capa de autenticación OpenID Connect (OIDC), los cuales son implementados por servicios de Google, para poder administrar los permisos otorgados por un usuario a una aplicación (en este caso, Casa Techie). Además OpenID Connect provee un token de acceso para poder interactuar con las APIs autorizadas (por ejemplo, la API de Calendar).
Tanto la autenticación del usuario para acceder a la aplicación como la securización de los endpoints expuestos por el backend resolvimos implementarlas aprovechando los servicios anteriormente mencionados, y utilizando plugins y librerías de soporte para los mismos (VueAuth en la aplicación móvil y Python Social Auth como librería en la aplicación backend). Este camino tomado nos permitió desentendernos de la implementación de estos aspectos para maximizar el tiempo de desarrollo en otros aspectos relacionados con los requerimientos funcionales.
En resumen
Luego de un mes de desarrollo, llegamos a una versión prototípica de la visualización del calendario en una de las salas de Flux IT. Tuvimos que resignar algo de la expectativa inicial ( tener una experiencia de realidad aumentada lo más cercana posible a las que ofrecen las librerías nativas móviles) en pos de cumplir un objetivo mucho más importante: lograr esta experiencia de realidad aumentada en la mayor cantidad de dispositivos posibles.
En el medio de la búsqueda nos topamos con dificultades como la gran cantidad de procesamiento requerido para la renderización de texto en 3D, el posicionamiento espacial de los objetos virtuales y la precisión de ubicación de estos, consecuencia de la diversidad de sensores de cada dispositivo móvil. Algunos aspectos de estas dificultades los resolvimos a nivel de la configuración. Otros, en cambio, necesitaron de ciertas intervenciones en alguno de los frameworks utilizados.
Actualmente empezamos la segunda etapa de la aplicación, que tiene como objetivo sumar otros requerimientos funcionales, conectar la aplicación móvil con servicios de backend, y dar acceso a las APIs de Google para la autenticación de los usuarios y la gestión de los calendarios de las salas de reunión.
El objetivo de esta segunda fase es lograr una aplicación 100% productiva y disponibilizada para uso de los fluxers.
