{"id":176,"date":"2007-08-02T17:57:08","date_gmt":"2007-08-02T15:57:08","guid":{"rendered":"http:\/\/ollmetzer\/?p=176"},"modified":"2010-05-28T23:48:37","modified_gmt":"2010-05-28T21:48:37","slug":"automatische-gerateerkennung","status":"publish","type":"post","link":"https:\/\/www.ollmetzer.com\/?p=176","title":{"rendered":"Automatische Ger\u00e4teerkennung"},"content":{"rendered":"

Ich wurde schon h\u00e4ufiger gefragt, wie ich es hinbekomme, da\u00df meine Webapplikationen (zumindest zzap<\/a> und fastfiction<\/a>) zwischen normalem Browser und Handy unterscheiden k\u00f6nnen und unterschiedliche, angepasste Inhalte ausliefern. Die Antwort lautet: mittels automatischer Ger\u00e4teerkennung.<\/p>\n

Leider gibt es nicht die eine<\/em> Methode, mit der man ganz einfach abfragen kann, welche Eigenschaften das Ger\u00e4t hat, sondern man mu\u00df sich einer Kombination unterschiedlicher Methoden bedienen. Die Methode, die ich f\u00fcr meine Projekte benutze ist mehrstufig. <\/p>\n

Bei der Konzeption definiere ich zun\u00e4chst die grundlegenden Ger\u00e4teklassen, die unterst\u00fctzt werden sollen. Jede dieser Ger\u00e4teklassen wird sp\u00e4ter mit speziell angepasstem Content beliefert. Typische Vertreter sind ‚web‘ (also normale Webseiten auf einem Computer), ‚wap1‘ (Alte WAP-Telefone, WML-basiert. Mittlerweile zu vernachl\u00e4ssigen), ‚wap2‘ (XHTML-basiert, farbig, von nahezu allen Handies der letzten 2 Jahre unterst\u00fctzt) ‚imode‘ (In Deutschland nicht sehr popul\u00e4r) und ‚pda‘ (Windows mobile, Palm, evtl. Symbian). In der Regel konzipiere ich nur noch f\u00fcr zwei Klassen, n\u00e4mlich ‚web‘ und ‚wap2‘. <\/p>\n

\n

Exkurs: Warum \u00fcberhaupt noch f\u00fcr WAP entwickeln?<\/b>
\nIch h\u00f6re immer h\u00e4ufiger, da\u00df WAP tot sei, weil die tollen neuen Handies doch alle schon „richtige“ Browser an Bord haben. Das mag f\u00fcr einige hochwertige Ger\u00e4te stimmen, z.B. f\u00fcr mein Nokia E61, aber erstens sind diese Ger\u00e4te noch nicht so zahlreich, zweitens fehlen noch immer wichtige Features, wie z.B. Flash-Unterst\u00fctzung (z.B. f\u00fcr Videos), drittens ist selbst UMTS f\u00fcr „fette“ HTML-Seiten zu langsam und viertens sind die Ein- und Ausgabem\u00f6glichkeiten prinzipbedingt extrem eingeschr\u00e4nkt.
\nDer wichtigste Punkt ist allerdings, da\u00df normale Internetseiten einfach nicht den Anforderungen f\u00fcr eine mobile Anwendung entsprechen. Sie m\u00fcssen schnell, \u00fcbersichtlich und einfach sein, und den mobilen Nutzungskontext ber\u00fccksichtigen (kurze Aufmerksamkeit, Ablenkung, etc.). Daher m\u00fcssen mobile Web\/Wapseiten auf das Wesentliche reduziert sein: Simple Navigationsstruktur, Content auf das Notwendigste reduziert, minimale Eingaben.
\nWenn aber ohnehin schon die ganze Sitestruktur f\u00fcr mobile Nutzung angepasst werden muss, kann man die Inhalte auch gleich so ausliefern, da\u00df sie auf mindestens 98% aller Mobiletelefone funktionieren.<\/p><\/blockquote>\n<\/div>\n

Meine Strategie der Ger\u00e4teerkennung zielt nun darauf ab, in der ersten Phase die Ger\u00e4teklasse zu ermitteln und danach zu versuchen, die Daten f\u00fcr eine verfeinerte Anpassung zu ermitteln. Es ist stets eine Kombination von Grundannahmen und dem Versuch anschlie\u00dfend genaueres zu ermitteln. Die erste Grundannahme ist, da\u00df der Client ein normaler Webbrowser ist. Dann wird im Useragent-String nach Hinweisen darauf gesucht, da\u00df es sich um ein Mobiltelefon oder PDA handelt. Wie man das schnell und sauber hinbekommen kann, zeigt Andy Moore in dem Artikel „PHP to detect mobile phones<\/a>„.
\nFalls ein Mobile-Client erkannt wurde, wird abschlie\u00dfend versucht, Details, wie Screengr\u00f6\u00dfe und unterst\u00fctzte Medienformate zu ermitteln. Diese Ermittlung kann recht aufw\u00e4ndig sein und sollte nur einmal zu Beginn einer Session gemacht werden.<\/p>\n

Wenn man dann wei\u00df, was f\u00fcr ein Ger\u00e4t man vor sich hat, kann man endlich mit der Erzeugung und Auslieferung des spezifischen Contents beginnen.<\/p>\n

Weiterf\u00fchrende Links:<\/strong><\/p>\n