Compartir a través de

Mayo de 2016

Volumen 31, número 5

Aplicaciones para la Plataforma universal de Windows: aplicaciones web hospedadas para la empresa

Por Tim Kulp | Mayo de 2016

Los desarrolladores que trabajan en una empresa estructurada ahora saben que no siempre es fácil implementar nuevas tecnologías. Introducir una novedad en la empresa, como un proyecto de aplicación para la Plataforma universal de Windows (UWP) puede ser un reto en caso de no tener equipos experimentados (o seguros) en su capacidad de ofrecer este tipo de aplicación. Muchas empresas han realizado una inversión considerable en sus aplicaciones web de intranet y los equipos que las respaldan. Las aplicaciones web hospedadas (HWA) ofrecen un puente para que las aplicaciones web de intranet de la empresa se unan a la Tienda Windows para empresas con poco esfuerzo.

En este artículo, convertiré una aplicación web de intranet existente en una aplicación para UWP de la Tienda Windows y, luego, mejoraré la aplicación con las funcionalidades nativas de Windows. Como se muestra en la Figura 1, la aplicación web es una aplicación de reconocimiento social denominada "Gotcha" que permite a los empleados de Contoso Corp. reconocer a sus homólogos para actos de bondad o para mostrarles apreciación. Gotcha está destinado a realizar homenajes mutuos, así como a crear un equipo más sólido y feliz. Esta aplicación web es un excelente candidato para la Tienda Windows porque proporciona integración sencilla con los contactos, los recursos compartidos y la cámara.

Aplicación web Gotcha
Figura 1 Aplicación web Gotcha

Puentes y aplicaciones web hospedadas para la empresa

Para los desarrolladores empresariales, los puentes de UWP y las aplicaciones HWA tienen sentido porque los desarrolladores pueden mantener sus herramientas, procesos y sistemas de implementación actuales para sus aplicaciones. Los puentes se usan para permitir a los desarrolladores proporcionar sus aplicaciones de iOS, Android, Win32 o web existentes a UWP y a la Tienda Windows multiplataforma. El objetivo es permitir a los desarrolladores proporcionar su base de código existente a UWP con la capacidad de mejorar la experiencia del usuario con características específicas para Windows, como los logros de Xbox.

Los puentes permiten establecer la conexión del código con UWP fácilmente, pero los desarrolladores empresariales se enfrentan a otros retos que pueden dificultarles la conversión del código. Los desarrolladores de una sociedad anónima pueden enfrentarse a restricciones sobre los editores de código que tienen a su disposición o sobre la ubicación donde se puede implementar el código según la confidencialidad de la información en la aplicación. El valor real de los puentes de UWP para la empresa no es la facilidad de convertir aplicaciones, sino la capacidad de mantener las herramientas de desarrollo de software empresarial existentes, así como las prácticas y la administración de cambios para entregar aplicaciones para UWP a través de la Tienda Windows.

A modo de ejemplo, las aplicaciones HWA (con el alias "Project Westminster") permiten a los desarrolladores insertar aplicaciones web en una aplicación para UWP. Una vez que la aplicación para UWP está integrada para usar el contenido de la aplicación HWA, los desarrolladores pueden usar sus prácticas actuales para mantener la aplicación web, de modo que la experiencia de la aplicación web de la aplicación para UWP se actualizará automáticamente. Mediante el puente de HWA, los desarrolladores se pueden centrar en su aplicación web e incluir características específicas para UWP a través de la detección de características. Trabajar con una intranet existente es un excelente caso de uso para los puentes de UWP, pero los desarrolladores ajenos a la empresa también pueden aprovechar las aplicaciones HWA para incluir sus aplicaciones web en la Tienda Windows. Cualquier sitio web puede convertirse en HWA siempre que pase el proceso de certificación de la Tienda Windows.

Los conceptos básicos de las aplicaciones HWA se cubren ampliamente en la entrada de blog de Kiril Seksenov "Project Westminster in a Nutshell" (bit.ly/1PTxxW4). Recomiendo leer esta entrada para comprender mejor las ideas de las aplicaciones HWA.

Inicio de un proyecto web de aplicación HWA

Para comenzar a convertir la aplicación web Gotcha en una aplicación HWA, creo una nueva aplicación para UWP JavaScript en Visual Studio. Una vez creada la aplicación, abro el manifiesto del paquete y establezco la página de inicio de la aplicación para que sea la URL de la aplicación web, como se muestra en la Figura 2. En este caso, la aplicación web Gotcha se ejecuta fuera de localhost:6107. Con esta página de inicio establecida, la aplicación mostrará la página web en la dirección especificada en lugar del contenido local de la aplicación.

Establecer la página de inicio en el manifiesto del paquete
Figura 2 Establecer la página de inicio en el manifiesto del paquete

Finalmente, establezca los URI de contenido en el manifiesto del paquete. Estos URI indicarán a la aplicación qué páginas pueden acceder a las bibliotecas de Windows Runtime (WinRT) y qué nivel de acceso pueden tener dichos URI. Se dice que definen dónde se detiene la aplicación y se inicia Internet, y pienso que es una gran imagen mental de cómo usar los URI de contenido. En la aplicación web Gotcha existente, existen distinciones claras entre lo que hace la aplicación y lo que puede hacer a través de Internet. A modo de ejemplo, en Gotcha, los usuarios pueden compartir el reconocimiento en las redes sociales, como LinkedIn. El sitio web de LinkedIn no forma parte de la aplicación para UWP Gotcha, sino que es parte de Internet. Solo incluiría aquellos URI que se usen directamente en la aplicación y que necesiten acceder a las API de UWP.

El uso de los URI de contenido permite al desarrollador proteger a los usuarios de la aplicación. Para ello, impide a los URI no registrados el acceso a las bibliotecas de WinRT. Para cada URI, especifique el nivel de acceso a las bibliotecas de WinRT que se necesita:

  • Todo: el código JavaScript que se ejecuta en la aplicación web (en este caso, Gotcha) puede acceder a todas las API de UWP definidas a través de las funcionalidades de la aplicación.
  • Permitir solo para web: el código JavaScript que se ejecuta en la aplicación web puede ejecutar componentes personalizados de WinRT incluidos en el paquete de la aplicación, pero no puede acceder a las API de UWP.
  • Ninguno: el código JavaScript que se ejecuta en la aplicación web no puede acceder a las API de UWP locales (esta es la opción predeterminada).

Al configurar URI de contenido, recuerde que son un componente clave de la seguridad de la aplicación para los usuarios de aplicaciones para UWP. Asegúrese de proporcionar solo los permisos mínimos necesarios a un URI para las funciones necesarias de la aplicación para UWP, como se muestra en la Figura 3. Intente evitar configurar el acceso a WinRT del URI raíz en Todo si no es realmente necesario en la aplicación.

Establecer los URI de contenido con el privilegio mínimo necesario para ejecutar la aplicación
Figura 3 Establecer los URI de contenido con el privilegio mínimo necesario para ejecutar la aplicación

No recomiendo quitar el contenido existente que se incluye con el proceso de creación del proyecto (como las carpetas .css, .js y WindJS). Este contenido existente proporciona a los desarrolladores un marco excelente que se puede usar para agregar contenido local a la aplicación HWA web. Más adelante en este artículo, usaré estas carpetas de contenido local para crear algunas funcionalidades que complementarán la experiencia sin conexión de la aplicación HWA web.

Con el manifiesto del paquete configurado, ejecute la aplicación para UWP. Como se muestra en la Figura 4, la aplicación web aparecerá ahora en la ventana de la aplicación como cualquier otra aplicación para UWP.

Aplicación Gotcha preparada para la Tienda Windows
Figura 4 Aplicación Gotcha preparada para la Tienda Windows

Depuración de una aplicación web hospedada

Las aplicaciones HWA presentan una experiencia de depuración ligeramente diferente a la de una aplicación nativa pura. Con la aplicación para UWP abierta, presione F12. Se mostrará Herramientas de desarrollo F12 para la aplicación para UWP. A través de Herramientas de desarrollo F12, puedo depurar y probar la aplicación web, así como generar sus perfiles, como podría hacerlo en un explorador. Mientras que todas las características de Herramientas de desarrollo F12 son útiles para los desarrolladores de HWA, los componentes que he encontrado más útiles son la depuración fuera de Visual Studio y la creación de perfiles de la actividad de red. Uso estas características para investigar comportamientos de una aplicación específica y comprender los problemas (como el almacenamiento en caché) que causan una experiencia inesperada en la aplicación.

Igual que al usar F12 en el explorador, los desarrolladores también pueden modificar el DOM y probar distintas experiencias de UI según el tamaño de la pantalla o de la ventana. Se puede usar para explorar los cambios de diseño de una aplicación web basados en las necesidades de capacidad de respuesta de la aplicación. A modo de ejemplo, el ajuste de la aplicación para UWP para que se muestre como una barra lateral debería redistribuir la aplicación para ofrecer una gran experiencia. Si el cambio de tamaño no redistribuye la aplicación, Herramientas de desarrollo F12 puede usarse para determinar el motivo y para experimentar con el DOM, a fin de ver qué se necesita para conseguir la redistribución deseada.

Adición de funcionalidad para la aplicación para UWP

Con una aplicación HWA básica preparada, voy a profundizar en las funcionalidades de la aplicación web para habilitar algunas API de UWP y mejorar la experiencia del usuario. Las aplicaciones web de intranet pueden tener algunas limitaciones que no tienen las aplicaciones HWA. Mediante las API de UWP, una aplicación HWA puede tener acceso a muchas de las funcionalidades locales del dispositivo de UWP (como la cámara, la ubicación y otros sensores). Para comenzar, piense en los casos de uso que dirigen la implementación de la aplicación web en una aplicación web hospedada. En la aplicación Gotcha, quiero que los usuarios puedan seleccionar entre sus contactos a quién conceder un premio, en lugar de solo escribir el nombre de la persona y adjuntar una imagen al reconocimiento.

Para empezar, creo un archivo de código GotchaNative.js remoto en la aplicación web (el archivo de script GotchaNative.js estará en el servidor remoto de la aplicación web), que detectará los espacios de nombres de la API nativa y ejecutará el código adecuado para desencadenar nuestros casos de uso nativo. Agregue el código siguiente al archivo de código NativeGotcha.js:

var GotchaNative = (function () {
  if (typeof Windows != 'undefined') {
    // Add find contact here
    // Add capture photo here
  }});

Este código compila el objeto GotchaNative, que contendrá toda la funcionalidad de las API de UWP. La centralización de estas API permite que un archivo único se incluya en páginas que se agregarán a la funcionalidad de la API de UWP. Aíslo este archivo para poder declarar de forma explícita los URI de contenido que incluyen este archivo específico como identificadores URI con acceso a las API de UWP necesarias. De este modo, puedo implementar el concepto de seguridad del privilegio mínimo y conceder permiso solo a los URI que requieren acceso a las API de UWP.

Otra ventaja de aislar este archivo es la preparación para otras plataformas nativas. Lo examinaré más tarde en este artículo, pero, por ahora, considere este archivo el inicio de toda la funcionalidad nativa que se incluirá en la aplicación web Gotcha.

Extensión de la funcionalidad existente

Ahora, con el objeto GotchaNative creado, puedo agregar la funcionalidad específica para conectar la aplicación HWA a las API de UWP. Para el primer caso de uso, la aplicación web Gotcha permite a los usuarios introducir una persona que quieran reconocer. En la UWP, los usuarios tienen la aplicación Contactos, que almacena los contactos. Es mucho más fácil para el usuario seleccionar el contacto que escribir el nombre de la persona. Reemplace el comentario "Add find contact here" en el archivo de código GotchaNative.js por lo siguiente:

this.FindContact = function () {
  var picker = new Windows.ApplicationModel.Contacts.ContactPicker();
  picker.desiredFieldsWithContactFieldType.append(
    Windows.ApplicationModel.Contacts.ContactFieldType.email);
  return picker.pickContactAsync();
}

Este código es una conexión básica para que la API ContactPicker pueda seleccionar un contacto de la lista de contactos. Una lista de las API de UWP que puede ajustarse en las aplicaciones HWA web se puede encontrar en rjs.azureWebsites.net. En este sitio web se enumeran algunas de las API más populares con código listo para copiar y pegar para ayudar a compilar un proyecto de aplicación HWA web.

La funcionalidad para agregar una persona se puede encontrar en el modelo de vista de persona del sitio web de Gotcha. Agregue el código de la Figura 5 al modelo de vista de persona.

Figura 5 Código para agregar al modelo de vista de persona

if (Windows != undefined) {
  var nativeGotcha = new NativeGotcha();
  nativeGotcha.FindContact().done(function (contact) {
    if (contact !== null) {
      $("#txtWho").val(contact.displayName);
    } else {
      // Write out no contact selected
    }
  });
}
else {
  $('#add-person').on('shown.bs.modal', function () {
    $("#txtWho").focus();
}

El código de la Figura 5 usa el método FindContact si el objeto de Windows está definido debido a un script que se ejecuta como una aplicación HWA. Si el objeto de Windows no está definido, la aplicación web seguirá usando la ventana modal de arranque existente para recopilar información sobre la persona que se debe reconocer. Este código permite que la aplicación web use un enfoque para especificar una persona para el reconocimiento, mientras que la aplicación para UWP puede aprovechar una experiencia diferente más adaptada para el usuario.

Adición de nueva funcionalidad

A veces, habilitar las API de UWP permitirá una nueva funcionalidad que no existiría normalmente en la aplicación web. En la aplicación HWA Gotcha, quiero permitir a los usuarios tomar fotos y enviarlas para el reconocimiento a otros usuarios de Gotcha. Esta funcionalidad sería nueva para la aplicación y no existiría en la aplicación web. Al compilar una aplicación HWA, considere las oportunidades que las API de UWP abren para la aplicación.

Para comenzar a implementar esta nueva funcionalidad, reemplace primero el comentario "Add capture photo" por el siguiente código en el archivo de código GotchaNative.js:

this.CapturePicture = function () {
  var captureUI = new Windows.Media.Capture.CameraCaptureUI();
  captureUI.photoSettings.format =
    Windows.Media.Capture.CameraCaptureUIPhotoFormat.png;
  return captureUI.captureFileAsync(
    Windows.Media.Capture.CameraCaptureUIMode.photo);
}

En este código, abro la UI de captura y permito al usuario tomar una foto y devolverla a continuación al autor de la llamada. Esta nueva característica debe habilitarse en la aplicación web si el objeto de Windows está definido. Usando la detección de características como hice en el modelo de vista de persona, agrego el código de la Figura 6 al modelo de vista principal, que es donde se encuentra el código para agregar el reconocimiento.

Figura 6 Código de detección de características para agregar al modelo de vista principal

$('#give-modal').on('shown.bs.modal', function () {
  if (typeof Windows != 'undefined') {
    var gotchaNative = new NativeGotcha();
    $("#btnCamera").click(function () {
      gotchaNative.CapturePicture().then(function (capturedItem) {
        // Do something with capturedItem;
      });
    }).show();
  }
  else {
    $("#btnCamera").hide();
  }
})

En el código de la Figura 6, oculto el método btnCamera si el objeto de Windows no está definido. Si el objeto de Windows no está definido, configuro el evento de clic para desencadenar la función CapturePicture. Por cuestión de brevedad, he dejado un comentario sobre qué hacer con la imagen. Al habilitar la cámara, debo tener en cuenta que esta aplicación HWA sigue siendo una aplicación para UWP y necesita tener la funcionalidad de cámara web habilitada para la aplicación, lo que se puede realizar a través del manifiesto del paquete.

Las aplicaciones web empresariales pueden convertirse en aplicaciones HWA y aprovechar las API de UWP de la Tienda Windows. Con las aplicaciones web existentes se pueden compilar fácilmente aplicaciones para UWP en la Tienda Windows, pero se requiere conexión a Internet para las aplicaciones HWA. A continuación, mostraré cómo puede asegurarse de que una aplicación funcione sin acceso a Internet.

Acceso sin conexión

La aplicación para UWP puede tener archivos locales para proporcionar una experiencia sin conexión o local. El uso de contenido local permite desconectar algunas de las llamadas API de UWP de la aplicación web hospedada. Del mismo modo que la detección de características realizada, la vinculación a contenido local se puede realizar activando vínculos. Para Gotcha, agregaré una característica de asignación que usará los controles de asignación local.

En la aplicación HWA, puedo usar la misma detección de características que se usaba anteriormente en el modelo de vista principal. Usar el esquema URI correcto permitirá a la aplicación HWA cambiar entre el contenido web y el contenido local. En la pantalla de inicio agrego el vínculo siguiente:

<a href="ms-appx:///default.html" id="lnkMap">
  <span class="glyphicon glyphicon-map-marker">&nbsp;</span> Show Map
</a>

El vínculo se conecta al esquema ms-appx:///, que permite a la aplicación conectarse al contenido local dentro del paquete de aplicación. Al trabajar con el esquema ms-appx, la aplicación puede conectarse a las API de UWP necesarias. El proceso es muy similar a usar los URI de contenido para declarar el nivel de acceso que tiene una página para acceder a las API. Usar ms-appx es igual que marcar un URI como Todo. En este caso, la página default.html tiene acceso a las API de UWP. Cuando aparece el vínculo en la aplicación HWA, los usuarios pueden hacer clic en él para trabajar en el paquete de la aplicación.

Para los desarrolladores empresariales, esta característica permite el aislamiento de casos de uso específicos de UWP no conectados necesariamente a la aplicación web. La conexión al paquete de contenido también puede ayudarle a evitar proporcionar acceso a las API de UWP para la aplicación web y a mantener el acceso dentro del paquete.

¿Qué sucede en el caso de más de una tienda?

Según la empresa, puede existir un entorno Bring Your Own Device. Esto significa que una empresa ya podría estar orientando dispositivos iOS o Android con las aplicaciones existentes. Las aplicaciones de Android e iOS tienen conceptos similares a los de las aplicaciones HWA, que se conocen como control WebView. WebView permite a los desarrolladores proporcionar una ventana de dentro de su aplicación a una aplicación web existente y, después, interactuar con dicha aplicación web como si formase parte de la aplicación nativa (¿le suena?). Las aplicaciones HWA se pueden compilar para funcionar bien con otras, con la adaptación de la funcionalidad de una aplicación web existente a la plataforma que la ofrece. A continuación, actualizaré GotchaNative.js para que admita Android y mostraré cómo el código HWA existiría paralelamente con JavaScript orientado a otras plataformas.

Anteriormente, configuré GotchaNative.js, cuya función es mantener todo el código nativo de la aplicación. Las clases ViewModel procesarán la salida de estos métodos nativos. El uso de las API en cualquier plataforma es similar al de las aplicaciones HWA: En primer lugar, la aplicación debe determinar si las API nativas están disponibles y, luego, debe llamar a la API apropiada. Para comenzar a actualizar GotchaNative.js, agregaré una propiedad que me indique la plataforma nativa (si existe) que se reconoce. Para los siguientes ejemplos, supongo que la aplicación de Android usa un control WebView que declara "Android" como el espacio de nombres de script local:

this.Platform = function () {
  if (Windows != 'undefined')
    return "Windows";
  else if (Android != 'undefined')
    return "Android";
  else
    return "Web";
}

Esta función permite que mi código determine la plataforma con la que va a funcionar, de modo que pueda adaptar el código y la respuesta a la plataforma. A partir de aquí, cada método de GotchaNative.js puede comprobar la plataforma para saber cómo proceder, como se muestra en la Figura 7.

Figura 7 Comprobación de métodos GotchaNative.js para la plataforma

this.CapturePicture = function () {
  switch (this.Platform()) {
    case "Windows":
      var captureUI = new Windows.Media.Capture.CameraCaptureUI();
      captureUI.photoSettings.format =
        Windows.Media.Capture.CameraCaptureUIPhotoFormat.png;
      return captureUI.captureFileAsync(
        Windows.Media.Capture.CameraCaptureUIMode.photo);
      break;
    case "Android":
      Android.CaptureFile(); // Calls Android code in Native app
      break;
    default:
      return null;
      break;
}

Ahora, en los patrones ViewModel, el código se actualizaría para usar la detección de plataforma y averiguar qué hacer con la salida de los métodos GotchaNative. Esta es una actualización del evento de botón de cámara desde la clase HomeViewModel:

$("#btnCamera").click(function () {
  switch (gotchaNative.Platform()) {
    case "Windows":
      gotchaNative.CapturePicture().then(function (capturedItem) {
        // Do something with capturedItem;
      });
      break;
    case "Android":
      // Handle Android output
      break;
  }
}).show();

Ahora, dado que la aplicación admite más plataformas, tengo una sola ubicación en mi código para aumentar las funcionalidades de todas las plataformas. Si un nuevo sistema operativo se lanzara mañana, el equipo de desarrollo podría adaptar el código a la nueva plataforma.

Resumen

Los desarrolladores empresariales se enfrentan a numerosos retos en su trabajo. Las herramientas y los procesos estandarizados se pueden ver como un obstáculo para la implementación de nuevas tecnologías, como las aplicaciones para UWP. Mediante los puentes de UWP, los desarrolladores empresariales pueden incluir sus aplicaciones web de intranet o externas existentes en la Tienda Windows (ya sea pública o en la Tienda Windows para empresas). Los puentes para aplicaciones HWA pueden convertir una aplicación web en una aplicación para UWP multiplataforma, aprovechando las API de UWP para mejorar la experiencia del usuario.

En este artículo, he explorado cómo se toma una aplicación web existente y se convierte en una aplicación HWA, al mismo tiempo que se agregan características específicas de la aplicación para UWP, como el acceso a la cámara y a los contactos. He usado el esquema ms-appx para mostrar cómo pasar de la aplicación web hospedada al contenido local en el paquete de la aplicación. Finalmente, he mostrado, con algún planeamiento, como se pueden compilar aplicaciones HWA teniendo en cuenta muchas plataformas diferentes, lo que permite a la empresa seguir el ritmo del mundo de los dispositivos móviles, que se expande constantemente. Mediante estas técnicas, las aplicaciones HWA pueden aprovechar las inversiones realizadas en aplicaciones web y ayudar así a las empresas a unirse al ecosistema de la Tienda Windows.

Tim Kulpes un arquitecto técnico sénior que vive en Baltimore, Maryland. Es desarrollador móvil, web y de UWP, así como autor, pintor, padre y "aspirante a científico loco". Puede seguirle en Twitter, en @seccode, o a través de LinkedIn en linkedin.com/in/timkulp.

Gracias al siguiente experto técnico de Microsoft por revisar este artículo: John-David Dalton y Kiril Seksenov