Mobilitätsnachweis

PHP in Googles Android
Kommentare

Android ist zweifelsohne auf dem Durchmarsch. Nach aktuellem Wissen und Einschätzung unter Marktanalysten wird sich die Verbreitung in den kommenden Jahren nicht nur stabilisieren, Android wird sich zum Marktführer mobiler Betriebssysteme entwickeln. Grund genug zu prüfen, wie man PHP darauf zum Laufen bringt.

Android zählt zu den Erfolgsgeschichten, die Google mit einem Blick auf sein breites Produktportfolio zu erzählen hat. Zu verdanken ist dieser anhaltende, wachsende Erfolg maßgeblich der Open Handset Alliance, die Google Ende 2007 – zwei Jahre nach dem Zukauf des Startups Android Inc. und ein Dreivierteljahr nach Vorstellung des ersten iPhones – mit einer ganzen Reihe von Unternehmen wie HTC, Motorola und Samsung geschmiedet hat. Denn spätestens seit Apple die Kombination aus moderner Hardware, komfortablem Betriebssystem und überwältigendem Angebot an Apps zum Erfolg geführt hat, weiß auch die Konkurrenz, dass man ohne überzeugendes Gesamtpaket schnell im Mobilmarkt an Boden verliert. Und wenn man den Software-Stack für seine Smartphones, der einem die kritische Masse von Anhängern und Entwicklern sichert, umsonst bekommt, umso besser! Seit der Gründung ist die Alliance stetig gewachsen, nicht nur mit Hardwareherstellern, es finden sich ebenso prominente Namen wie eBay, Accenture, Vodafone oder Broadcom auf der Liste der Unterstützer. Obwohl Android ursprünglich in C und Java geschrieben ist, äußert sich seine Vielseitigkeit und Offenheit unter anderem auch darin, dass sich mittlerweile eine große Anzahl von Programmiersprachen zur Implementierung von Zusatzprogrammen einsetzen lässt. Unter den Zusatzprogrammen sind freilich nicht diejenigen Apps zu verstehen, die sich aus dem Android Market herunterladen lassen. Die bestehen aus Java- oder C-Quellcode. Allerdings verfügt Android über einen experimentellen Scripting Layer, der die Entwicklung in JavaScript, Perl, Python oder auf der Shell ermöglicht – oder eben PHP. Man kann diesen Scripting Layer von der Funktion her mit einem Webserver vergleichen. Skripte, die darin installiert sind, werden zum Aufrufzeitpunkt vom jeweiligen Interpreter verarbeitet und erlauben die Interaktion mit dem Anwender. Anders als im Web ähnelt die Abarbeitung aber eher einem Desktopprogramm. Es ist nämlich nicht so, dass ein Skript einmal von Anfang bis Ende durchläuft und dessen Ausgabe im Browser dargestellt wird. Stattdessen verfügen die Skripte zumeist über eine allumspannende Endlosschleife, in der unter anderem Maskenfolgen und Interaktionsmöglichkeiten definiert werden. PHP-GTK lässt grüßen.
Webserver für Android Selbstverständlich lässt sich eine neue Umgebung so lange anpassen, bis sie dem Altbekannten ähnlich sieht. Und in der Tat gibt es auch Webserver für Android; iJetty ist der bekannteste Vertreter und ein Ableger des Java-Webservers Jetty. Über Umwege bekommt man dort scheinbar auch PHP in Form von Webapps zum Laufen. Das allerdings erscheint als zu großer Umweg angesichts der Tatsache, dass die Integration von PHP auch mit nativen Mitteln einfacher vonstatten geht.
Auf den folgenden Seiten lernen Sie PHP for Android kennen, mit dem sich beliebiger PHP-Code auf Android-Geräten ausführen lässt. Dazu ist jedoch vorher ein Exkurs in den bereits angesprochenen Scripting Layer for Android (landläufig abgekürzt als SL4A) notwendig. Das ist allerdings nicht der erste Schritt: Zuallererst kümmern wir uns um eine Laufzeitumgebung, denn trotz der Verbreitung von Android ist nicht vorauszusetzen, dass jeder Leser ein solches Endgerät im Zugriff hat.

Laufzeitumgebung

Als Testsystem muss Ihr Android Smartphone bzw. Tablet herhalten. Wer noch kein Android-Gerät sein Eigen nennt oder wer sein Gerät nicht dem offensichtlichen Risiko eines Softwareproblems durch experimentelle Software aussetzen will, muss sich zur Entwicklung von PHP-Anwendungen mit einem Emulator zufriedengeben, den Google selbst online – und natürlich kostenfrei – für unterschiedliche Betriebssysteme zur Verfügung stellt. Anders als Linux oder Mac User haben die Windows-Nutzer noch die Wahl zwischen einem Installer und einer konfigurationslosen Zip-Version. In allen Varianten ist die Installation ein Kinderspiel. Der auf QEMU basierende Emulator ist Teil eines Software Development Kits, das darüber hinaus auch ein Plug-in für die Entwicklungsumgebung Eclipse beinhaltet. Im Weiteren konzentrieren wir uns allerdings auf den Emulator bzw. den so genannten „SDK Manager“. Darin erzeugen und konfigurieren Sie virtuelle Geräte, basierend auf unterschiedlichen Versionen des Android-API – angefangen bei Version 3 (Android 1.5) bis derzeit Version 12 (Android 3.1). Der SDK Manager prüft bei jedem Start, ob neue API-Versionen verfügbar sind und installiert sie lokal, sodass Sie als Entwickler immer auf dem neuesten Stand sind. Um ein virtuelles Android-Gerät zu erstellen, bedarf es lediglich der Angabe der API-Version und der Größe der eingebundenen SD-Karte. Weitere Einstellungen wie die Größe des Arbeitsspeichers oder ob Kamera, GPS etc. aktiviert sein sollen, sind optional. Ohne manuelle Angabe arbeitet der Emulator mit Standardwerten. Gestartet wird eine Emulation aus dem SDK Manager heraus und öffnet sich in einem neuen Fenster. Abhängig von der Version ist die Fenstergröße: Ein Android 3 kann schon einmal den gesamten Laptop-Monitor einnehmen. Ein Android 2.x hingegen ist von Haus aus sehr klein, bringt dafür aber eine eigene Softwaretastatur und BACK- bzw. HOME-Buttons mit. Die Fenstergröße lässt sich übrigens beim Start einstellen. Dabei passen 7 Inch (d. h. die Größe des ersten Samsung Galaxy Tab) bequem auf einen Laptopmonitor. Einige Boot-Zeit später ist das Android bereit zum Einsatz.
Nicht täuschen lassen Grundsätzlich zwingt der Plattformwechsel vom Personal Computer zum Handy/Tablet erst einmal zum Umdenken. Während Ihr PC unter dem Schreibtisch mit hoher Wahrscheinlichkeit auf einer x86-Architektur basiert, dominiert die alternative ARM- (Advanced RISC Machine) Architektur die Welt der Handhelds, Smartphones und Taschenrechner, in der es auf stromsparende Rechenleistung ankommt. Wie aber nicht anders zu erwarten, wildert jeder in des anderen Garten: Ubuntu gibt es in einer ARM-Version, Windows will sich mit der kommenden Version 8 für ARM-basierte Systeme öffnen und gerüchteweise plant Apple ähnliche Schritte. Anders herum gibt es auch eine Portierung von Android für x86 (derzeit für Android 2.2). Android für ARM auf einer x86-Plattform zu emulieren, bedeutet zwangsläufig ein ARM-System vorzutäuschen. Jeder ARM-spezifische Prozessorschritt innerhalb des Emulators wird auf das System der Hostplattform umgerechnet. Das erzeugt einen durchgängigen Rechenaufwand, der zu Lasten der Emulation geht. Anders ausgedrückt: Android ist im SDK enttäuschend langsam – speziell mit Honeycomb. Ein geringes Maß an Linderung schafft es, der Emulation mehr Speicher zuzugestehen und innerhalb von Android nicht benötigte Features wie Fensteranimationen abzuschalten.

Scripting Layer for Android

Abb. 1

Abb. 1

Den Einsatz diverser Programmiersprachen ermöglicht der so genannte Scripting Layer for Android – ehemals Android Scripting Environment (ASE). Die Open-Source-Software wird als Google Project veröffentlicht und erlaubt den Zugriff auf Systemkomponenten wie die Kamera, den GPS-Empfänger, natürlich das Telefon und Kontakte im Adressbuch. Im Auslieferungszustand lassen sich Shell und JavaScript-Programme über SL4A ausführen. Die Unterstützung neuer Skriptsprachen wird mit der manuellen Installation des jeweiligen Interpreters hinzugefügt. Das ist, als müsse man das PHP Package erst einmal in seinem Webserver nachinstallieren. Auf seiner Projektwebseite weist das SL4A-Projekt verschiedene Interpreter zum Download aus, PHP ist nicht darunter. Wir werden nach der Installation des Scripting Layers also eine fremde Quelle bemühen müssen. Zuerst einmal lassen wir den Browser das aktuelle SL4A-Paket herunterladen und führen die Downloaddatei danach aus. Die Software installiert sich danach im Handumdrehen selbst – der Bestätigungsdialog ist in Abbildung 1 abgebildet. Die Applikation findet sich danach im App-Menü. Skripte sind von Haus aus nicht installiert.
Abb. 2

Abb. 1

SL4A ist ein Wrapper, der Befehle einer installierten Skriptsprache – genauer gesagt des dazugehörigen Interpreters – entgegennimmt und sie an das native Android-API weiterreicht. Die Kommunikation zwischen Skriptsprache und SL4A nutzt das JSON-Format und setzt eine RPC-Schnittstelle voraus, die in der Skriptsprache selbst geschrieben ist. Explizit bedeutet dies, dass der PHP Interpreter eine eigens definierte Klasse mitbringen muss, die in jedem Skript einzubinden ist (Abb. 2). Der SL4A Serverprozess nimmt die Anfragen entgegen und bedient damit das Android Java Facade API. In Konsequenz bedeutet dies, dass der Interpreter keine genaue Kenntnis über die Android eigene Java-Implementierung benötigt, geschweige denn eine Programmiersprachen übergreifende Bridge zur Verfügung stellen muss – nur der Vollständigkeit halber: PHP besitzt sehr wohl eine Möglichkeit, direkt mit Java zu kommunizieren, entweder in einer Servlet-Umgebung oder über eine Extension.

PHP for Android

Alles, was uns an diesem Punkt noch zum Glück fehlt, sind der PHP Interpreter für SL4A und ein paar Beispiele. Der Interpreter findet sich unter www.phpforandroid.net, die Quellcodes liegen wiederum im Fundus der Google-Projekte. Allerdings gehören diese Projekte nicht direkt zusammen. Die bisherigen Versionen von PHP for Android wurden von dem spanischen Internetdienstleister IronTec entwickelt, der hierzulande weitestgehend unbekannt ist. PHP for Android lässt sich genauso einfach installieren wie der Scripting Layer. Die Applikation entpuppt sich beim ersten Start als reiner Installer/Uninstaller und bringt keine eigenen Features mit. Der Zauber passiert nach der Einrichtung in SL4A, wohingegen Sie die PHP for Android App maximal ein zweites Mal starten – zur Deinstallation. Über die App, für dessen Icon ein spanischer Designer dem Android-Roboter eine Elefantenmaske übergestülpt hat, laden Sie alle nötigen Ressourcen herunter, um PHP im Zusammenhang mit SL4A einzusetzen. Darunter fallen
  • der PHP Interpreter – unter dem Namen php_r3.zip
  • Extras (php_extras_r3.zip) – die die php.ini und die Klasse Android.php umfassen
  • Skripte (php_scripts_r3.php) – Beispiele für den Einstieg in PHP unter SL4A
Die Installation bringt ein nacktes PHP 5.3.3 zum Vorschein, d. h. neben den Standardbibliotheken wie der Reflection API oder SPL sind nur sehr wenige Extensions installiert: lediglich JSON, Sockets und OpenSSL sind es laut der Release Notes. Dafür finden sich unter SL4A eine Handvoll Beispiele. Wenn Sie genauso intuitiv wie ich das „Hello World“-Skript starten, lassen Sie sich nicht von der Meldung entmutigen, Anweisungen seien veraltet („deprecated“). Das liegt daran, dass die Beispiele schon etwas länger nicht mehr aktualisiert worden sind. Der Lauffähigkeit tut das keinen Abbruch. Viel wichtiger ist, dass die Klasse Android nun an ihrem Platz ist und per include() eingebunden werden kann. Das Gerüst der grundlegenden Klasse Android.php ist im ersten Listing zu sehen. Die zentrale Methoden rpc() übernimmt sowohl die Kommunikation über den geöffneten Socket als auch die Konvertierung der vorab übergebenen Parameter in einen gültigen JSON-String bzw. der Dekodierung der zurückgelieferten Daten. Die rpc() wird dank der magischen Methode __call() jedes Mal ausgeführt, wenn eine nichtexistente Methode der Klasse aufgerufen wird. Das erspart die Implementierung eines vollständigen Wrappers in PHP, der im Laufe der Zeit für jede neue Version des Android-API anzupassen wäre.
rpc($name, $args);
}
}
?>
Es ist auf die fehlende Aussagekraft der PHP-for-Android-Webseite zurückzuführen, dass man von diesem Punkt an auf sich allein gestellt ist. Im Internet finden sich einige Beispiele, wie sich mit SL4A arbeiten lässt, zum Thema PHP for Android sucht man vielerorts vergebens. Zum Glück funktionieren die meisten Beispiele anderer Programmiersprachen auch nach der 1:1-Portierung auf PHP. Der folgende Abschnitt enthält trotz allem eine Reihe von Tipps und soll verdeutlichen, wie sich am schnellsten entwickeln lässt.

Bitte Beipackzettel beachten

Abb. 3

Abb. 3

Auch bei SL4A gilt: Die API-Referenz ist dein Freund. Sie listet sämtliche Befehle auf, inklusive Signatur aller obligatorischen und optionalen Parameter. Dabei bezieht sie sich immer auf die aktuellste Version. Auf der Webseite von PHP for Android wird auch eine Version des Scripting Layers zum Download angeboten, dieser zeigt jedoch auf eine alte Version. Alternativ gibt es den API-Browser, der sich im Optionsmenü der SL4A-Applikation versteckt. Auch hier gibt es eine vollständige Liste aller API-Methoden, allerdings beschränkt sie sich auf die aktuell unterstützten. Schade ist, dass sich sowohl die Onlinereferenz als auch der API-Browser auf die bloße Auflistung der Befehle beschränkt und keine Beispiele mitliefern. Als Gegenbeispiel sei hier die PHP-Dokumentation erwähnt, die in nahezu allen Fällen Beispiele und Userkommentare mit Code beinhaltet. Ebenso wenig mitteilsam ist Android, wenn es um Fehler in den PHP-Skripten geht. Diese werden zwar mitunter als Notification angezeigt (Abb. 3), zumeist bricht das Programm aber wortlos ab. Für das Debugging kann man sich zum einen damit behelfen, einen Dialog zu öffnen und darin die Ausgabe einer Variablen per var_export($variable, true) anzuzeigen. Zum anderen führt man das Programm im Kommandozeilenmodus aus. Mitunter werden darin Fehlermeldungen angezeigt. Zusätzlich zur Dokumentation und zum Debugging macht schon die Eingabe neuer Programme das Entwickeln schwer. In vielen Fällen ist die physische Tastatur bei einem Smartphone dem Touchscreen mit Softwaretastatur gewichen. Außerdem entbehrt der Editiermodus des Scripting Layers jeglichen gewohnten Komforts wie etwa dem Syntax Highlighting. Um außerdem nicht auf vier (Handy) bis zehn (Tablet) Zoll entwickeln zu müssen, kann man sich zu Nutze machen, dass in der Android-Version von PHP die Option allow_url_include auf ON steht. Damit ist es möglich, seine Entwicklung wie gewohnt am Desktop-PC oder Laptop zu tätigen und das Ergebnis von folgendem Grundgerüst unter Android einbinden zu lassen. Entscheidet man sich für dieses Vorgehen, bietet sich als Host wahlweise eine Domain im Internet an, auf die man seine Skripte während der Entwicklung zügig und komfortabel kopieren kann, oder aber im Fall einer Android-Emulation auch der lokale Webserver. Darauf kann das emulierte Android direkt zugreifen. Allerdings ist zu beachten, dass sich die Adresse 127.0.0.1 nicht verwenden lässt. Stattdessen findet sich der Webserver des (Windows/Linux/Mac-)Hostsystems unter der IP 10.0.2.2. Die Datei datei.php.txt kann dann auf $droid und damit das gesamte Android-API aufbauen. Damit sie nicht vom Webserver auf dem Hostsystem interpretiert wird, hat sie den Namenszusatz .txt bekommen. Mit diesem Grundgerüst steht Ihnen also die Welt der Android-Entwicklung offen. Ein ausführliches Beispiel finden Sie auf der Heft-CD (oder schicken Sie eine Anfrage an redaktion@phpmagazin.de). Darin wird gezeigt, wie sich das Adressbuch auslesen lässt, um Kontakte bei Google, Facebook und Twitter nachzuschlagen. Aus technischer Sicht sind unterschiedliche Methoden enthalten, Informationen mit eingebauten UI-Komponenten anzuzeigen und die Aktionen des Anwenders zu verarbeiten.

Auf bekannten Pfaden – HTML als UI

Zusätzlich zu den eingebauten Android-User-Interface-Komponenten, die in der Regel über pickXXX oder dialogCreateXXX initialisiert werden, lässt sich auch HTML zur Oberflächengestaltung einsetzen. Diese so genannten WebViews werden in einem browserähnlichen HTML Interpreter angezeigt, der selbstverständlich auch JavaScript und Cascading Stylesheets versteht. Auf Android UI zu verzichten und stattdessen auf WebViews zu setzen, kann unterschiedliche Beweggründe haben. Dass man bislang immer mit HTML als Frontend gearbeitet hat, ist einer der möglichen Gründe – aber vielleicht nicht der ausschlaggebende. Interessant ist das Anwendungsszenario zuallererst dann, wenn eine bestehende Webanwendung auf Android migriert werden soll. Im Idealfall, falls also bereits eine mobile Version der eigenen Webseite besteht, kommt man mit minimalem Anpassungsaufwand davon. Das gilt aber auch nur dann, wenn die Logik weiterhin im Internet liegen soll und man auf die Features des eigenen Handys verzichten kann – beispielsweise das lokale Adressbuch oder die eingebaute Kamera. Will man diese jedoch nutzen, muss man sich wiederum etwas umgewöhnen. Die WebView wird von einem SL4A-Skript aus aufgerufen. Das Skript – anders gesagt: die Logik – läuft im Hintergrund weiter, während das HTML-Frontend angezeigt wird. Und natürlich können diese beiden Schichten miteinander kommunizieren. Hier werden Ereignisse (Custom Events) benutzt, wie sie beispielsweise aus JavaScript bekannt sind. Und in der Tat kommt JavaScript auch zum Einsatz, um das Event vom Frontend aus loszutreten (Listing 2).
var droid = new Android();
var ping = function() { droid.postEvent("customEvent"); };

<button>ping</button>

Die WebView wird ebenfalls im Kontext von SL4A ausgeführt. Das bedeutet in erster Konsequenz, dass mit der Klasse Android der Funktionsumfang des API zur Verfügung steht. Damit die Methode postEvent() auch ihr Ziel findet, muss die WebView von einem (PHP-)Skript im SL4A angestoßen werden, das auch auf dieses Event wartet. In Listing 3 sieht man, wie die Ausführung des Skripts so lange geblockt wird, bis das gewünschte Ereignis eintritt. Der Parameter $url bezeichnet dabei die Lokalität der WebView.
webViewShow($url);
while(true){
$droid->eventWaitFor('customEvent');
$droid->exit();
exit();
}
?>

Fazit

Der Gesamteindruck von PHP unter Android hinterlässt nach erster Begeisterung eines PHP-Enthusiasten einen faden Beigeschmack. Auf der Habenseite ist zu verbuchen, dass mit dem aktuellen Release ein funktionstüchtiges PHP 5.3.3 zur Verfügung steht. Die Version ist mit dem aktuellen Scripting Layer für Android-Release R4 lauffähig, was will man eigentlich mehr? Nun, Beispielskripte ohne „Deprecated“-Meldungen, eine Dokumentation, die über Stichworte hinausgeht und eine Perspektive für Weiterentwicklung des Projekts wären zu wünschen. Diese Dinge sind eindeutig unter Soll einzusortieren. Das letzte Release stammt aus Oktober 2010 und die Roadmap endet bei kritischem Hinsehen einen Monat danach. Alles in allem macht PHP for Android den Eindruck, als sei es ein Testballon gewesen. Es bleibt zu hoffen, dass der Eindruck täuscht. Bis dahin drängt sich freilich die blasphemische Frage auf, wozu man PHP unter Android benötigt. Zur Lauffähigkeit bedarf es eines Scripting Layers; der zweifache Installationsaufwand rüttelt an der Benutzerfreundlichkeit für wenig technikaffine Anwender, zumal SL4A nicht standardmäßig unter Android installiert und selbst noch als Alphaversion einzustufen ist. Zudem ist die Kommunikation eines Skripts mit dem API unabhängig von der Programmiersprache. JavaScript ist beispielsweise im SL4A vorinstalliert und spätestens dann ein Muss, sobald man WebViews und Events einsetzt. Die Migration bestehender Anwendungen vom Web auf Android ist ein valider Anwendungsfall. Dafür erweist sich die gezeigte Lösung als wirklich freizügig: Die Logik kann ohne viele Änderungen übernommen werden, solange sie nicht auf spezielle Extensions zurückgreift. Als Datenquelle kommt dank allow_url_include neben dem Inhalt des Smartphones auch das Internet hinzu und bezüglich der Darstellung kann man sich zwischen HTML in Form von WebViews oder Android-UI-Komponenten entscheiden.
Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -