Archiv:

Latest photoblog

photoblog

Blog » LBS

W3C Geolocation API Polyfill

Ich habe meine freie Zeit gerade etwas genutzt um ein Javascript zu erstellen, mit dem man aus dem Browser heraus auf eine einheitliche Geolocation API zugreifen kann. Aktuell unterstützt das Script offiziell die folgenden Browser:

  • Android Webkit
  • Android Dolphin HD
  • Apple iPhone/iPod Safari iOS 3.0+
  • Blackberry OS 4.1+
  • Firefox 3.5+
  • Firefox < 3.5 mit Geode Addon
  • Google Chrome
  • Opera 10.6+
  • Alle Browsers mit installiertem Google Gears

Andere Browser bieten zur Zeit keine Unterstützung für Geolocation (korrigiert mich bitte wenn ich einem Browser Unrecht tue).

Wie wird das Script verwendet?

Das Script muss einfach vor dem ersten Geolocation Request eines Dokuments mittels <script src="geolocation.js"></script> eingebunden werden. Danach kann einheitlich durch navigator.geolocation.* auf die Methoden aus dem W3C Standard zugegriffen werden. Namentlich sind das getCurrentPosition(), watchPosition() und clearWatch().

Das Script mappt dann die proprietären Abfragemethoden (Blackberry Location, Google Gears) auf das navigator.geolocation Objekt und stellt eine einheitliche API zur Abfrage bereit.

Demo

http://www.manuel-bieh.de/publikationen/scripts/geolocation/demo.html

Download

Das Script gibt es bei Github und auf Google Code. Zieht es euch dort, wo es euch lieber ist. Ich halte für gewöhnlich beide Versionen auf dem aktuellen Stand
Google Code: http://code.google.com/p/better-geolocation-api/
Github: https://github.com/manuelbieh/Geolocation-API-Polyfill

Es tut sich was, bei der Geolokalisierung

… wenn vielleicht auch nur langsam: bei insFX ist ein Artikel erschienen in dem schön beschrieben wird, was ich hier ja bereits öfters bemängelt hatte; nämlich die native Unterstützung der Standortermittlung im Browser.

Hier gehts es zum Artikel: Der iPhone-App Killer: Mobile Webbrowser bekommen endlich Zugriff auf die Geolocation! Und hier noch eine etwas ältere Ausführung von mir, von Anfang des Jahres, mit einigen Fragen und Wünschen: Einige Dinge die ich mich gelegentlich frage.

Dann dürfte es ja jetzt nur noch ein paar Jahre dauern, bis sowas vielleicht flächendeckend funktioniert, schön!

Einige Dinge, die ich mich gelegentlich frage …

… im Bezug auf Location Based Services.

  1. Wann werden wir Location Based Services endlich vernünftig nutzen können?
  2. Warum hält es kein Handset-Hersteller für nötig, per aktivierbarer Optionen in den Browsereinstellungen, die Übertragung der GPS-Koordinaten an die angeforderte Seite bspw. mittels Headerdaten o.Ä. zu erlauben, wenn GPS sowieso schon im Gerät integriert ist?
  3. Wann portiert Google sein Gears-Framework inklusive Geolocation-API endlich auf Symbian und Co?
  4. Warum muss das alles so kompliziert sein?

Zu 1.

Mit vernünftig meine ich: wirklich vernünftig! Vernünftig, im Hinblick auf Einfachheit, Integration und Standards. Ich möchte mir nicht für jede noch so kleine (aber dadurch nicht zwangsläufig weniger interessante) ortsbezogene Applikation eine Software laden und im Handy installieren müssen. In einigen Fällen, wie z.B. aka-aki, die sich auf Bluetooth Reichweite beschränken wollen, mag das noch sinnvoll sein. Auch Google Maps Mobile, deren Schwerpunkt (vorerst) nicht im Wesentlichen auf den ortsbasierten Infos liegt und was zudem ein sehr komplexes (aber gutes) Handling beinhaltet, nehme ich hier aus. Aber neuere (Smart-)Phones beherrschen inzwischen alle Javascript, zu teilen sogar XMLHttpRequest/AJAX, Flashlite und diverse andere üblichen Webtechnologien. Dennoch kocht hier jeder sein eigenes Süppchen und stellt umständlich, da notwendigerweise für unzählige Handsets einzeln optimiert, eigene Applikationen zur Verfügung, jeweils für Symbian, Windows Mobile, Android, iPhone OS und was es nicht noch alles gibt.

Zu 2.

Punkt 2 knüpft hier nahtlos an Punkt 1 an. Bedeutend einfacher wäre hier meiner Meinung nach, wenn die Mobiltelefon-Hersteller von sich aus eine simple, idiotensichere Funktion, in den ab Werk integrierten Handybrowser einbauen würden, die es dem Benutzer ermöglicht, einer aufgerufenen Seite per SEND-Header (bspw: "HTTP_USER_LOCATION=51.514285,7.464201" oder etwas ähnliches) die aktuellen Aufenthaltsdaten zukommen zu lassen. Diese werden mittels im Telefon integriertem GPS-Empfänger ausgelesen, und ein Seitenbetreiber kann so nun Standort-Informationen zu den vom Benutzer übermittelten Koordinaten zur Verfügung stellen. Mir ist durchaus klar, dass dies ein ziemlicher Datenschutz-/Sicherheits-GAU werden könnte, meiner Meinung nach würde es aber ausreichen wenn diese Funktion in der Werkseinstellung deaktiviert ist. Leute, die wissen was Sie tun, aktivieren die Option, alle anderen bekommen davon eben nichts mit und können auch nicht geortet werden.

Eine solche Option könnte für mich im Einstellungsmenü in etwa so aussehen:

Standortdaten beim Seitenaufruf übermitteln

Zu 3.

Google hat hier mit seiner MyLocation/Geolocation-API im Gears-Framework einen ersten Anfang gemacht. Diese API erlaubt es die aktuellen Standortdaten über Javascript abzufragen, jedoch nur dann, wenn Gears auf dem Client-Rechner installiert ist. Allerdings ist Gears proprietär und bisher nur für Windows, Mac, Linux und Android verfügbar, ob jemals eine wirklich (Mobile-)plattformübergreifende Version herausgebracht wird, ist angesichts der Tatsache, dass Google mit Android über ein eigenes Mobile OS verfügt, äußerst fraglich. Die Standortabfrage wäre dann jedoch im Browser ganz einfach möglich, mit dem folgenden kurzen Code-Schnipsel:

<script type="text/javascript" src="gears_init.js"></script>
<script type="text/javascript">
var geo = google.gears.factory.create('beta.geolocation');
function updatePosition(position) {
  alert('Current lat/lon is: ' + position.latitude + ',' + position.longitude);
}
function handleError(positionError) {
  alert('Attempt to get location failed: ' + positionError.message);
}
geo.getCurrentPosition(updatePosition, handleError);
</script>

Wird aber wohl erstmal ein Traum bleiben. Das W3C arbeitet zwar an einer Geolocation API, was das aber irgendwann mal ergibt, wie das in der Praxis aussieht was die Implementierung und Anwendbarkeit dieser durchaus interessant klingenden API angeht und wann diese Technik jemals flächendeckend verwendet werden kann, das steht wohl in den Sternen.

Zu 4.

Mit Google Maps Mobile, Aka-Aki und dem Nokia Sports Tracker befinden sich aktuell drei LBS-Anwendungen auf meinem E90 Communicator. Für jede Applikation, die sich auf meinen Standort berufen will, kommt eine weitere Anwendung hinzu, die installiert werden muss. Für mich als jemanden, der in diesem Bereich zuhause ist, ist das auch absolut kein Problem. Allerdings werden Location Based Services meiner Meinung nach nie zu dem Massen-Durchbruch kommen, der ihnen schon seit Jahren vorausgesagt wird, wenn sich an der Anwendbarkeit nicht schnell einiges ändert und vereinfacht wird. Und nein, auch das iPhone bietet für mich, trotz leichter Bedienbarkeit, keine zufriedenstellende Lösung. Es mag sein, dass es dort dank App-Store und allerhand netter Features recht einfach geworden ist, sich diese Tools auf das Gerät zu holen. Probleme wie die Plattformabhängigkeit bzw. die Notwendigkeit zur oft kostenintensiven Entwicklung für die verschiedensten Plattformen sind damit auch nicht gelöst, so lange das iPhone nicht 95% aller Marktanteile besitzt – äußerst unwahrscheinlich.

Was wir im mobile Web meiner Meinung nach wirklich brauchen, ist eine einheitliche, standardisierte Schnittstelle, ähnlich dem oben beschriebenen Google-Ansatz. Auch finde ich keine fundierten Gegenargumente, was gegen meinen Vorschlag mit den durch den Header gesendeten Standortdaten sprechen könnte. Aber ich fürchte dazu wird es weder in kurz- noch in mittelfristiger Zukunft mal kommen und die Anwender werden weiterhin jedes Mal damit belästigt, eine Software installieren zu müssen, möchten sie auf Location Based Services zurückgreifen.