Anzeige
Tutorialbeschreibung

Web-Apps erstellen (Teil 23): Offlinefähigkeit und Browserweiche

Web-Apps erstellen (Teil 23): Offlinefähigkeit und Browserweiche

In diesem Video-Training geht es um zwei Dinge. Ihr werdet zunächst einmal sehen, wie ihr die App dafür rüsten könnt, wenn keine Onlineverbindung besteht. Im zweiten Teil wird dann eine Browserweiche vorgestellt, die automatisch die „normale“ Webseite oder aber eben eure Web-App lädt. Abhängig ist das Ergebnis dann davon, über welches Gerät die Seite aufgerufen wird.


Web-Anwendungen funktionieren üblicherweise nur, wenn eine Onlineverbindung besteht. Bei einer Web-App möchte man aber eben oftmals erreichen, dass diese auch dann nutzbar ist, wenn die Besucher offline sind. Genau dafür hält HTML5 entsprechende Mechanismen bereit. Diese funktionieren folgendermaßen: Ruft ein Besucher eure Web-App auf, werden wichtige Ressourcen vorgeladen und gecacht. Geht der Besucher dann offline, stehen ihm die Ressourcen unverändert zur Verfügung. Damit das funktioniert, müsst ihr eure Web-App natürlich entsprechend präparieren.

Mittlerweile gibt es verschiedene Ansätze für Offline-Applikationen. Die wichtigste dieser Varianten ist dabei zweifellos die Offline Web Applications API, die im Mittelpunkt des folgenden Abschnitts steht.

Bilder



 
Das wichtigste Konzept dieser Offline Web Applications API sind die sogenannten Manifest-Dateien. In diesen Dateien sind die URLs zu allen Ressourcen enthalten, die offline verfügbar gemacht werden sollen.

Das folgende Beispiel zeigt, wie sich die Offline Web Applications API üblicherweise nutzen lässt.
<!DOCTYPE html>
<html manifest="clock.manifest">
 <head>
  <title>Clock</title>
  <script src="clock.js"></script>
  <link rel="stylesheet" href="clock.css">
 </head>
 <body>
  <p>Aktuelle Uhrzeit/Datum: <output id="clock"></output></p>
 </body>
</html>

Das ist eine normale HTML-Datei, über die mittels eines JavaScripts die aktuelle Uhrzeit ausgegeben werden soll.

Bilder



 
Formatiert wird das Ganze mittels CSS.
/* clock.css */
output { 
   font: 2em sans-serif; 
}

Das Script selbst wurde in einer externen Datei definiert, deren Inhalt folgendermaßen aussieht:
setTimeout(function () {
    document.getElementById('clock').value = new Date();
}, 1000);

Damit die Anwendung tatsächlich auch offline läuft, benötigt man die entsprechende Manifest-Datei. Diese Dateien müssen immer in UTF-8 kodiert sein und den MIME-Type text/cache-manifest haben. Verwiesen wird auf die Manifest-Datei im einleitenden html-Element der App-Hauptseite.

Eingeleitet werden sie durch folgenden Eintrag:
CACHE MANIFEST

Daran schließt sich der CACHE-Bereich an. Hier werden all die Dinge notiert, die nach dem ersten Laden der App gecacht werden sollen.
CACHE: 
index.html 
clock.js 
clock.css 

Jede Datei steht dabei innerhalb einer eigenen Zeile. Achtet darauf, wie viele Dateien ihr in den Cache laden wollt. Von Hause aus stehen euch nämlich maximal fünf MB zur Verfügung. Ist der Cache größer, müssen die Anwender dem explizit zustimmen.

Weiter geht es mit dem NETWORK-Bereich. Hier gibt man all die Ressourcen an, die niemals gecacht werden sollen. Diese Dateien benötigen in jedem Fall eine Onlineverbindung, damit sie zu sehen sind.
NETWORK: 
kontakt.html

Beim dritten Bereich der Manifest-Datei handelt es sich um FALLBACK.
FALLBACK: 
/index.html /offline.html

 
Hier notiert man die Dateien, die zu sehen sein sollen, wenn die gecachten Dateien nicht angezeigt werden können. Im aktuellen Beispiel soll die index.html angezeigt werden. Klappt das – aus welchem Grund auch immer – nicht, greift die App auf die offline.html zurück.

Bilder



Das folgende Beispiel zeigt, wie diese offline.html aussehen könnte.
<!DOCTYPE html> 
<html> 
<head> 
<meta charset="utf-8"> 
<title>Die Seite ist offline</title> 
</head> 
<body> 
<h1>Offlinemodus</h1> 
<p> 
Diese Seite befindet sich im Offlinemodus. 
</p> 
</body> 
</html>

Technisch läuft die Offline-Funktionalität dann folgendermaßen ab: Ruft ein Anwender eine Seite auf, die für das Cachen vorgesehen wurde, versucht der Browser, diese zu aktualisieren. Dafür wird im ersten Schritt die Manifest-Datei heruntergeladen. Beim ersten Aufruf landen dadurch alle Dateien im Cache. Beim nächsten Seitenaufruf wird überprüft, ob sich die Manifest-Datei geändert hat. Ist das nicht der Fall, erfolgt keine Aktualisierung des Cache. Der Cache wird erst aktualisiert, wenn die Cache-Manifest-Datei verändert wird. Es spielt also keine Rolle, ob ihr eine andere Datei der App aktualisiert. Sollen Änderungen, die man an einer der App-Dateien vorgenommen hat, sichtbar werden, muss man also die Manifest-Datei anpassen. Das geschieht über einen Kommentar.

Das folgende Beispiel zeigt, wie eine entsprechende Manifest-Datei aussehen kann.
CACHE MANIFEST
# Aktualisiert am 12.3.2014, 12.34
CACHE
index.html
clock.js
clock.css
NETWORK:
/kontakt.html
FALLBACK:
/index.html /offline.html

Die App automatisch laden

Wenn ihr mit eurer App zufrieden seid, solltet ihr euch überlegen, was mit ihr passieren soll. Wollt ihr sie in einem App-Store veröffentlichen? Soll sie als normale Webseite nutzbar sein? Ich werde euch an dieser Stelle den klassischen Weg vorstellen. Dabei gehe ich davon aus, dass ihr eine normale Webseite betreibt, die für die Anzeige auf Desktop-Rechnern optimiert ist. Ruft ein Besucher die Seite über ein Smartphone auf, soll stattdessen die Web-App zu sehen sein. Eine solche Anwendung lässt sich denkbar einfach über eine Browserweiche realisieren.

Umgesetzt wird die Browserweiche über ein PHP-Skript. Achtet in jedem Fall darauf, dass dieses Skript unter dem Namen index.php abgespeichert wird. Sie muss in jedem Fall da liegen, wo die üblicherweise genutzte URL hinzeigt. Auf der Verzeichnisebene, auf der die index.php liegt, darf es keine index.html oder index.htm geben. (Wenn ihr euren Server selbst konfiguriert habt, könnte die Startseite natürlich anders heißen. Passt in diesem Fall den Namen des PHP-Skripts entsprechend an).

 
Die Verzeichnisstruktur eurer Webseite könnte folgendermaßen aussehen:

public_html
--index.php
mobil/index.html
desktop/index.html


Ruft ein Besucher eure Seite auf, wird automatisch die index.php geöffnet.

In dieser index.php ist letztendlich die Browserweiche enthalten. Wird ein Smartphone oder Tablet erkannt, erfolgt die Umleitung auf die Seite mobil/index.html. Beim Aufruf über einen normalen Desktop-Rechner wird der Besucher hingegen auf die desktop/index.html umgeleitet.

Die Anwendung sieht folgendermaßen aus:
<?php
$useragent = $_SERVER['HTTP_USER_AGENT'];
if (preg_match("/(alcatel|amoi|android|avantgo|blackberry|benq|cell|cricket|docomo|elaine|htc|iemobile|iphone|ipad|ipaq|ipod|j2me|java|midp|mini|mmp|mobi|motorola|nec-|nokia|palm|panasonic|philips|phone|playbook|sagem|sharp|sie-|silk|smartphone|sony|symbian|t-mobile|telus|up\.browser|up\.link|vodafone|wap|webos|wireless|xda|xoom|zte)/i",$useragent))
{
header( 'Location: mobil/index.html' );
} else {
header( 'Location: desktop/index.html' );
}
?>

Das Prinzip dieser Browserweiche ist denkbar einfach. Über eine if-Abfrage wird überprüft, ob beim Besucher ein mobiler Browser im Einsatz ist. Welche Browser das sein können, steht innerhalb der Liste.
alcatel|amoi|android|avantgo|blackberry|benq|cell|cricket|docomo|elaine|htc|iemobile|iphone|ipad|ipaq|ipod|j2me|java|midp|mini|mmp|mobi|motorola|nec-|nokia|palm|panasonic|philips|phone|playbook|sagem|sharp|sie-|silk|smartphone|sony|symbian|t-mobile|telus|up\.browser|up\.link|vodafone|wap|webos|wireless|xda|xoom|zte

Die Liste könnt ihr natürlich jederzeit selbst um zusätzliche Einträge erweitern. Sobald ein entsprechender Browser erkannt wird, erfolgt die Umleitung auf die Seite mobil/index.html. Ist der Browser nicht in der Liste enthalten, wird automatisch auf die Seite desktop/index.html umgeleitet. So könnt ihr den Besuchern immer die für sie passende Webseite anbieten. Achtet aber immer darauf, die Browserliste möglichst aktuell zu halten.

Kommentare
Achtung: Du kannst den Inhalt erst nach dem Login kommentieren.
Alternative Portrait
-versteckt-(Autor hat Seite verlassen)
  • 16.10.2016 - 15:11

Vielen Dank für das Tutorial

Portrait von MicroSmurf
  • 17.09.2014 - 00:28

Wieder sehr interessant. Vielen Dank.

Portrait von Kundentest
  • 13.08.2014 - 23:47

Herzlichen Dank für das Tutorial.

Portrait von Domingo
  • 13.08.2014 - 22:51

Vielen Dank für diesen weiteren Teil .

Portrait von Schwupp
  • 13.08.2014 - 18:27

Immer wieder aufregend lehrreich!

Portrait von Steve007
  • 13.08.2014 - 16:41

Vielen Dank für diesen weiteren Teil Deiner interessanten Reihe.

Portrait von chris213
  • 13.08.2014 - 16:38

Vielen Dank! Das Tutorial ist wieder einmal sehr interessant.

Portrait von pallasathena
  • 13.08.2014 - 16:18

Ein interessantes Thema verständlich aufbereitet, danke

Portrait von Caesarion2004
  • 13.08.2014 - 15:45

Vielen Dank für einen weiteren, sehr informativen Teil der Reihe.

Portrait von BOPsWelt
  • 13.08.2014 - 15:31

Danke für den nächsten Teil der Reihe!

Portrait von Steve007
  • 23.07.2014 - 18:46

Vielen Dank für diesen weiteren Teil Deiner interessanten Reihe.

Portrait von Kundentest
  • 20.07.2014 - 10:43

Herzlichen Dank für das Video.

Portrait von johen
  • 19.07.2014 - 12:37

Herzlichen Dank für das Video und die Arbeit damit.Tolle Tipps ;-)

Portrait von renate_C
  • 19.07.2014 - 11:48

Danke für das interessante und sinnvolle Tutorial.

Portrait von Caesarion2004
  • 19.07.2014 - 11:01

Vielen Dank für das wieder sehr interessante und informative Tutorial sowie die Datei.

Portrait von MicroSmurf
  • 19.07.2014 - 10:48

Sehr interessant, wie immer. Danke.

x
×
×