n3po - Personen/Partnersuche via Bluetooth

• › PDF aus Powerpoint-Präsentation, Funktionsweise der Software [PDF | 9 MB ] [link 02]
• › Kurzes Demonstrationsvideo, Ablauf der Applikation auf Siemens S65, 320x240 [11 MB ] [link 03]

Inhaltliche Beschreibung

Während meiner Diplomarbeit über J2ME (Java 2 Micro Edition) entstand eine Applikation für Javafähige Mobiltelefone. Java ist eine Plattformunabhängige Programmiersprache und ermöglicht es, eine Applikation auf unterschiedlichen Hardware- und Betriebssystemplattformen ablaufen zu lassen. Alle modernen Handys unterstützen mittlerweile Java.

Einsatzbereich der Applikation ist die Suche von Personen mit bestimmten Merkmalen im direkten Umfeld via Bluetooth sowie die Herstellung einer direkten Verbindung zwischen zwei Personen bzw. deren Endgeräten und die Übertragung von Multimediadaten.

Dabei bietet die Applikation zwei grundsätzliche Suchmodi - zum einen die Suche über Kennwörter, welche individuell festgelegt werden können, zum anderen die Partnersuche über ein persönliches Profil, welches aus Merkmalen wie Alter, Größe, Geschlecht, persönlichen Interessen, sowie persönlichen und optischen Merkmalen besteht.

Angelehnt an die bekannten Internet-Partnerbörsen werden zwei Profile miteinander verglichen, welche zuvor direkt am Endgerät konfiguriert werden können. Ein persönliches Profil zur Beschreibung der eigenen Person, zum anderen ein Partnerprofil, das definiert welche Anforderungen der potentielle Partner erfüllen muss, beziehungsweise welche Eigenschaften unwichtig sind. Zusätzlich kann ein Übereinstimmungsprozentsatz definiert werden, den das Profil des potentiellen Partners erfüllen muss, also wie viele der gewünschten Eigenschaften der Partner aufweisen muss, damit das Profil akzeptiert wird.

Bei der Suche über Partnerprofile müssen beide Profile, auf beiden Endgeräten, zum jeweils individuell eingestellten Prozentsatz übereinstimmen, damit eine Kommunikation stattfindet. Falls nur ein Profil nicht passt, gehen beide Geräte ohne Rückmeldung an den Benutzer wieder auf die Suche nach anderen Geräten. Dabei werden die Geräte, mit denen bereits kommuniziert wurde, bei späteren Suchvorgängen nicht mehr berücksichtigt um unnötigen Datenverkehr zu vermeiden.

Die Profile werden nicht wie bei Internet-Partnerbörsen an einen zentralen Server geschickt, welcher die weitere Auswertung und Darstellung übernimmt, sondern per Bluetooth zwischen Mobiltelefonen ausgetauscht. Dafür wird auf jedem Endgerät ein Server gestartet, mit dem sich ein Client verbinden kann. Gleichzeitig sucht jedes Gerät in einem einstellbaren Intervall nach anderen Geräten mit aktiviertem Server um sich mit diesem als Client zu verbinden. Vorteil einer mobilen Partnersucheapplikation gegenüber den Internet-Partnerbörsen ist die örtliche Begrenztheit der Übertragung, potentielle Partner sind also nicht hunderte von Kilometern entfernt, sondern befinden sich innerhalb der Bluetooth-Reichweite, also maximal 10 – 100 Meter entfernt. Natürlich ist auch der „Erlebniswert“ der Applikation wesentlich höher als bei Internet-Plattformen, da die Personen unmittelbar und persönlich miteinander in Kontakt treten können.

Als zweiten Suchmodus bietet die Applikation die Personensuche über Kennwörter an, da auch eine Identifizierung von Personen mit gemeinsamen Interessen oder bestimmten anderen Eigenschaften ein interessantes Einsatzgebiet darstellt. Durch einfache Kennwörter oder komplexere Zeichenfolgen können so zahllose andere Anwendungsbereiche universell abgedeckt werden.

Die Suchfunktion über Kennwörter erlaubt die Eingabe von zwei Strings, zum einen das persönliche Kennwort, ein Begriff oder eine Zeichenfolge, unter der man selbst gefunden werden will, zum anderen das Partnerkennwort, ein Begriff oder eine Zeichenfolge nach der gesucht wird und welche zu findende Person als persönliches Kennwort definiert hat.

Beispielsweise können Käufer einer Gruppen-Fahrkarte am Bahnhof als persönliches Kennwort „Suche Mitfahrer“ eingeben, wenn sie mit Ihrem Ticket noch weitere Personen mitnehmen können, welche sich dann z. B. am Fahrpreis beteiligen.

Personen, die auf der Suche nach einer Mitfahrgelegenheit sind, geben als persönliches Kennwort „Suche Karte“ an. Damit man nicht nur gefunden werden kann, sondern selbst aktiv in der Umgebung sucht, muss das jeweilige Partnerkennwort eingegeben werden. Der Kartensuchende gibt also „Suche Mitfahrer“ als Partnerkennwort ein, da er nach Personen sucht, die „Suche Mitfahrer“ als persönliches Kennwort angegeben haben. Damit auch der Besitzer der Fahrkarte aktiv nach Mitfahrern suchen kann, gibt er als Partnerkennwort „Suche Karte“ ein, er sucht schließlich nach Personen die auf der Suche nach einer Mitfahrgelegenheit / Karte sind.

Weitere Szenarien für die Anwendung wären zum Beispiel Automärkte, Festivals oder Konzerte, die Suche nach Personen mit ähnlichen Hobbys oder eine Identifizierung, wenn man sich zuvor noch nie gesehen hat, über ein Passwort oder eine UID. Die zu verwendenden Strings müssen natürlich vorher vereinbart werden.

Wie häufig die Applikation nach anderen Geräten in der Umgebung sucht, legt Bewegungsprofil fest. Es sind drei Profile vordefiniert – „Sitzen“, „Gehen“ und „Joggen“, wobei die Applikation bei dem Profil „Joggen“ alle 20 Sekunden nach anderen Geräten sucht, da sich der Benutzer schnell fortbewegt. Das Profil „Gehen“ nimmt an, dass sich der Benutzer mit normaler Schrittgeschwindigkeit fortbewegt, die Suche nach anderen Geräten findet einmal pro Minute statt – beim Profil „Sitzen“ nur alle 5 Minuten. Der Benutzer hat die Möglichkeit ein bestimmtes Profil als Vorgabe zu Speichern, zudem kann das Profil auf dem Hauptbildschirm jederzeit temporär geändert werden.

Der Verlauf nach Abschluss der Suche ist bei beiden Suchvarianten gleich. Wenn ein Kommunikationspartner gefunden wurde (also ein Endgerät mit installierter und aktivierter n3po-Software), werden die Profile bzw. die Kennwörter verglichen.

Passen die Profile nicht zusammen, wechseln die Geräte wieder in den Suchmodus und halten nach anderen Geräten Ausschau, um mit diesen zu kommunizieren. Passen die Profile zusammen, wird ein Infopaket über die eigene Person an den Kommunikationspartner geschickt, welches neben Name, Profil/Kennwort und Informationstext auch ein Foto enthält, welches die Suche nach der jeweiligen Person im direkten Umfeld erleichtert. Das Foto kann entweder mittels der internen Kamera des Endgeräts direkt aufgenommen werden oder über das Filesystem eingelesen werden.

Nachdem beide Infopakete an den jeweiligen Kommunikationspartner verschickt wurden, wird der Benutzer durch Vibration, Aufleuchten der Hintergrundbeleuchtung des Displays sowie Abspielen einer Melodie benachrichtigt. Auf dem Display wird das Foto sowie Name und Infotext auf dem Endgerät angezeigt, ebenso ist eine textuelle Auswertung des Profils bzw. das Kennwort der anderen Person abrufbar. Nun besteht eine direkte Bluetooth-Verbindung zwischen beiden Mobiltelefonen, falls keine Sichtverbindung besteht oder man den anderen in einer Menschenmenge nicht findet, bietet "n3po" die Möglichkeit, mit dem anderen Benutzer kostenlos via Bluetooth Textnachrichten auszutauschen, also zu Chatten.

Über die Funktion "Voice Chat" ist es möglich, ähnlich wie bei den neuen Push-to-Talk Diensten, Audiodaten über Bluetooth zu verschicken, welche nach dem Empfang auf dem anderen Endgerät abgespielt werden. Die Benutzer können per Bluetooth kostenlos miteinander sprechen, die Audiodatei wird über das interne Mikrofon des Telefons aufgenommen und gespeichert, danach an den Kommunikationspartner übertragen. Dass die Nachricht den Kommunikationspartner erreicht hat, wird durch einen Bestätigungston signalisiert, falls während der Übertragung ein Fehler aufgetreten ist, informiert ein tieferer Ton den Benutzer.
Falls man sich durch den Kommunikationspartner gestört fühlt, kann man die Bluetooth-MAC-Adresse des anderen Geräts in einer Blacklist permanent speichern, Geräte deren MAC auf der Blacklist stehen, werden als Kommunikationspartner in Zukunft generell abgelehnt.

Da Bluetooth–Verbindungen aufgrund ihrer beschränkten Reichweite recht instabil sind, versuchen die Geräte nach einem ungewünschten Verbindungsabbruch automatisch wieder, die Verbindung zum anderen Endgerät aufzubauen. Wenn die Kommunikation durch einen Benutzer bewusst abgebrochen wird, wird der Kommunikationspartner darüber informiert. Die Geräte versuchen dann nicht, sich erneut zu verbinden.

Um dem hypothetischen Anbieter der Applikation ein Bezahlmodell zu bieten, wird die Applikation bei der Installation für die Dauer von 7 Tagen freigeschaltet - nach Ablauf dieser Zeitspanne muss über die Funktion „Abo verlängern“ weiteres Zeitkontingent gekauft werden, damit die Applikation weiterhin aktivierbar ist. Diese Funktion schickt eine SMS an eine kostenpflichtige, voreingestellte Nummer unter der „Abocenter“ erreichbar ist, welches die SMS mit einer Textnachricht beantwortet, die den Freischaltungscode für einen Monat enthält.

Wenn das Abo abgelaufen ist, ist es dem Benutzer zwar noch möglich das Programm zu starten, jedoch ist die Bluetoothfunktionalität nicht mehr aktivierbar, bis das Abo verlängert wurde.

• › PDF aus Powerpoint-Präsentation, Funktionsweise der Software [PDF | 9 MB ] [link 04]
• › Ablauf der Applikation [JPEG | 406 KB ] [link 05]
• › Zusammenspiel der Bluetooth-Schicht [248 KB ] [link 06]
• › Schichtenmodell der Applikation [48 KB ] [link 07]
• › Teilübersicht der Packages [10 KB ] [link 08]
• › Server-Clientkommunikation [189 KB ] [link 09]

Technische Beschreibung

Die Applikation wurde in Java (Java 2 Micro Edition, J2ME) geschrieben. Vorraussetzung sind ein MIDP 2.0 fähiges Mobiltelefon mit Bluetooth und den entsprechenden APIs zur verarbeitung von Multimediadaten (Sprache, Fotos, MIDI-Dateien) und zum Steueren der Bluetooth-Schicht.

--------------------Auszug aus der Diplomarbeit-----------------

Architektur der Applikation

Die Klassen der Applikation verteilen sich über die Packages n3po.core, n3po.conf und n3po.net, die Klassen für die Benutzeroberflächen sind in den Packages n3po.core.gui und n3po.conf.gui zu finden.

Die Applikation ist, angelehnt an das Model-View-Controller-Pattern ( MVC ), in drei Schichten aufgeteilt:

Die Benutzeroberfläche für die Ein- und Ausgabe von Informationen durch und an den Benutzer. Die Steuerungsschicht, die auf die Eingaben des Benutzers reagiert und die jeweilig daraus folgenden Aktivitäten der Netzwerkschicht anstößt bzw. Rückmeldungen an den Benutzer weitergibt. Die Netzwerkschicht ist für die Kommunikation über Bluetooth und Wireless Messages (SMS) zuständig. Alle drei Schichten greifen auf die Konfigurationsdaten des Programms zu, welche durch die Klassen im Package n3po.conf repräsentiert werden.

Das folgende Diagramm veranschaulicht das Zusammenspiel der verschiedenen Schichten.

Die Klasse für die Darstellung des Voice-Chats und der Aufnahme von Audiodaten ist ebenfalls von Canvas abgeleitet. Um eine Push-To-Talk ähnliche Benutzung zu ermöglichen wird hier auf die LowLevel – UI zurückgegriffen, dadurch ist es möglich Events wie das Drücken einer Taste sowie den Zeitpunkt, wenn sie wieder losgelassen wird, abzufragen. Die Aufzeichnung der Audiodatei beginnt dabei mit dem Drücken einer festgelegten Taste, solange die Taste gedrückt bleibt, werden die Audiodaten aufgenommen. Lässt der Benutzer die Taste los, wird die Aufzeichnung gestoppt und die daraus resultierenden Daten an den Kommunikationspartner übertragen.

Im Paket n3po.conf.gui befinden sich die Klassen für die Konfiguration des Programms und die Einstellung des persönlichen Profils bzw. des gewünschten Partnerprofils. Die Eingabe der Kennwörter für den zweiten Suchmodus findet über eine weitere Form-Klasse statt, welche nur anwählbar ist, wenn der Kennwort-Modus aktiviert wurde.

Für die Eingabe der Grundangaben wie Name, Infotext und Foto ist die Klasse F_Identity vorgesehen, der Zugriff auf die Interne Kamera des Mobiltelefons mit Hilfe der MMAPI findet in der Klasse F_Identity_Photo statt.

Falls ein Endgerät nicht über eine interne Kamera verfügt oder die Aufnahme von Fotos mittels der J2ME nicht unterstützt, lässt sich über die Klasse F_Filebrowser ein Foto vom Dateisystem bzw. der Speicherkarte des Handys auswählen und laden.

Die Systemeinstellungen wie Vibrationsalarm, Klingelton, Bewegungsmodus können mit der Form F_SystemConfig gesetzt werden, die Laufzeit des Abonnements kann über die Klassen F_Abo und F_Abo_SMS angezeigt und verlängert werden.

Zusätzlich ist die Klasse F_Debug für Test- und Debugzwecke vorhanden, über diese Form kann der Debug-Modus aktiviert und deaktiviert, das Löschen des Recordstores und der Blacklist angestoßen werden, oder die Bildschirmauflösung abgefragt werden.

Die Anzeige des Konfigurations-Hauptmenues und die Auswahl der einzelnen Kategorien wird durch die Klasse F_Conf implementiert.

Steuerungsschicht:
Die Methoden zur Steuerung der Programmlogik finden sich im Package n3po.core in der Klasse CoreMidlet, welche die Interfaces für die Behandlung von Bluetooth – und SMS-Events, implementiert. Über die in den Interfaces definierten Callback- Methoden wird auf eingehende Nachrichten und Ereignisse über die Bluetooth- oder Wireless-Messaging-Schnitstelle reagiert und die entsprechenden Reaktionen darauf angestoßen.

CoreMidlet ist von MIDlet abgeleitet und implementiert die Grundfunktionen zum starten, beenden und pausieren der gesamten Applikation. Das CoreMidlet vermittelt zwischen den Eingaben des Benutzers über die GUI-Klassen und der Netzwerkschicht. Es enthält die Methoden zum Verschicken von unterschiedlichen Nachrichtentypen über die Netzwerkschnittstellen, ebenso finden sich im CoreMidlet Methoden zum Pausieren sowie Deaktivieren und Reaktivieren der Netzwerkaktivität, welche dann die entsprechenden Methoden im Netzwerklayer aufrufen.

Die Klasse MMUtil enthält Hilfsmethoden zur Verarbeitung von Multimediadaten. Dabei werden Funktionen zur Anpassung der Fotos an die unterschiedlichen Displayauflösungen der Endgeräte, zum Abspielen von MIDI-Dateien als Klingelton sowie zum Aufzeichnen und Abspielen von Audiodaten in gerätespezifischen Formaten zur Verfügung gestellt.

Für die Protokollierung von Debugausgaben ist die Klasse DebugUtil vorgesehen, sie implementiert die Funktionalität zur lesbaren Ausgabe von Bluetooth-ServiceRecords, Geräte-IDs und UUIDs sowie zur Protokollierung in ein File.

Im n3po.conf – Package finden sich die Klassen mit den Einstellungen für das persönliche Profil (MyProfile), das Partner-Profil (PartnerProfile) und die Systemeinstellungen (SysConf). Die Funktionalität zum Laden der Einstellungs-Attribute aus dem RecordStore des Endgeräts, sowie das persistente Speichern von Daten im RecordStore findet sich in diesen Klassen.

Methoden zum Erzeugen eines Profil-Strings für den Versand, zum Vergleichen von zwei Profilen und für die textuelle Auswertung eines Profil-Strings sind ebenfalls in diesen Klassen zu finden.

Zum Testen der SMS-Abonnement Funktion unter realen Bedingungen findet sich ein zweites MIDlet im n3po.core – Package, welches auf eine eingehende SMS wartet, diese nach dem Eingang anzeigt und eine gültige Bestätigungs-SMS zurückschickt. So kann die Abonnementfunktion mit zwei Mobiltelefonen getestet werden, normalerweise übernimmt diese Funktion ein SMS-Gateway eines Service-Providers , der auf sogenannte Premium-SMS spezialisiert ist.

Die Klassen der Benutzerschnittstelle und der Steuerungsschicht sind als Singletons implementiert, da von jeder Klasse maximal eine Instanz benötigt wird. Über die Methode getInstance() wird die aktuelle Instanz zurückgegeben oder, falls noch nicht vorhanden, ein neues Objekt instantiiert und zurückgegeben. Somit wird kein Speicherplatz verschwendet und das jeweilige Objekt kann global angesprochen werden. Falls bei einer späteren Weiterentwicklung des Programms mehrere Objekte benötigt werden, ist diese Änderung leicht möglich.

Für die Ausgabe von Fehlermeldungen oder Debug – Informationen besitzen alle wichtigen Klassen eine Methode zum Protokollieren des Programmstatus welcher ein String mit dem Ausgabetext übergeben wird. Die log() – Methode leitet alle Ausgaben an die Methode gui_log() der Klasse CoreMidlet weiter und fügt den jeweiligen Klassennamen als Source hinzu.

Benutzeroberfläche:
Die Klassen für die Benutzeroberfläche bauen bis auf zwei Ausnahmen auf den Form-Klassen der High-Level-UI auf, da die Anforderungen des Programms an die GUI gut mit den vorgefertigten Items abgedeckt werden können.

Die von Form abgeleiteten Klassen im Paket n3po.core.gui sind für die Anzeige des Hauptmenüs und des Status-Bildschirms während der Suche nach anderen Geräten zuständig. Auch die Klassen für die Anzeige der Partnerdaten nach einer erfogreichen Verbindung, sowie für die grafische Darstellung des Text – und Voice-Chat und der Profilanzeige befinden sich in diesem Package.

Für die Darstellung von Debugausgaben auf dem Handydisplay dient eine von Canvas abgeleitete Klasse, welche zur LowLevel-UI gehört. Die Ausgabe ist horizontal und vertikal scrollbar und erleichtert somit die Lesbarkeit der Protokolle auf dem Handy-Display wenn der Debug-Modus aktiviert wurde. Um möglichst viel Platz für die Ausgabe von Debugdaten verwenden zu können wurde hier eine Canvas verwendet, welche eine exakte Positionierung der Ausgabe erlaubt.

Netzwerkschicht:
Das Package n3po.net enthält die Klassen, welche für die Netzwerkfunktionalität und Kommunikation über Bluetooth übernehmen. Ebenso sind die Klassen für die Kommunikation über SMS in diesem Package enthalten.

Die Klasse BluetoothLayer bildet den Kern der für die Bluetooth-Kommunikation zuständigen Klassen. Sie implementiert Methoden zum Erzeugen eines Server-Threads, der auf eingehende Bluetooth-Verbindungen wartet und einen eigenen Bluetooth-Service auf dem Endgerät registriert.

Nachrichten werden mittels einer SIGNAL – Nummer in verschiedene Typen aufgeteilt, die Klasse BluetoothLayer legt einige SIGNAL-Typen fest, z.B. SIGNAL_DATA für Binärdaten, SIGNAL_MESSAGE für Textnachrichten oder SIGNAL_PACKET für das Informationspaket aus Name, Infotext und Foto. Anhand des SIGNAL kann der Inhalt eines Datenpakets identifiziert und dann entsprechend behandelt werden.

Die Methode query() stößt die nebenläufige Suche nach anderen Bluetooth-Geräten in der Umgebung (Device Discovery) in den über das Bewegungsmuster voreingestellten Intervallen an. BluetoothLayer verwaltet bereits bekannte und abgefragte Geräte sowie Geräte mit denen keine Kommunikation mehr erwünscht ist, um Mehrfachverbindungen zu vermeiden. Die Liste mit den unerwünschten Kommunikationspartnern wird über die Konfigurationsklassen persistent gespeichert.

Die innere Klasse Listener implementiert das DiscoveryListener - Interface welches über Callback-Methoden auf Ereignisse wie gefundene Geräte und den Abschluss der Gerätesuche reagiert. Ebenso enthält es die Callback-Methoden für die Reaktion auf gefundene Services auf anderen Geräten und den Abschluss der Service-Suche.

Die interne Klasse DoServiceDiscovery implementiert die Funktionalität für die Suche nach Services auf gefundenen Endgeräten.

Eine aktive Verbindung zu einem anderen Gerät repräsentiert die Klasse Endpoint, sie besitzt jeweils einen Sender- und einen Reader-Thread, welche für die Datenübertragung zwischen den Mobiltelefonen über Input- bzw. Outputstreams zuständig sind. Endpoint verwaltet eine Nachrichten-Queue mit den anstehenden Nachrichten und informiert die Steuerungsschicht durch das BTListener - Interface über aufgetretene Netzwerkevents wie eingehende oder verschickte Nachrichten sowie den Verbindungsaufbau und -abbruch.

Nachrichten sind Instanzen der Klasse DataPacket, die Klasse verfügt über mehrere, überladene Konstruktoren für unterschiedliche Pakettypen wie z.B. das Infopaket, das aus mehreren unterschiedlichen Informationen bestheht, reine Textnachrichten oder Binärdaten.

Für die Kommunikation über Kurznachrichten stehen die Klassen SMSSender und SMSReceiver zur Verfügung, welche jeweils einen Sender bzw. Reader-Thread erzeugen und auf eingehende Nachrichten auf einem definierten Port warten oder Nachrichten verschicken. Durch das Interface SMSListener wird die Steuerungsschicht über Events von der Wireless-Messaging-Schnittstelle benachrichtigt.

Hardware / Software

zum Beispiel Siemens S65 oder alle anderen Javafähigen Mobiltelefone die obenstehende Voraussetzungen erfüllen.