Cutting Edge

Sviluppo di siti per dispositivi mobili, parte 3: richieste di routing

Dino Esposito Più spesso, un sito mobile è il sottoinsieme di un sito più grande costruito per un pubblico di desktop. Un utente desktop spesso visita il tuo sito usando, per esempio, un computer portatile con una risoluzione alta dello schermo e la notevole potenza di calcolo. Inoltre, l'utente si basa sulla connettività stabile e non è particolarmente preoccupato per lo scarico della batteria. Tutti questi parametri fanno una differenza enorme per gli architetti e gli sviluppatori di siti Web, nonché esperti di dominio. Quando si tratta di siti di telefonia mobile, la parte più difficile è non codifica ma capire i casi di utilizzo di codice — e prima di allora, i casi di business per il quale si desidera avere un sito mobile (o un'applicazione mobile).

Il sito mobile esiste per rendere più facile per gli utenti in viaggio utilizzare i servizi più rilevanti che espongono già attraverso il sito Web principale. Quindi supponiamo che abbiamo un insieme ben definito di casi d'uso e siamo pronti per iniziare la codifica e produrre qualche buon markup. Ma, anzitutto, come noi di raggiungere il sito mobile?

Credo fermamente che un sito mobile dovrebbe essere un sito autonomo che corrisponde a un'applicazione IIS distinta. Questo semplifica notevolmente l'esperienza di sviluppo. Concentrano solo su casi di utilizzo mobile. Ottimizzare il rendering e lo strato di applicazione solo per i casi di utilizzo mobile. Si tratta solo con le tecnologie e gli strumenti correlati agli scenari mobili. Infine, si verifica più facilmente.

D'altra parte, come un utente, io odio dover digitare un URL distinto solo per visualizzare la versione mobile di un sito in cui sono interessato. Non sarebbe bello se si potrebbe semplicemente digitare o segnalibro www.contoso.com e lasciare il sito capire se stai venendo da un dispositivo mobile o un computer portatile? Una volta che è accertata la provenienza, il sito potrebbe eventualmente reindirizzare l'utente al sito mobile. Applicando tale strategia in grado di fornire un'esperienza piacevole, ma questo richiede alcune ipotesi e avendo alcuni macchinari sul posto.

Routing utenti per il sito giusto

Supponiamo che ci sono due siti Web distinti in luogo — dire, www.contoso.com e m.contoso.com. L'utente, tuttavia, non è previsto di conoscere il sito-m; lei conosce solo il sito Web principale. Così lei tipi www.contoso.com nel suo dispositivo mobile. Qualche codice ospitato nel sito principale intercetta la richiesta ed esamina la stringa agente utente. Se la richiesta proviene da un browser desktop, non accade nulla e la richiesta procede come al solito. Se il browser richiedente è ospitato su un dispositivo mobile, l'utente viene reindirizzato a una pagina di atterraggio dove lei ha chiesto di scegliere tra il pieno e il sito mobile. Figura 1 offre una visualizzazione grafica della strategia sto delineando.

A Strategy for Routing Users to the Most Appropriate Site
Figura 1 strategia di Routing gli utenti al sito più appropriato

Più in generale, entrambi i siti hanno un intercettore che filtra le richieste in arrivo e reindirizza a una pagina di destinazione, se il dispositivo richiedente non è compatibile con il tipo di sito. Per mantenere le cose ancora più semplice, si può anche lasciare laptop Mostra pagine mobile se richiesto in modo esplicito e ospitare solo una pagina di destinazione quando il sito principale è richiesto da un dispositivo mobile.

Questa strategia solo spiega cosa fare la prima richiesta per un sito — in genere diretto alla homepage. Per le richieste successive che l'utente può effettuare come lei lavora con il sito, non si desidera l'intercettore di calcio nuovo e visualizza la pagina di destinazione. Vediamo come implementare questa strategia.

Un modulo HTTP per instradare le richieste

In ASP.NET, il modo standard per intercettare le richieste in arrivo è l'installazione di un modulo HTTP. Per ogni richiesta intercettata, il modulo HTTP esaminerà la stringa agente utente e determinare se il browser è ospitato su un dispositivo mobile. Se il browser in esecuzione su un dispositivo mobile, il modulo HTTP reindirizza l'utente a una pagina di atterraggio dato; Se così non fosse, semplicemente lascerà la richiesta passa e trattati come al solito. Figura 2 Mostra il codice sorgente di un modulo HTTP di esempio per le richieste di routing mobile a una pagina di atterraggio (mobile).

Figura 2 Mobile Router componente implementato come un modulo HTTP

public class MobileRouterModule : IHttpModule
{
  private const String ForceFullSiteCookieName = "FullSiteMode";
  public void Dispose()
  {
  }
 public void Init(HttpApplication context)
 {
   context.BeginRequest += OnBeginRequest;
 }
 private static void OnBeginRequest(Object sender, EventArgs e)
 {
   var app = sender as HttpApplication;
   if (app == null)
     throw new ArgumentNullException("sender");
   // Check whether it is a mobile site
   var isMobileDevice = IsMobileUserAgent(app);
   // The mobile user confirmed to view the desktop site 
   if (isMobileDevice && ForceFullSite(app))
   {
     app.Response.AppendCookie(new HttpCookie(ForceFullSiteCookieName));
     return;
   }
   // The mobile user is navigating through the desktop site
   if (isMobileDevice && HasFullSiteCookie(app))
     return;
   // The mobile user is attempting to view a desktop page
   if (isMobileDevice)
     ToMobileLandingPage(app);
 }
}

Ci sono fondamentalmente tre scenari del caso d'uso.Uno è quando l'utente con un dispositivo mobile raggiunge una pagina di atterraggio e conferma che vuole visualizzare il sito completo.Un altro scenario è quando l'utente mobile richiede una pagina sul sito completo perché lei sta seguendo un link in una delle pagine del sito completo.Mettere un altro modo, l'utente mobile ricevuto nella pagina di atterraggio, ha confermato lei vuole visualizzare il sito completo e ora sta navigando attraverso il sito.Infine, il terzo scenario è quando l'utente mobile sta cercando di visitare il sito completo per la prima volta in quella sessione del browser.Nei primi due casi, il modulo HTTP consente la richiesta di passare.In quest'ultimo caso, esso semplicemente reindirizza l'utente mobile a una pagina di atterraggio ad hoc.

La pagina di destinazione sarà una pagina mobile ottimizzata che mostra un messaggio per l'utente e offre link alla homepage del sito desktop o sito mobile.Figura 3 Mostra una pagina di destinazione del campione.Si può provare dal vivo puntando il vostro dispositivo a easycourt.net/contosoen.

A Sample Landing Page for a Mobile Site Figura 3 esempio Landing Page per un sito Mobile

L'URL dietro i punti di collegamento "Mobile site" alla homepage del sito mobile.Altri link punti alla homepage del sito completo con un parametro di stringa di query extra.Il nome e il ruolo di questo parametro sono fino a voi, ma il nome potrebbe essere qualcosa come questo: https://www.contoso.com?mode=Full.

Questo parametro sarà controllato dal modulo HTTP attraverso una delle funzioni menzionate Figura 2, come illustrato di seguito:

private static Boolean ForceFullSite(HttpApplication app)
{
  var full = app.Context.Request.QueryString["mode"];
  if (!String.IsNullOrEmpty(full))
    return String.Equals(full, "full", 
      StringComparison.InvariantCultureIgnoreCase);
  return false;
}

Si vede Figura 2 che la scelta dell'utente viene memorizzata in un cookie. Questo significa che un utente che ha scelto espressamente per navigare il sito completo con un dispositivo mobile non essere disturbato affatto più lungamente con una pagina di atterraggio fintanto che il cookie è disponibile.

Prima di discutere la struttura della pagina di destinazione in modo più dettagliato, mi permetta di specificare come il modulo HTTP capisce se l'utente fa clic per visualizzare il sito completo o naviga attraverso il sito completo. In Figura 2 si vede che l'esempio di codice riportato di seguito viene utilizzato per controllare se il cookie per visualizzare il sito completo si trova:

private static Boolean HasFullSiteCookie(HttpApplication app)
{
  var cookie = app.Context.Request.Cookies[FullSiteModeCookie];
  return cookie != null;
}

Se non c'è nessun cookie e nessun parametro di stringa di query, l'utente accede al sito desktop da un dispositivo mobile semplicemente viene reindirizzato alla pagina di destinazione:

private static void ToMobileLandingPage(HttpApplication app)
{
  var landingPage = ConfigurationManager.AppSettings["MobileLandingPage"];
  if (!String.IsNullOrEmpty(landingPage))
    app.Context.Response.Redirect(landingPage);
}

Il punto chiave è che l'utente potrebbe essere reindirizzato alla pagina di destinazione solo la prima volta che si tenta di accedere a un determinato sito desktop da un dispositivo mobile. Da che punto su, eventuali ulteriori richieste sono informazioni aggiuntive che impedisce il modulo HTTP di reindirizzamento.

Rilevare i dispositivi mobili

Di tutto il codice che vedete Figura 2, solo un pezzo resta per pienamente spiegare: come si rileva se il dispositivo richiedente è un dispositivo mobile. Ciò può essere ottenuto in vari modi e con diversi livelli di affidabilità. Ad esempio, può semplicemente affidamento su qualche codice simile a quello mostrato Figura 4. Tenta di interrogare la stringa agente utente per alcune parole chiave, solo mobile.

Figura 4 l'interrogazione la stringa agente utente per Parole chiavi solo Mobile

private static Boolean HasAnyMobileKeyword(String userAgent)
{
  string ua = userAgent.ToLower();
  return (ua.Contains("midp") ||
    ua.Contains("mobile") ||
    ua.Contains("android") ||
    ua.Contains("samsung") ||
    ua.Contains("nokia") ||
    ua.Contains("phone") ||
    ua.Contains("opera mini") ||
    ua.Contains("opera mobi") ||
    ua.Contains("blackberry") ||
    ua.Contains("symbian") ||
    ua.Contains("j2me") ||
    ua.Contains("windows ce") ||
    ua.Contains("vodafone") ||
    ua.Contains("ipad;") ||
    ua.Contains("maemo") ||
    ua.Contains("palm") ||
    ua.Contains("fennec") ||
    ua.Contains("wireless") ||
    ua.Contains("htc") ||
    ua.Contains("nintendo") ||
    ua.Contains("zunewp7") ||
    ua.Contains("silk");
}

L'elenco delle parole chiave non è esaustivo, ma è abbastanza rappresentativa dell'universo mobile. Questo codice può essere estesa a volontà per farlo lavorare meglio e meglio come appaiono nuovi dispositivi e utenti mobili più iniziano visitando il vostro sito. Ma è proprio questo il punto. Siete disposti ad aggiornare costantemente questo pezzo di codice? Non dover rivedere tale codice è solo uno dei vantaggi che offre un Repository di descrizione del dispositivo (DDR). Una DDR è una biblioteca costruita sulla cima di un database che contiene stringhe agente utente. Tutto ciò fa una DDR è analizzare l'user agent e restituire un elenco di funzionalità conosciuta. Ho detto "conosciuto" e non "rilevato" perché questo è proprio il caso. Una DDR ottiene staticamente le informazioni da un database aggiornato di frequente. Non rileva le funzionalità del dispositivo. Tuttavia, questo è un vantaggio di soluzioni DDR, piuttosto che una limitazione! Dietro DDR c'è intervento umano, e il lavoro umano stabilisce se un determinato dispositivo ha una determinata capacità. Alcune funzionalità possono essere rilevate algoritmicamente, ma il valore restituito non è sempre completamente affidabile. Alcune altre funzionalità — la maggior parte, infatti, non può essere rilevato in modo algoritmico, ma può essere utile sapere per poter decidere in modo intelligente che markup per servire a un determinato dispositivo.

DDR popolare per lo spazio ASP.NET sono Wireless Universal Resource File, o WURFL e 51degrees, come discusso nel mio articolo precedente (msdn.microsoft.com/magazine/jj190798). Perché entrambi questi quadri hanno un'offerta libera per uso limitato (per lo più basato su cloud), si potrebbe desiderare di scegliere uno di loro, anche se hai solo bisogno di determinare se un dispositivo mobile o non. Almeno potrai risparmiare l'onere di aggiornare frequentemente la funzione IsMobile per tenere il passo con nuovi dispositivi e casi di angolo.

Ottimizzazione per dispositivi diversi

Avvolgendo, credo che siti Web dovrebbe offrire un set ottimizzato delle pagine per diversi dispositivi, siano essi smartphone, Tablet o computer portatili. Questo avviene meglio se potete offrire diversi siti Web o almeno fisicamente diversi punti di vista che è possibile gestire e mantenere separatamente. Tuttavia, questa separazione deve essere sempre trasparente ai visitatori del sito. Il sito dovrebbe essere raggiungibile attraverso un URL univoco. Si lascia la piattaforma sottostante fare la magia di comprensione del tipo di dispositivo e passare alla visualizzazione più appropriata. Nel mio prossimo articolo userò DDR per discutere di un'implementazione di diversi punti di vista per diversi dispositivi.

Dino Esposito è l'autore di "Architettura Mobile soluzioni per l'impresa" (Microsoft Press, 2012) e "programmazione ASP.NET MVC 3" (Microsoft Press, 2011) e coautore di "Microsoft .net: Architecting Applications for the Enterprise" (Microsoft Press, 2008). Vive in Italia e partecipa spesso come relatore a eventi del settore in tutto il mondo. Seguirlo su Twitter a twitter.com/despos.

Grazie all'esperto tecnica seguente per la revisione di questo articolo: Pranav Rastogi