Ein Smartphone ist ein Gerät mit einer großen Anzahl von Sensoren. GPS, Kompass, Accelerometer und Gyroskop sind fast immer vorhanden. Einerseits.
Andererseits ist das Debugging einer Android-App nicht wirklich einfach. Deshalb war die Idee, die Sensor-Daten auf einen PC zu übertragen und dort komfortabler mit .Net auszuwerten. Die erste Idee war eine serielle Verbindung per Bluetooth zu nutzen. Mit meinem Smartphone, ein Samsung Galaxy S III mini (Modell GT-18200N), war das leider nicht möglich. Da hat auch das tagelange ausprobieren von Tipps aus dem Internet nicht geholfen. Genauso erging es mir mit USB. Es bleibt WiFi. Erste Versuche waren recht erfolgreich. Was herauskommen soll, ist ein TCP-Server auf dem Smartphone, der von einem Visual Basic TCP-Client auf dem PC angesprochen werden kann. Und das Ganze natürlich auch in umgekehrter Richtung. Also
1. Der Plan
Features Server:
- Startet mit Start der Applikation
- Zeigt die eigene IP-Adresse und den Service-Port an
- Zeigt eine eingehende Anfrage an
- Liefert als Rückmeldung ein Echo der Anfrage
- Ist die Anfrage eine Ganzzahl wird diese um eins erhöht und zurückgeliefert
Features Client:
- Prüfen, ob eine IP im Netzt erreichbar ist (Ping)
- Eingabe einer Message
- Schaltfläche zum senden der Nachricht
- Anzeige der Antwort des Servers
Die Objektmodelle in beiden Systemen erlauben es, relativ ähnliche Algorithmen zu nutzen. Aus diesem Grund wurde so viel wie möglich identisch gehalten. Dies gilt auch für die Namenskonventionen. Da Eclipse meckert, wenn man sich nicht an den üblichen Java-Stil hält (z.B. lowerCamelCase) wurden die Java-Konventionen auch nach VB übernommen.
Die erste Herausforderung auf dem Android-Handy war, die eigene lokale IP-Adresse heraus zu finden. Details gibt es hier:
- getWlanIp(): Ermittelt die eigene IP-Adresse
- checkIp(): Zur Überprüfung der Erreichbarkeit eines Servers
2. TCP-Server
Die von .Net (Namespace System.Net(.Sockets)) und Java (Package java.net) bereitgestellten sind sehr ähnlich und basieren auf einer Socket-Struktur. In beiden Fällen (Kern-Funktionalität) wird ein Socket eingerichtet, der auf eingehende Verbindungswünsche eines Clients reagiert. In diesem Fall einen Text einliest, diesen ggf. etwas modifiziert und wieder zurück sendet.
Das Warten auf eine eingehende Verbindung blockiert den Programmablauf. Damit die Oberflächen nicht einfrieren und weiterhin bedient werden können, laufen die Server in einem eigenem Thread.
Der Übersichtlichkeit wegen wurde beide Varianten in einer Klasse gekapselt. Das API dieser Klasse besitzt eine Methode zum Start (start) des Servers (des Threads) und eine zur Rückmeldung einer eingegangenen Nachricht (onMessageArrived). Im VB-Fall ist dies ein Event, bei Java eine Callback-Funktion.
In .Net ist es etwas komplizierter, aus einem asynchronen Thread ein Steuerelement anzusprechen (zumindest ich habe es bisher nicht richtig kapiert). VB kennt aber die Klasse BackgroundWorker, die diese Probleme kapselt und ein einfach zu handhabendes Interface bereit stellt. android.os stellt die Klasse AsyncTask bereit, die eine ähnliche Funktion bietet. Demzufolge muss im VB-Hauptprogramm ein passender Eventhandler implementiert werden. Im Java-Programm muss die Klasse abgeleitet und die Rückruffunktion passend überschrieben werden. In beiden Implantierungen wurde auf eine detaillierte Fehlerbehandlung verzichtet.
Anzumerken wäre noch, dass Textzeilen eingelesen werden. Es ist also wichtig, dass die Nachrichtentexte mit einer Zeilenende-Kennung abgeschlossen werden.
Details zur Server-Implementierung
3. TCP-Client
Das API des Client besteht nur aus einer Methode public String transmit(String HostName, int Port, String Message). Es werden die Zieladresse, der Service-Port und die zu sendende Nachricht übergeben. Zurückgeliefert wird die Antwort des Servers. Auch hier findet keine detaillierte Fehlerbehandlung statt. Tritt ein Fehler wird die Fehlermeldung einfach im Rückgabe-String eingetragen.
Die Kernfunktionalitäten sind in beiden Varianten wieder sehr ähnlich. Socket zur Übertragung einrichten, Verbindung herstellen, Nachricht senden, Antwort abwarten und zum Schluss die Verbindung wieder schließen.
.Net erlaubt es, dies in eine einfache Funktion zu packen. Demzufolge ist für die VB-Implementierung keine weitere Sonderbehandlung notwendig. Android hingegen beschwert sich mit einer Exception, wenn eine Netzwerk-Funktion im Main-Thread aufgerufen wird. Hier muss die Übertragungsfunktion in einen separaten Thread gekapselt werden. Da ein Rückgabewert erwartet wird, bietet es sich an, ein Callable zu nutzen.
Details zur Client-Implementierung
4. So sieht's aus
PC-Applikation
Android-App
