App-Entwicklung mit HTML5
Matti Mäkitalo
- software
1 molily
Hi,
ich stehe gerade vor der Entscheidung, eine Applikation für Android zu entwickeln und bin mir nicht sicher, ob ich es mit HTML5 oder nativ als Android-App entwickeln sollte.
Im Zusammenhang mit dieser Frage schaute ich mir gerade den Talk zu diesem Thema von Google I/O an.
In diesem Zusammenhang habe ich mir (mal wieder) Gedanken gemacht, wie denn nun am sinnvollsten Webapplikationen aufgebaut sein sollten.
Ich differenziere mal zwei Möglichkeiten:
(a) die Seiten werden alle on-the-fly mit üblichen Techniken auf dem Server generiert und fertig an den Client übertragen. Ich gehe davon aus, dass hier komplett/weitgehend auf client-seitige Technologie abseits von HTML und CSS verzichtet werden kann (insbesondere kann man davon ausgehen, nicht von JavaScript abhängig zu sein).
(b) die Seiten liegen als statisches HTML vor, dynamische Inhalte (z.B. die Ergebnisse aus einer Datenabfrage) werden mit JavaScript in das Dokument eingefügt. Ich bezeichne dies mal dreist als die HTML5-Methode. Nicht-statische Inhalte würde ich per REST oder einem RPC-Weg per JavaScript übertragen und dann das Dokument aufbauen.
Ganz grob die Vor- und Nachteile der Methoden, wie ich sie derzeit sehe.
Mit der HTML5-Methode kann ich insbesondere durch das Manifest erreichen, dass sämtliche statischen Inhalte bereits auf dem Client vorhanden sind. Dies ist insbesondere dann wichtig, wenn die Verbindung zum Server nicht dauerhaft gewährleistet ist. Diese ist nur noch dann notwendig, wenn Informationen nachgeladen werden.
Mit REST+JSON gäbe es einen einfachen Weg, diese Informationen zu transportieren.
An serverseitiger Technologie hätte man "nur noch" reine Business-Logik.
Nachteil ist sicherlich, dass man vollkommen auf JavaScript angewiesen ist. Ich halte es nicht für vorstellbar, dass man als Fallback-Lösung für Anwender ohne JS auf Methode (a) zurückgreift, da sind die Vorteile der HTML5-Methode zu gering.
Mich persönlich reizt es, die HTML5-Methode einmal auszuprobieren.
Allerdings bin ich mir da ein wenig unsicher. Bei "alten" Projekten habe ich erlebt, dass eine Mischung der Dokumentgenerierung von serverseitiger und clientseitiger Technologie schwerer wartbar ist als reine serverseitige Lösungen, nichtsdestotrotz "musste" ich einige Male diesen Weg gehen (zugegebenermaßen aus Bequemlichkeit, denn der Weg, alle Informationen der Seite zu sichern, an den Server zu schicken und ein neues Dokument dort zu erstellen ist zwar fast immer möglich, aber IMHO manchmal eben mit Kanonen auf Spatzen geschossen, wenn man "nur" eine neue Zeile irgendwo einfügen will).
Mit der HTML5-Methode würde man den kompletten Gegenweg gehen: dynamische Seitenteile würden nur noch aus JavaScript rauskommen, vom Server kommt nichts dynamisches (außer die Funktionen der Web-Service).
Nun zu meinen Fragen:
Habt ihr euch mit einer solchen Frage mal beschäftigt? Habt ihr diese (für euch) beantworten können?
Ist der Weg, den ich als HTML5-Weg bezeichnet habe, überhaupt praktikabel? Habt ihr diesen vielleicht sogar mal irgendwo eingesetzt?
"Gängige Lehre" in diesem Forum ist "Unobtrusive JavaScript". Dies bezieht sich darauf, das Dokument selbst dann funktional zu halten, wenn JavaScript deaktiviert oder eingeschränkt ist. Ist es ein sinnvoller Weg, eine Web-Applikation (welche ja etwas anderes ist als ein "einfaches" Dokument) auf JavaScript aufzubauen, so daß diese ohne JS quasi unbenutzbar wird (**)?
*: mit nicht vorstellbar meine ich: es ist zwar technisch möglich, beide Methoden zu implementieren, halte es aber für unwahrscheinlich, dass man beides machen würde, da man doppelten Implementierungsaufwand hätte.
Obwohl insbesondere REST ja darauf ausgelegt ist, dies zu tun. Man könnte einfach anhand etwa des Accept-Headers unterscheiden, ob da jetzt ein Browser eine statische HTML-Seite haben will oder ob ihm die Inhalte etwa als JSON reichen, damit er diese client-seitig in einem selbstgewünschten Format darstellen kann.
**: diese Frage ist in meinem Fragekomplex eher akademischer Natur, da dies keine Applikation für die freie Wildbahn wird, sondern nur für einen eingeschränkten Anwenderkreis. Also liegt eine kontrollierte Umgebung vor.
Danke an alle, die sich durch meinen Text durchgewühlt haben :).
Bis die Tage,
Matti
Mich persönlich reizt es, die HTML5-Methode einmal auszuprobieren.
Allerdings bin ich mir da ein wenig unsicher. Bei "alten" Projekten habe ich erlebt, dass eine Mischung der Dokumentgenerierung von serverseitiger und clientseitiger Technologie schwerer wartbar ist als reine serverseitige Lösungen
Klar. Bei einer JavaScript-Apps sollte die Dokumentgenerierung clientseitig erfolgen. Da schreibst du deine View-Templates genauso wie auf der Serverseite. Höchstens die Syntax ist eine etwas andere. Mit dem Server kommunizierst du lediglich - wie du sagst - mit REST und JSON.
Mit der HTML5-Methode würde man den kompletten Gegenweg gehen: dynamische Seitenteile würden nur noch aus JavaScript rauskommen, vom Server kommt nichts dynamisches (außer die Funktionen der Web-Service).
Richtig.
Nun zu meinen Fragen:
Habt ihr euch mit einer solchen Frage mal beschäftigt? Habt ihr diese (für euch) beantworten können?
Mit JavaScript kommst du sehr schnell zu Ergebnissen, die auch auf verschiedenen Geräten funktionieren. Hier kannst du Frameworks wie Phonegap oder Appcelerator Titanium nutzen. Damit hast du teilweise auch Zugriff auf APIs, die sonst nur native Apps bekommen.
Java-Entwicklung für Android bietet dir eine bekannte Entwicklungsumgebung und -verfahren, dafür musst du dich in viele APIs einarbeiten und Erfahrung sammeln. Zudem hast du letztlich wenig Kompatibilität. Mit JavaScript kommst du wahrscheinlich schneller zu Ergebnissen, dafür musst du dir über die Struktur selbst Gedanken machen, sofern du nicht die eines Frameworks übernimmst (z.B. MVC). Vorhandenes HTML/CSS/JS-Wissen lässt sich sehr einfach übertragen, auch wenn es viele Kleinigkeiten zu beachten gibt.
Ist der Weg, den ich als HTML5-Weg bezeichnet habe, überhaupt praktikabel? Habt ihr diesen vielleicht sogar mal irgendwo eingesetzt?
In unserer Firma haben wir schon mehrere HTML5-Apps z.T. mit den genannten Tools geschrieben, aber auch native Android-Anwendungen. Viele native iPhone- und Android-Apps nutzen übrigens intern einen Webkit, um verschiedene Aufgaben zu lösen. Mischformen sind daher üblich.
"Gängige Lehre" in diesem Forum ist "Unobtrusive JavaScript". Dies bezieht sich darauf, das Dokument selbst dann funktional zu halten, wenn JavaScript deaktiviert oder eingeschränkt ist. Ist es ein sinnvoller Weg, eine Web-Applikation (welche ja etwas anderes ist als ein "einfaches" Dokument) auf JavaScript aufzubauen, so daß diese ohne JS quasi unbenutzbar wird (**)?
Für mobile Apps ergibt das auf jeden Fall Sinn. Vor allem wenn du die Offline-Web-Apps in native Apps wrappst, ist sichergestellt, dass JavaScript zur Verfügung steht. Wenn du zudem noch eine klassische Mobil-Website ohne JavaScript anbieten willst, kannst du das natürlich tun. Die wird natürlich nicht die Features und den Bedienkomfort der App bieten können, dafür ist sie mit jedem Mobilgerät mit jedem noch so miesen Browser und schlechter Verbindung nutzbar.
Es kommt halt darauf an, welche Funktionalität du bieten willst und ob dazu eine stinknormale (für Mobilbenutzung optimierte) Web-App nicht ausreicht. Die kann natürlich durchaus an den üblichen sinnvollen Stellen mit JavaScript und Ajax angereichert sein.
**: diese Frage ist in meinem Fragekomplex eher akademischer Natur, da dies keine Applikation für die freie Wildbahn wird, sondern nur für einen eingeschränkten Anwenderkreis. Also liegt eine kontrollierte Umgebung vor.
Mit HTML5-Apps bzw. JavaScript-Web-Apps kannst du durchaus einige Plattformen abdecken. Andererseits, wenn der Anwenderkreis mit Android-Geräten ausgestattet ist, so spricht nichts dagegen, sich auf diese Plattform einzuschießen. Android wird zunehmend Mainstream.
Es gibt also verschiedene Möglichkeiten, die alle ihren sinnvollen Anwendungsbereich haben. Um sich zu entscheiden, muss man die nötigen Features zusammentragen und abwägen, wie wichtig gewisse Zugriffsarten sind. D.h. was sind die Aufgaben der App und wie lassen diese sich benutzerfreundlich umsetzen, wie helfen dabei native APIs, Offline-Benutzung oder andererseits Online-Zugriff selbst bei fehlender JavaScript-Unterstützung.
Mathias