Compartir a través de


Nota del editor

Detección ligera de dispositivos del lado cliente

Dino Esposito

Dino EspositoHay dos opciones básicas para crear sitios web descriptivos del dispositivo: crear un sitio para móvil independiente (m-sitio) o modificar un sitio para que pueda adaptar contenido y comportamiento de forma inteligente a la orientación y el tamaño de pantalla actuales. Ninguna de esas dos estrategias es ideal en todos los casos. Por lo tanto, el enfoque más acertado es el clásico, el enfoque en el que "depende".

El enfoque del sitio m tiene dos inconvenientes principales. En primer lugar, todos los dispositivos son diferentes en cuanto a tamaño de pantalla y otras capacidades físicas (desde smartphones, tabletas y tabletas miniaturizadas a teléfonos móviles, tabléfonos, dispositivos portátiles y otros más antiguos). Al final, ¿cuál es la verdadera definición de "móvil"?

Hace años, tener un sitio m tenía más sentido porque había una separación clara entre los equipos de escritorio y todo lo demás. Hoy en día, el espacio de "todo lo demás" tiene tantas opciones, que un sitio móvil genérico unificado no tiene cabida. La segunda desventaja de un sitio m es que requiere que los usuarios naveguen a una dirección URL distinta, normalmente del tipo m.suservidor.com. Esta ya no es una solución conveniente y solo se acepta como una corrección temporal.

La otra opción, una interfaz de usuario adaptativa, tampoco está libre de problemas. La pregunta clave es ¿cómo conseguir que un sitio web sea adaptativo? Un sitio adaptativo normalmente se asocia a la idea de que se creó con diseño web adaptativo (RWD). RWD es un enfoque de desarrollo que usa la implementación de explorador de las consultas de medios de CSS para detectar la orientación y el tamaño de pantalla, y permite definir puntos de interrupción (principalmente un ancho de píxel) para aplicar automáticamente un CSS distinto.

El efecto global es atractivo. A medida que se cambia el tamaño de la ventana del explorador y se traspasa uno de esos puntos de interrupción visual, la apariencia del sitio cambia para usar mejor el espacio disponible. El contenido se adapta sin ningún coste adicional en cualquier explorador móvil de pantalla completa que se use para visitar el sitio. RWD es independiente del dispositivo y escalable a cualquier número y tipo de dispositivos disponibles ahora y en el futuro.

Como indiqué en mi columna de diciembre de 2014, "Control eficaz de la imagen en sitios web adaptativos" (msdn.microsoft.com/magazine/dn857356), la independencia del dispositivo es a la vez un punto fuerte y uno débil de RWD. Si los clientes están satisfechos con los resultados que se pueden conseguir con RWD (principalmente, rendimiento y facilidad de uso), todo estará listo. RWD es su creación y ha terminado.

Normalmente, RWD funciona bien con sitios que presentan contenido sin necesidad de demasiada interacción o flujos de trabajo de tipo asistente. Cuantos más formularios tenga, mayor necesidad de que los usuarios seleccionen y escriban tendrá. En ese caso, un enfoque de uno para todo, como RWD, es menos apropiado. ¿Entonces, dónde nos situamos?

La industria exige una forma eficaz para servir el contenido adecuado a cualquier dispositivo sin tener que recordar una dirección URL diferente. RWD es un enfoque generalizado para conseguir este objetivo. Sin embargo, RWD es independiente del dispositivo. A los desarrolladores no les entusiasma realizar la detección de dispositivos. Hay malos recuerdos de cuando para conseguir que un sitio web tuviera la misma apariencia en varios exploradores, era necesario analizar la cadena de agente de usuario y pasarla a innumerables partes del código.

Detección de dispositivos y detección de características

Mientras espera a que todos los exploradores finalmente expongan la plataforma y las capacidades a través de un modelo de objetos estándar, actualmente el análisis de la cadena de agente de usuario es la única forma de averiguar qué explorador está solicitando páginas realmente desde un sitio web. El análisis de un agente de usuario es un desafío, pero hay algunas herramientas que pueden reducir la dificultad hasta cierto punto.

Una de estas herramientas es el script que se obtiene de detectmobilebrowsers.com. Este script usa expresiones regulares para comprobar una lista de palabras clave móviles conocidas y responder a la pregunta: "¿Es móvil?" En este contexto, móvil simplemente significa que no es un explorador de escritorio. Otra herramienta es Modernizr, que tiene una extensa lista de complementos para la detección de eventos de toque y el análisis del agente de usuario para intentar detectar una tableta.

Sin embargo, Modernizr no es la herramienta adecuada para detectar cosas que no sean características que JavaScript pueda detectar. Y tanto si el explorador es una tableta como un smartphone, no es algo que se pueda detectar con JavaScript. Solo puede solicitar al explorador su identidad a través de JavaScript, pero la mayoría de los exploradores (especialmente los exploradores móviles) devuelven información inexacta por una serie de motivos, como que el código heredado en función de los agentes de usuario lo reconozca de forma incorrecta.

Modernizr anuncia la marca de detección de características frente a la detección de dispositivos. Es como una comparación entre manzanas y naranjas. Son cosas diferentes que sirven para fines distintos. Si debe determinar el factor de forma del dispositivo solicitante, la detección de características no es la forma adecuada. Algunos desarrolladores detectan tabletas y smartphones a través de JavaScript mediante la comprobación de eventos táctiles que realiza Modernizr. Esto es cada vez menos confiable, teniendo en cuenta el creciente número de dispositivos y equipos de escritorio con pantalla táctil que desea tratar como equipos de escritorio.

Necesita ayuda experta para analizar agentes de usuario y devolver información que se pueda consumir con facilidad. Ayuda experta quiere decir algún marco que se actualiza continuamente para agregar nuevos dispositivos que aparezcan en el mercado. También implica la lógica de análisis sofisticada que controla correctamente los falsos positivos y usa análisis estadísticos para evitar la información incorrecta que pasan algunos exploradores móviles. Francamente, es mucho trabajo. No obstante, hay algunas compañías que lo hacen por usted. Estas herramientas se conocen como repositorios de descripciones de dispositivos (DDR).

El extremo WURFL.JS

Una forma ligera de detección de dispositivos de JavaScript puede mejorar la experiencia de usuario en aplicaciones web del lado cliente de uso intensivo, por ejemplo, una aplicación de página única (SPA). WURFL (wurfl.sourceforge.net) es un conocido DDR que lleva unos años en el mercado como solución del lado servidor. Escribí sobre el uso de WURFL en una aplicación ASP.NET MVC en mi columna de agosto de 2013, "Creación de vistas móviles optimizadas en ASP.NET MVC 4, parte 2: uso de WURFL” (msdn.microsoft.com/magazine/dn342866.aspx).

WURFL del lado servidor depende de un pago de licencia, lo use de forma local o acceda a DDR en la nube. El equipo de WURFL ha publicado recientemente un extremo de HTTP gratuito (WURFL.JS) que se puede invocar desde el lado cliente a través de JavaScript. Para habilitar la detección de dispositivos de JavaScript a través del extremo WURFL.JS, lo único que necesita hacer es agregar la siguiente línea en HTML (en ASP.NET, puede incluso colocarlo en la página maestra o en el archivo de diseño):

<script type="text/javascript" src="http://wurfl.io/wurfl.js"></script>

El recurso al que se hace referencia, wurfl.js, no es claramente un archivo de JavaScript sin formato que pueda descargar y hospedar de forma local, o cargarlo en su sitio de la nube. Es un extremo de HTTP de tipo JavaScript que inserta un derecho de objeto de JavaScript en el modelo de objetos del documento (DOM). El efecto final es que, cuando el explorador ha realizado una llamada al extremo, el DOM contiene lo siguiente:

var WURFL = {
  "complete_device_name":"iPhone 5",
  "is_mobile":false,
  "form_factor":"Smartphone"};

El explorador envía su cadena de agente de usuario al realizar la solicitud. Con el respaldo del marco de trabajo WURFL del lado servidor, el extremo analiza la cadena y determina la información clave sobre el dispositivo solicitante. Dicha información adopta un formato de tres propiedades en un objeto global denominado WURFL (consulte la figura 1). Es interesante destacar que WURFL.JS también puede detectar de forma confiable si se está viendo la página web desde dentro del componente de vista web de una aplicación móvil nativa. Esto sucede cuando la propiedad form_factor devuelve la aplicación.

Figura 1 Información del dispositivo que WURFL.JS inserta en la página del DOM.

Propiedad Descripción
complete_device_name Contiene un nombre descriptivo para el dispositivo detectado que normalmente incluye el proveedor y el nombre de dispositivo (por ejemplo, iPhone 5).
form_factor Contiene una entre unas cuantas cadenas predefinidas, como: Desktop, App, Tablet, Smartphone, Feature Phone, Smart-TV, Robot, Other non-Mobile, Other Mobile.
is_mobile Valor booleano que indica si el dispositivo no es un equipo de escritorio.

WURFL.JS usa una gran cantidad de almacenamiento en caché para garantizar una respuesta rápida. En la fase de desarrollo, puede desactivar la memoria caché si agrega debug=true en la dirección URL. Cuando se desencadena el evento ready de DOM, puede utilizar sin ningún riesgo el objeto WURFL para habilitar o deshabilitar características del lado cliente, o solicitar datos opcionales al servidor.

WURFL.JS agrega potencia a RWD

Supongamos que tiene una página con vídeo y no desea que se reproduzca en smartphones por motivos de rendimiento. Con RWD sin formato, no se pueden realizar ajustes de ese tipo. Si oculta el reproductor de vídeo debajo de un punto de interrupción determinado, no podrá reproducir nada cuando se cambie el tamaño del explorador de escritorio a una ventana pequeña. El uso de WURFL.JS con RWD soluciona el problema, como se muestra aquí:

<script type="text/javascript">
  $(document).ready(function () {
    if (WURFL.form_factor == "Smartphone") {
      $("#video_player").hide();
    }
  });
</script>

En primer lugar, cargue la página y el estilo según el diseño de RWD. A continuación, use WURFL para comprobar el factor de forma y ocultar el reproductor de vídeo. Cuando se cambia el tamaño de un explorador de escritorio al tamaño de un smartphone, los usuarios todavía podrán reproducir vídeos, pero no cuando se trate de un dispositivo smartphone real. Una formulación aún mejor del código anterior se muestra aquí:

<script type="text/javascript">
  $(document).ready(function () {
    if (WURFL.form_factor != "Desktop" &&
        WURFL.form_factor != "Tablet") {
      $("#video_player").hide();
    }
  });
</script>

En este caso, el reproductor de vídeo está oculto en todos los casos, excepto cuando el dispositivo es un escritorio o una tableta. Hay otro escenario más interesante de WURFL.JS. Suponga que tiene un sitio RWD en producción, donde todas las vistas se generan en el servidor, por ejemplo, dentro de una aplicación ASP.NET MVC.

En algún momento, obtendrá comentarios sobre que los usuarios de smartphones no tienen una experiencia adecuada. ¿Debería considerar crear un sitio m totalmente nuevo para ellos? Si puede usar los servicios del lado servidor de WURFL, puede implementar fácilmente un modificador de vista dentro del mismo sitio, como se muestra en mi columna de agosto de 2013.

Este enfoque guarda la mayor parte del trabajo que ha realizado. De otra manera, no hay muchas más posibilidades, salvo crear un sitio independiente e implementar algún mecanismo de redirección, como se muestra en mi columna de enero de 2015, "Movilización de un sitio web existente" (msdn.microsoft.com/magazine/dn890366). Para mostrar el sitio m y el normal en la misma dirección URL, necesitará que se realice una buena detección de dispositivos en el lado servidor.

Un efecto secundario positivo del uso de WURFL.JS es que puede recopilar información del dispositivo desde el objeto WURFL y transferirla a Google Analytics. Eso le proporciona una medida inmediata de la forma en que los usuarios visitan su sitio y los dispositivos que más usan. Si ha actualizado al nuevo archivo analytics.js, necesita lo siguiente:

<script type="text/javascript">
  /* Universal tracking code of Google Analytics:
    see http://goo.gl/HakYmP
  */
  ga('create', 'UA-XXXX-Y', 'auto');
  ga('send', 'pageview', {'dimension1': WURFL.form_factor});
</script>

Si usa el script clásico de Google Analytics (ga.js), a continuación se muestra el leve cambio que deberá implementar:

_gaq.push(['_setCustomVar', 1, 'form_factor', WURFL.form_factor, 1]);

Google Analytics tiene una serie de características integradas para realizar un seguimiento del tráfico de los dispositivos móviles y tabletas. El tráfico móvil también incorpora el tráfico de tabletas y no se puede separar inmediatamente smartphone de tableta, por ejemplo. WURFL.JS agrega información útil que falta al principio de Google Analytics, de forma que pueda crear informes personalizados que solo se centren en los números en lugar de la previsión de datos. Sin embargo, WURFL.JS solo es un proveedor de datos. Funciona con Google Analytics, pero también se puede utilizar con otras herramientas de análisis.

Resumen

En muchos casos, un sitio RWD es más difícil (más caro) de implementar que un sitio web de ASP.NET Web Forms sin formato. No escuche a las sirenas de RWD. RWD es una excelente solución para escritorios y dispositivos de gama altas, pero podría no ser adecuado cuando la implementación eficaz de funciones en dispositivos pequeños es fundamental para el negocio. RWD presume de ser independiente del dispositivo. Esto significa que los sitios web RWD ofrecen el mismo contenido en una ventana del explorador de escritorio cuyo tamaño ha cambiado a 480 x 360 y en un teléfono de gama baja y pantalla completa.

El hardware y la conectividad pueden ser significativamente distintos en los dos casos. Objetivamente, el rendimiento es el punto débil del RWD. Al mismo tiempo, es posible que no sea igual de problemático en todos los sitios. Los problemas de rendimiento afectan principalmente a los dispositivos de gama baja. Si esos dispositivos no son los visitantes habituales del sitio, puede decidirse por RWD, que le servirá.

Sin embargo, la cantidad de datos que se proporcionan y las expectativas de los usuarios pueden crecer en un futuro próximo. Esto implicaría que más dispositivos serían inadecuados e, idealmente, se requeriría una vista ad hoc. En este artículo, presento una solución ligera del lado cliente que pasa casi desapercibida para detectar el dispositivo subyacente, WURFL.JS.

WURFL.JS es un extremo que inserta la información del dispositivo en el DOM, en concreto el factor de forma. En otras palabras, indica si el dispositivo es de escritorio, una tableta, un smartphone, un teléfono antiguo, una consola Xbox o una aplicación nativa. En función de ello, puede organizar pequeños cambios en las páginas e incluso proporcionar información de factor de forma a las herramientas de análisis.

Conocer cómo funciona su sitio según el factor de forma es un indicador eficaz de su rendimiento y las áreas que debe mejorar. Si desea obtener más detalles sobre cómo usar WURFL.JS con Google Analytics, consulte bit.ly/1u0lpGB.


Dino Esposito es el coautor de “Microsoft .NET: Architecting Applications for the Enterprise” (Microsoft Press, 2014) y “Programming ASP.NET MVC 5” (Microsoft Press, 2014). Esposito, evangelizador técnico para las plataformas Android y Microsoft .NET Framework en JetBrains y orador frecuente en eventos del sector en todo el mundo, comparte su visión de software en software2cents.wordpress.com y en Twitter en twitter.com/despos.

Gracias al siguiente experto técnico por su ayuda en la revisión de este artículo: Jon Arne Saeteras