Statt App

Es müssen nicht immer Apps sein. Mit HTML, CSS und JavaScript kann man Webanwendungen schreiben, die auf mobilen Geräten wie native Anwendungen daherkommen.

In Pocket speichern vorlesen Druckansicht 6 Kommentare lesen
Lesezeit: 7 Min.
Von
  • Kai König

In der letzten Ausgabe der Internet-Infos ging es um die Entwicklung nativer Anwendungen, sogenannter „Apps“ – üblicherweise in Sprachen wie C++, Java oder .Net programmiert. Daneben stellt das weite Feld der Webtechniken verschiedene Möglichkeiten zur Entwicklung mobiler Anwendungen bereit.

Wer sich noch an die zwischen 1994 und 1999 gängigen Mobilgeräte erinnern kann, weiß, dass der mobile Zugriff aufs Internet damals bei Weitem nicht selbstverständlich war. Eine Onlinerecherche deutet auf Nokias 1996 erschienenen Communicator 9000 als das erste Handy mit einem Internet-Browser, man findet allerdings widersprüchliche Aussagen zur Darstellungsqualität von HTML-Inhalten innerhalb dieser Umgebung. Wer Interesse an einer Zeitreise zurück zum Internet auf dem Communicator 9000 hat, kann diese mit der Bedienungsanleitung (Kapitel 7) starten.

Vor dem Einzug des Web auf mobilen Endgeräten gab es WAP. Das Wireless Application Protocol wurde Ende des letzten Jahrtausends auf mehr und mehr sogenannten Consumer-Handys zur Verfügung gestellt. Für Programmierer war in diesem Zusammenhang WAE (Wireless Application Environment) interessant, das WML (Wireless Markup Language) als Sprache zur Deklaration der Inhalte nutzte, die über WAP-Browser erreichbar waren. In der WAP-Version 2 wurde sie durch ein mobiles Profil von XHTML ersetzt. Tutorials zu WAP und WML finden sich nach wie vor im Internet, jedoch werden sie aufgrund der immer geringer werdenden Verbreitung von WAP kaum mehr aktualisiert.

In Europa hatte WAP einen eher schweren Stand und mit überhöhten Preisen für mobilen Netzzugriff zu kämpfen. Dagegen ist das Protokoll in Japan nach wie vor eine regelmäßig genutzte Technik auf sogenannten „Feature-Phones“ und steht im Wettbewerb mit NTTDoCoMos iMode. Weithin unbekannt ist, dass selbst moderne Endgeräte wie Android oder das iPhone nach wie vor WAP nutzen – die Übertragung von MMS-Nachrichten basiert in der Regel darauf. Eine ausführliche Erklärung der MMS-Architektur findet man bei DAFU.

Ähnlich wie im Fall der nativen Anwendungen für die neuen Gadgets war die Initialzündung des mobilen Web das iPhone. In diesem speziellen Fall lässt sich sogar guten Gewissens sagen, dass der Erfolg des drahtlosen Web zu großen Teilen Apple zuzuschreiben ist. Die Tatsache, dass die erste iPhone-Version Entwicklern keine Möglichkeiten bot, Apps mithilfe eines nativen SDK für iOS zu entwickeln, hat das mobile Web deutlich belebt. Als Alternativen blieben nur Jailbreaks oder das Erstellen von Webanwendungen im Browser, die über die Datenverbindung des Geräts betrieben wurden.

Infolgedessen entstanden zunächst CSS-Frameworks und -Vorlagen, die darauf abzielten, Webanwendungen im Safari-Browser so darzustellen, als handele es sich um eine lokale iOS-Anwendung. Es wurden also Komponenten der iOS-Bedienoberfläche in Aussehen und Verhalten in CSS und JavaScript im Browser emuliert.

Einer der großen Vorteile mobiler Webanwendungen ist das einfache Deployment, da die Auslieferung schlichtweg über den Browser erfolgt. Entwickler müssen sich daher nicht mit Regeln für betriebssystemspezifische App-Stores beschäftigen und die eigentliche Anwendung nur einmal entwickeln, um sie Nutzern verschiedener Plattformen wie iOS, Android oder Symbian zur Verfügung zu stellen.

Auf den ersten Blick scheint diese Vorgehensweise jedoch zu großen Einschränkungen zu führen, da Entwickler mobiler Webanwendungen nicht auf die typischen Eigenschaften von Mobilgeräten wie die gegenwärtige GPS-Position, den lokalen Datenspeicher, den Beschleunigungsmesser et cetera zugreifen können. Der Schein trügt jedoch, denn es gibt mehrere Ansätze zur Überwindung dieser Hürden.

Bei der ersten Option handelt es sich um die Nutzung von WebKit-Eigenschaften und standardisierten W3C-APIs. WebKit ist eine unter offener Lizenz (LGPL und BSD) verfügbare Umgebung zur Darstellung von HTML und zum Ausführen von JavaScript. Browser wie Apples Safari, Googles Chrome und die HTML-Engine von Adobes AIR-Laufzeitumgebung basieren darauf. Außerdem ist Webkit die Basis der HTML-Browser auf Nokias mit Symbian bestückten s60-Mobiltelefonen sowie der Android-Browser. Google hat kürzlich angekündigt, die bislang noch nicht vollständige Portierung von WebKit für Android in Richtung Chrome und Chromium weiterzuentwickeln. WebKit unterstützt verschiedene, vom W3C empfohlene oder standardisierte HTML5-APIs, sodass sich Webanwendungen entwickeln lassen, die offline betrieben werden können oder Zugriff auf die HTML5-Geolocation-APIs haben.

In diesem Zusammenhang dürfen natürlich auch die gegenwärtigen Platzhirsche der JavaScript-Frameworks für die Mobilentwicklung nicht fehlen: jQuery Mobile (s. den Artikel auf S. 124), Sencha Touch sowie jqTouch. Jedes der Frameworks hat sicherlich je nach Anwendungszweck verschiedene Vor- und Nachteile. Das Web bietet viele objektive und subjektive Vergleichsartikel, die bei der Meinungsbildung unterstützen können (bei campino2k oder WinfWiki).

Für Webentwickler mit der Zielplattform iOS bietet sich Apples hauseigenes Dokument zu Safari als Lektüre an. Das Buch enthält die wahrscheinlich beste und detaillierteste Auflistung von Apples Vision zum Thema mobile Webentwicklung.

Noch besseren Zugang zu Eigenschaften der Geräte bieten Systeme wie PhoneGap oder Appcelerator Titanium. Bei beiden handelt es sich um Umgebungen für die Cross-Plattform-Entwicklung von nativen Anwendungen mit Webtechniken wie HTML, CSS und JavaScript für mobile Endgeräte.

Oberflächlich betrachtet scheinen beide Produkte ähnliche Eigenschaften zu bieten. Sie unterstützen das Erzeugen und Betreiben von Apps für die gängigen Betriebssysteme auf Mobilgeräten. Darüber hinaus stellen sie dem Entwickler (je nach Zielplattform) verschiedene Geräte-Eigenschaften über produktspezifische APIs zur Verfügung.

Beide Systeme unterscheiden sich jedoch deutlich in der Art und Weise, wie sie ihr Endprodukt erzeugen. PhoneGap bündelt einfach alle Quelldateien mit einer gerätespezifischen Komponente zur Darstellung von HTML-Inhalten; bei iOS handelt es sich letztlich um einen UIWebView. Die fertige Anwendung kann man somit (zugegebenermaßen hier nur oberflächlich beschrieben) als eine Art HTML-Browser inklusive mitgeliefertem und voreingestelltem Inhalt betrachten. PhoneGap ist unter der MIT Open-Source-Lizenz verfügbar.

Appcelerator geht mit Titanium einen anderen Weg und übersetzt den vom Entwickler erzeugten JavaScript-Quellcode mit einem Cross-Compiler direkt in eine native Anwendung für die jeweilige Zielplattform. Titanium hat deutlich mehr Elemente eines umfassenden JavaScript-Frameworks inklusive einer Bibliothek von UI-Komponenten. Aufgrund dieser Tatsache ist es oftmals einfacher, Anwendungen zu erzeugen, die optisch und hinsichtlich ihres Verhaltens an native Anwendungen herankommen. Titanium unterstützt nur Android und iOS als mobile Plattformen, wohingegen PhoneGap direkt die sechs wichtigsten Handy-Betriebssysteme bedienen kann.

Auch für Flash-Liebhaber hält die mobile Webentwicklung Zugänge bereit. Apple erlaubt kein Flash im iOS-Browser, auf Android ist das jedoch problemlos möglich. Darüber hinaus kann man sowohl mit Adobes Flash als auch mit dem offenen Flex-Framework (beziehungsweise dem kommerziellen Flash Builder) native Anwendungen für iOS und Android erstellen. Adobe geht dafür auf iOS den Weg der Cross-Kompilierung und nutzt AIR zum Verteilen von Flash-basierten nativen Anwendungen auf Android.

Rapid development tool to create mobile web apps
YouMinds Web App Composer ist ein neues Werkzeug (BETA) zum Erstellen von Web Anwendungen für mobile Geräte. Anwendungen lassen sich optional direkt aus Sitemaps/Mindmaps erstellen. Der Composer exportiert fertige HTML Projekte die direkt auf einen Webserver deployed werden können.
Zugeschickt von: Bernd Seeberger (ka)