progressive-web-apps
De sitios web a Progressive Web Apps: el nacimiento de una nueva generación de aplicaciones (Parte II)
27 marzo, 2019
Madrid Norte Digital
Kabel participa en el proyecto Madrid Norte Digital
1 abril, 2019

En el anterior post os explicábamos en qué consistían las real-time apps y os contábamos las opciones de integración existentes en Windows Mixed Reality. Igualmente, os dábamos un adelanto de lo que vamos a presentaros en este post, que no es otra cosa que la creación por pasos de una aplicación para Windows Mixed Reality. En concreto, crearemos una aplicación compuesta por varios cubos 3D “sincronizados”, de manera que cuando un usuario mueva uno de ellos el resto de usuarios vea ese movimiento en tiempo real en sus respectivos dispositivos.
 

1. Preparación del entorno para nuestra app de Mixed Reality

Para el desarrollo de esta solución necesitaremos lo siguiente:

  • Windows 10 Pro/Enterprise (versión 1703 o superior)
  • Visual Studio 2017 (versión 7.6 o superior)
  • Unity 2017.4.9 LTS
  • Emulador de HoloLens
  • Suscripción de Azure (podéis obtener una gratuita aquí)
  • Clonar el repositorio de GitHub con todos los recursos necesarios y la versión final de la aplicación

 

2. Creando el backend

2.1. Creación del proyecto

El backend de nuestra aplicación será el encargado de intermediar en las conexiones entre los clientes. Su estructura va a ser la de una Web API 2 que contendrá los componentes necesarios para el servicio de SignalR.

Ahora bien, ¿por qué no usar ASP.NET Core SignalR o Azure SignalR? Para la versión LTS de Unity no tenemos soporte oficial del cliente de .NET Core, por lo que tendremos que utilizar la versión clásica (SignalR 2). En Unity 2018, con .NET Standard 2.0, se da un soporte inicial pero no estable.

El primer paso es abrir Visual Studio 2017 y crear un nuevo proyecto de tipo ASP.NET Web Applications:

visual-studio

A continuación, se nos dará la opción de utilizar varias plantillas ya definidas. En este caso, seleccionaremos la plantilla vacía con la estructura mínima de la Web API:

visual-studio-plantilla

Una vez generado el proyecto, deberemos tener una estructura de archivos inicial como la que aparece en la siguiente imagen:

visual-studio-estructura

2.2. Añadir y configurar SignalR

El siguiente paso será añadir el NuGet Microsoft.AspNet.SignalR al proyecto. Este paquete nos proveerá de todos los componentes necesarios para construir el servicio de SignalR.

signalR

Después de añadir al proyecto el paquete NuGet, tendremos que crear tres scripts de C#:

  • Startup.cs: Crearemos este script en la raíz de la estructura de ficheros del proyecto (pulsando este enlace podréis visualizar el código en GitHub). Durante el inicio de la aplicación se buscará una clase Startup y, dado que SignalR es un middleware OWIN, tendremos que añadir en dicha clase la instrucción de mapear los hubs para que sean accesibles.
  • HoloHub.cs: En la raíz del proyecto, crearemos una carpeta llamada Hubs, y dentro de ella añadiremos el script, Esta clase será la encargada de servir de punto de conexión para enviar/recibir mensajes entre los distintos clientes conectados. Para la aplicación que estamos construyendo, sólo necesitaremos un tipo de mensaje (o función) que llamaremos SendTransform, la cual será invocada cuando un cliente efectúe algún movimiento en el cubo, enviando la nueva transformación al resto para que apliquen los cambios.
  • TransformModel.cs: Añadiremos este script dentro de la carpeta Models. Esta clase será el modelo del propio mensaje que los clientes intercambiarán entre sí. Está compuesta por varias propiedades:
    • Name: Nombre del cubo que se ha movido.
    • Index: Contador incremental para establecer el orden de los movimientos del cubo. Esto permite, entre otras cosas, garantizar que los clientes que reciben los movimientos puedan aplicarlos en orden.
    • PositionX, PositionY, PositionZ: Valores del eje de coordenadas en los que se encuentra el cubo.
    • JsonProperty: Se trata de un atributo que poseen todas las propiedades. Dicho atributo sobrescribe el nombre de la propiedad al serializar la clase en formato JSON para que el mensaje final ocupe lo mínimo posible. Esto es muy importante dada la enorme cantidad de mensajes que se van a intercambiar. Podéis obtener más información al respecto aquí.

Una vez generados estos tres ficheros, la estructura final de proyecto debería ser la siguiente:

estructura-final

2.3. Publicar en Azure

Con estos cambios ya tendríamos lista nuestra Web API. El último paso será hacerla accesible desde otros dispositivos. Para ello, la desplegaremos en un App Service de Azure.

En el explorador de la solución abrimos el menú contextual del proyecto y seleccionamos Publish:

A continuación, se abrirá una ventana que nos permitirá establecer dónde se va a publicar la web. En este caso, crearemos un nuevo App Service. Sin embargo, en caso de disponer de uno ya creado, se podría seleccionar el existente.

El siguiente paso será establecer la definición del nuevo App Service. Cabe destacar que deberemos tener iniciada sesión en Visual Studio (desde la cuenta que tenga acceso a la suscripción de Azure).

1. Éste será el nombre de la aplicación. El texto que pongamos aquí compondrá la dirección de acceso: [App Name].azurewebsites.net.
2. Suscripción en la que se van a generar los recursos.
3. Contenedor en el que se van a agrupar todos los recursos generados. Se puede crear uno nuevo o utilizar otro existente.
4. El plan será la definición del servidor donde se va a alojar la web. Tendremos que determinar la localización y las especificaciones técnicas del mismo.
5. Para esta aplicación no es necesario activar la analítica. Sin embargo, es muy recomendable hacerlo si se quiere tener control total del rendimiento, errores, logs o uso.

Al terminar de crearse los recursos y publicarse la Web App, se abrirá en el navegador, como podemos ver a continuación:

La dirección web de la aplicación es la que más adelante necesitaremos para conectarnos al servicio de SignalR.

Por último, iremos al portal de Azure para terminar de configurar la App Service. Una vez allí, necesitaremos activar los Web Sockets para garantizar una experiencia en tiempo real. De no activar esta característica, SignalR intentaría simular esta tecnología mediante otros modos de transporte.

 
Con esto ya tendríamos el Servicio de SignalR desplegado y funcionando.
 
 
En la siguiente y última entrega de esta serie de posts continuaremos trabajando en este proyecto hasta finalmente desplegarlo.
 
 
 
Podéis comentarnos lo que sea en info@kabel.es.

También podéis seguirnos en Twitter, LinkedIn y Facebook.
 
 


 

Licencia de Creative Commons
Este obra está bajo una licencia de Creative Commons Reconocimiento-NoComercial 4.0 Internacional.

 

Compártelo: Share on FacebookTweet about this on TwitterShare on LinkedInPin on Pinterest

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

NEWSLETTER