Kommunikation von Services untereinander und mit der Oberfläche?

Hallo,

es geht um Folgendes:

Ich programmiere mir gerade eine Fahrradcomputer App.

Diese soll zunächst diese Funktionen bieten:

- Tachoanzeige mit aktueller Geschwindigkeit, Tageskilometer, Durchschnitt usw.
- Maps-Ansicht mit Anzeige der aktuellen Position
- Tracking History Funktion. Es werden alle Fahrtrouten aufgezeichnet und
man kann diese jederzeit abrufen
- Anzeige von GPS Status Informationen

Ich habe diese Funktionen jeweils in einer eigener Activity realisiert,
sie sind über einen Hauptbildschirm aufrufbar.

Die Oberflächen sind weitestgehend umgesetzt, jetzt geht es
an die programmtechnische Umsetzung der Funktionen.
Die MapView habe ich bereits integriert und die GPS Status Infos
werden auch in Echtzeit angezeigt.

Nun bin ich auf eine Problematik gestoßen, bei der ich nicht so recht weiterkomme.
Der LocationManager samt seiner Funktionen (+Konvertierungsmethoden etc.) wird ja
in mehreren Activities benötigt. Außerdem wird ein XML Writer/Reader (gpx Format)
für die Trackingfunktion implementiert werden müssen.
Diese (eigentlich) Hintergrundprozesse würde ich in einen oder mehrere Services
und damit GUI unabhängige Threads auslagern. Ist dieser Ansatz schonmal richtig?
Falls ja kann ich mir noch nicht so richtig vorstellen, wie der Austausch mit
den einzelnen Activities von statten gehen soll?! Wird dies mit dem Intentsystem
umgesetzt oder gar BroadcastReceivern? Oder ist das nicht geeignet dafür und ich
muss die Interprozesskommunikation von Java (hat erstmal nichts mit Android zutun)
verwenden?

Für einen Denkanstoß wäre ich sehr dankbar, da ich im da Moment etwas im Dunkeln tappe
und auch den richtigen Ansatz wählen möchte.

Vielen Dank schonmal!

Super, vielen Dank! Auch das mit der Wiederaufnahme des Trackings nach einem evtl. Absturz ist ein guter Hinweis. Sowas findet man in der Literatur nirgends.

Ich habe es jetzt mal ausprobiert, indem ich den Broadcast-Receiver als innere Klasse der Activityimplementiert habe. Der Service versendet einen benutzerdefinierten Intent, auf den ich dann filtere.
Ist das so ein guter Weg oder sollte ich die BroadcastReceiver als eigene Klassen erzeugen?
Dann stellt sich mir aber die Frage, wie die Kommunikation zur jeweiligen Activity von statten gehen soll. Dann bräuchte ich ja wohl nochmals einen Intent, was umständlich wäre.

Außerdem müsste ich noch wissen, ob ich die ausgelagerten Funktionen XML Read/Write und LocationFunktionen in einen gemeinsamen Service packen soll oder das Ganze in zweien getrennt halte?

Jup, aber genau das mach ich ja auch. Das meinte ich mit innerer Klasse. Wollte nur wissen, ob dies die bessere Lösung ist (anstatt den BroadcastReceiver in eine eigene abgeleitete Klasse einer neuen Datei zu verlagern)

Prinzipiell spricht ja nichts dagegen, aber ich finde den Übergabeprozess dann doch etwas unnötig verlängert, wenn man macht:
- Activity ruft Service über Intent auf
- Service sendet im LocationChanged ein BroadcastIntent
- Broadcast empfängt BroadcastIntent
- Broadcast sendet Intents mit den Daten an alle betroffenen Activities
- Activities empfangen Intent und führen nun endlich ihre Oberflächenupdates aus
Ist das wirklich ein guter Weg?

Ok ok, hast mich ja überzeugt.



Naja, ich gehe bei diesem Konstrukt eben davon aus, dass die Broadcastreceiver nicht als innere Klassen der Activities realisiert sind, sondern
direkt als eigene Klassen, die von Broadcastreceiver ableiten.
Dann muss ja irgendwie die Kommunikation zwischen den Broadcastreceiverklassen und den Activities (auch eigene Klassen) hergestellt werden - und das geht doch nur über Intents oder?

Kleine Umformulierung:
- Broadcastreceiver empfängt BroadcastIntent vom Service und reagiert darauf in seiner OnReceive()-Methode
- Broadcastreceiver sendet in der OnReceive()-Methode Intents mit den Daten an alle betroffenen Activities


In diesem Fall sind die Klassen zB. so:

— geändert am 21.06.2012, 21:10:24

Irgendwie finde ich diese Art zu implementieren nicht "so schön". Es macht den Code unübersichtlich und entspricht nicht dem objektorientierten Kapselung. Aber wie du schon erwähnt hast, ist es wohl bei BroadcastReceivern nicht angemessen, diese als eigene vollwertige Klasse auszulagern.
Wie ich schon sagte, fände ich das zusätzliche Senden eines Intents zu der Acitvity wiederum zu holprig. Man macht es sich damit ja nur unnötig schwer und bläst den Code dadurch nur auf. Somit werde ich wohl die Implementierung als inneren Klassen wählen.
Mich hat es im Prinzip auch nur mal interessiert, wie du diese Alternative findest.



Doch, ich denke ich hab's gefunden?
http://developer.android.com/guide/practices/performance.html#package_inner
Sieht aber auf den ersten Blick so aus, als würde hier gegen Inner Classes argumentiert.

Übrigens danke für diesen Tipp mit der Performance Sparte. Kannte ich nicht und ist sehr interessant!