HTML5 Mobile

Die wichtigsten mobilen User Agents

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

*
* Simple:	iPhone
* Exact:	iPhone with iOS 3_2/3_2_ oder higher
*/
const iPhone_simple = "/iPhone/";	
const iPhone_exact = "/iPhone.* (([3]_[2-9](_| ))|([4-9]_[0-9](_| )))/";

iPod (Smartphone)

Mozilla/5.0 (iPod; 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

iPad (Tablet)

Mozilla/5.0 (iPad; U; CPU 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

/*
* Simple:    iPad
* Exact:	iPad with iOS 3_2/3_2_ oder higher
*/
const iPad_simple = "/iPad/";	
const iPad_exact = "/iPad.* (([3]_[2-9](_| ))|([4-9]_[0-9](_| )))/";

Link: Apple Safari Web Content Guide

Android

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

/*
/*
* Simple:    Android
* Exact:	Android Smartphone
*/
const Android_exact = "/Android/";
const Android_exact = "/Android.*Mobile/";

Link: Best Practices for Web Apps

BlackBerry

BlackBerry 6 and 7 (Smartphone)

Mozilla/5.0 (BlackBerry; U; BlackBerry AAAA; en-US) AppleWebKit/534.11+ (KHTML, like Gecko) Version/X.X.X.X Mobile Safari/534.11+

/*
* Simple:    BlackBerry
* Exact:	BlackBerry 6 or higher 
*/
const BlackBerry_simple = "/BlackBerry/";	
const BlackBerry_exact = "/BlackBerry.*Version\/[6-9]\./";

PlayBook (Tablet)

Mozilla/5.0 (PlayBook; U; RIM Tablet OS 1.0.0; en-US) AppleWebKit/534.8+ (KHTML, like Gecko) Version/0.0.1 Safari/534.8+


/*
* Simple:    PlayBook
* Exact:	PlayBook with OS 1.0 or greater
*/
const PlayBook_simple = "/PlayBook/";	
const PlayBook_exact = "/PlayBook.*OS [1-9]\./";

Link: How to detect the BlackBerry Browser

Kindle

Kindle (Tablet)

Mozilla/5.0 (Linux; U; en-US) AppleWebKit/528.5+ (KHTML, like Gecko, Safari/528.5+) Version/4.0 Kindle/3.0 (screen 600×800; rotate)

/*
* Simple:    Kindle
* Exact:	Kindle 3 or higher
*/
const Kindle_simple = "/Kindle/";	
const Kindle_exact = "/Kindle\/[3-9]/";

Kindle Fire (Tablet)

Mozilla/5.0 (Linux; U; Android 2.3.4; en-us; Kindle Fire Build/GINGERBREAD) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1



const KindleFire_simple = "/Kindle Fire/";

Link: The User Agent String of Kindle Fire Revealed

Opera Mobile

Opera Mobile

Opera/9.80 ($OS; Opera Mobi/$BUILD_NUMBER; U; $LANGUAGE) Presto/$PRESTO_VERSION Version/$VERSION

Link: Opera’s User Agent String

Windows Phone

IE9 on Mango

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.

Startansicht von apple.com auf mobilen Device (links) und gezoomte Ausschnitt mit lesbarer Schrift (rechts)

Für die Änderung fügt man folgende Zeile in den HTML-Head ein, die dann von mobilen Geräten ausgewertet wird.

<!DOCTYPE html>
<head>
    <meta name="viewport" content="width=1024" />
</head>
<body>
</body>

Viewport für mobile Websites anpassen

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.

Vergleich: Ansicht auf mobilem Device mit Meta-Element im Quellcode (links; width=device-width) und ohne (rechts)

An dieser Stelle sei kurz auf einen iOS-Bug hingewiesen, der manchen beim Ausprobieren und Einstellen des Viewports verwirren könnte: Skalierungs­fehler beim Drehen ins Querformat

Viewport-Einstellungen

Das Meta-Element für den Viewport besitzt neben der Breite weitere Eigenschaften, die komma-separiert aufgelistet werden.

<meta name="viewport" content="width=device-width, initial-scale=1.0, user-scalable=no">
  • 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.

Abfotografiert: Deutliche Unterschiede zwischen dem normalen Icon (links) und der optimierte Version (rechts)

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.

<img width="124" height="110"  src="cloud-sd.png" />
<img width="124" height="110"  src="cloud-hd.png" />

Retina-Optimierung für Hintergrundbilder (CSS)

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.

<style> 
.cloud-default, .cloud-for-retina {                       
    width: 124px;
	height: 110px;
	background: url(cloud-sd.png);
	display: inline-block;
}
@media only screen and (-webkit-min-device-pixel-ratio: 2) {
	.cloud-for-retina {
		background: url(cloud-hd.png); 
		background-size: 124px 110px;
	}
}
</style>     
[...]
<div class="cloud-default">  
</div>
<div class="cloud-for-retina">  
</div>

Deprecated: Directive 'allow_url_include' is deprecated in Unknown on line 0