nicht angemeldet
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