Passendes Mobiltelefon gefunden! Frage damit beantwortet!
Suche Handy programmierbar in Java Me für Bluetooth, WLAN und GPS.
-
-
-
Darf man seiner ungezügelten Neugier freien Lauf lassen und fragen, welches?
-
Für den Moment verwende ich Mobiltelefone mit folgender Spezifikation:
S60 Nokia Handy mit Symbian OS, 5th Edition
Der Typ spielt keine Rolle, da die Spezifikation entscheidend ist.
Meine Telefone stellen bereit:
Qt
Java
Open C/C++
Symbian C++Zusätzlich zu Bluetooth, WLAN und GPS nutze ich die eingebaute Sensorik:
JSR 139 Connected, Limited Device Configuration (CLDC) 1.1
JSR 118 MIDP 2.1
JSR 248 Mobile Service Architecture Subset for CLDC
JSR 75 FileConnection and PIM API 1.0
JSR 82 Java™ APIs for Bluetooth 1.1
JSR 172 J2ME™ Web Services Specification 1.0 (RPC package)
JSR 172 J2ME™ Web Services Specification 1.0 (XML Parser package)
JSR 179 Location API for J2ME™ 1.0
JSR 184 Mobile 3D Graphics API for J2ME™ 1.1
JSR 205 Wireless Messaging API 2.0
JSR 256 Mobile Sensor API
Nokia UI API 1.2Other APIs
Open C APIs
Open C++ APIsSensor API Channels
Accelerometer Double Tap
Accelerometer XYZ
Magnetic North
Magnetometer XYZ
Orientation
RotationIch programiere aktuell in Java, Python und C++. Sobald ich mit meiner Programmiererei fertig bin, schaue ich mir Symbian noch genauer an.
Ich werde allerdings auf andere Marken umschwenken, um zu schauen, ob die bekannten NOKIA Bugs dort auch zu finden sind.
Meine Java Programme sind abwärtskompatibel. Will meinen, alle neuen und alten Programme laufen auf jedem meiner NOKIA Handys, egal wie alt es ist, sofern JAVA unterstützt wird.
-
… und wie hast Du die Bluetooth-Timeouts in den Griff bekommen? Verlässt das entfernte/gescannte Gerät den Empfangsbereich hänge ich hier in Timeouts, die mir im Vergleich zur Nokia Series 40 zu lang sind.
-
Ich habe kein Timeout Problem oder sehe das Suchen nicht als Timeout Problem an.
Ich gehe zurück auf das, was ich schon mal geschrieben haben:
Der ablaufende Prozess findet ein Gerät oder eben er findet kein Gerät. Bei JAVA ME dauert die Suche samt Timeout ca. 20 Sekunden. Danach macht das Programm eine Pause und beginnt eine neue Suche.
deviceDiscovered( RemoteDevice remoteDev, DeviceClass devClass ) {}
servicesDiscovered( int transID, ServiceRecord[] servRecord ) {}
serviceSearchCompleted( int transID, int respCode ) {}
inquiryCompleted( int discType ) {}Ich bin seinerzeit mit dem Studium des folgenden Artikels angefangen:
http://www.developer.nokia.com…uetooth_device_in_Java_ME
Nokia fügt quasi Geräte zu einer Liste hinzu oder entfernt sie. Mehr mache ich im Prinzip auch nicht. Ich habe nur noch eine Schleife über den Przess gestülpt. Mit einer Wartezeit von 5-10 Sekunden zwischen den Durchläufen habe ich bei der kontinuierlichen Erkennung kein Problem.
-
Ach so, Du verbindest nicht, um die Dienste zu checken.
Ich habe das Problem, dass ich das Gerät verbinde. Ich lade die Dienste. Das „dauert“. Verlässt das Gerät während dieser Zeit meinen Empfangsradius, wartet Symbian „sehr lange“, bis es die Verbindung schließt. Und währenddessen kann ich nicht weiter suchen.
-
Ich frage nicht alles zusammen ab.
Dienste frage ich gesondert/gezielt ab. Ich wähle aus einem Menü das zu untersuchende Handy und schaue dann, was ich finde.
Meine Suche beschränkt sich im wesentlichen auf MAC und FDN. Minor/Major Class und Services frage ich gesondert ab.
-
Wobei selbst der Friendly-Device-Name (FDN) für mich immer eine Verbindung war – also mit all den Risiken eines Verbindungsverlusts + Timeout. Vielleicht löst der aktuelle Bluetooth-Stack in Symbian das über das Extended-Inquiry. Ich werde mal wieder testen müssen.
-
Ich denke folgendes.
Das Entscheidende bei der Suche nach Bluetooth Geräten ist die MAC Adresse.
Das Remote Device erhält man aus:
getRemoteDevice(javax.microedition.io.Connection conn)Schaut man sich das Remote Device an, so stellt man fest, dass es sich formal um nichts anderes als einen Hash Code handelt.
getBluetoothAddress() macht eigentlich nichts anderes, als das 'gefundene Gerät' lesbar zu machen. getBluetoothAddress ist also sozusagen getRemoteDevice.
Ich habe z.B. eine Klasse 'myRemoteDevice' erzeugt, um aus einer MAC Adresse ein Remote Device zu errechnen.
getFriendlyName(boolean alwaysAsk) macht hingegen etwas anderes. Hier wird direkt noch einmal versucht, den Namen korrekt über die Luftschnittstelle zu erhalten.
Probiert man quasi getBluetoothAddress() und getFriendlyName(boolean alwaysAsk) in Konkurrenz, so stellt man fest, dass die MAC Adresse über getBluetoothAddress() sofort verfügbar ist, während der Name über getFriendlyName(boolean alwaysAsk) u.U. weitere 20 Sekunden benötigt.
Da der FDN nicht wirklich etwas aussagt, ist die Suche für mich nur ein Add On, um zu sehen, was sich wohlmöglich hinter der MAC verbirgt (Omas Rechner oder Papas Handy). Über Major und Minor Class ist ja schon vorab bekannt, um was für eine Gerät es sich genau handelt.
Wertet man MAC und die Classes aus, so kann man schön sehen, ob gerade eine Audi mit Bluetooth Schnittstelle an einem vorbeifährt, oder aber ein Handy spazieren geht, oder aber neben einem ein Laptop steht.
Jetzt mitmachen!
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!