Anwendungen für Online und Offline mit Google Gears - Teil 2

Teil 1 erklärte die Architektur von Google Gears und stellte einige Vorüberlegungen zu Webanwendungen an, die auch im Offline-Modus funktionieren sollen. Nun geht es ans Coden mit zwei einfachen praktischen Gears-Beispielen.

Eine statische Gears-Anwendung

Als erstes Beispiel dient eine statische Website. Diese einfache Gears-Anwendung hält den Inhalt einer oder mehrerer URLs in einem clientseitigen Speicher bereit. Ist der Speicher einmal befüllt, kann der Anwender die Internetverbindung trennt, ja sogar den Browser-Cache leeren, und dennoch bleibt der Inhalt der URLs aufrufbar. Eine solche Anwendung ließe sich beispielsweise für ein Hilfesystem mit verlinkten Handbuchseiten nutzen.

Eine statische Gears-Anwendung legt die gewünschten URLs fest, bezeichnet den clientseitigen Speicherort, lädt dann die Inhalte herunter und speichert diese. Daneben soll sich der lokale Speicher aktualisieren, wenn sich die Daten auf dem Server ändert. Zu guter Letzt lässt sich der Speicher auf dem Client auch löschen

Gears-Installation

Die Arbeit am Beispielprojekt beginnt mit Download und Installation von Gears, was gerade einmal fünf Minuten in Anspruch nimmt. Eine Installationsanleitung für verschiedene Plattformen und Browser gibt es auf der Gears-Homepage.

Im nächsten Schritt schreibt der Entwickler alle URLs nieder, die die Anwendung clientseitig speichern soll. Dazu gehören nicht nur HTML-Seiten, sondern auch alle benötigten Bilder, CSS- und Javascript-Dateien sowie Multimedia-Inhalte. Diese Liste wird im Gears-"Manifest" in Javascript Object Notation (JSON) festgehalten. Der Dateiname des Manifests ist folglich "manifest.json" - Listing 1 zeigt dessen Inhalt.

{
  "betaManifestVersion": 1,
  "version": "Linux Magazine Demo 1.0",
  "entries": [
      { "url": "js/gears_init.js"},
      { "url": "js/go_offline.js"},
      { "url": "http://dcauto.gotdns.com/demo/js/jquery.js"},
      { "url": "css/styles.css"},
      { "url": "demo.html"}
    ]
}

Der Eintrag ""betaManifestVersion": 1", zu Beginn ist Pflicht. Er gibt das Format des Manifests an, damit Gears dieses verarbeiten kann.

Die Angabe "version" nimmt eine beliebige Zeichenkette auf, sollte aber zumindest dem Entwickler selbst die aktuelle Version der Datensammlung mitteilen. Beispielsweise könnte ein Exemplar des Manifests als Versionsbezeichnung "Documentation 1.0" tragen, ein anderes "Documentation 1.1". Wichtig: Enthält das Manifest auf dem Client eine andere Version als das auf dem Server, lädt Gears automatisch die in der Server-Version verzeichneten Dateien auf das lokale System herunter, um für synchronen Datenbestand zu sorgen.

Übrigens erfordert jede Änderung an der Mainfest-Datei eine neue Versionsbezeichnung. Ändert sich der Inhalt einer im Manifest angegebenen Datei, kann der Entwickler durch Änderung der Versionsbezeichnung die Synchronisation erzwingen.

Die Auflistung der gewünschten Dateien findet sich in "entries". Eine Datei lässt sich durch ihren absoluten URL referenzieren oder durch den relativen Pfad - gesehen vom Speicherort des Manifests auf dem Server. Eine Datei sollte in dieser Liste auf jeden Fall enthalten sein: "gears_init.js" gehört zur Gears-Distribution und sorgt für die korrekte Initialisierung von Gears. Unter anderem initialisiert diese Datei das Javascript-Object "google.gears" - und zwar nur, falls Gears im aufrufenden Browser installiert ist. Mit "pf google-gears" lässt sich auslesen, ob Gears verfügbar ist.

Das fertige Manifest findet seinen Platz im Wurzelverzeichnis der Webanwendung. Dort wird es von Browsern mit Gears-Installation gefunden.