Innovation

Entwicklung mobiler Websites, Teil 3: Weiterleiten von Anforderungen

Dino Esposito Mehr als oft nicht, ist eine mobile Website die Teilmenge der einen größeren Standort für ein desktop Publikum gebaut. Desktop-Benutzer besucht oft Ihre Website verwenden, z. B. einen Laptop mit einer hohen Bildschirmauflösung und erhebliche Rechenleistung. Darüber hinaus wird der Benutzer stützt sich auf stabile Verbindung und ist nicht besonders besorgt über die Batterie entleeren. Alle diese Parameter machen einen großen Unterschied für Architekten und Entwickler von Web-Sites sowie Domain-Experten. Wenn es darum geht, mobile Websites, ist der schwierigste Teil nicht codieren aber herauszufinden, die Anwendungsfälle Code — und davor die Geschäftsfälle, für die Sie eine mobile Website (oder einer mobilen Anwendung) haben möchten.

Die mobile Website vorhanden ist, um es einfacher für Benutzer unterwegs die wichtigsten Dienste zu verwenden, die Sie bereits über die Haupt-Website verfügbar gemacht werden. Nehmen wir also an, wir haben eine definierte Menge von Anwendungsfällen und wir können beginnen, Programmieren und produzieren einige gute Markup. Aber zuallererst, wie erreichen wir die mobile Website?

Ich glaube fest daran, dass eine mobile Website eigenständige Website sein sollte, die eine unterschiedliche IIS-Anwendung entspricht. Dies vereinfacht die Entwicklungserfahrung. Sie konzentrieren sich nur auf mobilen Einsatz Fälle. Sie optimieren, Rendering und die Anwendungsschicht nur für mobilen Einsatz-Fälle. Sie befassen sich nur mit Technologien und Tools zu mobilen Szenarien. Schließlich testen Sie es leichter.

Auf der anderen Seite, als Benutzer, hasse ich eintippen zu eine eindeutige URL nur um die mobile Version einer Website anzeigen, in denen ich interessiert bin. Wäre es nicht toll, wenn Sie einfach eingeben könnten oder Lesezeichen www.contoso.com und lassen Sie die Website herausfinden, ob Sie ein mobiles Gerät oder einen Laptop herkommen? Sobald Ihre Herkunft festgestellt wird, könnte die Website möglicherweise Sie auf die mobile Website umleiten. Eine solche Strategie anwenden kann, liefern eine schöne Erfahrung, aber dies erfordert einige Annahmen und mit einigen Maschinen vorhanden.

Routing Benutzer auf der rechten Seite

Nehmen wir an, gibt es zwei unterschiedliche Websites — sagen, www.contoso.com und m.contoso.com. Der Benutzer ist nicht jedoch erwartet, dass Wissen über die m-Website; Sie kennt nur die Haupt-Website. Also gibt sie www.contoso.com in ihrem mobilen Gerät. Etwas Code in der Haupt-Website gehostet fängt die Anfrage und untersucht die Zeichenfolge des Benutzer-Agenten. Wenn die Anfrage von einem desktop-Browser kommt, passiert nichts und die Anforderung wird wie gewohnt fortgesetzt. Wenn auf einem mobilen Gerät der anfordernde Browser gehostet wird, wird der Benutzer auf eine Zielseite umgeleitet, wo sie gebeten hat, zwischen der vollständigen und dem mobilen Standort wählen. Abbildung 1 bietet eine grafische Ansicht der Strategie ich bin gliedern.

A Strategy for Routing Users to the Most Appropriate Site
Abbildung 1 Strategie für Routing-Benutzer an den am besten geeigneten Standort

Beide Standorte haben generell einen Interceptor, der filtert alle eingehenden Anfragen und leitet auf eine Landing Page, wenn das anfordernde Gerät ist nicht kompatibel mit dem Typ der Website. Um die Dinge noch einfacher, lassen Sie auch Laptops mobile Seiten anzeigen, wenn explizit angefordert und Gastgeber nur eine Landing Page für wenn die Haupt-Website von einem mobilen Gerät angefordert wird.

Diese Strategie wird nur erläutert, was bei der ersten Anforderung an einen Standort zu tun — in der Regel auf der Homepage geleitet. Für aufeinander folgende Anforderungen, die der Benutzer als sie arbeitet mit der Website vornehmen können, wollen Sie nicht den Interceptor kick wieder und zeigen die Zielseite. Mal sehen, wie Sie diese Strategie zu implementieren.

Ein HTTP-Modul zum Weiterleiten von Anforderungen

In ASP.NET ist die Standardmethode zum Abfangen von eingehender Anfragen ein HTTP-Modul installieren. Für jede Anforderung abgefangenen das HTTP-Modul überprüft die Zeichenfolge des Benutzer-Agenten und bestimmen, ob der Browser auf einem mobilen Gerät gehostet wird. Wenn der Browser auf einem mobilen Gerät ausgeführt wird, wird das HTTP-Modul der Benutzer zu einer bestimmten Zielseite; Wenn dies nicht der Fall ist, es wird einfach die Anforderung übergeben und wie gewohnt verarbeitet werden lassen. Abbildung 2 zeigt den Quellcode eines Beispiel-HTTP-Modul für mobile Routinganforderungen auf eine Zielseite (mobil).

Abbildung 2 Mobile Router-Komponente als ein HTTP-Modul implementiert

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);
 }
}

Grundsätzlich gibt es drei Anwendungsfall Szenarien.Eine ist, wenn der Benutzer mit einem Mobilgerät eine Landing Page erreicht und bestätigt, dass sie die ganze Seite sehen möchte.Ein weiteres Szenario ist, wenn der mobile Benutzer eine Seite auf der gesamten Website anfordert, weil sie einen Link in einer der Seiten der voll-Website folgt.Anders ausgedrückt, der mobile Benutzer empfangen die Landing Page, bestätigt sie die volle Seite sehen möchte und ist jetzt durch die Website navigieren.Schließlich ist das dritte Szenario Wenn der mobile Benutzer versucht, die vollständige Website zum ersten Mal in der Browsersitzung zu besuchen.In den ersten beiden Fällen kann das HTTP-Modul die Anforderung übergeben.Im letzten Fall leitet es einfach mobile Anwender auf ein ad-hoc-Landing-Page.

Die Landing Page ist eine Handy-optimierte Seite, die zeigt eine Nachricht an dem Benutzer und bietet Links zu der Homepage der desktop Website oder mobile Website.Abbildung 3 zeigt eine Beispiel-Landing-Page.Sie können es ausprobieren Leben durch Ihre eigenen Zeigegerät zu easycourt.net/contosoen.

A Sample Landing Page for a Mobile Site Abbildung 3 Beispiel Landing Page für eine Mobile Website

Die URL hinter dem "Mobile Site" Link verweist auf die mobile Website-Homepage.Der andere Link verweist auf der Homepage des Standortes voll mit einer zusätzlichen Abfragezeichenfolgen-Parameter.Den Namen und die Rolle dieses Parameters sind Ihnen überlassen, aber der Name könnte etwas wie folgt: https://www.contoso.com?Mode=Full.

Dieser Parameter wird durch das HTTP-Modul durch eine der genannten Funktionen überprüft Abbildung 2, wie hier gezeigt:

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;
}

Sehen Sie in Abbildung 2 , die Auswahl des Benutzers wird in einem Cookie gespeichert. Dies bedeutet, dass ein Benutzer, der ausdrücklich beschlossen, die ganze Website mit einem mobilen Gerät aufrufen werden nicht mehr mit einer Zielseite belästigt werden, solange das Cookie zur Verfügung steht.

Bevor ich auf die Struktur der Zielseite genauer eingehe, möchte ich angeben, wie das HTTP-Modul versteht, ob der Benutzer geklickt haben, um die vollständige Seite sehen oder ist die Navigation durch die ganze Site. In Abbildung 2 Sie sehen, dass der folgende Code verwendet wird, zu prüfen, ob das Cookie für die Anzeige der vollständigen Website gefunden wird:

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

Wenn es kein Cookie und keine Abfragezeichenfolgen-Parameter, wird der Benutzer Zugriff auf die desktop-Website von einem mobilen Gerät einfach auf die Zielseite umgeleitet:

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

Der entscheidende Punkt ist, dass der Benutzer auf die Landing-Page nur beim ersten Mal könnte, das Sie umgeleitet werden auf einen desktop Standort von einem mobilen Gerät zuzugreifen versucht. Von diesem Punkt auf, weiteren Anforderungen haben zusätzliche Informationen, die das HTTP-Modul umleiten verhindert.

Erkennen von Mobile Geräten

Der Code sehen Sie in Abbildung 2, nur ein Stück bleibt vollständig zu erklären: Wie erkennen Sie, ob das anfordernde Gerät ein mobiles Gerät handelt. Dies kann auf unterschiedliche Weise und mit unterschiedlichen Zuverlässigkeit erreicht werden. Zum Beispiel einfach Verlass auf einige Code wie in Abbildung 4. Es versucht, die Zeichenfolge des Benutzer-Agenten für einige Handy-nur Keywords abzufragen.

Abbildung 4 die Zeichenfolge des Benutzer-Agents für Mobile nur Keywords Abfragen

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");
}

Die Liste der Suchbegriffe ist nicht erschöpfend, aber es ist ziemlich repräsentativ für die mobile Welt. Dieser Code kann verlängert werden, nach Belieben um es besser und besser, da neue Geräte erscheinen und mobiler Benutzer starten Ihre Website besuchen. Aber das ist genau der Punkt. Sind Sie bereit, dieses Stück Code ständig zu aktualisieren? Nicht zu solchen Code überarbeiten müssen, ist nur einer der Vorteile, die ein Device Description Repository (DDR) anbietet. Ein DDR ist eine Bibliothek, die auf eine Datenbank mit Benutzer-Agent-Strings aufbauen. Alles, was ein DDR tut ist User Agent analysieren und eine Liste der bekannten Funktionen zurückgeben. Ich sagte "bekannt" und nicht "erkannt", da dies genau der Fall ist. Ein DDR erhält seine Informationen statisch aus einer häufig aktualisierten Datenbank. Es erkennt nicht die Fähigkeiten auf dem Gerät. Dies ist jedoch ein Vorteil der DDR Lösungen anstatt eine Einschränkung! Hinter der DDR gibt es menschliches Eingreifen, und menschlicher Arbeit legt fest, ob ein bestimmtes Gerät eine bestimmte Fähigkeit hat. Einige Funktionen können algorithmisch erkannt werden, aber der zurückgegebene Wert ist nicht immer ganz zuverlässig. Einige andere Funktionen – die Mehrheit, in der Tat — nicht algorithmisch erkannt werden kann jedoch nützlich sein zu wissen, um intelligent zu entscheiden, welche Markup für ein bestimmtes Gerät zu bedienen.

Beliebte DDRs für ASP.NET Raum sind Wireless Universal Resource File, oder WÜRFL und 51degrees, wie in meinem vorherigen Artikel beschrieben (msdn.microsoft.com/magazine/jj190798). Da beide dieser Frameworks ein kostenloses Angebot für beschränkt (meist Cloud-basierte) verwendet haben, sollten Sie eine davon auswählen, selbst wenn Sie nur benötigen, um festzustellen, ob ein Gerät oder nicht beweglich ist. Zumindest sparen Sie sich die Belastung häufig aktualisieren Ihre IsMobile-Funktion mit neuen Geräten und Ecke Fälle halten.

Für verschiedene Geräte optimieren

Nachbereitung, glaube ich, dass Websites eine optimierte Seiten auf verschiedenen Geräten anbieten sollten, ob sie Smartphones, Tabletten oder Laptops sind. Dies geschieht am besten, wenn Sie verschiedene Web-Sites oder zumindest physisch unterschiedliche Ansichten, die Sie verwalten und pflegen separat anbieten können. Jedoch sollte diese Trennung immer für Besucher der Website sein. Die Website sollte über eine eindeutige URL erreichbar sein. Lassen Sie die zugrunde liegende Plattform zaubern den Typ des Geräts zu verstehen und zu den am besten geeigneten Ansicht wechseln. In meinem nächsten Artikel werde ich DDRs verwenden, um eine Implementierung der verschiedenen Ansichten für verschiedene Geräte zu diskutieren.

Dino Esposito ist der Autor von "Architecting Mobile Lösungen für Unternehmen" (Microsoft Press, 2012) und "Programmierung ASP.NET MVC 3" (Microsoft Press, 2011) und Mitautor von "Microsoft .net: Architecting Applications for the Enterprise" (Microsoft Press, 2008). Esposito lebt in Italien und ist ein weltweit gefragter Referent für Branchenveranstaltungen. Sie können ihm auf Twitter unter twitter.com/despos folgen.

Unser Dank gilt dem folgenden technischen Experten für die Durchsicht dieses Artikels: Pranav Rastogi