Article
03/03/2015

Cet article a fait l'objet d'une traduction automatique.

Le mot du rédacteur en chef

La détection d'appareils légère côté client

Dino Esposito Il y a deux options de base de création de sites Web respectueux de l'appareil — créer un site distinct mobile (m-site) ou de retravailler un site afin de s'adapter intelligemment contenu et comportement à la taille de l'écran actuel et l'orientation. Aucune de ces deux stratégies est idéale dans tous les cas. Par conséquent, l'approche plus perspicace est le classique, « Ça dépend », approche.

L'approche de m-site présente deux inconvénients majeurs. Tout d'abord, tous les appareils sont différents en termes de taille de l'écran et d'autres capacités physiques (à partir de smartphones, tablettes et mini-comprimés pour les téléphones plus anciens, phablets, appareils portables et ainsi de suite). En fin de compte, comment réellement définir « mobile » ?

Ans, ayant un m-site fait plus de sens, parce qu'il y avait une nette séparation entre les ordinateurs de bureau et tout le reste. Aujourd'hui, l'espace de « tout le reste » a tellement d'options qu'un site mobile unifié générique est hors de question. Le deuxième inconvénient d'un m-site est qu'il oblige les utilisateurs à naviguer vers une URL distincte, généralement quelques m.yourserver.com. Ce n'est plus une solution souhaitable et uniquement pris en charge comme une solution temporaire.

L'autre option — une interface utilisateur réactive — n'est pas sans ses problèmes, soit. La principale question est comment feriez-vous pour rendre un site Web adapté ? Un site sensible est souvent associé à l'idée qu'il a été construit avec responsive Web design (RWD). RWD est une approche de développement qui utilise l'implémentation de navigateur de CSS Media Queries pour détecter l'orientation et la taille de l'écran et vous permet de définir des points d'arrêt (essentiellement une largeur en pixels) pour appliquer automatiquement un CSS différent.

L'effet net est séduisante. Lorsque vous redimensionnez la fenêtre du navigateur et intrusion l'un de ces points d'arrêt visuelles, l'apparence du site change pour faire un meilleur usage des biens immobiliers disponibles. Le contenu s'adapte sans surcoût à n'importe quel navigateur mobile utilisé pour visiter le site en plein écran. RWD est indépendant du périphérique et évolutive à n'importe quel nombre et les types de périphériques disponibles maintenant et à l'avenir.

Comme indiqué dans mon article de décembre 2014, "efficaces Image manipulation en Responsive Sites Web" (msdn.microsoft.com/magazine/dn857356), être indépendant du périphérique est une force et faiblesse de RWD. Si vos clients sont satisfaits des résultats que vous pouvez obtenir par le biais de RWD (pour la plupart, performance et facilité d'utilisation), puis vous êtes tous ensemble. RWD est votre bébé et vous avez terminé.

RWD fonctionne généralement bien avec les sites présentant le contenu sans exiger beaucoup interaction ou les workflows de type assistant. Les formes plus vous avez, plus vous avez besoin aux utilisateurs de sélectionner et de type. Dans ce cas, l'approche universelle comme RWD est moins appropriée. Alors où allons-nous, alors ?

L'industrie exige un moyen efficace pour servir un contenu approprié à n'importe quel appareil sans en comprendre une autre URL. RWD est une approche populaire pour atteindre cette fin. Cependant, RWD est unapologetically appareil-agnostique. Les développeurs n'aiment pas faire la détection des périphériques. Il y a mauvais souvenirs de quand faire un site Web se ressemblent sur plusieurs navigateurs requis l'analyse de la chaîne d'agent utilisateur et amenant à d'innombrables branches de code.

Détection de périphérique au cours de la détection

Pendant que vous attendez pour le temps où tous les navigateurs exposent éventuellement plate-forme et fonctionnalités via un modèle objet standard, l'analyse de la chaîne d'agent utilisateur est actuellement le seul moyen de savoir quel navigateur est réellement demandant des pages d'un site Web. L'analyse d'un agent utilisateur est un défi, mais il y a quelques outils qui peuvent atténuer la douleur dans une certaine mesure.

Un de ces outils est le script que vous obtenez de detectmobilebrowsers.com. Ce script utilise les expressions régulières pour vérifier une liste de mots-clés mobiles connus et de répondre à la question : « Est-ce mobile? » Dans ce contexte, le mobile signifie simplement que ce n'est pas un navigateur de bureau. Un autre outil est Modernizr, qui a une longue liste de plug-ins pour agent utilisateur l'analyse et la détection des événements tactiles tenter de détecter une tablette.

Cependant, Modernizr, n'est pas le bon outil pour détecter les autre chose que des fonctionnalités JavaScript détectables. Et si le navigateur est une tablette ou un smartphone n'est pas quelque chose, vous pouvez détecter avec JavaScript. Vous pouvez seulement demander le navigateur sur son identité par le biais de JavaScript, mais la plupart des navigateurs (en particulier les navigateurs mobiles) retournent des informations inexactes pour un certain nombre de raisons, y compris incorrectement reconnu par le code hérité issu des agents utilisateurs.

Modernizr annonce le drapeau de détection par rapport à une détection des périphériques. C'est une comparaison de pommes-de-oranges. Ils ont des choses différentes servant à des fins différentes. Si vous devez déterminer le facteur de forme de l'appareil demandeur, détection de fonctionnalité n'est pas la manière. Certains développeurs détecter tablettes et smartphones via JavaScript en demandant Modernizr à vérifier pour toucher des événements. C'est de plus en plus incertain, compte tenu du nombre croissant de dispositifs que vous voulez traiter comme des ordinateurs de bureau et les ordinateurs de bureau tactiles.

Vous avez besoin d'aide d'un expert analyse les agents utilisateurs et retournant les informations facilement consommables. Aide expert : un cadre qui est continuellement mis à jour pour ajouter de nouveaux périphériques comme ils ont frappé le marché. Elle implique également la logique d'analyse sophistiqué qui bien gère les faux positif et utilise l'analyse statistique pour contourner les informations erronées transmises par certains navigateurs mobiles. Franchement, c'est beaucoup de travail. Il y a certaines entreprises le fait pour vous, cependant. Ces outils sont appelés Device Description référentiels (DDR).

Le WURFL.Point de terminaison JS

Une forme légère de détection des périphériques JavaScript peut améliorer l'UX dans les applications Web de client-côté-intensive, telle qu'une application de page unique (SPA). WURFL (wurfl.sourceforge.net) est un populaire DDR qui existe depuis quelques années comme une solution côté serveur. J'ai écrit sur l'utilisation de WURFL dans une application MVC de ASP.NET dans mon article d'août 2013, "Creating Mobile optimisé vues dans ASP.NET MVC 4, partie 2 : À l'aide de WURFL » (msdn.microsoft.com/magazine/dn342866.aspx).

WURFL côté serveur est assujettie à une redevance de licence si vous utiliser local ou accédez à la DDR dans le nuage. L'équipe WURFL a publié récemment un point de terminaison HTTP gratuit (WURFL.JS) que vous pouvez appeler du côté client par le biais de JavaScript. Pour activer la détection de périphérique JavaScript via le WURFL.Point de terminaison JS, tout ce que vous devez faire est ajouter la ligne suivante au format HTML (en ASP.NET, vous pouvez même le placer dans le fichier principal de la page ou de mise en page) :

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

La référence resource—wurfl.js—is pas clairement un fichier JavaScript simple vous pouvez le télécharger et l'hôte local ou télécharger dans votre site de nuage. C'est un point de terminaison HTTP de type JavaScript qui injecte un droit objet de JavaScript dans le modèle DOM (Document Object). L'effet net est une fois que le navigateur a lancé un appel au point de terminaison, votre DOM contient les éléments suivants :

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

Le navigateur envoie sa chaîne d'agent utilisateur tout en faisant la demande. Soutenue par l'infrastructure de serveur-côté WURFL, le point de terminaison analyse la chaîne et détermine les informations clées sur le périphérique demandeur. Cette information est ensuite mise en forme dans trois propriétés dans un objet global nommé WURFL (voir Figure 1). Il est intéressant de remarquer WURFL.JS peut également détecter si votre page Web est perçue dans le composant WebView d'un natif de l'application mobile de. Cela se produit lorsque la propriété form_factor retourne App.

Figure 1 dispositif Information WURFL.JS injecte dans la Page de DOM

Propriété	Description
complete_device_name	Contient un nom descriptif pour le périphérique détecté qui inclut habituellement le vendeur et le nom de périphérique (par exemple, l'iPhone 5).
form_factor	Contient l'une des quelques chaînes prédéfinies telles que : Ordinateur de bureau, App, tablette, Smartphone, fonction téléphone, Smart-TV, Robot, autre Mobile non Mobile, autres.
is_mobile	Valeur booléenne, indique si le périphérique n'est pas un ordinateur de bureau.

WURFL.JS utilise beaucoup de mise en cache pour assurer une réponse rapide. Dans la phase de développement, vous pouvez désactiver le cache en ajoutant debug = true à l'URL. Lorsque l'événement ready DOM est déclenché, vous pouvez utiliser en toute sécurité l'objet WURFL pour activer ou désactiver les fonctionnalités côté client ou demande des données facultatives pour le serveur.

WURFL.JS ajoute puissance à propulsion arrière

Supposons que vous avez une page avec la vidéo et que vous ne voulez pas qu'elle puisse jouer sur les smartphones pour des raisons de performances. Avec plain RWD, vous ne pouvez apporter des ajustements comme ça. Si vous masquez le lecteur vidéo ci-dessous un point d'arrêt donné, vous ne serez pas en mesure de jouer quoi que ce soit lors du redimensionnement du navigateur de bureau vers une fenêtre minuscule. WURFL.JS utilisé avec RWD résout le problème, comme illustré ici :

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

Tout d'abord, chargez la page, et le style ça selon le schéma RWD. Ensuite, utilisez WURFL vérifier le facteur de forme et de cacher le lecteur vidéo. Lorsqu'un navigateur de bureau est redimensionné à la taille d'un smartphone, les utilisateurs seront toujours en mesure de lire des vidéos, mais pas quand c'est un véritable smartphone. Une formulation encore mieux de l'ancien code est montré ici :

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

Dans ce cas, le lecteur vidéo est caché dans tous les cas, sauf lorsque l'appareil est un bureau ou une tablette. Il y a un autre scénario plus intéressant pour WURFL.ISM Supposons que vous ayez un site RWD production où toutes les vues sont générés sur le serveur, au sein d'une application MVC ASP.NET , par exemple.

À un moment donné, vous obtiendrez vos commentaires ce smartphone utilisateurs ne sont pas forte d'une expérience appropriée. Devriez vous envisager de créer un toute nouvel m-site pour eux ? Si vous pouvez utiliser les services de serveur-côté de WURFL, alors vous pouvez facilement implémenter un mélangeur de vue au sein du même site, tel que démontré dans mon article d'août 2013.

Cette approche permettrait d'économiser le travail que vous avez fait. Dans le cas contraire, il n'y a pas beaucoup vous pouvez faire autre que créer un site distinct et mettre en place un mécanisme de redirection, tel que démontré dans mon article de janvier 2015, "mobiliser d'un Site Web existant" (msdn.microsoft.com/magazine/dn890366). Pour afficher régulière et la m-site sous la même URL, vous devez toujours certains détection bon appareil faite côté serveur.

Un effet secondaire agréable d'utiliser WURFL.JS est vous pouvez recueillir des informations relatives au périphérique de l'objet WURFL et le transmettre à Google Analytique. Cela vous donne une mesure immédiate de comment les utilisateurs visitent votre site et dont ils utilisent la plupart de dispositif. Si vous êtes passé à la nouvelle analytics.js vous besoin des éléments suivants :

<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 vous utilisez le classique Google Analytique au script (ga.js), ici, la légère modification vous devez implémenter :

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

Google Analytique a un tas de fonctionnalités intégrées pour suivre mobile et tablette de trafic. Le trafic mobile intègre la tablette trafic, aussi bien et ne peut pas séparer immédiatement smartphone de tablette, par exemple. WURFL.JS ajoute pratiques informations manquantes dans un premier temps dans Google Analytique, ainsi vous pouvez créer des rapports personnalisés se concentrer uniquement sur les numéros au lieu de la projection de données. WURFL.JS, cependant, est seulement un fournisseur de données. Il fonctionne avec Google Analytique, mais vous pouvez aussi l'utiliser avec d'autres outils d'analytique.

Jaquette en haut

Dans de nombreux cas, un site RWD est plus difficile (plus cher) pour mettre en œuvre qu'un simple site de Web Forms Web ASP.NET . Don' t écouter les sirènes de RWD. RWD est une excellente solution pour les ordinateurs de bureau et les appareils haut de gamme, mais il ne serait pas approprié lorsque la mise en œuvre efficace des fonctions sur les petits appareils est crucial pour l'entreprise. RWD met un point d'être indépendant du périphérique. Cela signifie que les sites Web de RWD servent le même contenu d'une fenêtre de navigateur de bureau redimensionnée de 480 x 360 et un téléphone plein écran petite particularité.

Matériel et raccordement peuvent être significativement différentes dans les deux cas. Performance est objectivement un point douloureux de RWD. Dans le même temps, on pourrait ne pas être douloureux de la même manière pour tous les sites. Problèmes de performances affectent principalement les dispositifs bas niveau. Si ces dispositifs ne sont pas communs aux visiteurs du site, vous pouvez aller avec RWD et être heureux.

Cependant, la quantité de données desservies et les attentes des utilisateurs peuvent croître dans un avenir proche. Cela rendrait plus d'appareils inadéquats et, idéalement, nécessitant un mode ad hoc. Dans cet article, j'ai présenté une solution côté client léger et presque discrète pour détecter le périphérique sous-jacent — WURFL.ISM

WURFL.JS est un point de terminaison qui injecte dans le DOM, plus précisément le facteur de forme, les informations relatives au périphérique. En d'autres termes, il vous indique que le périphérique est un ordinateur de bureau, une tablette, un smartphone, un vieux téléphone, une Xbox ou peut-être une application native. Sur cette base, vous pouvez organiser de petits changements dans les pages et même nourrir les outils analytique avec informations de facteur de forme.

Savoir comment se comporte votre site sur une base per-form-factor est un puissant indicateur de son succès et les zones que vous devez améliorer. Si vous voulez plus de détails sur comment utiliser WURFL.Vérifier la JS avec Google Analytique, bit.ly/1u0lpGB.

Dino Esposito est le co-auteur de « Microsoft .NET : Conception d'Applications pour l'entreprise » (Microsoft Press, 2014) et "programmation ASP.NET MVC 5" (Microsoft Press, 2014). Un spécialiste technique de Microsoft .NET Framework et les plates-formes Android à JetBrains et lors des événements de l'industrie dans le monde entier, Esposito partage sa vision du logiciel à software2cents.wordpress.com et sur Twitter à twitter.com/despos.

Grâce à l'expert technique suivante pour avoir relu cet article : Jon Arne Saeteras

Partager via