Web-App Entwicklung mit HTML5: Der Große Praxis-Guide

html5-web-app-entwicklung-tutorialHTML5 ist noch kein offizieller Standard und doch zu recht das Schlagwort schlechthin für aktuelle Internettechnologie: er ist - in Verbindung mit JavaScript - die erste und einzige Programmiersprache, mit der Inhalte nur einmal programmiert und danach auf jedem beliebigen Endgeärt mit einem Browser dargestellt werden können. Dabei spielt es keine Rolle, ob das Endgerät mit Windows, iOS, Android oder einem anderen exotischen Betriebssystem läuft. Es macht auch keinen (großen) Unterschied, ob der User die Inhalte per Smartphone, Tablet oder Desktop-PC abruft: mit HTML5 haben wir das Handwerkszeug, alles zu bedienen. 

Die segensreichen Möglichkeiten des Zweiergespannes HTML5 + JS erschöpfen sich dabei aber nicht in der Darstellung von statischem Content. Der aktuelle JS Standard (siehe ECMAScript 5 auf Wikipedia) ermöglicht aus eigener Kraft, ohne die Einbettung in nativen Code, eine Vielzahl von hardwarespezifischen Interaktionen, wie etwa das Auslesen der GPS-Daten oder Beschleunigungssensoren.

Wir stellen daher ausgehend von einer Basisimplementation einer Web-App dar, welche Möglichkeiten, aber auch welche Grenzen sich beim Einsatz von HTML5 zur Entwicklung von Web-Apps auftun.

 

Inhaltsverzeichnis Web-App Entwicklung

Vorüberlegungen zur Web-App

Bevor wir mit dem Programmieren beginnen, sollten wir uns einen kurzen Überblick verschaffen, was die App können soll und wie wir die gewünschten Funktionalitäten umsetzen. Dabei sind insbesondere zu überlegen, ob und wie wir Daten austauschen möchten und ob die App offline funktionieren soll, oder nicht.

Datenaustausch mit einer Web-App

In den meisten Fällen besteht der Charme einer App darin, Daten von einem Server zu empfangen und darzustellen. Ob wir eine "Lovoo" oder eine Quiz-App mit Highscoreliste programmieren möchten: immer benötigen wir dafür Daten vom Server, mit denen der User interagieren kann. Grundsätzlich gibt es dabei zwei Möglichkeiten, Daten zu übertragen und anzuzeigen: eine synchrone und eine asynchrone. 

Synchron bedeutet in diesem Falle, dass der User Eingaben macht und diese an den Server schickt. Der Server verarbeitet die Daten und antwortet mit einem Ergebnis an den User. Dabei wird die Seite komplett neu geladen. 

Flüssiger ist die asynchrone Datenübertragung, bei der die Eingaben des Benutzers ohne das Neuladen der Seite an den Server übertragen und die Serverantwort direkt in die HTML-Struktur der Seite eingespeist wird. Diese Programmiertechnik nennent man AJAX (asynchronous JavaScript and XML) und neben der deutlich besseren Usability ermöglicht sich durch die Entkoppelung des HTML Grundgerüsts und der Datenquelle eine flexiblere Programmierung. So kann man die Daten aus diversen Quellen anzapfen und es macht dabei keinen Unterschied, ob der Server mit PHP oder einer anderen Serversprache arbeitet und welches Datenformat er zurücksendet.

 

Offline-Fähigkeit von Web Apps

Grundsätzlich können auch Web Apps offline gespeichert und ohne Verbindung zum Internet genutzt werden. Der User muss lediglich eine entsprechend optimierte Website besuchen und das sogennannte Cache Manifest sorgt dafür, dass der Browser angwiesen wird, alle spezifizierten Files lokal zu speichern und zu behalten.

Dazu wird im ersten Schritt der HTML Datei im HTML Tag mitgeteilt, dass es ein Cache Manifest gibt und wo dies zu finden ist:

<html manifest="ManifestName.manifest" ...>

Der nächste Schritt ist, sicherzustellen, dass der Browser den Content-Type ".manifest" versteht. Dazu muss in der .htacces der folgende Eintrag ergänzt werden:

AddType text/cache-manifest .manifest

Schließlich legen wir das eigentliche Cache Manifest an: ein File mit einem beliebigen Namen und der Dateiendung .manifest. Im Manifest werden nach der obligatorischen Einleitung "CACHE MANIFEST" alle Files genannt, die lokal gecached werden sollen, z.B.:

CACHE MANIFEST
index.html
styles.css
js/script.js
img/logo.png

Schon funktioniert die App auch offline und das sogar relativ zuverlässig: Die Anweisung der W3C an die Browserentwickler lautet, diese Daten so lange als möglich auf dem Endgerät vorzuhalten. In der Praxis bleiben diese Daten also, bis der Speicher des Engeräts zur Neige geht und das Betriebssystem diese überschreibt, oder der User ausdrücklich alle lokalen Files des Browsers löscht.

Insgesamt stehen für diese Daten maximal 5MB zur Verfügung, die je nach Browser in Rücksprache mit dem Benutzer auf bis zu 10MB erweitert werden können.

Wer mehr Informationen dazu sucht, findet diese hier: Cache Manifest bei selfhtml5

Nachdem wir erörtert haben, wie man Apps offline verfügbar macht, wollen wir noch aufzeigen, was dabei planerisch zu beachten ist. Grundsätzlich ist es immer wünschenswert, alle Daten, die lokal gespeichert werden können, auch lokal zu halten. Diese Daten stehen bei einem Verbindungsabbruch zur Verfügung und ermöglichen je nach Programm-Design der Web-App auch dann eine Funktionsfähigkeit wenn "das Netz" weg ist. Neben den statischen HTML, CSS und JavaScript Dateien muss dabei wie im vorherigen Kapitel auch überlegt werden, wie die Datenverbindung zum Server konzipiert sein muss, dass diese, falls nötig auch zeitweise unterbrochen werden kann.

In einigen Szenarien muss die Web App unbedingt auch dann funktionieren, wenn keine Netzwerkverbindung besteht. Beispiele sind etwa Apps, die im Außendienst verwendet werden sollen und vor Ort, etwa auf der Baustelle oder bei dem Kunden, Daten aufnehmen sollen. Da nicht gewährleistet werden kann, dass an jedem Ort ein Funknetz zur Verfüng steht, ist es in solchen Fällen eine Voraussetzung, alle vor Ort notwendigen Daten zu laden und lokal zu speichern, sowie vom Nutzer eingegebene Daten für die spätere Synchronisierung mit dem Server aufzuzeichnen. Wie die lokale Speicherung von Serverdaten technisch umgesetzt wird, besprechen wir weiter unten im Kapitel localStorage.

Fazit: Da die Programmierung des Daten-Management wesenlicht von den Anforderungen an die Offline-Verfügbarkeit abhängt, müssen diese unbedingt im ersten Schritt der App Entwicklung definiert werden.

 

Meta Tags für Web-Apps

Viewport

html5-web-app-viewport-meta-tagBei der Entwicklung von Web-Apps ist vielleicht der erste und wichtigste Schritt das Konzept des Viewports zu verstehen. Da die Displays von Smartphones deutlich kleiner sind als Monitore, wird deren Anzeigebereich im Vergleich zur Normalgröße einer Website als Viewport, also eine Art Bildausschnitt aus dem größeren Ganzen angesehen. Man kann sich den Viewport als Bilderrahmen in Smartphonegröße auf dem Monitor vorstellen. 

Standardmäßig skalieren mobile Browser Websites so, dass die ganze Website zusammengeschrumpft wird, um auf das schmale Display zu passen. In der Analogie mit dem Bilderrahmen bewegen wir uns zusammen mit unserem Rahmen rückwärts vom Monitor weg, bis das ganze Bild in unseren Rahmen passt. 

Die Inhalte werden entsprechend unleserlich klein dargestellt (siehe Bild von zendoo  links).

Das Viewport Meta-Tag verhindert dies, indem man die Seitenbreite auf die tatsächliche Breite des Displays festlegt:

<meta name="viewport" content="width=device-width, initial-scale=1.0" />

Damit sagt man dem Browser: lass den Bilderrahmen auf dem Monitor liegen. In einer nicht optimierten Seite bewirkt dies zwar, dass der User nur einen Teil des Bildes sieht, diesen aber in der angedachten Größe. Im nächsten Kapitel zum fluiden Design besprechen wir, wie wir den Screen größengerecht füllen. 

 

Mobile-Web-App-Capable: Das Icon für den Homescreen

Wenn wir darüber sprechen, ob eine Web-App eine native App ersetzen kann, ist ein wichtiger Gesichtspunkt für die Web-App auch, wie eine native App gestartet zu werden. Dazu gehört ein eigenes Starticon auf dem Homescreen des Smartphones. Auch diese Hürde lässt sich einfach nehmen dank folgender Codezeile:

<meta name="mobile-web-app-capable" content="yes"><link rel="icon" sizes="192x192" href="img/icon.png"> 

Etwas weniger elegant als bei der nativen App, deren Icon automatisch nach dem Download aus dem App Store erscheint, ist es in der Web-App das Icon auf den Homescreen zu bekommen: der User muss die Website als Lesezeichen speichern. Dann greift jedoch das "mobile-web-app-capable" Meta-Tag und speichert das dort angegebene Icon als Starticon.

 

Fluides Design in der praktischen Umsetzung

html5 webapp responsive designWir möchten an dieser Stelle nicht auf alle Details responsiver Websites eingehen, weil wir uns in diesem Artikel speziell mit der Entwicklung von Web-Apps beschäftigen, also davon ausgehen, dass die Anwendung von Grund auf mobil optimiert entwickelt wird ("mobile first") und keine klassische Desktop-Website sein soll. Folgende Grundregeln sollten Sie daher dennoch beim Aufbau einer Web-App immer beherzigen:

  • Relative Größenangaben, statt absoluter Werte, also z.B. 100% statt 980px erlauben es den Elementen, sich an die Größe der Screens anzupassen
  • Keine absoluten Positionierungen - diese gehen immer von einer bestimmten Bildschirmgröße aus, können jedoch nie gleichermaßen für Smartphones und Tablets gültig sein

Um für die unterschiedlichen Seitenbreiten Inhalte optimiert darzustellen, gibt es zwei Hauptalternativen, die auch kombiniert verwendet werden können

Media Queries

Media Queries sind eine CSS Technik, bei der CSS Formatierungen z.B. entsprechend der verfügbaren Seitenbreite unterschiedlich definiert werden.

@media (min-width: 370px) {
    .myClass{}
}

Mit diesem Statement werden CSS-Formatierungen eingefügt, die nur dann greifen, wenn die Seite mindestens 370 Pixel breit ist. Hier eine kleine Zusammenfassung besonders nützlicher Media-Queries:

  • min-width
  • max-width
  • orientation (landscape/portrait)
  • min-resolution (z.B. 200dpi)
  • max-resolution

Es können dabei auch mehrere Bediungungen aufgestellt und durch logische Operatoren verknüpft werden, z.B.:

@media (min-width: 370px) and (min-resolution: 200dpi) {
    .myClass{}
}

Je nach Detailierungsgrad lassen sich damit sehr fein abgestimmte Designs programmieren, die etwa für das Smartphone einspaltig, für Phablets oder kleinere Tablets zweispaltig sind und ab einer Auflösung von ca. 1000 Pixeln ein dreispaltiges Design ausgeben. Das Media Query für so eine Konfiguration könnte wie folgt aussehen:


@media (max-width: 370px) {
    .box{
width: 100%}
.featureZuGrossFuerMobile {display: none}

}
@media (min-width: 371px) and (max-width: 999px) {
    .box{float: left; width: 50%}
}
@media (min-width: 1000px) {
    .box{float: left: }
}

Achten Sie auch darauf, auf dem Smartphone den Content auf das notwendigste zu beschränken. Es ist nicht die Aufgabe, alles was man in einer Desktopanwendung finden, auch in eine (smartphoneoptimierte) Web-App hineinzupressen. Features, die einfach zu sperrig sind, sollten Sie ausblenden, wie wir im ersten Media Query veranschaulicht haben. 

Das bringt uns aber auch zu einem kleinen Problem der Technik: mit Media-Queries liefert der Server trotzdem den kompletten Content aus, eventuell auch solchen, der nicht für das Smartphone gedacht ist. Wir können diesen zwar problemlos verstecken, doch eleganter wäre es, diesen gar nicht erst zu laden. An dieser Stelle kommt die serverseitige Erkennung des mobilen Endgerätes zum Einsatz.

Serverseitige "mobile detection" 

Wenn wir serverseitig bereits wüssten, ob wir ein Smartphone oder einen Desktop-PC bedienen, könnten wir einiges an Bandbreite einsparen und damit das mobile Surfen beschleunigen. Außerdem halten wir dadurch den Code sauber und vermeiden, von Google für versteckte DIVs oder gar Links bestraft zu werden.

In unserer Beispiel Web-App zum Download haben wir exemplarisch eine Lösung, dafür mit hinterlegt, wenn Sie PHP verwenden.

An dieser Stelle wird wieder deutlich, wie wichtig die genaue Festlegung des Einsatzbereiches der App im ersten Schritt ist: Wenn die Web-App auch offline funktionieren soll, verbietet sich der Eisatz dieser serverseitiger Techniken.

 

Pixel Density, Auflösungen und Retina Displays

html5 web app retina displayMobile Browser von Endgeräten mit einer größeren Pixeldichte (=dpi, dots per inch) als klassische Monitore rendern dem CSS 2.1 Standard folgend einen Pixel mit einem Vielfachen eines Pixels. So wird bei Smartphones zwischen 200dpi und 300dpi auf rechnerische 1,5 Pixel gezoomed; ab 300dpi sogar auf 2 Pixel. Warum das Ganze? Da mit steigender Pixeldichte die Größe eines jeden Pixels sinkt, wird durch das Zoomen diesem Effekt, zumindest ansatzweise, entgegengewirkt. Anders ausgedrückt: Nehmen wir an, ein Programmierer legt eine Box mit  einer Breite von 500 Pixeln fest, so ist diese auf einem 72dpi Monitor etwas über 17cm breit (500px/72dpi*2,54cm/inch). Auf einem Smartphone mit 300dpi wäre die gleiche Box gerade mal 4cm groß; dank des Zoomfaktors wird sie jedoch mit 8cm Breite dargestellt. 

Gleichzeitig bedeutet dieses automatische Zoomen, dass Bilder nicht die physische Auflösung des Geräts nutzen, sondern eben gezoomed und damit in schlechterer Qualität dargestellt werden. Bei der Entwicklung von Web-Apps, die ja vorwiegend auf Smartphones mit hohen Pixeldichten laufen, sollte diesem Umstand Rechnung getragen werden, indem man das gesamte Design in doppelter Größe anlegt und auch die Bilder in der doppelten Größe hinterlegt. Werden diese grafischen Elemente nun per CSS auf die angedachte Pixelgröße (die der Hälfte der realen Auflsöung der Bilder entspricht) festgelegt, erhält man sehr scharfe Grafiken, die die physische Auflösung des Gerätes tatsächlich nutzen.

In der Praxis lässt sich für designtragende Inhalte (also solche, die die Mühe wert sind), die Retina-Auflösung etwa so einbinden:

@media 
(-webkit-min-device-pixel-ratio: 2), 
(min-resolution: 192dpi) { 
	img#Box1 {
    	background-image: url('urlDesBildesMitDoppelterAuflösung')
	}
}

Smartphone Hardware in HTML5 Apps nutzen

html5 web app foto camera captureWas die echte Web-App von einer responsiven Website unterscheidet, ist Ihre Fähigkeit, Nutzen aus der Hardware der Smartphones zu ziehen - ganz wie eine "richtige" App eben. 

Hier bieten sich dem Entwickler zahlreiche, oft unbekannte und selten genutzte Möglichkeiten zur Interaktion, mit der in zahlreichen Anwendungsfällen die Web-App eine native App ersetzen kann (siehe zu dieser Frage auch "Vergleich Web-App vs. native App"). 

Die Kamera nutzen

Das Aufnehmen von Bildern ist für den Web-App Entwickler eine der leichtesten Übungen, denn das ganze geht mit einer kurzen Zeile:

 

<input capture="camera" accept="image/*" type="file" id="bildAufnehmen" /> 

Durch das spezielle Attribut capture="camera", das nur von mobilen Browsern interpretiert wird, bewirkt ein Tap auf den Link das Öffnen des nativen Bilder-Dialogs (siehe Screenshot aus iOS 9). Dieser enthält bei den meisten Betriebssystemen nicht nur die Auswahl, eines Fotos aus der Mediathek auszuwählen, sondern die Möglichkeit zum Aufnehmen eines neuen Fotos. Dadurch wird die native Foto-App gestartet und der User kann ein spontan geschossenen Bild in die Web-App knipsen.

GPS-Daten anzapfen und Standort ermitteln

Extrem vielseitig sind die Anwendungsmöglichkeiten für WebApps, die es vermögen, die Position zu bestimmen. Auch hier versorgt uns HTML5 mit der Hilfe einer Prise JavaScript mit allem, was wir für die Standortermittlung des Users benötigen.


< script >
navigator.geolocation.getCurrentPosition(
function(position){ // Position konnte bestimmt werden
var latitude = position.coords.latitude; 
var longitude = position.coords.longitude;
var accuracy = position.coords.accuracy+'m'; },
function(){ // Positionsbestimmung gescheitert
},
{enableHighAccuracy: true}

) < /script >

Mittels der Methode "getCUrrentPosition" wird die Geolocation aus dem gleichnamigen Objekt bestimmt. Der Rückgabewert ist ein Objekt, das neben Längen- und Breitengrad auch die Höhe (.altitude), die Genauigkeit die Geschwindigkeit (.speed) und die Himmelrichtung (heading) beinhaltet, also alles was man z.B. für eine eigene Lovoo-App benötigt. 

Grundsätzlich werden zur Positionsbestimmung per Geolocation lediglich ohnehin verfügbare Daten verwendet, also IP Adresse, Wlan und Mobilfunktriangulationsdaten. Möchte man GPS-Daten und damit eine auf den Meter genaue Positionsbestimmung, muss dieses ausdrücklich in den Parametern angegeben werden (enableHighAccuracy). Da das GPS viel Saft und ggf. eine lange Vorlaufzeit benötigt, bevor es Resultate ausspuckt, sollte es auch nur im Bedarfsfalle aktiviert werden (Quelle und weitere Details: Standortermittlung per HTML5 Geolocation API).  

 

Daten in der Web-App lokal speichern mit localStorage

Wie in der Einleitung angeschnitten gehört es zu einer Web-App, Daten auch offline zu speichern, um deren Funktionsfähigkeit zu gewährleisten, wenn keine Mobilfunkverbindung besteht. In der Praxis hat es sich bewährt, beim Start der App zu prüfen, ob eine Verbindung besteht und alle Daten vom Server zu holen, sofern das der Fall ist. Wenn nicht, wird in regelmäßigen Abständen wieder ein Verbindungscheck durchgeführt. Zwischenzeitlich lokal anfallende Daten werden im localStorage gespeichert und synchronisiert, sobald die Verbindung wiederhergestellt ist.

Das Schöne am localStorage ist, dass man diesem per JSON.stringify beliebig komplexe Objekte mit nur einer Zeile Code füttern kann:

 

< script >
// speichern im localStorage localStorage.setItem('ObjektnameImSpeicher', JSON.stringify(objektname));
// laden aus dem localStorage
var obj = JSON.parse(localStorage.getItem('ObjektnameImSpeicher'));
 ) < /script > 

 In den Entwicklertools des Browsers (meist per F12 zu öffnen) finden sich die so gespeicherten Daten im Reiter "Resources" und dort unter "Local Storage":

html5 web app localStorage

Das Laden der Daten geht umgekehrt per localStorage.getItem ebenso einfach. Hier dient die JSON Funktion JSON.parse dazu, aus der gespeicherten Zeichenfolge wieder ein JavaScript Objekt zu machen.

 

Zusammenfassung zur Web App Programmierung mit HTML5

Wir wir in diesem Artikel gesehen haben, lassen sich mit den Mitteln von HTML5 und JavaScript Web-Apps programmieren, die sogar einige Hardware-Funktionen nativer Apps bereitstellen. Durch die Kombination der hier vorgestellten Techniken von der lokalen Datenspeicherung, über die Positionsbestimmung per Geolocation bis hin zum Aufnehmen eines eigenen Bildes durch die Web-App lassen sich auch komplexe Apps wie z.B. ein Lovoo-Klon programmieren.

 

 





Twittern