Buddy-Tracker (Technik) - Kommunikationsmethoden

Beitragsseiten

Kommunikationsmethoden

Der Buddy-Tracker kann über verschiedene Methoden Kontakt zu den Buddies aufnehmen.

Warum mehr als eine Methode?
Jede der Methoden hat ihre Besonderheiten. SMS ist sehr einfach, aber die Kommunikationsmenge ist sehr begrenzt und es kostet Geld. Einen eMail-Account hat jeder, aber nicht jeder will sich seine Inbox mit diesen automatischen Mails zumüllen oder einen separaten Mailaccount dafür anlegen. Shared Folder benötigt Zusatzsoftware, die auch erstmal beherrscht werden will ...
Außerdem kann ich so mit den Methoden experimentieren und Erfahrungen sammeln, wie praktikabel sie jeweils sind und wo ihre Stärken und Schwächen liegen.

eMail

Für die Klartext-Kommunikation mit Buddies, die den Buddy-Tracker nicht installiert haben, nutze ich den entsprechenden Android-Intent, der die jeweilige Default-eMail App startet und den Mailbody mit den entsprechenden Informationen füllt. Dies erfordert keine besonderen Berechtigungen für die App und der Benutzer kann seine gewohnten Kontaktdaten verwenden.

Für die regelmäßige automatische Kommunikation von Buddy-Tracker zu Buddy-Tracker ist diese Methode aber ungeeignet. Hier muß ich alle Mailparameter inclusive des Versands und des Abholens von Mails steuern können. Dies realisiere ich mit den Open-Source Mail-Funktionen aus der JavaX-Library. Die entsprechenden Funktionen werden dann über einen SyncAdapter aufgerufen. Um diesen benutzen zu können muß ich natürlich auch die passenden Account-Services erzeugen und bedienen.

Hier steht ein Update zum Firebase-Network-Manager an, der nochmal erweiterte Konfigurationsoptionen hat. So z.B. das Versenden von Mails abhängig von der jeweils aktuellen Verbindungsart. Könnte ich natürlich aus den System-Intents nachbilden, aber wenn es dafür vorgefertigte Libraries gibt ...

Shared Folder

Die Idee dahinter ist simpel: Es gibt Software mit der man einen lokalen Ordner und dessen Unterordner übers Internet mit Freunden teilen kann. Die Kommunikation ist dabei verschlüsselt und nur die gewünschten Freunde haben auch Zugriff. Also legt der Buddy-Tracker für sich in diesem Ordner einen Unterordner an, in dem er die zu teilenden Daten dann in Form einzelner kleiner Dateien, die die Nachrichtenart und den Zeitstempel im Dateinamen und die Payload als Dateiinhalt haben, ablegt.
Teilt man diesen Ordner dann mit Freunden, so bekommt man dadurch die Unterordner der Freunde auf sein Gerät synchronisiert. Synchronisiert dann die Sharing-Software neue Dateien in diesen Ordner, so bekommt das der Buddy-Tracker über File-Watcher, die in einem Hintergrund-Service gestartet werden, mit und kann die Daten enstprechend verarbeiten.

Allerdings ist man auf die Synchronisationseigenschaften dieser Software angewiesen ...

SMS

Eigentlch nur der Vollständigkeit halber implementiert, denn alleine der Kostenfaktor schränkt den Einsatz wohl sehr ein. Aber da die Funktion recht einfach umzusetzen ist ...

Location-Services

Als ich mit dem Buddy-Tracker angefangen habe, gab es zur Positionsbestimmung nur die Location-Services aus dem Paket android.location. Inzwischen propagiert Google seine eigenen Location-Services aus den Google-Play Services. Ich habe sie einem ersten Test unterzogen und für im Moment ungeeignet befunden.

Neben dem asynchronen Aufruf der Funktionen war die Qualität der Positionsdaten nicht ausreichend. Auch wenn man Positionen mit hoher Präzision anfordert liefert dieser Dienst gelegentlich Ergebnisse mit einer Genauigkeit von größer 500 Metern zurück (und zwar reproduzierbar in einigen Gebieten). Und das im zwar im Stadtgebiet aber unter freiem Himmel an Orten an denen die alten Android-Location Services problemlos genaue GPS-Daten liefern.

Abgesehen davon arbeiten die Google-Location Services überwiegend asynchron - man muß sich erst mit dem Google-API-Client mit der Google-API verbinden und kann erst dann seine eigentlichen Abfragen starten. Für die periodische Positionsabfrage im Hintergrund ist das O.K. Aber um zwischendurch mal einzelne Werte abzufragen - insbesondere bei Start der App, sind doch einige Klimmzüge nötig.
Will ich aber nur feststellen, ob der User gerade die Location-Services deaktiviert hat um z.B. auf der Karte den Button für die eigenen Position ausblenden zu können, kann ich nicht einfach das System fragen, sondern muß eine asynchrone Anfrage starten und das Ergebnis dann in einem Callback verarbeiten.

Zum Test habe ich die API-Aufrufe in einer Klasse gekapselt. In dieser Klasse gibt es eine weitere abstrakte Klasse, die meine interne private API für den Zugriff auf die Location-Services abstrahiert habe. Von dieser abstrakten Klasse sind dann zwei Klassen (wieder private innere Klassen) abgeleitet, die die jeweiligen APIs konkret umsetzen. So kann ich sogar on the fly die verwendeten Location-Services umschalten und die Ergebnisse miteinander vergleichen.

Des weiteren zeichne ich bei Geräten die einen Luftdrucksensor eingebaut haben, auch den aktuellen Luftdruck bei einer Positionsmessung auf. Aktuell wird das noch nicht weiter ausgewertet, verspricht aber bessere Ergebnisse bei der Bestimmung der Höhenunterschiede auf dem Track da die Luftdruckmessung genauer als die Werte vom GPS sein sollten.