Direkt zum Hauptbereich

Device-Weiche in PHP

Anforderungen für Device-Weichen

Je mehr Anforderungen an die Unterstützung von unterschiedlichen Devices kommen, desto öfter steht man vor der Frage, wie die verschiedenen Ausgabegeräte zwecks unterschiedliche Behandlung auf einer Seite unterschieden werden können, um dann z.B. jeweils eine Weiterleitung auf unterschiedliche Zielseiten vorzunehmen welche das entsprechende Device unterstützen, also eine sogenannte Device-Weiche oder Browser-Weiche.

Klassische Use Cases sind hier:

  • Je nach Device die "klassische" Website oder die mobile Site anzeigen
  • Eine Landing Page erstellen, welche unterschiedliche mobile Devices zu unterschiedlichen Zielseiten (z.B. Subdomains) verzweigt
  • Eine Redirect-Verteilerseite, welche mobile Devices in die verschiedenen Stores für einen mobile App Download weiterleitet
Das letztgenannte Beispiel möchte ich hier einmal exemplarisch demonstrieren. Man stelle sich folgendes Szenario vor:

Demo-Szenario

Im Rahmen einer Web-Anwendung werden native mobile Apps für iOS un Android Devices angeboten oder ansnsten auf eine mobile oder klassische Website weitergeleitet. Wir nehmen als Beispiel Wikipedia und wollen folgende Regeln abbilden
  • Wenn Device ein iOS Device ist, leite um in den App-Store
  • Ist es ein Android Device, leite um auf den Google Marketplace
  • Ist es ein sonstiges mobile Device, leite um auf die mobile Website
  • Alle anderen sollen auf der klassischen Website landen
Zentral wird eine URL bereitgestellt, welche die hereinkommenden Anfragen nach den aufrufenden Device-Typen erkennt und dann an die entsprechenden Ziel-URLs weiterleitet.

Lösungsansatz

Zu Umsetzung wird in diesem Beispiel PHP herangezogen, selbstverständlich lässt sich das Konzept auch in anderen Programmiersprachen analog umsetzen.

Das Prinzip ist recht einfach: Aus dem Http-Call des Aufrufs werden bestimmte Request-Header Variablen extrahiert und dann analysiert. Je nachdem welche Variablen existieren oder mit Inhalten belegt sind kann man dann Regeln für eine Weiterleitung oder andere Aktion definieren. Dabei können allgemeine Request-Header Variablen wie:
  • HTTP_USER_AGENT
  • HTTP_ACCEPT
  • HTTP_PROFILE
genutzt werden oder auch hersteller- und carrierspezifische wie:
  • HTTP_X_NOKIA_IPADDRESS
  • HTTP_X_VODAFONE_3GPDPCONTEXT
  • HTTP_X_HUAWEI_USERID
  • HTTP_X_ORANGE_ID
Je nachdem welche Regeln dabei positiv oder negativ ausgewertet werden können kann dann in der Programmierlogik eine serverseitige Weiterleitung (301 oder 302-Redirect) erstellt werden.

(Für die Regeln sei hier auf den Quelltext von Mobile_Detect (s.u.) verwiesen).

Umsetzung

Framework Mobile_Detect

Für PHP gibt es ein sehr schönes und schlankes Open Source Framework, welches die oben stehende Logik in einer Klasse gekapselt bereits abbildet und sich einfach in eigene Applikationen einbinden lässt. Es kann hier bezogen werden:


Mobile_Detect bietet verschiedene Klassen Methoden, um vom anfragenden Device den Typ (
mobile, Tablet) das Betriebssystem (z.B. iOS, Android) oder den benutzten Browser (z.B. Safari, Chrome, Opera) zu erfragen.

Dazu sind nur zwei Zeilen notwendig. Beispiel um zu erfahren, ob ein anfragendes Gerät ein Apple iOS Device ist:


// detect device
$detect = new Mobile_Detect();
// is iOS?
if ($detect->isiOS())
echo "Welcome iOS Device";

Landing Page

Nun wird eine Landing Page in PHP erstellt, die genau diese Funktion übernimmt:

  • Evaluieren der Devices
  • Rückmeldung eines 302 redirects, bei dem als Location, also Ziel-URL die entsprechende Zieladresse zum App-Download bzw. zu den Websites gesetzt wird.
Der Quelltext der Device-Weiche gestaltet sich also wie folgt:



 <?php  
 $iOSURL = "itunes.apple.com/de/app/wikipedia-mobile/id324715238";  

 $androidURL = "play.google.com/store/apps/details?id=org.wikipedia";  

 $mobileURL = "en.m.wikipedia.org";$desktopURL = "en.wikipedia.org";  

 // include Mobile_Detect class  
 require_once 'Mobile_Detect.php';  

 // set 302 header variable to notify that the sites was found  
 header($http["HTTP/1.1 302 Found"]);  

 // detect device  
 $detect = new Mobile_Detect();  

 // redirect to AppStor if iOS  

 if ($detect->isiOS())  
  header( 'Location: http://'.$iOSURL );  
 elseif ($detect->isAndroidOS())  
  header('Location: http://'.$androidURL);  
 elseif ($detect->isMobile())  
  header('Location: http://'.$mobileURL);  
 else header( 'Location: http://'.$desktopURL);  

 exit;  
 ?>

Die ersten Zeilen definieren Variablen für die Redirect-Ziele. Danach wird im Response-Header die Information für einen 302 Redirect gesetzt. Die folgenden Zeilen sind bereit bekannt. Die Mobile_Detect Klasse wird instantiiert, es werden die Informationen zu dem aufrufenden Device abgefragt und die Redirect-Ziele gesetzt.

Eine Live-Demo existiert hier.

Die Quelltexte können (inkl. Mobile_Detect Klasse) hier heruntergeladen werden.

Es gibt verschiedene Online Emulatoren, mit denen man die Weiche testen kann, z.B. mobilephoneemulator.com

Oftmals erfolgt die Publizierung von App-Downloads mit der Verbreitung von QR-Codes über klassische Median wie Print. Wer das in unserem Beispiel einmal ausprobieren möchte kann das hier tun:



(QR-Codes lassen sich auf verschiedenen Websites wie dieser mittlerweile leicht Online erstellen).


Referenzen:

Kommentare

Kommentar veröffentlichen

Beliebte Posts aus diesem Blog

CQRS - Command Query Responsibility Segregation

A lot of information systems have been built with a data manipulation focus in mind. Often CRUD (create, read, update delete) operations built on top of a predefined relational data model are the first functionalities that are implemented and lay out as a foundation for the rest of an application. This is mainly because when we think about information systems we have a mental model of some record structure where we can create new records, read records, update existing records, and delete records. This had been learned throughout the last decade of data centric and transaction oriented IT systems. This approach often leads to shortcomings when it comes to query and analyze the system's data. Classical layered architecture This is where CQRS comes into the game. CQRS stands for Command Query Responsibility Segregation and has been first described by Greg Young and later on by Martin Fowler. This architectural pattern calls for dividing the software architecture into two parts
Kommentar veröffentlichen
Mehr anzeigen

Create a Bearer token in Scala

Bearer tokens are a standard which is used in OAuth 2.0 . Although there have been discussions if the security mechanisms are significantly weaker than the use of using signatures as many implementations of OAuth 1.0 did (see http://tools.ietf.org/html/draft-ietf-oauth-v2-http-mac-00 ), bearer tokens are part of the OAuth 2.0 specification and therefore widely adopted in nearly all implementations. The syntax of Bearer tokens is specified in RFC6750 ( http://http://tools.ietf.org/html/rfc6750 ) This is a lean utils object to create specification compliant Bearers in Scala using the java.security.SecureRandom implementation as a randomizer. The standard generate function returns a token of 32 byte length. A second polymorphic functions allows for the generation of a token of individual size. import scala.util._ import java.security.SecureRandom /* * Generates a Bearer Token with the length of 32 characters according to the * specification RFC6750 (http://http://tools.ietf
Kommentar veröffentlichen
Mehr anzeigen

Using Chrome as Web Browser in Eclipse on Mac OS X

Today a short one: If you want to use Google Chrome as the default web browser in Eclipse on Mac OS X, just do the following (of course after you installed Chrome). In Eclipse open the "Preferences" dialog Select "General ->Web Browser" Choose "New" Enter the information in the dialog as shown in the screenshot below. Click "OK" Check the button next to the newly created entry "Google Chrome" Click "Apply" Now Chrome will be taken when you select a URL to be opened in Eclipse.
Kommentar veröffentlichen
Mehr anzeigen