HowTo Sensor-App Entwicklung

Hallo Android-Programmierer,

ich bin auf der Suche nach Unterstützung bei der grundlegenden Erstellung einer Test-App. Mir fehlt die Erfahrung wie eine gut strukturierte Android-App aufzubauen ist.

Ich möchte eine Test-App aus einem mir vertrauten Themengebiet bauen, welche es schon x-fach gibt, ich aber verstehen möchte wie die Abläufe sind und auf was man bei der Entwicklung achten sollte sowie welche Tools einem das Abtesten erleichtern.

Was soll die App machen?
Durch drücken eines Button sollen alle verfügbaren Sensorsignale und GPS-Signale im Hintergrund abgefragt werden und mit einem Zeitstempel versehen an die UI und eine Tempdatei, Datenbank oder so in einen Ringspeicher zu Aufzeichnung und Weiterverarbeitung in einer sinnvollen Struktur weitergegeben werden. Die Anzeige soll erstmal nur in Zahlenform darstellen, aber auch beliebige weitere Activities sollen auf diesen zentralen Datenstream zugreifen können. Um die Bedienbarkeit robust zu bekommen möchte ich das Thema Threading hier mit einbeziehen und die verschiedenen Activities/Services sinnvoll aufteilen.

Wer könnte mir hier beginnend mit einem grundlegenden, cleanen Architekturaufbau mit Tipps und Link-Empfehlungen unter die Arme greifen, so dass ich am Ende verstanden habe wie professionelles Programmieren abläuft und eine saubere OOP-Struktur aussieht?

Als Ingenieur im Automotive-Bereich komme ich eher aus einer funktionsorientierten Programmierdenke (Nehme Eingangssignal x, manipuliere dieses und gebe es als Ausgangssignal an die nächste Funktion weiter), unterstützt im Wesentlichen durch grafikunterstützte Tools wie Matlab/Simulink/Stateflow. 

Seit mehreren Jahren versuche ich in die OOP-Denke reinzukommen. Dafür habe ich mir die JAVA-Grundkenntnisse über einschlägige Literatur, Tutorials und VHS-Kurse angeeignet, mich durch die AndroidDevelopers-Seiten geforscht und mehrere Anläufe in Android Studio gewagt. Aktuell fehlt mir die Möglichkeit neben dem einseitigen erklärt bekommen auch mal Fragen stellen zu können um nicht am Anfang schon in eine Sackgasse abzubiegen.

Ich bin gespannt ob sich hier jemand findet oder man evtl. diesen Post als Beispiel-Tutorial gemeinsam aufbaut... Antworten gerne hier oder nach Belieben per PN.

Erste konkrete Fragen sind:

Wie sieht für meine Anwendung eine sinnvolle Aufteilung in Activities und Services aus und welche Multi-Threading-Methode wäre zu empfehlen (ich würde zu Async-Tasks tendieren und die Sensorwerte an den UI-Thread zentral übergeben).

Viele Grüße

Oliver

Hallo Pascal,

danke für deine Erläuterungen. Wie schaut es denn mit der Festlegung des Threadhandlings aus? Der Link auf DevDeeds scheint sich nur auf die Geodaten in einem Thread zu konzentrieren und beendet den Service wenn die Activity geschlossen wird. Ich würde die Aufzeichnung auch gerne weiterlaufen lassen wenn die Activity verlassen wird und erst durch erneuten ButtonPush stoppen. Und das ohne die UI zu beeinträchtigen.

Wie erarbeitet man sich die Software-Architektur bevor man losprogrammiert? Wenn ich jetzt den DevDeeds-Umfang übernehme und dann die Sensorerfassung aus einem anderen Beitrag, dann werde ich doch eher in einen bunten Code-Mix ohne vorher definierte Struktur enden, oder?

Ok. Danke. Welches Multithreading-Konzept sollte ich für meine Anwendung in den Fokus nehmen? Ich würde wie erwähnt gerne im Hintergrund stumpf einen (oder mehrere) Services permanent laufen lassen und den Ringspeicher befüllen. Die UI soll dann nur auf den Ringspeicher zugreifen. Macht das Sinn?

Liege ich richtig, wenn ich einen Service für die internen Sensordaten, einen für die GPS-Signale und einen zentralen Sammel-Service (Datenhandling) nutze und die Activity nur mit dem Sammel-Service kommuniziert?

Ja - ich würde die Sensorsignale alle 10ms oder 100ms auslesen, wobei z.B. der Beschleunigungssensor auch bis zu 2ms könnte, für mich aber nicht notwendig ist. GPS liegt systemseitig i.d.R. eher bei 1000ms.
In meinen ersten Testversuchen habe ich die UI in kürzester Zeit durch den Service über den Main-Thread lahm gelegt, auch wenn ich nur die reinen Float-Zahlen in der Activity habe anzeigen lassen.
Von daher würde ich gerne die Services von vornherein in min. einem eigenen Thread laufen lassen. Welche Thread-Variante eignet sich dafür?

Die strukturierte Kommunikation zwischen Services bzw. Activities ist ein weiterer Punkt den ich bei Gelegenheit gerne genauer verstehen möchte. Aus Matlab kenn ich nachvollziehbare Structures in denen alle Signalwerte logisch hinterlegt werden. Dort gibt es z.B. die Logik eines zentralen Streams der als Beispiel "Signal.Acceleration.X.value" lauten könnte. Ähnlich einer Baumstruktur werden alle Werte ebenweise in einem einzigen zentralen Objekt zusammengefasst. Gibt es so eine Logik auch in Android-Java oder fliegen hier alle Signalwerte alleine für sich durch den Programmraum und müssen individuell von anderen Services/Activities abgegriffen werden ?

Ich habe gestern Abend noch etwas recheriert und das DevDeeds-Beispiel von oben ausprobiert. Dort wird die Position aber nicht über GPS abgefragt sondern über das Internet.

Heute früh habe ich dann folgende Vorgehensweise überlegt:
Im ersten Schritt erstelle ich einen einfachen Background-Thread der nur Text an die Activity gibt um zu testen ob das grundsätzlich funktioniert.
Xfabcirablog.weebly.com/blog/creating-a-never-ending-background-service-in-android

Dann würde ich im nächsten Schritt die GPS-Signale anhand dieses Beispiels in den Background-Service einbinden.
Xstackoverflow.com/questions/28535703/best-way-to-get-user-gps-location-in-background-in-android

Wenn das dann schon mal funktionieren sollte ist das nächste Ziel, die Signalkommunikation zwischen Service und Activity von Broadcast auf eine Zwischendatei (=Ringspeicher) umzustellen.

Klingt das zielführend?

Hat ein dateibasierter Ringspeicher nicht den Vorteil, dass man die Synchronitätsprobleme verschiedener Threads umgeht indem der eine (Background-Thread) stumpf die Werte in die Datei schreibt und der UI-Thread unabhängig davon in einem frei definierbaren Zeitraster (z.B. alle 100ms) die Anzeige mit den Werten aus der Datei aktualisiert? Oder ist die UI damit zu sehr belastet?

Upps - guter Punkt mit dem gleichzeitigen Read/Write-Problem einer Datei... dann werde ich mir die Singleton-Klasse mal anschauen.

Ich muss nochmal auf das Threading-Thema zurückkommen... ich habe die letzten Stunden wieder versucht herauszufinden welches der sinnvollste Weg für meine 10ms-Sensorabfragen ist und bin vom AlarmManager über ServiceIntent und JobServiceIntent bis hin zum JobService über alle möglichen Varianten geleitet worden. Der JobService scheint vor allem ab Oreo bzgl. Background-Regulatorik und Akku-Verbrauch die nachhaltigste Variante zu sein, benötigt aber wieder eine separate Threadhandling-Methode um nicht im Main-Thread die Sensorabfrage durchzuführen.
Aktuell bin ich wieder vor lauter Bäumen im Wald so schlau (bzw. so doof) wie die letzten Jahre auch schon - warum ist das Threadhandling so unendlich (oder unnötig?) kompliziert?

Kann man auf einfache Weise (und Oreo+ stabil) selbst definieren welcher Service in welchem Thread laufen soll oder ist es evtl. sinnvoller aus einem Service im Main-Thread heraus alle 10ms einen AsyncTask aufzurufen?

Hallo Stefan,

danke für deine schnelle Antwort. Es gibt ja schon dutzende Apps die unter Android genau diese Sensor-Erfassung im 10-100Hz Bereich über mehrere Stunden ordentlich machen können (z.B. OBDLink, RaceChrono, Torque, DriveDeck, TrackAddict, usw.)

Irgendeinen Weg scheint es also zu geben um diese Signalerfassung zu ermöglichen. Die Frage ist nur welche hier am ehesten funktioniert.

Sehr gut - jetzt bekommt die Diskussion endlich etwas Würze

Ich glaube wir sind gar nicht so weit auseinander wie es erscheinen mag. Um CAN-Bus Anbindung in einem Fahrzeug geht es mir gar nicht. Mich interessieren zunächst nur die geräteinternen Sensoren und GPS. Eine Anbindung des OBD-Protokolls lassen wir erstmal aussen vor.
Ich habe ein OBD-ScanLink und mit der zugehörigen App OBDLink eine CSV-Datei meiner Autofahrt über eine Stunde mit dutzenden Signalen erzeugt. Größtenteils sind das OBD-Signale mit der bekannten ca. 1Hz-Abtastung, es werden aber auch die geräteinternen Sensoren aufgezeichnet und hier liegt die Abtastrate bei 20Hz (also 50ms).
Ich habe mal einen Screenshot einer Beispiel-Datei angefügt um es sich besser vorstellen zu können.

Mehr als das was dort gemacht wird suche ich eigentlich nicht für meine Test-App. 10ms ist nicht zwingend notwendig auch wenn dies die geräteinternen Beschleunigungssensoren grundsätzlich ermöglichen würden.

Passt alles - ich lasse die Habaneros im Schrank

Mehr als über die Listener möglich ist, ist nicht gefragt (mit 10-50ms eher sogar weniger).

Mein Problem liegt darin, dass ich verstehen muss wie die App-Architektur bzw. die Hintergrund-Services zu gestalten sind um diese über einen längeren Zeitraum laufenden Listener-Daten so zu sammeln, dass man im Nachgang mit diesen in einer Art Ringspeicher weiterarbeiten kann (z.B. Signalfilterung) und der UI-Thread nicht in die Knie geht (so wie in meiner aktuellen Erstumsetzung mit Services im Main-Thread nach wenigen Sekunden der Fall).

Wenn ich am Ende so eine CSV-Datei generiert bekommen würde wie es OBDLink schafft wäre ich schon einen Riesenschritt weitergekommen. Und in diesem Zuge müsste ich verstehen wie man in Android möglichst strukturiert mit interner Signalverarbeitung umgehen kann, also wie der "Datenstream" aussehen sollte um möglichst einfach aus verschiedenen Methoden auf diese Einzelwerte zugreifen zu können.

— geändert am 19.11.2018, 16:10:14

Sehr schön - daran kann ich etwas knabbern....

Zu a):
Mit dem Beispiel aus dem Link den ich weiter oben gepostet hatte (Xfabcirablog.weebly.com/blog/creating-a-never-ending-background-service-in-android) habe ich zumindest schon mal einen Service erschaffen, der sich automatisch selbst wiederbelebt wenn er aus irgendeinem Grund abgeschossen wird. Diesen müsste ich nun mit einem Start/Stop-Button versehen - das würde mir schon genügen.

Zu b):
Ist die SQLite schnell genug um die parallelen Listener-Daten im gewünschten Zeitraster wegspeichern zu können? Der Delay in der Anzeige oder in der Signalverarbeitung stört mich nicht - die Anzeige sollte nur nicht allzu zeitverzögert sein (<500ms).

Läuft das alles weiterhin im Main-Thread und die UI ist durch die SQLite-Arbeit nicht spürbar beeinträchtigt?

Ja - den Link auf den Kalman-Filter habe ich gesehen. Danke

Den Code schaue ich mir im Details noch an, aber grundsätzlich werde ich mit den möglichst rohen Sensordaten weiterarbeiten (je nach Signalverarbeitung abzüglich eines Tiefpassfilters im Bereich 10Hz). Mir geht es auch nicht darum einen Handysturz zu detektieren (es sei denn das Auto stürzt irgendwo ab an dem das Handy fest montiert ist )

Wieso gibt es generell so wenige Tipps bzgl. Multi-Threading? Ist das nicht etwas was bei der App-Programmierung sehr schnell relevant wird und bereits in der Software-Architektur mitüberlegt werden sollte? Hier fehlt mir weiterhin der "goldene Pfad" welchen in in den Fokus nehmen sollte.

Mit meinem Uralt-S6 habe ich bei den weiter oben erwähnten Daten-Loggern eigentlich keine großen Auffälligkeiten. Bei OBDLink merkt man nur, dass die Diagramm-Aktualisierung in der UI nur mit geringerer Prio bedient wird und sich sehr selten aktualisiert wenn man die allumfassende CSV-Datei im Hintergrund erzeugen lässt.