Mobile Web Teil 2 - WRT

Im ersten Teil von "Mobile Web WRT" waren die Widgets noch optimierungsbedürftig. Um es direkt vorweg zu nehmen: sind sie immer noch. Aber es gibt neue Erkenntnisse und zwar in den folgenden Bereichen:
  * Persistente Objekte
  * Zugriff auf Standort Informationen (GPS)
  * Netzwerkzugriffe
  * Aptana Studio und der Emulator

Persistente Objekte
Nicht selten besteht die Anforderung das ein Programm sich bestimmte Daten speichert und das diese Daten beim erneuten ausführen wieder zur Verfügung stehen. Im Zeitalter der "Cloud" kann man natürlich sämtliche Daten einfach an einen Server schicken und diese einfach von dort aus wieder laden. Wir betrachten hier aber die Möglichkeiten von WRT und es ist zum Glück mehr als einfach Daten zu speichern und wieder zu laden. Und das geht so:
   // Save
   widget.setPreferenceForKey("VALUE", "KEY");

   // Load
   var value = widget.preferenceForKey("KEY");

Da wir uns innerhalb eines JavaScript Kontextes bewegen kann man natürlich für den "VALUE" Part auch JSON verwenden und kann so komplexe Objekte auf recht einfache Art und Weise speichern und wieder laden.
Da es ja bei diesem Experiment darum geht möglichst viele Devices zu unterstützen schauen wir schnell ob wir einer proprietären Funktion auf den Leim gegangen sind. Das Resultat ist sehr erfreulich, denn die Funktion finden wir bei:
Opera
Apple/iPhone
Da das "Widget"-Element Bestandteil von WebKit ist, kann es durchaus sein das Android und der Palm Pre diese Funktionen kennen. Wir werden da zu einem späteren Zeitpunkt verifizieren.

Zugriff auf Standort Informationen (GPS)
Was wäre eine heutige mobile Anwendung ohne standortbezogene Informationen? Eine einfache Anwendung erscheint mir die richtige Antwort zu sein. Nichtsdestotrotz sind einige Anwendungsfälle bekannt die vom aktuellen Standort Gebrauch machen möchten. Als Beispiel habe ich mir z.B. überlegt wie lange und wie weit ich eigentlich Fahrrad fahre. Aus dieser Frage meinem Stopuhr Widget und der Möglichkeit GPS Informationen zu erheben (und damit auch Wegstrecken zu berechnen) ist übrigens wiederum ein kleines Widget entstanden. Bleiben wir aber beim Thema.
   var serviceLocation = device.getServiceObject("Service.Location", "ILocation");
   var criteria = new Object(); // Hier besteht die Möglichkeit Kriterien zu bestimmen
   serviceLocation.ILocation.GetLocation(criteria, MyCallBackMethod); // MyCallBackMethod wird immer aufgerufen wenn sich der Standort ändert

Leider sind wir nach meinen aktuellen Recherchen hier schon recht proprietär und in keinster Weise angelehnt an die Spec der W3C. Die zukünftigen Workaround einmal außer acht gelassen ist es sehr einfach auf diese Informationen zuzugreifen und diese auszuwerten (immer positiv denken ;-).

Netzwerkzugriffe
Es sei erst einmal angemerkt das sich ein WRT eklatant von normalen Webseiten unterscheidet. Wenn es um Netzwerkzugriffe geht. Vor allem hat das etwas damit zu tun, das die HTML Seiten und die JavaScript Dateien nicht von einem Server geladen werden. Und zwar weil die "Same Origin Policy" nicht greifen kann, denn es gibt ja keine IP. Es gibt keinen Ursprung denn die Dateien kommen aus dem File System. Das heißt, der Zugriff auf Dienste im Netz (sagen wir eigentlich noch Netz oder sagen wir nur noch "Cloud"?) ist uneingeschränkt möglich. Das war auch schon alles was es zu diesem Thema zu sagen gibt. Alles andere sollte genau so funktionieren wie in einem normalen Browser und einer normalen Webseite. Um es mir selber einfacher zu machen habe ich jQuery verwendet.
   jQuery.get(url, data, MyCallbackToHandletheResponse); // MyCallbackToHandletheResponse wird aufgerufen nachdem die Daten vorliegen
Da jQuery ausreichend dokumentiert ist, brauche ich nicht weiter auf dieses Thema einzugehen. Es geht einfach. Und natürlich kann man auch Prototype, oder (bitte einfügen) [MEINE_LIEBSTE_JS_LIB] verwenden.

Aptana Studio und der Emulator
Da ich jetzt schon seit einigen Stunden Aptana Studio und den darin enthaltenen Emulator verwende, möchte ich auf einige Dinge ganz speziell hinweisen. Wer es sich auch immer ausgedacht hat das beim Speichern einer Datei der Fokus genommen wird, sollte entlassen werden. Oder schlimmeres. Der Arbeitsprozess (ich meine hier das Schreiben von Code) wird jäh unterbrochen um die Maus wieder an die gewünschte Stelle zu platzieren. Das ist mehr als nur nervig.
Weiterhin unterstützt der Emulator keine Eingabe von Geo-Koordinaten (lat/lon), sondern denkt sich selber (statische) Koordinaten aus. Um gezielt zu testen kann man sich natürlich Workarounds ausdenken, aber es würde helfen wenn man solche simplen Daten einfach selber eingeben könnte.
Der Emulator kann anscheinend keine URLs in einem neuem Fenster öffnen (_new) oder javascript.widget.openURL(); Nun gut, man muss sowieso auf den echten Endgeräten testen aber wenn schon ein Emulator ...
Beim SportTrack Widget musste ich blind programmieren da der Emulator (da nur eine Koordinate kennend) die Wegstrecke nicht berechnen konnte. Die Meldung "API Notice -- Service.Location:: GetLocation : Updateoptions.PartialUpdates not implemented in preview" zeigt warum.
Genug genörgelt. Ohne Emulator hätte ich viel mehr Zeit gebraucht - trotz der Ecken und Kanten.

Mein Fazit
Ich habe nun drei kleine Widgets geschrieben, von sehr einfach bis mittelmäßig kompliziert. Im Prinzip wurden in die Einarbeitungszeit und die Erstellung nur wenige Stunden investiert. Mit den Ergebnissen bin ich recht zufrieden, nicht grafisch, nicht von der Usability oder der User Experience, sondern da man in sehr kurzer Zeit passable Ergebnisse erzielen kann. Jetzt gilt es auf diesen Ergebnissen aufzubauen und in die Breite zu gehen damit die Anwendungen auf mehr Geräten laufen, denn das ist das erklärte Ziel.

Widget Übersicht
Zum Schluss noch die Übersicht über die Widgets und deren Funktionsumfang. Wie gesagt, die Widgets sind einfache Zip-Archive und den Source bekommt man indem man das ganze entpackt.
  * Stop Watch
Nur eine sehr einfache Stoppuhr

  * Sport Track
Die einfache Stoppuhr kombiniert mit Standort Informationen um die zurückgelegte Wegstrecke zu berechnen

  * GeoLocationClient
Dieses Widget basiert sowohl auf jQuery als auch auf iui. Wenn sich die Orientierung ändert wird die Darstellung neu berechnet. Es wird aufgrund der aktuellen Position eine Karte geladen die eine Zoom-In/Out Funktion bietet. Der Benutzer ist in der Lage einen Suchbegriff zu speichern und dieser steht beim nächsten Mal wieder zur Verfügung. Weiterhin wird eine lokale Suche durchgeführt aufgrund der aktuellen Position und des eingegebenen Begriffs. Eine eigene Logging Implementierung informiert den Benutzer über die durchgeführten Aktionen. Die Karte lädt manchmal nicht automatisch. Dann hilft der Zoom oder der Reload. Wenn jemand weiß warum oder einen Fix hat bin ich daran interessiert!

So das wars jetzt aber. Beim nächsten Mal schaue ich mir mal den Androiden an. Ihr könnt mich natürlich wie immer über die gegebenen Kanäle erreichen und mir eure Meinung sagen.

Back to top