Während Ember-Data somit extrem hilfreich ist und auch für sehr komplexe Applikationen geeignet ist, stießen wir auf das Problem, dass man zwar einstellen kann, ob man die Daten über eine REST-API oder den LocalStorage persistieren möchte, aber nicht beide Optionen gleichzeitig nutzen kann. Für Herculess brauchen wir aber eine Funktionalität, die standardmäßig Daten vom REST-Server holt und nur im Offline-Fall auf zwischengespeicherte Daten aus dem LocalStorage zurückgreift.

Der Weg zum Ziel

Die Lösung dieses Problems war nicht ganz einfach und hat erst einmal zu diversen Fehlversuchen geführt. Erste Ansätze waren es, den bestehenden LocalStorage-Adapter von Ember-Data umzubauen und um eine Hintergrund-Synchronisierung zu ergänzen. So hätte Ember immer lokal im LocalStorage gearbeitet und nur im Hintergrund wären die Daten von der REST-API in den LocalStorage geschrieben worden. Das Problem hierbei war jedoch, dass Ember, um stets eine Datenintegrität zu gewährleisten, es nicht ermöglicht, zur Laufzeit alle Daten aus dem LocalStorage zu erneuern. Es hätte stets nach dem Update von der REST-Schnittstelle eine kompletter Seitenrefresh durchgeführt werden müssen, was wiederrum die unbemerkte Synchronisierung unmöglich gemacht hätte.

Nachdem diverse Experimente in diese Richtung fehlgeschlagen sind, haben wir einen neuen Ansatz ausprobiert: Wenn die App offline ist, sollen die Ajax-Calls einfach statt an den Server an eine (offline verfügbar gemachte) Datei geroutet werden und diese dann aus dem LocalStorage zwischengespeicherte Daten in derselben Form wie die richtige REST-API zurückgeben. So könnte der Client immer gleich arbeiten und nur die URL der AJAX-Calls müsste geändert werden. Das Problem hierbei ist natürlich, dass man lokal nur JavaScript/HTML zwischenspeichern kann und diese clientseitig keine reinen JSON-Responses zusammenbauen können: Die AJAX-Calls parsen die Responses ja nicht, sondern geben nur den Dateiinhalt zurück.

Somit sind wir schlussendlich bei einer Adaption dieser Idee gelandet. Anstatt eine Pseudo-API zu implementieren, fangen wir alle AJAX-Calls ab und liefern mithilfe des jQuery-Plugins jquery.ajax.fake selbst zusammengebaute JSON-Responses zurück.

Unsere Lösung

In der Praxis sieht das wie folgt aus:

Der erste Schritt ist es, die Daten überhaupt einmal zwischen zu speichern. Dafür haben wir eine JavaScript-Klasse erstellt, welche für alle Synchronisations-Vorgänge zuständig ist. Diese ist komplett unabhängig von Ember.

Diese Klasse hat eine „sync()“ Funktion. Diese Funktion holt sich von der REST-API über eine eigene Route „/downSync“ eine Kollektion aller wichtigen Daten für diesen User. Diese Kollektion enthält alle Tasks und Projekte, die für diesen User wichtig sind.

Das Sync-Objekt speichert diese Daten dann in den LocalStorage. Danach wird nach einigen Sekunden erneut sync() aufgerufen und die Daten im LocalStorage aktualisiert. Somit sind die Daten im LocalStorage immer (bis auf seltene Ausnahmen) eine Spiegelung der Daten von der REST-API.

Der nächste Schritt ist es, abzufragen, ob gerade eine Internet-Verbindung besteht. Das machen wir beim ersten Seitenaufruf über „navigator.onLine“, welcher den Online-Status zurückgibt. So wird ein Cookie „is-offline“ auf true oder false gesetzt. Danach wird bei jedem Sync-Versuch dieser Cookie angepasst, falls der Sync-Versuch fehlschlägt oder doch wieder klappt.

Falls die App erkennt, dass man plötzlich offline geht, schaltet sie auf jquery.ajax.fake um. Dafür verändern wir über die jQuery-Funktion „$.ajaxSetup“, welche Voreinstellung für alle folgenden $.ajax-Calls setzen kann, das Attribut „fake: true“. Dieses braucht jquery.ajax.fake, um zu wissen dass dieser Request gefakt werden soll.

Zusätzlich dazu muss man, damit die Fake-Responses funktionieren, für jede URL einstellen, welcher Response kommen soll. Da es unmöglich wäre, hier im Vorfeld alle möglichen URLs einzustellen (da wir ja auch Parameter wie IDs mitsenden), muss das automatisch geschehen. Das haben wir so gelöst, dass wir in der Ember-Data Methode, die für die AJAX-Aufrufe zuständig ist, noch eine Zeile hinzugefügt haben, die – vor dem Senden – zu der nun gleich gesendeten URL immer die gleiche Funktion aufrufen soll.

$.ajax.fake.registerWebservice(url, function(data) {
    return restSyncer.fakeAjax(data);
});

Außerdem fügen wir vor dem Senden die URL als Parameter zum AJAX-Request hinzu.

Die Funktion, welche die Fake-AJAX-Responses zusammen bauen soll, kann dann über den so mitgelieferten Parameter „url“ ermitteln, welche Route angesprochen wurde, und dann aus dem LocalStorage entsprechend einen Response zusammenbauen und zurückgeben. Die eigentliche App merkt so nie, ob die Daten jetzt wirklich vom Server oder aus dem LocalStorage kommen. Sobald die App wieder online ist, wird automatisch umgestellt – ohne, dass der User es merkt.

Während diese Methode, soweit bisherige Test gezeigt haben, sehr gut und nahtlos funktioniert, hat sie auch zwei Nachteile: Jede Änderung der REST-API muss genau im Client gespiegelt werden, und es entsteht zusätzlicher Traffic durch das Syncen im Hintergrund. Letzteres werden wir in späteren Versionen optimieren, indem wir einen Timestamp der letzten Synchronisierung mitschicken und so nur neue Einträge erhalten. Außerdem soll man in der App die Frequenz der Sync-Abfragen einstellen können oder auch nur manuell synchronisieren.

Die aktuelle Implementation funktioniert bereits für alle GET-Requests. POST, PUT oder DELETE Requests sind aber genauso lösbar: Hierfür werden wir alle solche offline getätigten Requests eigens im LocalStorage speichern, und wenn die App wieder online geht werden diese gespeicherten Requests einer nacheinander erneut an den Server gesendet. Hierbei ist es besonders wichtig, den Status mitzuspeichern: Erstens muss der User immer wissen, ob gerade etwas synchronisiert wird oder ob alle Daten aktuell sind, und zweitens muss die App immer wissen, ob ein Request erfolgreich beim Server angekommen ist oder ob es wieder einen Fehler gab und es später erneut versucht werden muss, um den Verlust von Daten zu verhindern.

The post Offline REST Fallback via LocalStorage appeared first on Mobile USTP MKL.

Wichtig ist, dass sie mit CACHE MANIFEST beginnt. Anschließend werden alle notwendigen Dateien jeweils in einer Zeile aufgelistet. In meinem Fall habe ich sie als relative Pfade definiert, es können aber auch absolute Pfade angegeben werden. Wird die Website komplexer, bietet es sich an, die Erstellung der Cache Manifest Datei über ein Skript zu lösen. Ich habe das so realisiert:

<?php
header('Content-Type: text/cache-manifest');
echo "CACHE MANIFEST\n";
$hashes = '';

$dir = new RecursiveDirectoryIterator(".");
foreach(new RecursiveIteratorIterator($dir) as $file){
if($file->IsFile()&& !strpos($file, "/.") && substr($file->getFilename(), 0, 1) !="." && substr($file->getFilename(), -3, 3) != "php"){
echo $file . "\n";
$hashes .= md5_file($file);
}
}
echo "# HASH: ".md5($hashes) . "\n";
?>

Das Skript (inspiriert durch [1] und [2]) iteriert durch alle Unterverzeichnisse und schließt sowohl Dateien aus, die mit “.” beginnen als auch alle PHP-Dateien. Zusätzlich wird ein md5-Hash der Files generiert und dieser am Ende der Manifest-Datei als Kommentar ausgegeben. So kann sichergestellt werden, dass bei Änderung eines Files das Cache Manifest geändert wird und somit der Browser die Ressourcen neu lädt.

Die Manifest Datei muss mit dem Content-Type “text/cache-manifest” vom Server ausgeliefert werden. Wird sie manuell erstellt, kann dies bei einem Apache Webserver über die .htaccess-Datei erreicht werden. In diesem Fall muss dort die Zeile AddType text/cache-manifest .manifest hinzugefügt werden. In meinem PHP-Script erledigt das die Zeile header('Content-Type: text/cache-manifest'); für mich.

Außerdem kann im Manifest spezifiziert werden, welche Dateien nicht gespeichert werden sollen und somit egal ob offline oder nicht immer vom Server geladen werden. Dies wird über den Bereich NETWORK: erreicht und nennt sich Whitelisting. Wichtig ist zu wissen, dass nur Dateien, die nicht zum Cachen angeführt sind, in diesem Bereich angeführt werden können. Zudem kann ein Bereich FALLBACK: definiert werden, in dem zwischen Online- und Offline-Verfügbarkeit unterschieden werden kann. Eine einfache Manifest-Datei könnte dann wie folgt aussehen:

CACHE MANIFEST
./js/mobilot.js
./css/mobilot.css
./image/icon_sprite.png
./image/icon_sprite@2x.png

FALLBACK:
./image/ ./offline.png

In diesem File wird die im Ordner image liegende menu.png immer vom Server geladen (definiert im Bereich NETWORK:). Aus dem Bereich FALLBACK: können wir entnehmen: wenn eine Verbindung zum Netzwerk besteht, dann lade die Dateien im Ordner image, sonst lade die Datei offline.png.

Und zu guter Letzt muss der Startdatei der Webseite (in dem meisten Fällen wohl die index.html) im HTML Tag die Cache Manifest Datei verlinkt werden. Dazu wird das Attribut manifest gesetzt.
<html manifest="cache.manifest"> oder auch z.B. <html manifest="manifest.php">

Update 06.04.2012: Als Tücke beim Arbeiten mit dem Cache Manifest hat sich für mich heute herausgestellt, dass nur Dateien offline aufgerufen werden können, deren URL genau gleich im Cache Manifest hinterlegt sind. Das bedeutet, dass keine zusätzlichen Parameter beim Aufruf mitgegeben werden können, die nicht auch im Cache Manifest hinterlegt sind.

[1] Stark, J. (2011). Android-Apps mit HTML, CSS und JavaScript [mit Standard-Web-Tools zur nativen App]. Beijing; Cambridge; Farnham; Köln; Sebastopol; Tokyo: O’Reilly.
[2] Kessin, Z. (2011). Programming web applications in HTML5. Sebastopol CA: O’Reilly Media, Inc.

The post Cache Manifest dynamisch erstellen appeared first on Mobile USTP MKL.

Es versteht sich von selbst, dass man, solange man online ist, an alles Mögliche, was man offline benötigen könnte, denken sollte. Oder man sucht sich so ein tolles Hotel wie das Stella Maris in Hamburg aus, wo gratis WLAN zur Verfügung steht. Ich muss also an der Stelle schon mal zugeben, dass ich nach einer Woche Abstinenz in geringen Dosen online sein konnte.
Ein Tipp wäre auch McDonalds. Da aber braucht man, um in den Genuss einer Stunde gratis surfen zu kommen, eine deutsche Handynummer, die ich selbst dieses Mal nicht mit bei hatte. Das war also nix.

Facebook heißt es erstmal ade zu sagen, Mails ebenso.
Zum Glück funktionieren viele (aber leider nicht alle) Spiele offline. Geschenke an Freunde schicken geht natürlich nicht und meine Erfolge über Facebook oder Twitter kundtun, kann ich auch nicht. Nicht, dass ich das jemals getan hätte…
Die Hamburg City App ist extrem nützlich. Die GPS-Positionierung dauert merkbar länger, aber sie sagt mir dann doch, wo ich mich befinde und so find ich auch offline immer zurück zum Hotel. Mit dabei auch alle U- und S-Bahn-Haltestellen. Ein Hinweis: Die App “Karten” ist aufgrund der nicht vorhandenen Offline-Funktionalität keine Alternative

Aber ich habe trotzdem den Härtetest nicht bestanden, denn… widerstehen konnte ich nicht bei der Rückfahrt. Am Bahnhof Hamburg schienen irgendwie alle Züge Verspätung zu haben und wie sich zum Schluss herausstellte, waren die Informationen über die DB-App sicherer als die der Zugbegleiter – sofern sie überhaupt irgendetwas gesagt haben. Unser Anschlusszug in Würzburg hatte natürlich keine Verspätung. Aber wir aus Hamburg – 1 Stunde und 20 Minuten. Da wünschte man sich doch, dass die Zugbegleiter bei der Deutschen Bahn ein entsprechendes Gerät mit der DB-App dabei hätten. Dann hätte ich nicht die Roamingkosten in Kauf nehmen müssen. Ok zugegeben: Die Kosten waren schon vor dem Gespräch mit dem besagten Zugbegleiter entstanden.

Wie ihr dem Post entnehmen könnt, wird das iPhone (und vermutlich auch andere Smartphones, mir fehlen da aber die Vergleiche) mit abgeschaltetem Daten-Roaming nicht zum “ganz normalen” Telefon. Der Akku hält aber in jedem Fall länger, sofern man nicht vergisst, die App mit der GPS-Positionierung zu beenden. Natürlich – Telefonieren geht, wenn man da wieder die Roamingkosten beachtet. Siri nicht. Es erinnert auch immer noch an Termine. Richtig aber nur, sofern man die aktuelle Version seines Kalenders gesynct hat.

Und warum das alles hier?
In den nächsten Monaten werde ich mich im Zuge meiner Diplomarbeit mit dem Thema Datensynchronisierung für mobile Informationssysteme mit dem Hintergrund einer Offline-Nutzung beschäftigen. Deshalb wollte ich ausprobieren, wie es ist offline zu sein. Mit Hilfe des zukünftigen HTML-Standards HTML5 ist es leicht möglich auch Webanwendungen offlinefähig zu machen. Dabei fällt mir auf, dass ich bewusst bisher keine Webanwendungen auf dem Smartphone nutze, die offlinefähig ist. Hoffen wir mal, dass sich das im Laufe meiner Diplomarbeit ändern wird. Ich werde euch auf diesem Blog auf dem Laufenden halten – unter dem Tag: Offline.

The post Immer noch Online? Oder surfst du schon Offline? appeared first on Mobile USTP MKL.