Anmerkung der Redaktion

Artikel
03/03/2015

Einfache clientseitige Geräteerkennung

Dino Esposito Grundsätzlich stehen zwei Optionen für das Erstellen gerätefreundlicher Websites zur Verfügung – das Erstellen einer separaten mobilen Website (M-Website) oder das Überarbeiten einer Website, damit diese Inhalte und Verhalten intelligent an die vorgegebene Bildschirmgröße und Ausrichtung anpassen kann. Keine dieser beiden Strategien ist in allen Fällen ideal. Daher ist der klügste Ansatz zur Entscheidungsfindung die klassische Aussage „es hängt von den Umständen ab“.

Eine M-Website besitzt zwei wesentliche Nachteile. Einerseits sind alle Geräte hinsichtlich Bildschirmgröße und physischen Funktionen unterschiedlich (von Smartphones, Tablets und Minitablets bis hin zu älteren Mobiltelefonen, Phablets, Wearable Computing usw.). Wie wird andererseits „mobil“ überhaupt definiert?

Vor einigen Jahren war es noch sinnvoller, eine M-Website zu betreiben, weil es eine klare Trennung zwischen Desktopcomputern und allen anderen Geräten gab. Heute gibt es für „alle anderen Geräte“ so zahlreiche Optionen, dass eine generische vereinheitlichte mobile Website nicht in Frage kommt. Der zweite Nachteil einer M-Website besteht darin, dass Benutzer zu einer individuellen URL (normalerweise vom Typ „m.ihrserver.com“) navigieren müssen. Dies ist keine erstrebenswerte Lösung mehr und nur als temporäre Problemumgehung akzeptabel.

Die andere Option – eine dynamisch Benutzeroberfläche – weist ebenfalls Nachteile auf. Die zentrale Frage dreht sich also darum, wie eine Website dynamisch gestaltet werden kann. Einer dynamischen Website liegt im Allgemeinen das Konzept zugrunde, dass sie mit RWD (Responsive Web Design) gestaltet wird. RWD ist ein Entwicklungsansatz, der die Browserimplementierung von CSS-Medienabfragen (CSS Media Queries) zum Ermitteln der Bildschirmgröße und der Ausrichtung nutzt und das Definieren von Haltepunkten (im Wesentlichen einer Pixelbreite) ermöglicht, um automatisch ein anderes CSS anzuwenden.

Das Ergebnis ist ansprechend. Wenn Sie die Größe des Browserfensters ändern und einen dieser visuellen Haltepunkte überschreiten, ändert sich das Erscheinungsbild der Website, um die verfügbaren Ressourcen besser nutzen zu können. Der Inhalt wird ohne weiteren Aufwand an jeden mobilen Browser im Vollbildmodus angepasst, der verwendet wird, um die Website zu besuchen. RWD ist geräteunabhängig und kann für eine beliebige Anzahl von Geräten und jeden Gerätetyp skaliert werden, der jetzt erhältlich ist oder in Zukunft verfügbar sein wird.

Wie ich bereits im meinem Artikel „Effective Image Handling in Responsive Web Sites“ (msdn.microsoft.com/magazine/dn857356) im Dezember 2014 erläutert habe, stellt die Geräteunabhängigkeit von RWD eine Stärke und gleichzeitig eine Schwäche dar. Wenn Ihre Kunden mit den Ergebnissen zufrieden sind, die über RWD erreicht werden können (hauptsächlich Leistung und Nutzbarkeit), haben Sie kein Problem. RWD ist Ihr Entwicklungsansatz. Punkt.

RWD funktioniert im Allgemeinen gut für Websites, die Inhalte anbieten und nicht viele Interaktionen oder assistentenähnliche Workflows erfordern. Je mehr Formulare verwendet werden, desto mehr Auswahl- und Eingabemöglichkeiten bestehen für den Benutzer. In diesem Fall eignet sich ein Einheitsansatz wie RWD weniger. Was bedeutet dies also?

Die Branche verlangt ein effektives Verfahren zum Bereitstellen geeigneter Inhalte für jedes Gerät, ohne verschiedene URLs verwenden zu müssen. RWD ist ein beliebter Ansatz, dieses Ziel zu erreichen. RWD ist jedoch strikt geräteunabhängig. Entwickler führen Geräteerkennung nur ungern aus. Sie haben es in schlechter Erinnerung, einer Website in mehreren Browsern das gleiche Erscheinungsbild zu verleihen, weil zu diesem Zweck eine Analyse der Benutzer-Agent-Zeichenfolge und deren Integration in unzählige Codezweige erforderlich war.

Geräteerkennung vor Funktionserkennung

Auch wenn Sie darauf warten, dass alle Browser die Plattform und ihre Funktionen über ein Standardobjektmodell offenlegen – das Analysieren der Benutzer-Agent-Zeichenfolge ist zurzeit das einzige Verfahren zum Ermitteln des Browsers, der tatsächlich Seiten von einer Website anfordert. Das Analysieren eines Benutzer-Agents stellt eine Herausforderung dar. Es stehen jedoch einige Tools zur Verfügung, die den Aufwand ein wenig verringern können.

Eines dieser Tools ist das Skript, das Sie von detectmobilebrowsers.com abrufen können. Dieses Skript verwendet reguläre Ausdrücke zum Überprüfen einer Liste bekannter Schlüsselwörter für mobile Geräte und beantwortet die Frage „Handelt es sich um ein mobiles Gerät?“. In diesem Kontext bedeutet „mobiles Gerät“ einfach, dass es sich nicht um einen Desktopbrowser handelt. Ein weiteres Tool ist Modernizr. Dieses Tool verfügt über eine lange Liste von Plug-Ins für die Benutzer-Agent-Analyse und das Erkennen von Touch-Ereignissen, um ein Tablet zu identifizieren.

Modernizr ist jedoch nicht das richtige Tool zum Erkennen von anderen Funktionen als JavaScript-erkennbaren Funktionen. Und ob es sich bei einem Browser um ein Tablet oder ein Smartphone handelt, kann mit JavaScript nicht erkannt werden. Sie können über JavaScript nur die Identität eines Browsers abfragen. Die meisten Browser (insbesondere mobile Browser) geben jedoch aus verschiedenen Gründen falsche Informationen zurück. Sie werden z. B. von Legacycode basierend auf Benutzer-Agents falsch erkannt.

Modernizr hält die Flagge der Funktionserkennung im Gegensatz zur Geräteerkennung hoch. Hier werden Äpfel mit Birnen verglichen. Es handelt sich um verschiedene Aspekte, die unterschiedlichen Zwecken dienen. Wenn Sie den Formfaktor des anfordernden Geräts ermitteln müssen, ist Funktionserkennung der falsche Weg. Einige Entwickler identifizieren Tablets und Smartphones über JavaScript, indem Sie mithilfe von Modernizr überprüfen, ob Touch-Ereignisse vorhanden sind. Dieses Verfahren wird jedoch zunehmend unzuverlässiger, da die Anzahl der touchfähigen Desktops und der Geräte wächst, die Sie als Desktops behandeln möchten.

Sie benötigen Expertenunterstützung bei der Analyse von Benutzer-Agents und der Rückgabe einfach zu nutzender Informationen. Expertenunterstützung bedeutet ein Framework, das kontinuierlich aktualisiert und um neue Geräte bei ihrer Markteinführung ergänzt wird. Außerdem ist anspruchsvolle Analyselogik erforderlich, die falsch positive Ergebnisse verarbeitet und statistische Analysen nutzt, um falsche Informationen zu eliminieren, die von einigen mobilen Browsern übergeben werden. Offen gesagt, ist dies alles viel Arbeit. Einige Unternehmen übernehmen diese Arbeit jedoch für Sie. Deren Tools werden als DDRs (Device Description Repositories) bezeichnet.

Der WURFL.JS-Endpunkt

Eine einfache Form der JavaScript-Geräteerkennung kann die Benutzeroberfläche in clientseitigen intensiven Webanwendungen optimieren, z. B in einer SPA (Single-Page Application). WURFL (wurfl.sourceforge.net) ist ein bekanntes DDR, das seit einigen Jahren als serverseitige Lösung verfügbar ist. Ich habe die Verwendung von WURFL in einer ASP.NET MVC-Anwendung in meinem Artikel „Erstellen von für Mobilgeräte optimierten Ansichten in ASP.NET MVC 4, Teil 2: Verwenden von WURFL“ (msdn.microsoft.com/magazine/dn342866.aspx) im August 2013 beschrieben.

Für serverseitiges WURFL fällt unabhängig davon eine Lizenzgebühr an, ob die Verwendung lokal oder der Zugriff auf das DDR in der Cloud erfolgt. Das WURFL-Team hat vor Kurzem einen kostenlosen HTTP-Endpunkt (WURFL.JS) bereitgestellt, den Sie von der Clientseite über JavaScript aufrufen können. Wenn Sie JavaScript-Geräteerkennung über den WURFL.JS-Endpunkt aktivieren möchten, müssen Sie dem HTML-Code einfach nur die folgende Zeile hinzufügen (in ASP.NET können Sie diese sogar auf der Masterseite oder in der Layoutdatei platzieren):

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

Die Ressource, auf die verwiesen wird („wurfl.js“) ist nicht einfach eine JavaScript-Standarddatei, die Sie herunterladen und lokal hosten oder in Ihre Cloud-Website hochladen können. Vielmehr handelt es sich um einen JavaScript-ähnlichen HTTP-Endpunkt, der ein JavaScript-Objekt in das Dokumentobjektmodell (Document Object Model, DOM) injiziert. Als Ergebnis enthält Ihr DOM Folgendes, sobald der Browser den Endpunkt aufgerufen hat:

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

Der Browser sendet die Benutzer-Agent-Zeichenfolge beim Ausführen der Anforderung. Unterstützt durch das serverseitige WURFL-Framework analysiert der Endpunkt die Zeichenfolge und ermittelt Schlüsselinformationen zum anfordernden Dienst. Diese Informationen werden dann in einem globalen Objekt namens WURFL (siehe Abbildung 1) in drei Eigenschaften formatiert. Interessant ist außerdem, dass WURFL.JS zuverlässig erkennen kann, ob Ihre Webseite aus der WebView-Komponente einer systemeigenen mobilen App angezeigt wird. Dies ist der Fall, wenn die Eigenschaft „form_factor“ die Angabe „App“ zurückgibt.

Abbildung 1 – Geräteinformationen, die WURFL.JS in die DOM-Seite injiziert

Eigenschaft	Beschreibung
complete_device_name	Enthält einen beschreibenden Namen für das erkannte Gerät, normalerweise den Hersteller und den Gerätenamen (z. B. „iPhone 5“).
form_factor	Enthält einige vordefinierte Zeichenfolgen. Beispiel: „Desktop“, „App“, „Tablet“, „Smartphone“, „Feature Phone“, „Smart-TV“, „Robot“, „Other non-Mobile“, „Other Mobile“.
is_mobile	Ein boolescher Wert, der angibt, ob das Gerät ein Desktop ist.

WURFL.JS greift in einem großen Ausmaß auf den Cache zurück, um eine schnelle Reaktion zu gewährleisten. In der Entwicklungsphase, können Sie den Cache deaktivieren, indem Sie der URL „debug=true“ hinzufügen. Wenn das Ereignis „DOM ready“ ausgelöst wird, können Sie das WURFL-Objekt auf sichere Weise zum Aktivieren oder Deaktivieren clientseitiger Funktionen oder zum Anfordern optionaler Daten für den Server verwenden.

WURFL.JS fügt RWD Leistungsfähigkeit hinzu

Angenommen, Sie verwenden eine Seite mit einem Video, das aufgrund von Leistungserwägungen auf Smartphones nicht wiedergegeben werden soll. Mit Standard-RWD können Sie solche Anpassungen nicht vornehmen. Wenn Sie den Videoplayer unter einem bestimmten Haltepunkt ausblenden, kann überhaupt keine Wiedergabe mehr erfolgen, wenn die Größe des Desktopbrowsers an ein sehr kleines Fenster angepasst wird. WURFL.JS in Kombination mit RWD behebt das Problem. Das folgende Beispiel zeigt dies:

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

Laden Sie die Seite im ersten Schritt, und gestalten Sie sie gemäß dem RWD-Layout. Verwenden Sie im nächsten Schritt WURFL zum Überprüfen des Formfaktors und Ausblenden des Videoplayers. Wenn die Größe eines Desktopbrowsers an die Größe eines Smartphones angepasst wird, können Benutzer weiterhin Videos wiedergeben. Dies gilt jedoch nicht, wenn es sich um ein echtes Smartphone handelt. Das folgende Beispiel zeigt eine noch bessere Form des oben genannten Codes:

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

In diesem Fall wird der Videoplayer in allen Fällen ausgeblendet. Dies gilt nur dann nicht, wenn das Gerät ein Desktop oder Tablet ist. Für WURFL.JS gibt es ein weiteres interessantes Szenario. Angenommen, Sie verwenden eine RWD-Website in der Produktion, für die z. B. alle Ansichten auf dem Server in einer ASP.NET MVC-Anwendung generiert werden.

Irgendwann erhalten Sie das Feedback, dass für Benutzer von Smartphones keine geeignete Benutzeroberfläche angezeigt wird. Sollten Sie in Betracht ziehen, für diese Benutzer eine ganz neue M-Website zu erstellen? Wenn Sie die serverseitigen Dienste von WURFL nutzen können, können Sie auf einfach Weise eine Ansichtumschaltung innerhalb der gleichen Website implementieren, wie ich in meinem Artikel aus August 2013 zeige.

Dieser Ansatz nutzt den größten Teil Ihrer bereits erfolgten Entwicklung. Abgesehen davon gibt es nicht viele andere Möglichkeiten, als eine separate Website zu erstellen und einen Umleitungsmechanismus zu implementieren, wie in meinem Artikel „Mobilisieren von vorhandenen Websites“ (msdn.microsoft.com/magazine/dn890366) aus Januar 2015 gezeigt wird. Damit die reguläre und die M-Website unter der gleichen URL angezeigt werden, muss auch in diesem Fall eine geeignete Geräteerkennung auf der Serverseite erfolgen.

Bei der Verwendung von WURFL.JS ergibt sich ein praktischer Nebeneffekt: Sie können Geräteinformationen aus dem WURFL-Objekt erfassen und an Google Analytics übergeben. Auf diese Weise erfahren Sie sofort, wie Benutzer Ihre Website besuchen und welches Gerät dabei am häufigsten eingesetzt wird. Wenn Sie ein Upgrade auf die neue Version von „analytics.js“ ausgeführt haben, benötigen Sie Folgendes:

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

Wenn Sie das klassische Google Analytics-Skript („ga.js“) verwenden, müssen Sie die folgende kleine Änderung implementieren:

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

Google Analytics verfügt über zahlreiche integrierte Funktionen zum Nachverfolgen von mobilem und Tabletdatenverkehr. Der mobile Datenverkehr berücksichtigt ebenfalls Tabletdatenverkehr und kann z. B. Smartphone- und Tabletdatenverkehr nicht sofort trennen. WURFL.JS fügt nützliche Informationen hinzu, die in Google Analytics ursprünglich fehlen. Sie können daher benutzerdefinierte Berichte erstellen, deren Schwerpunkt auf den Zahlen und nicht auf der Datenprojektion liegt. WURFL.JS ist jedoch nicht nur ein Datenanbieter. WURFL.JS arbeitet mit Google Analytics zusammen, kann jedoch auch mit anderen Analysetools verwendet werden.

Zusammenfassung

In vielen Fällen ist eine RWD-Website schwieriger (mit größerem Aufwand) zu implementieren als eine ASP.NET Web Forms-Standardwebsite. Fallen Sie nicht den Lockrufen von RWD zum Opfer. RWD ist eine effiziente Lösung für Desktops und High-End-Geräte, ist jedoch ggf. nicht geeignet, wenn die effektive Implementierung von Funktionen auf kleinen Geräten für die Geschäftszwecke wesentlich ist. RWD führt seine Geräteunabhängigkeit als Pluspunkt an. Dies bedeutet, dass RWD-Websites den gleichen Inhalt für ein in der Größe angepasstes Desktopbrowserfenster (480 x 360) und ein kleines Telefon im Vollbildmodus bereitstellen.

Die Hardware und die Verbindung kann sich in diesen beiden Fällen erheblich unterscheiden. Leistung ist objektiv gesehen ein wunder Punkt von RWD. Die Nachteile müssen jedoch nicht alle Websites auf die gleiche Weise betreffen. Leistungsprobleme betreffen hauptsächlich Dienste auf niedriger Ebene. Wenn mit diesen Geräten die Website nicht häufig besucht wird, können Sie RWD verwenden und müssen sich keine weiteren Gedanken machen.

Die Menge der bereitgestellten Daten und die Benutzererwartungen können sich jedoch bereits in der nahen Zukunft vergrößern. Die Darstellung wäre dann auf einer größeren Anzahl von Geräten nicht ausreichend, und im Idealfall wäre eine Ad-hoc-Ansicht erforderlich. In diesem Artikel habe ich eine einfache und fast unauffällige clientseitige Lösung zum Erkennen des verwendeten Geräts vorgestellt: WURFL.JS.

WURFL.JS ist ein Endpunkt, der Geräteinformationen in das DOM injiziert – insbesondere den Formfaktor. Anders gesagt, informiert Sie WURFL.JS, ob es sich bei dem Gerät um einen Desktop, ein Tablet, ein Smartphone, ein altes Mobiltelefon, eine Xbox oder sogar um eine systemeigene App handelt. Basierend auf diesen Informationen können Sie kleine Änderungen auf den Seiten vornehmen und sogar Analysetools mit Formfaktorinformationen versorgen.

Das Wissen, wie Ihre Website pro Formfaktor abschneidet, ist ein leistungsfähiger Indikator für ihren Erfolg und für die Bereiche, die optimiert werden müssen. Wenn Sie weitere Einzelheiten erfahren möchten, wie WURFL.JS mit Google Analytics verwendet wird, besuchen Sie bit.ly/1u0lpGB.

Dino Esposito ist Mitautor von „Microsoft .NET: Architecting Applications for the Enterprise" (Microsoft Press, 2014) und "Programming ASP.NET MVC 5" (Microsoft Press, 2014). Esposito ist Technical Evangelist für die Microsoft .NET Framework- und Android-Plattformen bei JetBrains und spricht häufig auf Branchenveranstaltungen weltweit. Auf software2cents.wordpress.com und auf Twitter unter twitter.com/despos lässt er uns wissen, welche Softwarevision er verfolgt.

Unser Dank gilt dem folgenden technischen Experten für die Durchsicht dieses Artikels: Jon Arne Saeteras