In manchen Fällen ist es notwendig, mobile Devices anhand ihres User Agents zu erkennen (z.B. serverseitige Weiterleitung auf mobile Website). Im Folgenden ein Überblick über die User Agents der populärsten Devices (iOS, Android, BlackBerry, Kindle, Windows Phone).
Zur Erinnerung: Stellt ein Browser einen Request an einen Server, überträgt er seinen Namen („User Agent”) im HTTP-Header. Der Name wird in Form eines Strings übertragen, der z.B. über das Gerät, Betriebssystem und Browser inklusive entsprechender Version Auskunft gibt. Aus historischen Gründen sind auch einige Altlasten enthalten, so beginnen z.B. alle Browser mit Mozilla/5.0, nicht nur Firefox.
User Agent vs. Feature Detection
Grundsätzlich sollte man vorsichtig, einzelne Features und Funktionen anhand des User Agents (UA) auszuliefern. Das Problem hierbei ist, dass ständig neue User Agents im Umlauf sind und es schwierig ist, immer eine aktuelle und korrekte Zuordnung zu gewährleisten.
Sinnvoller ist stattdessen der Ansatz, über eine Feature Detection (z.B. mit der JavaScript-Bibliothek Modernizr) zu prüfen, was der Browser tatsächlich kann. Auch jQuery Mobile bietet eine JavaScript-Funktion gradeA, die zurückgibt, ob ein Device vollständig unterstützt wird und alle benötigten Funktion bietet.
Serverseitige Weiterleitung auf mobile Website
Nichtsdestotrotz gibt es Fälle, in denen man nicht am Auslesen des User Agents vorbeikommt. Hat man z.B. eine Website (www.domain..), die eine Startseite mit hoher Datenmenge besitzt, möchte man mobile Devices beim Aufrufen dieser direkt auf eine mobile Variante weiterleiten (m.domain..). Dies wäre mit einer Feature Detection in JavaScript nur bedingt sinnvoll, da das Device die „schwergewichtige” Startseite herunterladen muss.
Besser ist es, den User Agent serverseitig z.B. über den Apache oder PHP auszulesen und das Device direkt auf die mobile Website weiterzuleiten. So wird nur die mobile und optimierte Startseite mit geringer Datenmenge heruntergeladen, auf der man den Nutzer dann per Dialog noch fragen kann, ob er auch tatsächlich die mobile Website ansehen möchte.
Übersicht der wichtigsten User Agents
Im Folgenden eine Sammlung der wichtigsten User Agents und entsprechender Quellenangaben. Es handelt sich übrigens um Devices, die auch von jQuery Mobile unterstützt werden.
Außerdem habe ich jeweils einige Vorschläge für Regular Expressions hinzugefügt, um den User Agent abzufragen (am Beispiel einer PHP-Konstanten). Zum einen in einer recht einfachen Variante (die im Zweifel eher öfters greift), als auch ein exakteren Variante mit Versionsnummern.
iOS
Der User Agent unterscheidet sich bei den iOS-Geräten nur an der Stelle, die Auskunft über das Gerät (iPod, iPhone, iPad) gibt.
iPhone (Smartphone)
Mozilla/5.0 (iPhone; U; CPU iPhone OS 4_3_3 like Mac OS X; en-us) AppleWebKit/533.17.9 (KHTML, like Gecko) Version/5.0.2 Mobile/8J2 Safari/6533.18.5
Erwähneswert ist, dass bei Android-Smartphone immer die Kombination Android … Mobile vorkommt, während Android-Tablets
lediglich Android
(ohne Mobile) haben.
Mozilla/5.0 (Linux; U; Android 2.2.1; en-us; Nexus One Build/FRG83) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile
Safari/533.1
Mozilla/5.0 (compatible; MSIE 9.0; Windows Phone OS 7.5; Trident/5.0; IEMobile/9.0; <manufacturer>; <model> [;<operator])
/*
* Simple: Windows Phone
* Exact: Windows Phone 7 or higher
*/
const WindowsPhone_simple = "/Windows Phone/";
const WindowsPhone_exact = "/Windows Phone OS [7-9]/";
Mobile Devices: Viewport richtig einstellen
Zu den absoluten Grundlagen der mobilen Entwicklung gehört das Meta-Element viewport. Diese eine Zeile HTML-Code
sorgt für eine korrekte Skalierung der Website beim ersten Aufruf auf dem mobilen Gerät.
Die Browser der mobilen Devices gehen zuerst einmal davon aus, dass Websites nicht für mobile Endgeräte ausgelegt sind und die Website-
Breite die Display-Breite um einiges übersteigt. Der Browser-Viewport (Anzeigebereich) ist deshalb z.B. in Mobile Safari auf eine Breite von
980 Pixeln eingestellt, so dass die meisten Website komplett zu sehen sind. Logischerweise mit dem Nachteil, dass die Inhalte sehr klein und
Schriften nicht lesbar sind. Der Nutzer muss dementsprechend hineinzoomen.
Viewport für normale Websites einstellen
Die Einstellung des Viewport lässt sich sehr einfach über ein HTML-Element anpassen. Apple selbst schreibt, dass es sich dabei um die
wichtigste Einzelmaßnahme zur Optimierung für iOS handelt.
This is the single most important optimization that you can do for iOS—make sure your webpage looks good the first time it
is displayed on iOS.
Weicht die eigene Website von der oben genannten Standardbreite ab, so kann man den Viewport anpassen. Dadurch kann man dafür sorgen,
dass Inhalt und Anzeigebereich übereinstimmen. Bei schmaleren Layouts wird dadurch z.B. kein unnötiger Platz verschenkt, sondern die Website
in der möglichen Maximalgröße dargestellt.
Für die Änderung fügt man folgende Zeile in den HTML-Head ein, die dann von mobilen Geräten ausgewertet wird.
Handelt es sich um Website, die speziell für mobile Devices erstellt oder optimiert ist, geht man meist nicht den obigen Weg, eine fixe
Breite für den Viewport anzugeben (Ein iPhone hat z.B. im Hochformat eine Breite von 320px und im Querformat 480px). Dies hätte zur Folge, dass
im Hoch- und Querformat die gleichen Inhalte, lediglich in einem unterschiedlichen Zoomlevel, gezeigt würden.
Stattdessen wird deshalb üblicherweise folgende Formel verwendet: Breite des Viewports = Breite des Devices. Konkret bedeutet
dies: Das iPhone hat 320px Breite im Hochformat, weshalb genau 320px der Website gezeigt werden (1:1-Darstellung). Ebenso werden im Querformat
dann 480px gezeigt. Diese flexible Einstellung ist einerseits geräteunabhängig und ermöglicht es andererseits auch, im Querformat den gewonnen
Platz in der Breite sinnvoll zu nutzen.
initial-scale: Der Wert legt den anfänglichen Zoomgrad fest. 1.0 führt dazu, dass die Inhalte 1:1 dargestellt
werden, d.h. auf einem Screen mit 320px Breite füllt eine 320px-breite Grafik die komplette Breite aus (siehe auch Screenshot oben).
Dementsprechend führt z.B. 2.0 zu einer 2x-fachen Vergrößerung.
user-scalable: Mit diesem Attribut kann man definieren, ob der Nutzer auf der Seite zoomen kann (yes) oder
nicht (no).
minimum-scale und maximum-scale: Diese beiden Eigenschaft ermöglichen es, den Zoomgrad einzuschränken.
Setzt man z.B. die maximale Skalierung auf 2.0, kann der Inhalt maximal 2x-fach vergrößert werden.
Website-Bilder für das Retina Display optimieren
Erstellt man Websites und betrachtet sie zum ersten Mal z.B. auf einem iPhone 4/4s, stellt eventuell man fest: Manche
Bilder sind irgendwie nicht richtig scharf!
Die Ursache ist einfach erklärt: Im Falle der Apple-Geräte (ab iPhone 4) haben diese das sogenannte Retina-Display mit sehr hoher
Pixeldichte, die „normale” Bilder vergleichweise unscharf aussehen lässt, wenn man diese mit „optimierten” Bildern vergleicht.
Im Folgenden deshalb zwei Möglichkeiten, wie man recht einfach Bilder mit höherer Auflösung integrieren kann, die dann deutlich besser
aussehen.
Retina-Optimierung für das HTML-Element (img)
Das Prinzip, um ein Bild mithilfe des img-Elements für das hochauflösende Display zu verbessern, ist einfach: Man erstellt
die Bilddatei mit den doppelten Maßen (z.B. 248×220 statt 124×110), zeigt sie jedoch in der einfachen Größe (124×110) an.
Die vorhandenen Mehrinformationen im Bild werden auf einem hochauflösenden Display dargestellt, während z.B. am Rechner zwischen den
beiden Bilder kein Unterschied zu sehen ist.
Der Faktor 2 ergibt sich übrigens aus den Vorgaben des Herstellers und ist somit (eigentlich) speziell für Apple iPhone und iPad.
Der Nachteil liegt in der gestiegenen Dateigröße der Bilder. Je nach Bildinhalt und verwendetem Dateiformat muss hier letztlich
zwischen Ladezeit und Darstellungsqualität abgewogen werden. Bei Vektorgrafiken wie Icons, Firmenlogo, etc. lohnt sich dies in der
Regel, da die Größe nur unwesentlich zunimmt, die Grafiken jedoch deutlich besser aussehen.
Am Rande sei erwähnt, dass aufgrund dieser Limitierung nicht umsonst in letzter Zeit die Rufe nach einem neuen HTML-Element
(z.B. picture) laut werden, dass mehrere Bildquellen unterstützen soll. Dies würde die Möglichkeit bieten, sowohl für
unterschiedliche Pixeldichten als auch Darstellungsgrößen (Stichwort „Responsive Webdesign”) verschiedene Bilder zu hinterlegen.
Ausprobieren lässt sich die Darstellungsqualität mit folgendem
Beispiel (es handelt sich um die ersten beiden Logos).
Das normale Bild (cloud-sd) hat tatsächlich 124x110px, während cloud-hd 248x220px hat.
Etwas flexibler sind die Möglichkeiten, wenn man ein Bild als Hintergrund definiert. Hier kann man über
Media Queries gezielt das Display mit der höheren Pixeldicht ansprechen und diesem gezielt eigene Styles zuordnen.
Das folgende Code-Beispiel zeigt einen unoptimierten div mit der Klasse cloud-default und einen
div mit der Klasse cloud-for-retina für das Retina-Display. Zweiterer sieht auf normalen Displays gleich aus,
der CSS-Stil wird jedoch für Retina-Displays überschrieben und verweist auf ein hochauflösendes Bild,
was in einer besseren Darstellung resultiert.