Für die meisten Mobil-Entwickler ist das eine der ersten Fragen, wenn die Entwicklung einer Anwendung ansteht. Ehrlich gesagt, gibt es keine richtige Antwort auf die Frage. Wenn man es auf ein paar entscheidene Kriterien herunterbrechen würde, sähe die Liste vermutlich wie folgt aus:
Aufgrund der bereits gemachten Erfahrungen kommen die meisten hier genannten Beispiele aus dem Bereich der Mobil-Entwicklung mit Android.
Betriebssystem-/hardwarespezifische Funktionsanforderungen
HTML5 und native Mobilbrowser entwickeln sich schnell auf den Punkt zu, an dem sich die Lücke zwischen dem, was aus einem Browser und dem, was aus einer nativen Applikation heraus möglich ist, schließt. Allerdings gibt es immer noch ein bedeutendes Feature, das beide unterscheidet: Push-Benachrichtigungen.
Das Implementieren von Cloud-to-Device Messaging (C2DM) für Android erweist sich als unglaublich praktisch für die Kommunikation zwischen Server und Gerät. Man kann damit ein Gerät „nach Hause“ telefonieren lassen, einen Prozess auf dem Gerät starten oder sogar eine Kurznachricht schicken. Die einzige Funktion in HTML5, die dem nahe kommt, ist WebSocket. Doch wenn der Benutzer den Browser beendet, ist der Kommunikationskanal unterbrochen.
Ein anderer Grund, warum man möglicherweise beschließt, eine Rich App zu entwickeln, ist, dass ein lange laufender Dienst benötigt wird, der im Hintergrund ausgeführt wird. Ein Hintergrunddienst wird möglicherweise für unbegrenzte Standortverfolgung, Geräteüberwachung oder lang dauernde Berechnungen und Prozesse benötigt.
Eines der Merkmale, die man als Entwickler am meisten an Android schätzen dürfte, ist die Art und Weise, in der Intents konzipiert sind. Intents ermöglichen es einem nicht nur, andere Anwendungen in die eigene zu integrieren, sondern sie integrieren auch die eigene Anwendung in andere. Ein gutes Beispiel für Letzteres wäre das Starten eines Strichcode-Scanners eines Drittanbieters aus der eigenen App heraus mit der anschließenden Ausgabe eines UPC-Codes. Was die letztere Situation angeht, ermöglichen es einem viele Apps, Inhalte für andere Apps „freizugeben“, man kann daher erreichen, dass die eigene App in der Liste von Auswahlmöglichkeiten erscheint (beispielsweise einen Ort aus Google Maps „freigeben“). Diese einzigartige Interoperabilität ist definitiv ein sehr starkes Argument dafür, eine native Android-App statt einer Web App zu entwickeln.
Entwicklungsbudget und -zeitplan
Es gibt wohl nicht viele Entwickler, die nicht zustimmen, wenn man behauptet, dass mobile Web-Entwicklung billiger ist als die Entwicklung einer Rich App. Die Tatsache, dass man nur einmal entwickeln muss und automatisch jede internetfähige Plattform ansprechen kann, ist ein ziemlich starkes Argument. Wenn man dies etwa mit der separaten Entwicklung einer App für Android, iPhone und Blackberry vergleicht, ist der Unterschied leicht zu erkennen.
Was den Entwicklungszeitplan angeht, muss man wohl nicht mehr viel hinzufügen. Es geht natürlich schneller, eine Web App zu entwickeln als mehrere Rich Apps.
Zielpublikum
Auch bei Android-Fans, die iOS völlig vernachlässigen, dauert es nicht allzu lange, bis sie erkennen, dass man nicht einfach eines der beiden großen Handy-Betriebssysteme vernachlässigen kann, wenn man es mit dem „Vollzeit-Mobil-Entwickler“ wirklich ernst meint, ganz gleich, wie sehr man Apples Philosophie ablehnt oder an Androids Erfolg glaubt.
Also liegt es für den Android-Verfechter nahe, eine Mobil-Website für die iOS nutzenden Freunde zu entwickeln. Das Ergebnis ist in der Tat ganz beeindruckend, da mittels Webkit-Transforms und etwas Javascript zum Erstellen unabhängig voneinander scrollender Bereiche (was im mobilem Internet nicht ganz leicht ist) eine fast identische Version der Android-App für das Internet entstanden ist.
Zuerst freuen sich die Kollegen, dass sie nun eine App nutzen können, um deren Portierung sie schon seit Monaten gebeten hatten. Aber bald ebbt die Begeisterung über die Neuentwicklung wieder ab und es stellt sich heraus, dass die Version für das mobile Internet einfach nicht so elegant ist, wie es dageben eine native Rich App ist. Auch wenn sich ein Lesezeichen auf dem Startbildschirm erstellen lässt, um ihr den Anschein einer nativen App zu geben, sind die Unterschiede immer noch zu erkennbar (namentlich das Fehlen von Push-Benachrichtigungen, was durch das Versenden von E-Mails umgangen werden kann).
Fazit
Das hier sind nur ein paar Argumente für beide Lösungen. Natürlich spielen sehr viel mehr Faktoren bei dieser Entscheidung eine Rolle und es gibt keine richtige oder falsche Antwort. Die hier erwähnten Einschätzungen mögen auch durchaus subjektiv sein. Aber bei dem Tempo, mit dem sich die Mobiltechnologie-Branche entwickelt, kann alles, was hier ausgeführt wurde, morgen auch durchaus schon Makulatur sein.
Stand heute ist es wohl am besten, sowohl mobile Web Apps als auch Rich Apps ins Auge zu fassen, wenn alle entscheidenen Faktoren dies zulassen. Sicher muss man sich mit diesem Thematik im Laufe der Zeit immer wieder auseinandersetzen. Eric Schmidt sagte: „HTML5 ist der Weg, mit dem künftig fast alle Anwendungen entwickelt werden, auch solche für Handys.“ Ein Thema jedenfalls, das man im Auge behalten sollte.
Ergänzend gibt es ein Video auf YouTube mit einer interessanten Gegenüberstellung von Android und HTML5 aus Google I/O.
Der Cybersecurity Report von Hornetsecurity stuft 2,3 Prozent der Inhalte gar als bösartig ein. Die…
Die Hintermänner haben es auf Zugangsdaten zu Microsoft Azure abgesehen. Die Kampagne ist bis mindestens…
Cloud-Plattform für elektronische Beschaffungsprozesse mit automatisierter Abwicklung elektronischer Rechnungen.
Mindestens eine Schwachstelle erlaubt eine Remotecodeausführung. Dem Entdecker zahlt Google eine besonders hohe Belohnung von…
Nur rund die Hälfte schaltet während der Feiertage komplett vom Job ab. Die anderen sind…
Security-Experten von Check Point sind einer neuen Angriffsart auf die Spur gekommen, die E-Mail-Schutzmaßnahmen umgehen…