À la pointe

Création d'affichages optimisés pour mobile dans ASP.NET MVC 4

Dino Esposito

Si vous allez au-delà des considérations classiques en termes de programmation de sites mobiles, vous découvrez une contradiction inhérente. D'un côté, les gens veulent à tout prix orienter leur approche de la programmation des applications et des sites vers le mobile en priorité. D'un autre côté, ces mêmes personnes font souvent l'éloge des requêtes de média CSS et des affichages à cristaux liquides. Je constate la contradiction suivante : l'utilisation courante des requêtes de média CSS et des affichages à cristaux liquides ne fait pas passer le mobile avant tout le reste (il ne s'agit pas d'une technique qui donne priorité au mobile). Dans cet article, je vais expliquer comment utiliser une logique côté serveur afin d'obtenir un affichage optimal pour un appareil en incorporant une nouvelle fonctionnalité ASP.NET MVC 4 appelée Modes d'affichage.

Le problème ne vient pas de la technologie des requêtes de média CSS. Le problème ne vient pas non plus de la conception Web réactive utilisée comme méthode de prise en charge des requêtes de média CSS (si ce n'est la philosophie qui est à l'origine de la technologie). Alors, en quoi les requêtes de média CSS et les affichages à cristaux liquides sont-ils une approche qui ne donne pas la priorité au mobile ? Le slogan utilisé pour aborder cette approche peut donner un indice : Un seul code base peut servir plusieurs affichages. À cet effet, CSS (une technologie côté client) est utilisée pour basculer entre les affichages et JavaScript est utilisé pour les adapter ensuite si CSS ne suffit pas.

Selon moi, dans cette approche il y a la proposition sous-jacente consistant à fournir le même contenu à tous les appareils simplement en modifiant la disposition de la page pour qu'elle tienne dans l'écran. Ce faisant, vous risquez de ne pas pouvoir offrir la meilleure expérience possible à vos utilisateurs. Je pense que vous devez essayer de n'avoir qu'un code base unique (un socle commun d'API Web), mais que vous devez absolument vous concentrer sur des utilisations spécifiques pour chaque catégorie d'appareils que vous avez l'intention de prendre en charge. Le terme « mobile » ne signifie plus grand-chose aujourd'hui, il a été remplacé par des catégories d'appareils tels que des smartphones, des tablettes, des ordinateurs portables et des télévisions intelligentes (sans parler de l'informatique vestimentaire avec les lunettes et les bracelets intelligents).

Il y a environ un an, j'ai présenté dans cet article le suivi d'une approche côté serveur avec un développement de site ASP.NET MVC : pour créer des affichages ad hoc pour chaque catégorie d'appareil prise en charge (« Développement de sites mobiles : balisage », msdn.microsoft.com/magazine/jj133814). J'ai fait cela dans le cadre d'ASP.NET MVC 3. Il est agréable de constater qu'ASP.NET MVC 4 est fourni avec les modes d'affichage mentionnés ci-dessus qui peuvent être facilement utilisés pour implémenter une logique côté serveur qui offre le meilleur affichage et le meilleur contenu pour un appareil donné. Pour être vraiment efficace, cette approche nécessite que vous en sachiez le maximum sur les fonctionnalités de l'appareil effectuant la requête. Toutefois, en dehors des informations de base quant à la taille de l'écran et à son orientation, il n'y a pas grand-chose d'autre qui puisse être détecté sur le client. Vous devez alors avoir recours à un référentiel serveur ayant des informations sur l'appareil.

Présentation des modes d'affichage dans ASP.NET MVC 4

Avant de passer aux modes d'affichage, je tiens à indiquer que cet article (ainsi que la technologie du mode d'affichage en elle-même) concerne principalement la création d'un site unique qui lie dynamiquement la même URL à différents affichages. Si vous avez déjà un site Web et que vous voulez fournir un site d'assistance optimisé pour certains appareils (mobiles), c'est une toute autre affaire. Vous pouvez toujours utiliser cet article pour créer le site d'assistance, mais il faut des outils différents pour unifier les URL avec un site parent existant.

Dans ASP.NET MVC 4, les modes d'affichage sont des fonctionnalités système qui étendent le comportement classique des moteurs d'affichage et permettent de choisir le fichier de vue le plus approprié pour l'appareil demandeur. Dans l'article pour ASP.NET MVC 3 mentionné ci-dessus, j'ai utilisé un moteur d'affichage personnalisé à cet effet. Avec cette solution, j'étais également limité aux affichages Razor. Avec les modes d'affichage, les méthodes de votre contrôleur vont toujours invoquer un affichage appelé Index et le runtime ASP.NET MVC choisira à la place un fichier de vue appelé index.mobile.cshtml si l'appareil demandeur est un appareil mobile.

C'est une excellente nouvelle, car cela signifie que vous pouvez toujours avoir un seul code base pour votre site. Il vous suffit d'ajouter des fichiers de vue CSHTML pour chaque catégorie d'appareils que vous avez l'intention de prendre en charge. Pour commencer à utiliser les modes d'affichage, jetons un œil à l'exemple de code de la figure 1.

Figure 1 Liste standard des modes d'affichage pris en charge

    <h2>
      Display Modes currently active
      (@DisplayModeProvider.Instance.Modes.Count mode(s))
    </h2>
    <ul>
    @{
      foreach(var d in DisplayModeProvider.Instance.Modes)
      {
        <li>@(String.IsNullOrEmpty(d.DisplayModeId)
          ?"default" :d.DisplayModeId)</li>
      }
    }
    </ul>

La page du code de la figure 1 illustre la liste standard des modes d'affichage pris en charge. La figure 2 illustre la sortie générée par la page.

Figure 2 Liste par défaut des modes d'affichage

Les modes d'affichage ASP.NET MVC 4 suivent quelques conventions. Chaque mode d'affichage est notamment associé à un mot clé. Ce mot clé est utilisé pour composer le nom du fichier de vue correspondant. Le mode d'affichage par défaut est lié à une chaîne vide. Par conséquent, les fichiers de vue sont correctement gérés par n'importe quelle application ASP.NET MVC 4 sans que vous ayez à intervenir : index.cshtml et index.mobile.cshtml.

Pour voir une démonstration, copiez le fichier index.cshtml dans un nouveau fichier intitulé index.mobile.cshtml et ajoutez-le au projet. Pour faire la distinction entre les deux fichiers, ajoutez ce qui suit au fichier mobile :

    <div style="border-bottom: solid 1px #000">Mobile view</div>

Si vous exécutez l'application et que vous la testez avec Internet Explorer ou un autre navigateur, rien ne change. Appuyez sur la touche F12 pour afficher les outils de développeur Internet Explorer et définir un agent utilisateur mobile (AU) en sélectionnant Outils | Modifier la chaîne de l’agent utilisateur, comme indiqué dans la figure 3.

Figure 3 Forcer un agent utilisateur mobile dans Internet Explorer à des fins de test

J'ai déjà configuré quelques agents utilisateur pour tablette et mobile. Vous pouvez par exemple utiliser celui qui suit. Il identifie le navigateur qui effectue la requête en tant que smartphone HTC Desire Android :

Mozilla/5.0 (Linux; U; Android 2.1; xx-xx; HTC Desire Build/ERE27)
AppleWebKit/525.10+ (KHTML, like Gecko) Version/3.0.4 Mobile Safari/523.12.2

La figure 4 illustre ce que vous obtenez à partir du site ASP.NET MVC 4. La page traitée à partir de la même paire de contrôleurs et méthodes d'action est index.mobile.cshtml. Mais surtout, tout cela s'est déroulé sans apporter de modification au style de programmation et sans apprendre de nouvelles compétences.

Figure 4 Passage à un affichage d'appareil mobile

Dépasser les notions de base

Tout ce qui a été évoqué jusqu'ici est le minimum de ce que vous pouvez et devez faire dans votre développement de site mobile. Deux points essentiels doivent être traités avant de transformer des modes d'affichage en une solution pour un site réaliste. Le premier point consiste à chercher des façons d'ajouter plusieurs modes d'affichage. Le deuxième point consiste à chercher des façons d'injecter une logique ad hoc pour détecter des appareils de manière plus fiable.

La logique intégrée utilisée par ASP.NET MVC pour détecter des appareils mobiles n'est pas très fiable. Elle fonctionne certainement avec des smartphones, mais pas avec des téléphones cellulaires plus anciens. Prenons, par exemple, l'AU suivant :

SAMSUNG-GT-S3370/S3370DDJD4 SHP/VPP/R5 Dolfin/1.5 Qtv/5.3
SMM-MMS/1.2.0 profile/MIDP-2.1 configuration/CLDC-1.1 OPN-N

Il fait référence à un téléphone d'ancienne génération (assez populaire il y a deux ans) qui exécute un SE propriétaire et un navigateur personnalisé basé sur WebKit. Ce téléphone ne prend pas en charge la connectivité Wi-Fi mais, bizarrement, il a de bonnes fonctionnalités de rendu HTML. L'écran est plus petit que sur la plupart des smartphones, mais il dispose de la fonction tactile. Ce téléphone prend en charge le mode d'affichage de base d'ASP.NET MV, et par conséquent, il n'est pas reconnu comme un appareil mobile et reçoit les pages dans leur version complète. Cela a deux inconvénients. Tout d'abord, les utilisateurs peuvent à peine voir le contenu de l'écran car il est étiré et déformé. Ensuite, une grande partie du contenu est téléchargée et comme le téléphone ne prend pas en charge la connectivité Wi-Fi, cette opération va certainement s'effectuer via une connexion 3G (ce qui risque de prendre beaucoup de temps et peut s'avérer onéreux pour l'utilisateur).

Quand je fais part de ce problème, certaines personnes répondent que leurs sites ne prennent tout simplement pas en charge ce type de téléphone ancienne génération. On peut tout à fait le comprendre, mais ne serait-il pas dans ce cas préférable de prévenir poliment l'utilisateur au lieu de laisser les choses en l'état, sans aucun contrôle ? Pour pouvoir envoyer un message comme : « Désolé, le site ne peut pas être affiché sur votre appareil » il vous faut toujours reconnaître l'appareil correctement et comprendre qu'il est différent d'un iPhone par exemple. En outre, le fait de pouvoir ignorer ou non en toute sécurité les appareils anciens est une décision professionnelle et non une question d'implémentation. Le fait de ne pas recevoir les messages des appareils ancienne génération peut considérablement affecter l'entreprise. Voyons à présent comment ajouter plusieurs modes d'affichage correctement sur un site pour accepter plusieurs catégories d'appareils.

Catégories d'appareils

Un site Web moderne offre la meilleure expérience possible quel que soit le type d'appareil. Par « Meilleure expérience possible » on entend : fournir des utilisations ad hoc, des données sélectionnées et des fonctions spécifiques. Le balisage qui en résulte doit être spécifique à l'appareil. Si, au lieu de cela, vous réglez des éléments sur le client (comme c'est le cas quand vous vous basez sur les requêtes de média CSS), vous obtenez un résultat unifié des pages, il vous suffit ensuite de les adapter aux écrans plus petits. Cela signifie principalement masquer certains blocs et en étendre d'autres verticalement, et demander probablement un ensemble de visuels plus petit. La vision unifiée de la page est souvent la page du Bureau. Personnellement, ce n'est pas ce que j'appelle une approche qui donne priorité au mobile.

Quand je dis « type d'appareil », je ne cherche pas à faire la distinction entre un iPhone et un Windows Phone. Je cherche plutôt à utiliser une logique pouvant accepter différents balisages de smartphones, tablettes et ordinateurs portables. Dans ASP.NET MVC 4, j'ai déjà au moins trois modes d'affichage : smartphone, tablette et affichage par défaut (pour les navigateurs de bureau). Je vais ajouter une nouvelle catégorie DisplayConfig à invoquer dans App_Start (voir la figure 5).

Figure 5 La catégorie DisplayConfig

public class DisplayConfig
{
  public static void RegisterDisplayModes(IList<IDisplayMode> displayModes)
  {
    var modeDesktop = new DefaultDisplayMode("")
   {
     ContextCondition = (c => c.Request.IsDesktop())
   };
   var modeSmartphone = new DefaultDisplayMode("smart")
   {
     ContextCondition = (c => c.Request.IsSmartphone())
   };
   var modeTablet = new DefaultDisplayMode("tablet")
   {
     ContextCondition = (c => c.Request.IsTablet())
   };
   displayModes.Clear();
   displayModes.Add(modeSmartphone);
   displayModes.Add(modeTablet);
   displayModes.Add(modeDesktop);
 }
}

La catégorie commence par vider la collection de modes d'affichage fournie. Elle se débarrasse ainsi des modes par défaut. Le code remplit ensuite la collection système fournie par une nouvelle liste de modes d'affichage. Un nouveau mode d'affichage est une instance de la catégorie DefaultDisplayMode. Le nom de ce mode est défini via le constructeur. La logique qui détermine si un AU est mis en correspondance est définie via la propriété ContextCondition.

La propriété ContextCondition est un délégué qui accepte un objet HttpContextBase et retourne un booléen. Le corps du délégué consiste à espionner le contexte HTTP de la demande actuelle afin de déterminer si le mode d'affichage donné est approprié. Dans la figure 5, j'utilise quelques méthodes d'extension pour conserver le code très lisible. La figure 6 répertorie ces méthodes d'extension.

Figure 6 Méthodes d'extension pour maintenir la clarté du code

public static class HttpRequestBaseExtensions
{
  public static Boolean IsDesktop(this HttpRequestBase request)
  {
    return true;
  }
  public static Boolean IsSmartphone(this HttpRequestBase request)
  {
    return IsSmartPhoneInternal(request.UserAgent);
  }
  public static Boolean IsTablet(this HttpRequestBase request)
  {
    return IsTabletInternal(request.UserAgent);
  }
  // More code here.
}

Tout le code traité jusqu'ici est de l'infrastructure pure. Vous obtenez au final une méthode à écrire pour chaque mode d'affichage. Chaque méthode utilise un AU et doit retourner une réponse Booléenne. Voici une routine de base pour rechercher des tablettes :

private static Boolean IsTabletInternal(String userAgent)
{
  var ua = userAgent.ToLower();
  return ua.Contains("ipad") || ua.Contains("gt-");
}

Cette routine garantit uniquement la détection correcte des appareils de type iPad et Galaxy Tab, mais vous pouvez constater la manière dont ces routines de condition de contexte doivent être écrites. Vous pouvez ajouter plus de code pour rechercher, tout au moins, des smartphones. Pour détecter des tablettes et des smartphones, vous pouvez tirer parti de n'importe quelle infrastructure open source ou d'un référentiel DDR (Device Description Repository) commercial. J'aborderai ceci plus en détails dans mon prochain article.

Important pour un site professionnel

Une approche côté serveur des sites mobiles n'est pas toujours nécessaire, mais ce sujet devient important dès qu'il s'agit d'un site professionnel. Je ne recommanderais pas une approche côté serveur pour un site de conférence ou un site à courte durée de vie. Toutefois, un site professionnel destiné à un public très vaste doit insister sur l'optimisation pour les appareils et ne pas se contenter d'un rendu ordinaire pour les mobiles.

Sur le client, vous êtes limité à la taille et à l'orientation de la fenêtre du navigateur et vous ne pouvez pas vérifier le SE ou les fonctionnalités tactiles (ni vérifier les options avancées, par exemple si l'appareil prend en charge les connexions sans fil, la diffusion continue, les images en ligne, les SMS, etc.). Les modes d'affichage facilitent notamment l'implémentation d'une approche multivue dans ASP.NET MVC 4.

Dans mon prochain article, je vais conclure en montrant comment intégrer le DDR utilisé par Facebook (Wireless Universal Resource File (WURFL)) dans ASP.NET MVC 4.

Dino Esposito est l'auteur de « Architecting Mobile Solutions for the Enterprise » (Microsoft Press, 2012) et de « Programming ASP.NET MVC 3 » (Microsoft Press, 2011). Il a également coécrit « Microsoft .NET: Architecting Applications for the Enterprise » (Microsoft Press, 2008). Dino Esposito vit en Italie et participe régulièrement aux différentes manifestations du domaine organisées aux quatre coins du monde. Vous pouvez le suivre sur Twitter à l'adresse twitter.com/despos.

Merci à l'expert technique suivant d'avoir relu cet article : Mani Subramanian (Microsoft)
Mani Subramanian participe au développement et aux tests de projets logiciels depuis 12 ans. Il se consacre notamment à SOA, les services de cloud computing et core.net.