Entwurf und Implementierung einer PC- Fernbedienungssoftware für Bluetooth-fähige mobile Geräte

Größe: px
Ab Seite anzeigen:

Download "Entwurf und Implementierung einer PC- Fernbedienungssoftware für Bluetooth-fähige mobile Geräte"

Transkript

1 F Entwurf und Implementierung einer PC- Fernbedienungssoftware für Bluetooth-fähige mobile Geräte Design and Implementation of a PC Remote Control Software for Bluetooth Enabled Mobile Devices Daniel Müllenbach Bachelor Abschlussarbeit Betreuer: Prof. Dr. rer. nat., Rainer Oechsle Trier,

2 Kurzfassung In dieser Projektarbeit geht es um den Entwurf und Implementierung einer PC- Fernbedienungssoftware für mobile Geräte wie Handys oder PDAs. Ziel ist es, eine Client-Server-Anwendung zu entwickeln, die es möglich macht, genau diese Geräte zur Steuerung eines normalen (ebenfalls mit einem Bluetooth-Gerät ausgestatteten) Heimcomputers zu verwenden. Durch Verwendung der Bluetooth-Technologie kann dies ohne Kabel- oder Sichtverbindung zum PC realisiert werden. Dabei soll nicht gezielt auf die Steuerung einer bestimmten Anwendung eingegangen, sondern ein generelles Fernbedienen des Computers gewährleistet werden. Mit Hilfe der Software lässt sich der Mauszeiger steuern, Clicks ausführen und das Drücken von Tasten bzw. Tastenkombinationen simulieren. Diese Steuerung erfolgt dabei auf Betriebssystemebene, sodass eine gesteuerte Anwendung darauf reagiert, als ob der Benutzer vor dem PC an Tastatur und Maus sitzen würde. Zusätzlich ist eine Bildübertragung von PC zum mobilen Gerät implementiert, welche einen Bildausschnitt um den Mauszeiger abgreift und auf dem Handydisplay anzeigt. Dadurch lässt sich ein gezielter Click auch aus der Entfernung oder sogar gänzlich ohne Sichtkontakt zum Monitor ausführen. Der Anwender kann die Tastenkombinationen (Beispiel: Play bei einem Medienspieler, STRG+P) frei festlegen und für verschiedene Programme separate Tastenlayouts für das mobile Gerät erstellen. Während des Betriebs kann zwischen diesen Profilen gewechselt werden. Des Weiteren sind die Funktionalitäten des Servers in Plugins ausgelagert, um so ein späteres Erweitern um neue Funktionen zu erleichtern und je nach Profil unnötige Fähigkeiten abzuschalten (z.b. die Bildübertragung bei der Steuerung eines Audiospielers). Der Server ist in der Lage mehrere Geräte mit Profilen zu verwalten und gleichzeitige Verbindungen zu handhaben. Die komplette Konfiguration der Anwendung kann durch die Konfigurationsoberfläche des Servers durchgeführt werden.

3 Inhaltsverzeichnis 1 Einleitung Die Java Platform, Micro Edition Einführung Konfigurationen Connected Limited Device Configuration Connected Device Configuration Profile - Das Mobile Information Device Profile Der MIDlet-Lebenszyklus Virtuelle Bildschirme Java Application Descriptor Programmentwicklung Bluetooth Geschichte Funktionsweise Bluetooth und JAVA Java Micro Edition Java Standard und Enterprise Edition Java APIs for Bluetooth Wireless Technology (JSR-82) Verbindungsaufbau Bearbeiten von Service Records Geräte und Dienste suchen Robot Entwurf und Implementierung Übertragungsprotokoll und Kommunikation Client Programmablauf Geräteauswahl Verbindungsaufbau Eingabe und Anzeige Server

4 Inhaltsverzeichnis IV Repräsentation der Konfigurationsdaten Geräte Aliase Profile Programmstart und Verbindungsannahme Sessions Plugins Das Plugin ImageCapturer Das Plugin MouseController Das Plugin KeyController Konfigurationsoberfläche Tests Client Verbindungsprotokoll Server Bedienung Server Systenanforderungen Vorbereitung und Programmstart Konfiguration Client Systemanforderungen Installation Geräteauswahl Geräteinformationen Fernsteuern Fazit und Ausblick Literatur

5 Abbildungsverzeichnis 2.1 Übersicht über die Java-Editionen Architektur für CLDC und MIDP High-Level Architektur der CLDC Connection-Interfaces Hierarchie Der Lebenszyklus eines MIDlets Methoden der Klasse MIDlet (Auszug) Displayable und Unterklassen Bluetooth Netzwerktopologie (Piconets, Scatternet) Der Bluetooth-Stack Methoden der Klasse LocalDevice Methoden der Klasse DiscoveryAgent Methoden des Interface DiscoveryListener Methoden der Klasse Robot (Auszug) Client-Server-Anwendung Schema des Container-Datenpakets Verdoppelung des Control Characters in den Nutzdaten Format eines Kommando-Pakets Format eines Text-Pakets Format eines Bild-Pakets Das Package de.dm.remotecontrol.server.connection Das Interface RemoteControlKeyListener Das Interface RemoteControlConnectionListener Das Interface RemoteServerActionListener Programmablauf Client Klassendiagram Client (mobiles Gerät) Drücken einer Taste Aufbau der Konfigurationsdatei Geräte, Profile und Aliase Klassen der Gerätekonfiguration Methoden der Klasse RemoteDeviceManager Methoden der Klasse RemoteControlDevice (Auszug)

6 Abbildungsverzeichnis VI 5.19 Überprüfen eines Alias Übersicht Server Das Package de.dm.remotecontrol.server.session und Abhängigkeiten Methoden der Klasse Session (Auszug) Umschalten von Profilen und Laden von Plugins Methoden des Interfaces Plugin Lebenszyklus eines Plugins Das Package de.dm.remotecontrol.server.plugins Methoden der Klasse PluginManager (Auszug) Berechnung des abzugreifenden Ausschnittes Konfigurationsoberfläche Elemente des Auswahlbaums Konfigurationsoberfläche für Serverplugins Konfigurationsoberfläche für Geräte Konfigurationsoberfläche für Aliase Konfigurationsoberfläche für Profilauswahl Konfigurationsoberfläche für die Verwaltung von Profilen Konfigurationsoberfläche für die Zuteilung von Plugins zu Profilen Konfigurationsoberfläche für ImageCapturer Konfigurationsoberfläche für MouseController Konfigurationsoberfläche für KeyController Geräteauswahl Geräteinformationen Anzeige der Bildübertragung Menü zum Umschalten der Profile

7 1 Einleitung In den letzten Jahren hat sich der Personal Computer in die Multimediamaschine schlechthin entwickelt. Egal, ob man seine Musik in Form von MP3s oder einer CD hören oder einen DVD-Film schauen möchte - es gibt unzählige Programme, die dies leisten. Immer häufiger kommt es vor, dass ein mit einem SAT-Receiver ausgerüsteter PC für den Empfang von Fernsehsendern genutzt wird. Auf Grund dieser Vielfältigkeit ist es möglich, diverse Geräte in einem zusammenzufassen: Hatte man vor einiger Zeit noch Stereo-Anlage, DVD-Player, Receiver, Video-Recorder, CD-Player, Dolby-Surround-Decoder, Verstärker usw. im Regal stehen, kann alles dies sehr viel platzsparender und kostengünstiger durch einen sogenannten Home Theater Personal Computer (HTPC) [HTP] realisiert werden. Als weitere Untermauerung für diese Entwicklung seien auch die speziellen Windowsversionen, welche auf den Titel Media Center Edition hören, angeführt, die genau für diese Art PC konzipiert sind. Diese unterscheiden sich jedoch im Wesentlichen nur dahingehend von einer der bekannten Windowsversionen, dass sie über eine auf die Anzeige durch einen Fernseher zugeschnittene Benutzeroberfläche verfügen. Es existieren diverse Software-Projekte, die sich zum Ziel gesetzt haben, auch für Besitzer eines normalen Windows oder alternativen Betriebssystems diese Funktionalität bereitzustellen. So zahlreich die Möglichkeiten und Programme sind Multimedia wiederzugeben, so eingeschränkt ist die Auswahl an Steuerungsgeräten für diese. In meinen Augen wurde es lange versäumt Fernbedienungen, wie man sie vom Fernseher oder eben der Stereoanlage gewöhnt ist, für den PC zu entwickeln. Jeder PC besitzt zwar eine Maus und eine Tastatur, aber diese sind meist per Kabel mit dem PC verbunden. Und wer legt sich schon gerne Kabel quer durchs Wohnzimmer zum Sofa? Zwar gibt es auch kabellose Varianten, die per Funk kommunizieren, aber allen gleich ist ihre unhandliche Größe, wenn sie als Fernbedienung genutzt werden sollen. Inzwischen gibt es auch speziell für den PC entworfene Fernbedienungen. Diese sind aber (noch) viel zu teuer. Bei der Suche nach alternativen Steuerungsmöglichkeiten stieß ich auf die Idee, das Handy als Hardware zu nutzen. Nahezu jeder besitzt heute ein Handy und fast alle sind inzwischen Bluetooth-fähig, sodass es ihnen möglich ist über kurze Entfernungen kostenlos per Funk zu kommunizieren. Mit einer entsprechendenden Hardware-Erweiterung des PCs (USB-Bluetooth-Dongle), welche im Gegensatz zu

8 1 Einleitung 2 oben erwähnten Fernbedienungen viel billiger zu bekommen ist, kann auch mit einem beliebigen PC kommuniziert werden. Diese Idee ist nicht neu. Es gibt bereits Handys, die eine solche Software mit sich bringen. Diese sind leider meist auf ein bestimmtes Programm (und sogar Programmversion) abgestimmt, sodass z.b. nur der Windows Mediaplayer 9 gesteuert werden kann. Verwendet man eine aktuellere Version (Version 11), haben sich unter Umständen die Tastenkombinationen für die einzelnen Aktionen geändert, sodass beispielsweise anstatt Lauter, Leiser ausgeführt wird. Auch im Internet ließen sich nach einigen längeren und umfangreicheren Recherchen Programme finden, die sowohl auf Handy als auch auf PC installiert werden mussten und eine Steuerung ermöglichen. Die gefundenen Anwendungen waren jedoch ausnahmslos nur unter dem Windows-Betriebssystem lauffähig und meist nur als limitierte Testversion zu haben. Da meine Suche also ergebnislos blieb und ich nicht bereit war eine überteuerte Fernbedienung zu kaufen, beschloss ich selbst eine Anwendung zu entwickeln, welche keine der oben genannten Barrieren aufweist. Dies ist das Thema dieser Abschlussarbeit. Diese Dokumentation ist wie folgt aufgebaut: In den nächsten drei Kapiteln wird das nötige Grundwissen für diese Arbeit näher erläutert. Das 2. Kapitel ist eine Einführung in die Java Micro Edition und deren Besonderheiten. Im sich anschließenden Kapitel 3 kommen die Geschichte und Funktionsweise der Bluetooth- Technologie zur Sprache. Ein wichtiger Aspekt wird an dieser Stelle auch der Umgang mit dieser Technologie aus Java heraus sein. Ferner wird ein Einblick in die Klasse Robot in Kapitel 4 geboten, die für die Simulation von Benutzereingaben essenziell ist. Kapitel 5 befasst sich anschließend mit dem Entwurf und der Implementierung der Mobile PC Remote. Abschließend wird der Umgang mit der Software anhand der Bedienungsanleitung (Kapitel 6) näher erläutert.

9 2 Die Java Platform, Micro Edition 2.1 Einführung Neben der Java 2 Platform, Enterprise Edition (Java EE) und der Java 2 Platform, Standard Edition (Java SE) existiert noch eine weitere Java Platform Edition, nämlich die Micro Edition (Java ME). Diese ist für sogenannte Embedded Devices (eingebettete Geräte) ausgelegt, unter welche Handys, Personal Digital Assistants (PDAs), aber auch Set-Top-Boxen wie SAT-Receiver, DVD-Player oder sogar Drucker fallen. Eingebettete Geräte stellen hohe Anforderungen an die Hardware, was sich letztendlich auch auf die Software auswirkt. So sollen dieses Geräte möglichst klein und handlich sein, aber trotzdem leistungsfähig und bedienbar bleiben. Dies hat zur Konsequenz, dass die Hardware eines Gerätes speziell auf dieses Gerät zugeschnitten werden muss und auch die Leistungsfähigkeit an der ein oder anderen Stelle auf der Strecke bleibt. So werden meist Prozessoren verbaut, die genau den Anforderungen für ein betreffendes Geräte genügen, aber ohne Reserven die Geschwindigkeit betreffend, wie man es von einem PC her kennt. Aber auch beim Speicher unterscheiden sich Embedded Devices erheblich. Da mit steigender Speicherkapazität auch die physische Größe der Speicherbausteine und natürlich deren Preis zunimmt, steht den meisten Geräten nur ein sehr begrenztes Kontingent an Speicher für Java-Anwendungen zur Verfügung. Während es bei nicht flüchtigem Speicher (Memory Cards / Festplatten) inzwischen schon bis in die Gigabyte-Bereiche geht, sind es bei flüchtigem Speicher (Arbeitsspeicher) nur wenige Megabytes. Eine weitere Einschränkung im Vergleich zum PC stellen die Ein- /Ausgabegeräte dar. So finden sich meist nur wenige Tasten an mobilen Geräten. Ein Handy beispielsweise beschränkt sich in diesem Bereich auf die Tasten für die Zahlen Eins bis Null, Stern (*) und Raute (#), sowie einige wenige Funktionstasten. Lediglich PDAs und Organizer können schon einmal eine Tastatur mit allen Buchstaben des Alphabetes vorweisen. Auch was die Größe des Bildschirms angeht findet sich eine breite Palette an unterschiedlichen Typen. Diverse Auflösungen, Displaygrößen, Farbanzahlen und Techniken erschweren zusätzlich die Übersicht. Schließlich bleibt das Problem der Stromversorgung. Die angesprochenen eingebetteten Geräte besitzen meist eine Batterie, welche nur über eine begrenzte Ka-

10 2.1 Einführung 4 pazität und Stromabgabe verfügt. Daher muss darauf geachtet werden, dass die Hardware mit der Batterie harmoniert, diese nicht überlastet und natürlich das Gerät möglichst lange betriebsbereit bleibt. Stromsparmechanismen, effiziente Implementierungen und damit verbunden Kompromisse bezüglich Leistung sind aus diesem Grund unumgänglich. Die Notwendigkeit für die Java Micro Edition liegt also in der breiten Masse an unterschiedlichen Geräten und deren Eigenschaften. Es ist klar, dass man keine Standard Edition oder sogar Enterprise Edition der Java Plattform nehmen kann, da deren Anforderungen an das Gerät (noch) nicht erfüllbar wären. Allein der Speicherplatz für die Bibliotheken beansprucht weit über 100 Megabytes. Diese bereitzustellen würde die Kosten für das Gerät jedoch signifikant erhöhen. An diesem Punkt setzt die Java ME an. Sie soll eine Basis für die Ausführung von Java-Anwendungen auf möglichst vielen eingebetteten Geräten schaffen. Um dies zu erreichen musste jedoch ein anderer Wege gegangen werden als bei den anderen Editionen. Dies ist auch der Grund dafür, dass die Mirco Edition sich in ihrem Aufbau erheblich von ihren Schwestern unterscheidet (siehe Abbildung 2.1). Um der Vielfalt an Geräten gerecht zu werden, entschied man sich für einen modularen Aufbau. Dabei ist die Java ME so gesehen kein Stück Software, sondern eher eine Sammlung aus Spezifikationen und Technologien. Es ist klar, dass nicht jedes Gerät dieselben Eigenschaften vorweist und die gleiche Hardware besitzt. Je nach Hardware muss diese anders angesprochen werden, wodurch eine einheitliche Implementierung der Java Micro Edition nicht möglich ist. Es existiert zwar eine Referezimplementierung von Sun, diese dient jedoch nur als Anhaltspunkt für die Hersteller der mobilen Endgeräte und die letztendliche Implementierung ist ihnen überlassen. Abbildung 2.1. Übersicht über die Java-Editionen

11 2.1 Einführung 5 Die Spezifikationen werden im Rahmen des Java Community Process (JCP) entworfen. Dabei schließen sich meist die führenden Hersteller von eingebetteten Geräten zusammen und entwickeln einen Java Specification Request (JSR). Ein JSR ist zunächst nur ein Vorschlag für eine Spezifikation, der nach eingehender Prüfung auf mögliche Abdeckung durch bereits früher eingebrachte Vorschläge entweder angenommen oder abgelehnt wird. Bei Annahme wird eine Expertengruppe gebildet, die sich weiter um den Entwurf kümmert. Nach einer öffentlichen Ausstellung und Annahme durch das Executive Committee wird der JSR zur Spezifikation erhoben und ist ab diesem Zeitpunkt Bestandteil der Java-Programmiersprache. Wie in Abbildung 2.1 dargestellt, besitzt die Mirco Edition im Vergeleich zu den anderen Editionen einen weitaus kleineren Umfang an Bibliotheken und Funktionen. Sie beschreibt eine Untermenge der Standard Edition und gewährleistet somit Abwärtskompatibilität. D.h. Java-Applikationen, die auf Basis der Micro Edition entworfen wurden, sind auch unter den anderen (umfangreicheren) Java-Editionen lauffähig. Um diese Untermenge zu erhalten, waren jedoch erhebliche Eingriffe in die Bibliotheken-Struktur der Standard Edition nötig. Da viele Klassen von einer Vielzahl anderer Klassen abhängig sind und sich somit nicht einfach aus dem Geflecht herausnehmen lassen, mussten einige Klassen neu geschrieben werden, um sich unnötiger Klassenbeziehungen zu entledigen. Nur auf diese Weise konnte die Größe der Java Micro Edition auf ein Minimum reduziert werden. Während die Editionen für den PC als ein Ganzes daherkommen, wird die Mirco Edition in so genannte Konfigurationen und Profile gespalten. Diese werden in den folgenden Kapiteln näher erläutert. Abbildung 2.2. Architektur für CLDC und MIDP

12 2.2 Konfigurationen Konfigurationen Da die Laufzeitumgebung zu den Eigenschaften eines Gerätes passen muss, kam man auf die Idee Geräteklassen zu definieren. Für jede Geräteklasse gibt es eine Konfiguration, die aus einer Kombination von virtueller Maschine und einer Basis-API für Java-Programme besteht. Der Gedanke hinter den Konfigurationen ist, dass ein Java-Programm, das für eine bestimmte Konfiguration entwickelt wurde, auf allen Geräten, die diese Konfiguration unterstützen, lauffähig ist. Damit erreicht man einen gewissen Abstraktionsgrad und ist als Programmierer nicht mehr an die Eigenschaften eines speziellen Gerätes gebunden. Je nach Konfiguration werden natürlich andere Anforderungen an das unterliegende Betriebssystem und die Hardware gestellt. Zur Zeit gibt es nur zwei verschiedene Konfigurationen, die für Geräteklassen wie Handys oder für mächtigere Geräte wie PDAs und Set-Top-Boxen in Frage kommen. Diese werden meist in Verbindung mit einem Profil verwendet (Abbildung 2.3) Connected Limited Device Configuration Abbildung 2.3. High-Level Architektur der CLDC Die Connected Limited Device Configuration (CLDC) ist diejenige Konfiguration, die für dieser Arbeit in Frage kommt, da hauptsächlich Handys als Betriebsgerät für die Fernsteuerung angesprochen werden. Es liegen zwei verschiedene Versionen der CLDC vor, nämlich die ursprüngliche Fassung Version 1.0 (JSR-30) [J30] und die erweiterte Version 1.1 (JSR-139) [J13]. Herzstück dieser Konfiguration ist in beiden Fällen die sogennate Kilobyte Virtual Machine (KVM). Im Gegensatz zur von den anderen Java-Edition bekannten Java Virtual Machine (JVM) ist die KVM bedeutend kleiner, speziell für mobile Geräte entworfen und daher auch für ihr Einsatzgebiet hoch optimiert.

13 2.2 Konfigurationen 7 Die CLDC legt den Schwerpunkt auf die Anwendungsentwicklung. Ihre Aufgabe ist es Systemfunktionen bereitzustellen und das dynamische Laden von Programmen zu ermöglichen. Dazu definiert sie die Java-Kernbibliotheken, die man in der Package-Struktur unter java.lang und java. util findet und schreibt Klassen für die Ein-/Ausgabe (Package java. io) vor. Des Weiteren werden die Gebiete Sicherheit, Netzverbindungen und Internationalisierung abgedeckt. In der Spezifikation zur Version 1.0 [J30] lassen sich nur Mindestanforderungen an die Hardware finden: Ein 16 oder 32 Bit-Prozessor, mindestens 160 Kilobyte nicht flüchtigem Speicherplatz für die KVM und die Bibliotheken und mindestens 32 Kilobyte an Arbeitsspeicher. Die Spezifikation der CLDC Version 1.1 setzt 192 Kilobyte Speicherplatz voraus. Ferner wird ein minimal ausgestattetes Betriebssystem als Grundlage verlangt, welches die unterliegende Hardware ansprechen kann. Da die CLDC nur eine Untermenge der Bibliotheken der Standard Edition umfasst, ist klar, dass nicht alle bekannten Klassen zur Verfügung stehen. Nur etwa die Hälfte aller Klassen fanden Einzug in die CLDC. Es kann sogar sein, dass zwar gleichnamige Klassen und Interfaces existieren, aber nicht alle Attribute und Methoden implementiert sind. Daneben sind im Package java.microedition. io zusätzliche CLDC-spezifische Klassen vorhanden. Wie bereits angesprochen bringt die Entwicklung auf Grundlage der Java Micro Edition einige Einschränkungen mit sich. So fehlt in der Version 1.0 der CLDC komplett die Unterstützung für Gleitkommazahlen, weshalb keine Datentypen Float und Double existieren. Diese wurden erst in der aktualisierten Version 1.1 [J13] hinzugefügt. Des Weiteren gibt es keine Möglichkeit Objekte mit der Methode clone() zu klonen oder einen eigenen Destruktor für Objekte durch Überschreiben der Methode finalize () zu implementieren. Auch bezüglich der Strukturierung des Quellcodes müssen sich Programmierer, die zuvor mit der Java Standard Edition 5.0 oder 6.0 programmiert haben, etwas umgewöhnen. Da die virtuelle Maschine nur Byte-Code ab Version 1.1 bis Version 1.4 akzeptiert, kann nicht auf Mechanismen wie beispielsweise Generics oder for-each-schleifen bei der Entwicklung zurückgegriffen werden. Eigene Class-Loader können ebenfalls nicht implementiert werden und es existieren keine Thread-Gruppen und Dämonen-Threads. Daneben existieren noch weitere Besonderheiten, die jedoch weniger ins Gewicht fallen und deren Erwähnung den Rahmen sprengen würde. Wie bereits bekannt, ist auch der Einstiegspunkt bei Anwendungen für die CLDC die Methode public static void main(string[] args). Die CLDC wird meist in Verbindung mit dem Mobile Information Device Profile (MIDP) genutzt, zu dem nähere Erläuterungen im Abschnitt 2.3 zu finden sind.

14 2.2 Konfigurationen 8 Das Generic Connections Framework Das Generic Connections Framework (GCF) ist ein wichtiger Bestandteil der CLDC und spielt in diesem Projekt eine zentrale Rolle. Gerade in der mobilen Welt gibt es viele Möglichkeiten eine Netzwerkverbindung herzustellen. Dies kann durch einen Telefonanruf geschehen, über Infrarot, Bluetooth, WLAN oder USB-Kabel und damit verbunden über verschiedene Übertragungsprotokolle. TCP, UDP, aber auch höhere Protokolle wie HTTP, FTP und OBEX finden hier neben diversen Anderen Anwendung. Wegen der unterschiedlichen Ausstattung von eingebetteten Geräten ist jedoch nicht sichergestellt, dass jedes Gerät alle Übertragungsarten und alle Protokolle unterstützt. Eine API-Unterstützung für alle möglichen Kombinationen anzubieten, wäre daher verschwendeter Speicherplatz auf vielen Geräten und auch auf Grund der Vielfalt nur mit übermäßigem Aufwand zu realisieren. Außerdem wollte man sich die Option offen halten, neue Protokolle später hinzufügen zu können. Daher entschied man sich dazu nur ein Framework für den Aufbau von Netzverbindungen zu implementieren, welches aus Sicht des Programmierers möglichst transparent ist. Die CLDC an sich definiert nur Interfaces (siehe Abbildung 2.4) des GCF und schreibt weder vor, welche Protokolle unterstützt werden müssen, noch bietet sie für irgendwelche Protokolle konkrete Implementierungen. Abbildung 2.4. Connection-Interfaces Hierarchie Neben den Interfaces existiert noch die Connection Factory. Diese wird durch die Klasse Connector repräsentiert. Durch einen Aufruf der statischen Methode Connector.open(String uri) dieser Klasse kann das Herstellen einer Verbindung angestoßen werden. Die Methode verlangt dabei einen einzigen Parameter vom Typ String, der einen URI (Uniform Resource Identifier) repräsentieren muss:

15 2.2 Konfigurationen 9 <protocol>://<host>:<port>;<parameters> Welche Protokolle von dem mobilen Gerät unterstüzt werden, hängt in erster Linie von der vorhandenen Hardware, aber auch vom Hersteller und dem verwendeten Java ME-Profil ab. Optionale Pakete, wie beispielsweise Bluetooth (JSR-82), können den Umfang ebenfalls vergrößern. Wird ein Protokoll angegeben, das nicht zur Verfügung steht, löst dies eine ConnectionNotFoundException aus. Die übrigen Teile des URI sind protokollabhängig und können IP-Adresse, Geräte-Adresse, IP-Port, Service-ID oder was ganz anderes sein. Über welche Hardware die Verbindung zu der angeforderten Adresse/Ressource hergestellt wird, ist der Laufzeitumgebung überlassen. Für dieses Projekt sind nur die Datenstrom-orientierten Verbindungen von Bedeutung. Daher wird hier nur das Schema für das Herstellen von Kommunikationswegen bei dieser Art Verbindungen betrachtet. 1 S t r e a m C o n n e c t i o n N o t i f i e r n o t i f i e r = 2 ( S t r e a m C o n n e c t i o n N o t i f i e r ) Connector. open (... : / / l o c a l h o s t :... ) ; 3 4 StreamConnection c o n n e c t i o n = n o t i f i e r. acceptandopen ( ) ; 5 6 InputStream i n = c o n n e c t i o n. openinputstream ( ) ; 7 OutputStream i n = c o n n e c t i o n. openoutputstream ( ) ; Listing 2.1. Verbindungsaufbau Server Der Aufruf von Connector.open() liefert ein Objekt zurück, welches das Interface Connection implementiert (siehe Abbildung 2.4). Um als Server zu fungieren, muss in der verwendeten URI als Host localhost angegeben werden (siehe Listing 2.1). Das von der Connection Factory erhaltene Objekt wird anschließend in StreamConnectionNotifier gecastet. Ein StreamConnectionNotifier-Objekt stellt die Methode acceptandopen() bereit, welche solange blockiert, bis eine Verbindungsanfrage eintrifft (vergleiche Java-Socket-Programmierung ServerSocket.accept()). Als Rückgabeobjekt erhält man ein Objekt, welches das Interface StreamConnection implementiert (vergleiche Java-Socket-Programmierung Socket). Mit den Methoden openinputstream() und openoutputstream() kann man sich die nötigen Datenströme zum Lesen und Schreiben von Daten besorgen. 1 StreamConnection c o n n e c t i o n = 2 ( StreamConnection ) Connector. open (... : / / host :... ) ; 3 4 InputStream i n = c o n n e c t i o n. openinputstream ( ) ; 5 OutputStream i n = c o n n e c t i o n. openoutputstream ( ) ; Listing 2.2. Verbindungsaufbau Client Auf der Clientseite (Listing 2.2) wird als Host in der URI das Zielgerät angegeben, zu dem eine Verbindung hergestellt werden soll. Ein Cast in StreamConnectionNotifier entfällt, denn es wird sofort ein Objekt von der Connection Factory geliefert, welches in StreamConnection gecastet werden kann. Wie bereits beim Server geschildert,

16 2.2 Konfigurationen 10 können mit den entsprechenden Methoden die E/A-Ströme von diesem Objekt besorgt werden Connected Device Configuration Hier soll nur eine kurze Übersicht über die CDC der Vollständigkeit halber gegeben werden, da sie für diese Arbeit keine Rolle spielt. Die zweite existierende Konfiguration ist die Connected Device Configuration. Im Gegensatz zur CLDC fordert die Spezifikation aber, dass die Sprache Java voll unterstützt wird. Die CDC bildet daher die gesamte Menge an Bibliotheken und Funktionen der Java Standard Edition ab und keine echte Untermenge. Aus diesem Grund sind die Einschränkungen wie bei der CLDC hier nicht vorhanden. Wegen der Komplexität besitzt die CDC auch die gleiche Java Virtual Machine wie die Standard Edition. Die CDC wird meist in Verbindung mit dem Foundation Profile und dem Personal Profile verwendet und ist für den Einsatz auf mächtigeren Geräten als die von der CLDC abgedeckten gedacht.

17 2.3 Profile - Das Mobile Information Device Profile Profile - Das Mobile Information Device Profile Profile erweitern den Funktionsumfang der zugrunde liegende Konfiguration und erleichtern dem Programmierer das Erstellen von Programmen in vielerlei Hinsicht. Das Mobile Information Device Profile (MIDP) setzt auf die Connected Limited Device Configuration auf und ist in erster Linie für den Einsatz auf Handys gedacht. Da das MIDP sehr umfangreich ist und viele Funktionen bietet, welche für die Projektarbeit nicht von Bedeutung sind, beschränkt sich dieser Abschnitt nur auf die wesentlichen Aspekte Der MIDlet-Lebenszyklus Abbildung 2.5. Der Lebenszyklus eines MIDlets Das MIDP macht es möglich Anwendungen für mobile Geräte zu programmieren, die (ähnlich wie Applets) von der Laufzeitumgebung gestartet, pausiert, fortgesetzt und zerstört werden können. Dies ist sehr von Vorteil, da gerade auf mobilen Telefonen bei beispielsweise eintreffenden Anrufen der Bildschirm der Anwendung entzogen und der Prozessor für andere Aufgaben (z.b. Videotelefonat) benötigt wird. Eine Anwendung kann also ihre aktuellen Aufgaben zeitweise unterbrechen und nach dem Telefonat wieder fortsetzen. Diese Steuerung wird durch eine Application Management Software (AMS) realisiert. Die AMS ruft bestimmte Methoden auf, die die abstrakte Klasse MIDlet vorschreibt. Die sogenannten MIDlets erweitern daher diese Klasse und können so auf Zustandsänderungen mit den erforderlichen Maßnahmen entsprechend reagieren. Abbildung 2.5 zeigt

18 2.3 Profile - Das Mobile Information Device Profile 12 die möglichen Stadien des Zyklus und die Arten, wie das MIDlet seinen Zustand wechseln kann. Die AMS erstellt ein neues Objekt des MIDlets und führt dabei den parameterlosen Standardkonstruktor aus. Hier können ein paar einfache Initialisierungen vorgenommen werden, jedoch sollten zeitaufwendige Dinge vermieden werden und vorallem nichts durchgeführt werden, was zum eigentlichen Programmablauf gehört, da an diesem Punkt die Applikation quasi noch nicht läuft. Method Summary protected destroyapp(boolean unconditional) abstract void Signals the MIDlet to terminate and enter the Destroyed state. void notifydestroyed() Used by an MIDlet to notify the application management software that it has entered into the Destroyed state. void notifypaused() Notifies the application management software that the MIDlet does not want to be active and has entered the Paused state. protected pauseapp() abstract void Signals the MIDlet to enter the Paused state. void resumerequest() Provides a MIDlet with a mechanism to indicate that it is interested in entering the Active state. protected startapp() abstract void Signals the MIDlet that it has entered the Active state. Abbildung 2.6. Methoden der Klasse MIDlet (Auszug) Die Methode startapp() wird als nächstes von der AMS aufgerufen und signalisiert den Start der Anwendung. Auch hier sollten längere Vorgänge vermieden werden, da dieser Methodenaufruf von außerhalb geschieht und der Thread der AMS blockiert werden könnte. Eine gängige Programmiervorschrift ist, in dieser Methode einen neuen Thread zu starten und alle weiteren Aufgaben aus diesem heraus zu erledigen. Die Methode startapp() kann mehrere Male ausgeführt werden, nämlich genau dann, wenn das MIDlet gestartet wird und wenn es aus dem Zustand angehalten in aktiv wechselt. Daher muss vom Programmierer unterschieden werden, ob es sich um den ersten oder einen späteren Methodenaufruf handelt. pauseapp() wird bei einem Wechsel in den Zustand angehalten von der AMS ausgeführt. Dieser Fall tritt ein, falls irgendwelche Ressourcen für einen anderen Zweck benötigt werden und die Anwendung in den Hintergrund treten soll. Daher sollte

19 2.3 Profile - Das Mobile Information Device Profile 13 an dieser Stelle alles Nötige implementiert werden, um die Anwendung schlafen zu legen, sodass möglichst wenige Ressourcen in Verwendung sind. Ob ein MIDlet aber überhaupt auf diese Aufforderung reagiert, ist dem Programmierer überlassen. Sie kann auch einfach ohne Auswirkungen ignoriert werden. Die AMS selbst hält das MIDlet nicht an und es läuft einfach weiter wie zuvor, sollte die Methode nichts implementieren. Falls die AMS dem MIDlet signalisieren möchte, dass es sich beenden soll, wird die Methode destroyapp() aufgerufen. Diese Methode dient dazu eine Aufforderung an die Anwendung zu senden, alle nötigen Maßnahmen durchzuführen (z.b. Speichern von Daten) und sich anschließend zu beenden. Ein Aufruf dieser Methode kann jedoch, wie zuvor bei pauseapp(), einfach ignoriert werden. Damit das MIDlet auch selbst Kontrolle über sich hat, stehen weitere Methoden zur Verfügung, mit Hilfe welcher man der AMS Zustandsänderungen mitteilen kann, die das MIDlet selbst initiiert hat. notifypaused() teilt hierbei der AMS mit, dass das MIDlet in den Zustand angehalten gewechselt hat. Die erforderlichen Aufgaben für diese Zustandsänderung müssen vor dem Methodenaufruf bereits durchgeführt worden sein. Sollte ein MIDlet in den Zustand aktiv wechseln wollen, so kann es über ein Polling mit der Methode resumerequest() die AMS um Erlaubnis bitten. Wird der Anfrage statt gegeben, erfolgt ein Aufruf von startapp() durch die AMS. Das Ausführen von notifydestroyed() kommt einem Aufruf von System.exit (...); gleich und hat die sofortige Beendigung der Anwendung zur Folge. Bei der Benutzung der Methoden notifypaused() und notifdestroyed() ist noch anzumerken, dass die AMS nicht (wie vielleicht erwartet) mit einem entsprechenden Aufruf von pauseapp() oder destroyapp() reagiert. Diese Methoden werden lediglich bei Zustandsänderungen, die von der AMS ausgehen, aufgerufen Virtuelle Bildschirme Das Mobile Information Device Profile beschreibt mehrere virtuelle Bildschirmtypen, die bei Bedarf zu einem bestimmten Zweck angezeigt werden können. Abbildung 2.7 gibt einen Überblick über die vordefinierten Typen. Rot hinterlegte Klassen werden in der Projektarbeit verwendet, während grau hinterlegte nur der Vollständigkeit halber aufgelistet sind. Um auf dem Display des mobilen Gerätes angezeigt zu werden, muss ein Objekt die abstrakte Klasse Displayable erweitern. Das MIDP unterscheidet hierbei 2 Kategorien: Screen und Canvas. Bei der Verwendung von Screen und abgeleiteten Klassen hat der Programmierer wenig Einfluss auf die tatsächliche Darstellung. Er kann lediglich angeben, was dargestellt wird, jedoch nicht das Layout bestimmen. Wie das Gerät den Inhalt dem Benutzer auf der Anzeige präsentiert, ist vom Hersteller des Gerätes vordefiniert. Möchte man selbst die Kontrolle über das Aussehen haben, so kommt der Programmierer nicht um die Benutzung von Canvas oder einem seiner Kinder herum. Im Gegensatz zu Screen bietet Canvas die Möglichkeit die Methode paint(graphics g) zu überschreiben. Dadurch kann der Programmierer direkt auf den (virtuellen) Bildschirm zeichnen, wie bereits von AWT bekannt. Um einen virtuellen Bildschirm anzuzeigen, muss das MIDlet auf den eigentlichen

20 2.3 Profile - Das Mobile Information Device Profile 14 Abbildung 2.7. Displayable und Unterklassen Bildschirm zugreifen können. Die Klasse Display kapselt diese Funktionalität. Um eine Referenz auf dieses Objekt zu erhalten kann jedes MIDlet die statische Methode Display.getDisplay(MIDlet m) verwenden. Parameter muss das MIDlet sein, welches Zugriff auf den Bildschirm erlangen will. In den meisten Fällen ist dies das aufrufende MIDlet selbst (this). Mit der Methode setcurrent(displayable d) kann der AMS mitgeteilt werden, welches Objekt die Anzeige erhalten soll. Falls die Application Management Software der Anfrage stattgibt, erscheint der Inhalt des virtuellen Bildschirms auf der Anzeige. Wenn dies nicht geschieht, so hat der Aufruf keine Auswirkung und das Displayable-Objekt bleibt weiterhin unsichtbar. Displayable-Objekte können jederzeit verändert werden, egal ob sie gerade angezeigt werden oder nicht. Es gibt verschiedene Unterklassen von Screen, welche zu verschiedenen Zwecken angezeigt werden können. Form bietet dabei eine Anzeigemöglichkeit für verschiedene Dinge. Alert soll verwendet werden, um dem Benutzer Warnmeldungen oder Hinweise zu präsentieren. Mit List kann eine Liste angezeigt werden, aus welcher der Benutzer einen Eintrag auswählen kann. Displayable-Objekten können Kommandos zugeordnet und ein Listener für diese angemeldet werden. Kommandos sind Grundlage für Benutzereingaben und können als virtueller Button oder Funktionstaste aufgefasst werden. Die Klasse Command repräsentiert ein solches Kommando, welches unter anderem einen Namen (bzw. Text) haben kann und einer Taste des mobilen Gerätes zugeordnet wird. Durch Betätigen der Taste wird das Kommando ausgeführt. Meist werden nur bis zu 2 Kommandos direkt auf dem Bildschirm angezeigt, nämlich genau in der unteren linken bzw. rechten Ecke des Bildschirms. Nahezu alle Handys besitzen dort unterhalb des Anzeigebereiches 2 Funktionstasten, die mit den betreffenden Kommandos assoziiert werden. Sind jedoch mehr als zwei Kommandos vorhanden, so wird meist ein Menü gebildet, welches eine Liste von Kommandos enthält und über eine der eben genannten Funktionstasten zugänglich wird. Displayable-Objekte besitzen die Methode addcommand(command c) um ein Kommando hinzuzufügen und die Methode setcommandlistener(commandlistener l) um einen Listener für die Kommandos anzumelden. Das Interface CommandListener kann wie ein

21 2.3 Profile - Das Mobile Information Device Profile 15 aus AWT bekannter ActionListener verstanden werden. Es schreibt nur die Methode commandaction(command c, Displayable d) vor, welche als ersten Parameter das ausgelöste Kommando übergeben bekommt und als zweiten Parameter das Displayable- Objekt, welchem das Kommando zugeteilt wurde Java Application Descriptor Anwendungen, die für das MIDP geschrieben sind, bringen normalerweise auch einen Java Application Descriptor (JAD) mit sich. Dabei handelt es sich um eine eigene Datei neben dem JAR-Archiv, welche Informationen über die eigentlich Anwendung beinhält. Diese Informationen betreffen u.a. die Version der Konfiguration und des Profiles, welche für die Anwendung benötigt werden, sowie den Namen des Einstiegs-MIDlets zum Starten der Anwendung und die Dateigröße des JAR-Archivs. Außerdem können Daten über Hersteller, URL der Hersteller- Webseite und Programmversion hinterlegt werden. Der JAD wurde eingeführt, um den Benutzer vor unnötigen Kosten durch die Datenübertragung solcher Anwendungen zu schützen. Oft wird nach Datenvolumen abgerechnet, welches sehr teuer ist. Möchte man nun eine Anwendungen installieren, wird zunächst nur der Descriptor heruntergeladen, welcher wenige Bytes groß ist. Anhand der enthaltenen Informationen kann nun geprüft werden, ob das Programm überhaupt auf dem Gerät lauffähig ist, ohne die JAR-Datei (welche wesentlich größer ist) übertragen zu müssen.

22 2.4 Programmentwicklung Programmentwicklung Zum Programmieren auf Basis der Java Micro Edition kann grundsätzlich jeder (Java-) Editor verwendet werden. In dieser Projektarbeit fiel die Wahl auf den Editor Eclipse. Wie die meisten Entwicklungsumgebungen muss auch Eclipse auf die Erfordernisse der Java ME angepasst werden. Es existieren bereits Plugins für Ecplise, die dem Programmierer bei der Entwicklung Java ME basierter Anwendungen helfen sollen. Neben einigen kommerziellen Plugins fand sich EclipseME. Leider gelang es nicht, das Plugin so einzurichten, dass (auf mobilen Geräten) lauffähige Anwendungen kompiliert wurden. Daher musste nach einer alternativen Möglichkeit gesucht werden dieses Ziel zu erreichen. Am Ende blieb nicht viel übrig, als fast alles von Hand zu erledigen. Wie bereits erwähnt bilden Konfigurationen und Profile die Grundlage für diese Art Programme und bringen daher die Klassen des Basissystems mit, auf die bei der Entwicklung zurückgegriffen werden muss. Sun bietet diese im Rahmen seines Java Wireless Toolkit for CLDC (WTK) [WTK] an. Nach der Installation finden sich diverse JAR-Archive im Unterverzeichnis lib. Anhand der Dateinamen cldcapi11.jar (CLDC 1.1), midpapi20.jar (MIDP 2.0) und jsr82.jar (Bluetooth) lassen sich schnell die für das Projekt benötigten Bibliotheken ausfindig machen. Anstatt der Klassenbibliothek der Java Standard/Enterprise Edition müssen genau diese in den classpath eingebunden werden. Das WTK ist daher immer erorderlich, egal ob bei der Entwicklung eine vorkonfigurierte Umgebung verwendet oder von Hand kompiliert wird. Der Compiler der SE oder EE wird weiterhin für die Kompilierung benötigt, jedoch ist darauf zu achten, dass dieser Byte-Code produzieren muss, welcher zur Version 1.4 kompatibel ist. Bei den neueren Java Edition 5.0 und 6.0 muss dies explizit angegeben werden. Anders als von den anderen Java-Editionen bekannt, findet keine Verifikation der Klassen bei deren Laden statt. Um Zeit und Speicher zu sparen wurde beschlossen diese einfach wegzulassen und durch eine sogenannte Präverifikation (preverification) zu ersetzen. Diese Art der Verifikation muss vom Programmierer selbst durchgeführt werden. (Kompilierte) Klassen, die den Vorgang durchlaufen haben, werden speziell markiert und erst danach von der KVM akzeptiert. Ohne Präverifikation kann die betreffende Klassendatei nicht geladen werden. Das Java Wireless Toolkit for CLDC bringt eine Kommandozeilenanwendung für diesen Entwicklungsschritt mit ( preverify.exe ). Optional kann ein Obfuscator angewandt werden. Ein Obfuscator ist ein Programm, welches u.a. Variablen- und Klassennamen durch Platzhalter (wie a, b, c...) ersetzt. Normalerweise wird er angewandt, um bei einer möglichen Rückübersetzung, das Lesen des Programmcodes zu erschweren. Im Zusammenhang mit der Entwicklung für die Mirco Edition wird jedoch von einem positiven Nebeneffekt Gebrauch gemacht: Durch das Austauschen der (langen) Namen ist weniger Speicherplatz erforderlich. Daher wird weniger Datenvolumen beim Übertragen der Anwendung verbraucht und die Speicherkapazität der mobilen Geräte geschont. Nachdem die kompilierten Klassen präverifiziert sind, müssen sie in ein JAR-

23 2.4 Programmentwicklung 17 Archiv verpackt werden. Zu diesem JAR-Archiv muss ein Java Application Descriptor zusammengestellt werden, welcher die Informationen über das Archiv enthält (siehe Abschnitt 2.3.3). Um diese Vorgänge in der Projektarbeit weitestgehend zu automatisieren kam Ant zum Einsatz. Das Paket antenna [Ant] liefert genau zu diesem Zweck mehrere Ant-Tasks, mit denen die oben geannten Schritte durchgeführt werden. Anhand einer Konfigurationsdatei können Informationen über die Anwendung festgelegt werden. Neben der Kompilierung und Präverifikation (und Obfuscation) werden zusätzlich alle Klassen zu einem Archiv zusammengepackt und der benötigte JAD automatisch anhand der Einstellungen und festgelegten Informationen generiert.

24 3 Bluetooth Die Bluetooth-Technologie ermöglicht die drahtlose Kommunikation mit anderen Geräten, die ebenfalls über eine Bluetooth-Schnittstelle verfügen. Außerdem ist Bluetooth gerade bei mobilen Geräten sehr stark verbreitet und quasi in allen neuen Handys integriert. Damit ist eine der Grundvoraussetzungen gegeben, ein aktuelles Handy zum Fernsteuern eines anderen Gerätes zu verwenden, wie man es von einer richtigen Fernbedienung kennt. Auf der PC-Seite ist Bluetooth weniger verbreitet. Meist übernimmt hier WLAN die Aufgabe und ist auf Grund schnellerer Übertragung besser geeignet. Trotzdem bietet sich die Möglichkeit durch einen USB-Dongle, welcher ungefähr so aussieht wie ein USB-Speicherstick, dem PC kostengünstig die Möglichkeit zu geben Bluetooth zu nutzen. 3.1 Geschichte Bluetooth wurde Mitte der 1990er Jahre ursprünglich von dem schwedischen Unternehmen Ericsson entwickelt. Seinen Namen hat es dem im 10. Jahrhundert lebenden Wikingerkönig Harald Blåtand zu verdanken, welcher zu deutsch Blauzahn bzw. englisch bluetooth bedeutet. Ziel von Bluetooth ist in erster Linie das Ersetzen von Kabelverbindungen zwischen verschiedenen Geräten. Es ist ein Industriestandard, welcher sich nach IEEE für die drahtlose (Funk-)Vernetzung richtet. Ab 1997 übernahm die Bluetooth Special Interest Group (SIG), welche aus mehreren namhaften Unternehmen besteht, die Weiterentwicklung der Technologie. Zu dieser Gruppe zählen unter anderem Ericcson, IBM, Nokia und Microsoft. Aufgrund der geringen Größe und geringem Energievebrauch ist die Bluetooth- Technologie heute in einer breiten Masse von mobilen Geräten zu finden.

25 3.2 Funktionsweise Funktionsweise Bluetooth benutzt das sogenannte ISM-Band (Industrial, Scientific and Medical Band) für die Funkübertragung. Dadurch ist es möglich bluetooth-fähige Geräte weltweit problemlos einzusetzen, da das ISM-Band global frei zugänglich und keine Zulassung erforderlich ist. Die Frequenz liegt zwischen 2,402 und 2,480 GHz, was eine Abstufung in 79 Ein-MHz-Schritte ermöglicht [BTS]. Diese Abstufung ist nötig, da sich Bluetooth einem Frequenzsprungverfahren bedient um einerseits Störungen durch andere funkende Geräte vorzubeugen und andererseits das Abhören der Übertragung zu erschweren. Bluetooth-Geräte wechseln bis zu 1600 Mal pro Sekunde ihre Sendefrequenz. Daneben gibt es die Möglichkeit Daten symmetrisch (Upstream und Downstream gleich groß) oder asymmetrisch zu übertragen (meist Downstream größer als Upstream - vergleiche adsl). Es gibt verschiedene Versionen von Bluetooth mit unterschiedlichen maximalen Übertragungsgeschwindigkeiten. Version 1 bietet Übertragungen mit maximal 732,2 kbit/s, während bei Version 2 mit Enhanced Data Rate (EDR) bereits theoretisch 2,1 MBit/s möglich sind. Die kommende Version 3 soll Datenraten bis zu 480 MBit/s ermöglichen. Auch in der Reichweite und der damit verbundenen Leistungsaufnahme gibt es große Unterschiede. So werden Bluetooth-Geräte in Klassen unterteilt: Klasse 1 erreicht bis zu 100 m bei einem Energieverbrauch von 100 mw (milli Watt), Klasse 2 bis zu 20 m bei nur noch 2,5 mw Verbrauch und schließlich Klasse 3 bis 10 m bei lediglich 1 mw Leistungsaufnahme. Als Vergleichswert sei hier noch der Energieverbrauch eines handelsüblichen WLANs angeführt, welcher bei bis zu 500 mw liegt. Bluetooth-Geräte organisieren sich in Netzwerken, den sogenannten Piconets (Abbildung 3.1), welche bis zu 260 Teilnehmer umfassen können. Ein Gerät übernimmt dabei die Rolle des Masters (M, rot dargestellt), der das Netzwerk dirigiert. Die übrigen Teilnehmer sind Slaves (S, grün dargestellt) und müssen beim Master um Erlaubnis bitten, um Daten senden zu können. Maximal 8 Geräte können in einem Piconet gleichzeitig aktiv senden (1 Master, 7 Slaves). Die restlichen Teilnehmer befinden sich in dem Parkmodus (P, blau dargestellt) und halten so die Synchronisation mit dem Netzwerk. Erst wenn ihnen vom Master Sendezeit zugeteilt wird, dürfen sie anfangen Daten zu versenden. Ein Gerät kann stets nur Master eines einzigen Piconets sein, nicht Master in mehreren. Möglich ist jedoch, dass der Master eines Piconets ein Slave eines anderen Netzwerkes ist. Alle aktiven Geräte eines Piconets teilen sich die oben angeführten Bandbreiten. Daraus folgt, dass bei 8 aktiven Geräten jedem nur ein Achtel der maximalen Bandbreite zur Verfügung steht (bei Version 1 mit ca. 720 kbit/s wären dies 90 kbit/s pro Gerät). Je mehr Geräte also in einem Netzwerk vorhanden sind, desto langsamer wird das Netzwerk. Mehrere Piconets bilden ein Scatternet. Um in einem Scatternet die verschiedenen Piconets zu differenzieren, verwendet jedes Piconet eine bestimmte Reihenfolge im Frequenzsprungverfahren.

26 3.2 Funktionsweise 20 Abbildung 3.1. Bluetooth Netzwerktopologie (Piconets, Scatternet) Alle Bluetooth-Geräte besitzen eine 48-Bit lange und global eindeutige Seriennummer, ähnlich der MAC-Adresse bei Netzwerkkarten. Über diese ID könnnen sich die Geräte gezielt untereinander adressieren und miteinander kommunizieren. Um jedoch Daten zwischen Geräten übertragen zu können, muss die Seriennummer des Empfängers dem Sender bekannt sein. Durch eine Inquiry-Rundnachricht (deutsch Erkundigung ) kann ein Bluetooth-Gerät feststellen, welche anderen Geräte in seiner Reichweite sind und die Geräteadressen von diesen erfragen. Erst dann kann mit einer Page-Nachricht (deutch ausrufen ) eine Verbindung zu einem bestimmten Gerät hergestellt werden. Um die Datenübertragung abzusichern, stellt Bluetooth 3 Modi zur Verfügung. Der erste Modus ist der Non-Secure-Mode, welcher keinerlei Sicherheitsmechanismen bietet und bei dem lediglich das Abhören der Daten durch das Frequenzsprungverfahren erschwert wird. Beim 2. Modus, dem Service-Level Enforced Security, hat die Anwendung Kontrolle darüber, wie die Datenverbindung abgesichert werden soll. Link-Level Enforced Security ist der letzte Modus, welcher auf Verbindungsebene durch kryptographische Authentifizierung und (optionale) Datenverschlüsselung Sicherheit bietet. Eine Authentifizierung zwischen den Geräten findet nach dem Verbindungsauf-

27 3.2 Funktionsweise 21 bau statt, jedoch vor der eigentlichen Datenübertragung. Hierzu muss eine PIN, welche auf einem Gerät eingegeben wurde, von dem zweiten Gerät (durch Benutzereingabe) bestätigt werden. Stimmen die PINs überein, ist eine Authentifizierung geglück. Wenn nicht, wird die Verbindung abgelehnt. Nach einer erfolgreichen Authentifizierung tauschen die Geräte Sitzungsschlüssel aus, welche dann zum Verschlüsseln der Daten verwendet werden. Um nicht jedesmal die PINs abgleichen zu müssen, wenn zu einem späteren Zeitpunkt erneut eine Verbindung zu einem bereits authentifizierten Gerät hergestellt werden soll, können Bluetooth-Geräte eine Art Freundesliste verwalten. Hier werden Geräteadresse und PIN aufbewahrt, sodass diese nicht erneut erfragt werden müssen. Diese Funktion wird Pairing (Paarung) genannt. Bluetooth-Geräte stellen Dienste bereit, ähnlich Servern, welche auf verschiedenen Ports einer Internetadresse lauschen. Diese Dienste besitzen eine 128 Bit lange, global eindeutige UUID (universally unique identifier). Die Bluetooth- Geräteadresse stellt quasi die IP-Adresse, die UUID den Port dar (auf die TCP- Socketprogrammierung bezogen). Damit ein anderes Gerät die angebotenen Dienste ermitteln kann, muss jeder Dienst in die Service Discovery Database (SDDB) eingetragen werden. In Form von Service Records (SR) werden Dienstname, UUID sowie weitere optionale Informationen wie Hersteller, Webseite und Version neben anderen hinterlegt. Diese können mit Hilfe des Service Discovery Protocols (SDP) ausgelesen werden. Sobald das zweite Gerät diese Liste besitzt, kann es gezielt eine Verbindung zu einem der angebotenen Dienste aufbauen und diesen nutzen. Bluetooth spezifiert mehrere Profile für die Datenübertragung. Diese wurden eingeführt um die Kommunikation zu einem bestimmten Zweck zu vereinheitlichen. Als Beispiel sei hier die Audioübertragung zu einem Headset angeführt: Das Headset bietet das Profil A2DP (Advanced Audio Distribution Profile) an. Somit können sämtliche Bluetooth-Geräte, welche ebenfalls dieses Profil unterstützen, das Headset als Ausgabegerät für Audio benutzen. Ein Profil gibt dabei nicht nur die Art, wie die Daten übertragen werden, vor, sondern neben anderen Dingen auch, ob eine symmetrische oder asymmetrische Übertragung verwendet wird, welche maximale Bandbreite zur Verfügung steht, usw. (siehe oben). Es kann also als eine Art Konfiguration für einen bestimmten Anwendungsbereich verstanden werden. Für diese Projektarbeit von Bedeutung ist das Serial Port Profile (SPP), welches eine serielle Datenstromübertragung ermöglicht. Zum Auffinden des angebotenen Dienstes auf dem PC kommt zudem das Service Application Discovery Profile (SADP) zum Einsatz. Abbildung 3.2 zeigt die einzelnen Schichten, die bei der Kommunikation mittels Bluetooth von der JAVA-Anwendung bis zur eigentlichen Funkübertragung eine Rolle spielen. Die untersten 4 Schichten (blau dargestellt) sind in Hardware, Firmware und dem Treiber für diese realisiert. Wie deren Implementierung aussieht, ist dem Hersteller überlassen, muss jedoch der Spezifikation für Bluetooth genügen. Die Hauptaufga-

28 3.2 Funktionsweise 22 Abbildung 3.2. Der Bluetooth-Stack be besteht darin, die Datenübertragung zu kontrollieren und eventuell auftretende Fehler zu kompensieren. Darauf setzt der Host Protocol Stack, auch System Bluetooth Stack genannt, auf (grün dargestellt). Er ist meist im Betriebssystem integriert (Microsoft Bluetooth-Stack), kann jedoch durch andere Stacks ausgetauscht werden (WID- COMM, BlueSolei,...). Dieser Stack stellt verschiedene Protokolle bereit, über welche die Anwendungen später mit anderen Anwendungen kommunizieren können. In der Abbildung 3.2 sind nur 3 der Protokolle auszugsweise dargestellt, da diese für die Projektarbeit wichtig sind. Welche Protokolle überhaupt bereitgestellt werden ist auch hier dem Autor des Stacks überlassen. Allen anderen Protokollen zugrunde liegt das L2CAP (Logical Link Control and Adaption Protocol). Es kapselt sämtliche unterliegenden Schichten des Stacks. Darauf setzten die Protokolle SDP (Service Discovery Protocol) und RFCOMM (Radio Frequency Communication) auf. Wie bereits oben erwähnt, wird mit Hilfe des SDP ein Gerät nach den angebotenen Diensten abgefragt. Um das SPP nutzen zu können, muss der System-Stack das RFCOMM-Protokol unterstützen. RFCOMM dient dazu serielle Schnittstellen zu emulieren und ist somit für serielle Datenübertragungen über Bluetooth essenziell.

29 3.3 Bluetooth und JAVA Bluetooth und JAVA Sämtliche Java-Editionen sind von Haus aus nicht in der Lage Bluetooth-Hardware zu verwenden. Egal ob SE, EE oder ME, die Laufzeitumgebung muss in allen Fällen um Bluetooth-Funktionalität durch Drittanbieter erweitert werden. Dabei setzen diese Implementierungen auf dem System-Bluetooth-Stack auf (Abbildung 3.2, rot dargestellt). Erst dann können Java-Anwendungen (gelb dargestellt) von der Bluetooth-Hardware Gebrauch machen Java Micro Edition Um der Micro Edition die Nutzung der Bluetooth-Hardware zu ermöglichen, muss ein optionales Paket, welches eine JSR-82 Implementierung repräsentiert, installiert sein. JSR-82 (Java APIs for Bluetooth Wireless Technology, siehe 3.4) ist eine Spezifikation nach der sich Bluetooth-Implementierungen für die Java ME richten müssen. Es spezifiziert eine API, mit der der Programmierer alle Möglichkeiten, die Bluetooth bereitstellt, nutzen kann. Wie ein Hersteller die Spezifikation realisiert, ist ihm überlassen. Meist ist der Hersteller des Gerätes auch für die Erweiterung der Java-Umgebung verantwortlich. Obwohl ein Gerät über die nötige Hardware verfügt, muss nicht zwangsläufig die installierte Java-Umgebung die Möglichkeit besitzen von dieser Gebrauch zu machen. Ein Nachrüsten durch den Benutzer ist nicht vorgesehen und meist auch technisch gar nicht möglich Java Standard und Enterprise Edition Die Standard und Enterprise Editionen der Java Plattform 2 verfügen nicht über die Möglichkeit Bluetooth-Hardware zu nutzen. Die Laufzeitumgebung muss hier ebenfalls durch Bibliotheken über das JNI (Java Native Interface) erweitert werden um über das Betriebssystem die Hardware verwenden zu können. Im Gegensatz zur Java Micro Edition muss man sich hier nicht nach den Vorgaben des JSR-82 richten. Einem Hersteller einer Bluetooth-Implementierung für Java ist es freigestellt, wie dessen API letztendlich aussieht. Dennoch gibt es Implementierungen für Java SE und EE, welche den Anforderungen von JSR-82 genügen. Es wurde in dieser Projektarbeit Wert darauf gelegt, dass sowohl auf Client- als auch auf Serverseite eine möglichst gleiche Programmierbasis zur Verfügung steht. Daher fiel die Wahl auf BlueCove [Blu]. BlueCove ist eine freie Bluetooth-Implementierung für Java, welche zur Zeit auf Windows-Betriebssysteme beschränkt ist, jedoch in Zukunft um die Unterstützung von Apple Mac OS und Linux erweitert werden soll. Sie ist nach der Spezifikation der Java APIs for Bluetooth Wireless Technology entwickelt worden und lässt sich damit genauso handhaben wie eine JSR-82 Implementierung für die Java ME. Es ist ebenfalls möglich BlueCove durch eine andere JSR-82 Implementierung auszutauschen, ohne dass dadurch Änderungen am Quellcode der Projektarbeit nötig werden.

30 3.4 Java APIs for Bluetooth Wireless Technology (JSR-82) Java APIs for Bluetooth Wireless Technology (JSR-82) Java APIs for Bluetooth Wireless Technology (JABWT) [J82] sind in erster Linie für die Java Mirco Edition gedacht, jedoch nicht auf diese beschränkt. Sie sind das Bindeglied zwischen dem System-Stack und der eigentlichen Java-Anwendung. Im Folgenden werden nur die wichtigsten Schritte bei der Verwendung von Bluetooth unter Java in Verbindung mit einer JSR-82 Implementierung erläutert, da eine ausführliche Erklärung den Rahmen sprengen würde Verbindungsaufbau 1 // S e r v e r 2 Connector. open ( spp : / / l o c a l h o s t : ) ; 3 4 // Client, URL ohne w e i t e r e e r f o r d e r l i c h e Parameter! 5 Connector. open ( spp : / /AABBCCDDEEFF: ) ; Listing 3.1. URLs für Verbindungsaufbau einer Bluetooth-Verbindung mit GCF Wie bereits im Kapitel erläutert benutzen auch die JABWT das Generic Connection Framework um Verbindungen herzustellen. Als Protokoll in der URL wird hier das Bluetooth-Profil angegeben (z.b. SPP, A2DP,...). Der Host ist beim Server localhost und beim Client die Bluetooth-Geräteadresse des Zielgerätes. Als Port dient die UUID des Dienstes, welcher benutzt werden soll. Listing 3.1 zeigt beispielhaft die URLs, die auf Server bzw. Client verwendet werden müssen, um eine gemeinsame Verbindung aufzubauen. Sobald ein Server den Aufruf der acceptandopen()-methode auf dem Notifier, den er vom GCF geliefert bekommt, getätigt hat, wird automatisch ein Service Record in die SDDB eingetragen und der Dienst ist ab diesem Zeitpunkt auffindbar. Geräte, welche einen Dienst erfragen, erhalten ein Objekt, das das Interface ServiceRecord realisiert und damit die Methode getconnectionurl(int requiredsecurity, boolean mustbemaster) besitzt. Diese Methode liefert einen String zurück, welcher, als URL in der open(string url)-methode der Connection Factory übergeben, gezielt eine Verbindung zu dem betreffenden Dienst herstellt Bearbeiten von Service Records Die Klasse LocalDevice (Abbildung 3.3) repräsentiert das Bluetooth-Gerät und den Stack. Durch sie ist es möglich Einstellungen vorzunehmen und Informationen über das Gerät zu ermitteln. Es handelt sich um ein Singleton, sodass eine Referenz auf ein Objekt dieser Klasse nur über die statische Methode getlocaldevice() besorgt werden kann. Durch die Methode getrecord(connection notifier) kann ein Server Zugriff auf den Service Record des angebotenen Dienstes erlangen. Als Parameter ist der Notifier von

31 3.4 Java APIs for Bluetooth Wireless Technology (JSR-82) 25 Method Summary String getbluetoothaddress() Retrieves the Bluetooth address of the local device. DeviceClass getdeviceclass() Retrieves the DeviceClass object that represents the service classes, major device class, and minor device class of the local device. int getdiscoverable() Retrieves the local device's discoverable mode. DiscoveryAgent getdiscoveryagent() Returns the discovery agent for this device. String getfriendlyname() Retrieves the name of the local device. static LocalDevice getlocaldevice() Retrieves the LocalDevice object for the local Bluetooth device. Static String getproperty(java.lang.string property) Retrieves Bluetooth system properties. ServiceRecord getrecord(javax.microedition.io.connection notifier) Gets the service record corresponding to a btspp, btl2cap, or btgoep notifier. Static boolean ispoweron() Retrieves the power state of the local Bluetooth device. boolean setdiscoverable(int mode) Sets the discoverable mode of the device. void updaterecord(servicerecord srvrecord) Updates the service record in the local SDDB that corresponds to the ServiceRecord parameter. Abbildung 3.3. Methoden der Klasse LocalDevice nöten, damit der Service Record eindeutig identifiziert werden kann. Das zurückgelieferte Objekt implementiert das Interface ServiceRecord, welches mehrere Methoden zum Setzen und Auslesen von Informationen vorschreibt. setattributevalue(int attrid, DataElement attrvalue) wird verwendet um Informationen zu ändern. Der Parameter attrid gibt dabei das Feld im Service Record an, welches geändert werden soll. So ist beispielsweise 0x0100 der Name des Dienstes. Der zweite Parameter attrvalue ist ein Objekt der Klasse DataElement, welches als Kontainer für verschiedene Datenformate fungiert. Der Datentyp eines DataElements wird bei dessen Erstellung als Konstruktorparameter angegeben. Die Klasse spezifiert dazu mehrere öffentliche Konstanten, wie unter anderem DataElement.STRING oder DataElement.URL Geräte und Dienste suchen Um andere Geräte und deren Dienste aus Java-Applikationen heraus auffinden zu können, steht der Discovery Agent zur Verfügung. Eine Referenz auf diesen lässt sich durch die Methode getdiscoveryagent() besorgen. Die Klasse DiscoveryAgent bietet Methoden um eine Suche nach Geräten zu starten und zu stoppen sowie gefundene oder bekannte Geräte nach deren angebotenen Diensten zu fragen. Die Ergebnisse beider Suchvorgänge werden einem Objekt mitgeteilt, welches das Interface

32 3.4 Java APIs for Bluetooth Wireless Technology (JSR-82) 26 Method Summary boolean cancelinquiry(discoverylistener listener) Removes the device from inquiry mode. boolean cancelservicesearch(int transid) Cancels the service search transaction that has the specified transaction ID. RemoteDevice[] retrievedevices(int option) Returns an array of Bluetooth devices that have either been found by the local device during previous inquiry requests or been specified as a pre-known device, depending on the argument. int searchservices(int[] attrset, UUID[] uuidset, RemoteDevice btdev, DiscoveryListener disclistener) Searches for services on a remote Bluetooth device that have all the UUIDs specified in uuidset. String selectservice(uuid uuid, int security, boolean master) Attempts to locate a service that contains uuid in the ServiceClassIDList of its service record. boolean startinquiry(int accesscode, DiscoveryListener listener) Places the device into inquiry mode. Abbildung 3.4. Methoden der Klasse DiscoveryAgent DiscoveryListener implementieren muss. Method Summary void devicediscovered(remotedevice btdevice, DeviceClass cod) Called when a device is found during an inquiry. void inquirycompleted(int disctype) Called when an inquiry is completed. void servicesdiscovered(int transid, ServiceRecord[] servrecord) Called when service(s) are found during a service search. void servicesearchcompleted(int transid, int respcode) Called when a service search is completed or was terminated because of an error. Abbildung 3.5. Methoden des Interface DiscoveryListener Durch einen Aufruf der Methode startinquiry( int accesscode, DiscoveryListener listener ) der Klasse DiscoveryAgent wird die Suche nach Geräten angestoßen. Da der Discovery Agent in einem eigenen Thread arbeitet, kehrt der Aufruf sofort wieder zurück und die Suche findet parallel statt. Der Parameter accesscode gibt an, wie Geräte gesucht werden. Mit Hilfe der öffentlichen Konstanten DiscoveryAgent.GIAC und DiscoveryAgent.LIAC lässt sich eine (vollständige) Suche mit Anfragen an die sich in Reichweite befindlichen Geräte durchführen. Eine Angabe der Konstanten DiscoveryAgent.PREKNOWN bewirkt, dass nur die Geräte, welche gepaart sind (siehe Pairing, Abschnitt 3.2) geliefert werden. Ein weiterer Parameter listener repräsentiert das DiscoveryListener-Objekt, welchem die Ergebnisse mitgeteilt wer-

33 3.4 Java APIs for Bluetooth Wireless Technology (JSR-82) 27 den sollen. Wird ein Gerät gefunden, so ruft der Discovery Agent die Methode devicediscovered(remotedevice btdevice, DeviceClass cod) auf dem Listener auf. Der Parameter btdevice ist ein Objekt der Klasse RemoteDevice, welches nähere Informationen über das gefundene Gerät zur Verfügung stellt. Wurde die Suche abgeschlossen, so erfolgt ein Methodenaufruf von inquirycompleted(int disctype) auf dem Listenerobjekt. Der übergebene Parameter gibt an, ob die Suche erfolgreich war, fehlschlug oder abgebrochen wurde. Letztere Möglichkeit ergibt sich durch die Methode cancelinquiry(discoverylistener listener ) der Klasse DiscoveryAgent. Wie viele gleichzeitige Gerätesuchen ein Bluetooth-Gerät unterstützt, ist Herstellersache. Eine Suche nach Diensten folgt nahezu dem selben Prinzip. Sie wird duch einen Aufruf von searchservices( int [] attrset, UUID[] uuidset, RemoteDevice btdev, DiscoveryListener disclistener ) gestartet. Pro Suche können mehrere Dienste gezielt erfragt werden. Rückgabewert dieser Methode ist eine Transaktions-ID, welche beim Abbruch des Suchvorgangs durch die Methode cancelservicesearch(int transid) angegeben werden muss. Der erste Parameter gibt die IDs an, welche aus dem Service Record gelesen werden sollen. uuidset ist ein Array der UUIDs der Dienste, über die Informationen vom anderen Gerät erfragt werden sollen. Als dritter Parameter muss ein Gerät, welches Ziel der Dienstsuche ist, angegeben werden. Dies muss ein Objekt der Klasse RemoteDevice sein, das von der vorherigen Gerätesuche besorgt werden kann. Wie schon bei der Gerätesuche muss ein Listener für die Ergebnisse angemeldet werden. Das gleiche Objekt, welches schon bei der Gerätesuche verwendet wurde, kann auch hier nochmals benutzt werden. Sobald ein angegebener Dienst gefunden wurde, löst der Discovery Agent einen Aufruf der DiscoveryListener-Methode servicesdiscovered( int transid, ServiceRecord[] servrecord) aus. Um mehrere parallele Dienstsuchen auseinander zu halten, wird stets die Transaktions-ID als erster Parameter mitgeliefert. Der zweite Parameter ist ein Array aus ServiceRecords, welches aus einem oder mehreren Elementen besteht, je nach dem, wie viele Ergebnisse gleichzeitig vom Zielgerät zurückgeschickt wurden. Wie bereits oben erläutert kann von diesen Objekten eine URL zum gezielten Verbinden zu einem Dienst mittels der Methode getconnectionurl(...) erstellt werden. Zum Abschluss einer Dienstsuche wird die Methode servicesearchcompleted(int transid, int respcode) ausgeführt. Auch hier wird wieder die Transaktions-ID übergeben sowie ein Statuscode (Parameter respcode), der Auskunft über Erfolg, Fehlschlag oder Abbruch der Suche gibt.

34 4 Robot Die Klasse Robot ist eine der wichtigsten Komponenten, auf die sich diese Projektarbeit stützt. Sie wurde mit Java 1.3 von SUN eingeführt und soll es ermöglichen automatisiert Programme zu testen, indem Benutzerinteraktionen wie Tastatureingaben und Mausbewegungen/-klicks simuliert werden. Anders als beispielsweise im AWT Eingaben zu simulieren, greift Robot dazu auf das unterliegende Betriebssystem zu. Dadurch ist es möglich, nicht nur in der eigentlichen Java-Applikation Ereignisse auszulösen, sondern auch in anderen aktiven Anwendungen. Mausbewegungen, Tastendrücke und Klicks werden auf diese Weise vorgegaukelt und sind nicht von normalen Benutzereingaben zu unterscheiden. Wenn in den folgenden Abschnitten vom Drücken bzw. Loslassen einer Taste die Rede ist, dann ist damit eine Simulation auf Betriebssystemebene gemeint, sofern nichts anderes hinzugefügt wird. Um diese Low-Level-Eingaben realisieren zu können, braucht die Java-Laufzeitumgebung möglicherweise besondere Rechte. Es ist daher nicht gewährleistet, dass eine Java-Anwendung auf allen Betriebssystemen lauffähig ist. Es kann durchaus sein, dass ein System gar nicht die Möglichkeit bietet Eingaben zu simulieren. Sollte ein solcher Fall eintreten, wird bei der Erstellung eines Robot-Objektes eine AWTException ausgelöst. Die Klasse besitzt einige Methoden, auf die in der Projektarbeit zurückgegriffen wird. Abbildung 4.1 fasst die wichtigsten zusammen. Um einen Tastendruck zu simulieren, werden die Methoden keypress(int keycode) und keyrelease(int keycode) benötigt. Die Benennung dieser Methoden lässt bereits auf deren Funktion schließen: mit keypress() wird das Drücken einer Taste ausgelöst und mit keyrelease() teilt man dem System mit, dass die Taste wieder losgelassen wurde. Der Parameter keycode ist ein numerischer Wert, welcher eine Taste identifiziert. Die Konstanten der Klasse KeyEvent können an dieser Stelle verwendet werden, da die Werte der Tasten von Betriebssystem zu Betriebssystem varriieren können. Auf den meisten Systemen entspricht jedoch der keycode dem (ASCII-)Zeichenwert des großgeschrieben Buchstabens bzw. der Zahl. Das Verhalten, dass z.b. in einem Editor mehrere Zeichen erscheinen, wenn eine Taste auf der Tastatur längere Zeit gedrückt wird, lässt sich nicht bei einer längeren Pause zwischen dem Aufruf von keypress() und keyrelease() beobachten. Um dies zu erreichen muss der Programmierer dafür sorgen, dass die Methoden in der entsprechenden Reihenfolge mehrfach hintereinander aufgerufen

35 4 Robot 29 Method Summary BufferedImage createscreencapture(rectangle screenrect) Creates an image containing pixels read from the screen. void delay(int ms) Sleeps for the specified time. void keypress(int keycode) Presses a given key. void keyrelease(int keycode) Releases a given key. void mousemove(int x, int y) Moves mouse pointer to given screen coordinates. void mousepress(int buttons) Presses one or more mouse buttons. void mouserelease(int buttons) Releases one or more mouse buttons. Abbildung 4.1. Methoden der Klasse Robot (Auszug) werden. Mehrere aufeinanderfolgende Aufrufe von keypress() mit gleichem Parameter bewirken, dass mehrere Tastendrücke erkannt werden. Egal wie oft diese Methode aufgerufen wurde, mit einem einzigen Aufruf von keyrelease() wird die angegebene Taste wieder losgelassen. Daher hat ein mehrmaligen Ausführen der Methode ohne vorangegangenem keypress() keine Auswirkung mehr. Wird ein durch keypress() initiierter Tastendruck nicht durch keyrelease() widerrufen, so bleibt die Taste auch nach Beendigung der Java-Anwendung weiterhin gedrückt. Ein Tastendruck kann auch vorzeitig vom Benutzer durch Drücken der entsprechenden Tastatur-Taste beendet werden. In diesem Fall verliert keyrelease() ebenfalls seine Funktion. Neben der Möglichkeit Tasten zu drücken, bietet die Klasse Robot Funktionen zum Kontrollieren der Maus. Die Methode mousemove(int x, int y) kann dazu verwendet werden, den Mauszeiger auf eine bestimmte X/Y-Koordinate auf dem Bildschirm zu setzen. Ähnlich der Methoden zum Tastendrücken, kann mit mousepress(int buttons) und mouserelease(int buttons) eine oder mehrere Maustasten gedrückt bzw. losgelassen werden. Maustasten können durch die Konstanten der Klasse InputEvent adressiert werden. InputEvent.BUTTON1 MASK repräsentiert dabei die linke, InputEvent.BUTTON3 MASK die rechte und InputEvent.BUTTON2 MASK die mittlere Taste. Sollen mehrere Tasten gleichzeitig gedrückt werden, so muss man diese Konstanten mit einem binären ODER verknüpfen. Natürlich kann auch für jede Taste ein eigener Methodenaufruf stattfinden. Bei der Simulation von Doppelklicks ist darauf zu achten, die Maustaste mit mouserelease() loszulassen, bevor sie erneut mit mousepress() betätigt wird, da sonst der zweite Aufruf von mousepress() unwirksam ist. Auch hier sollten vor Programmende alle gedrückten Maustasten wieder losgelassen werden, da diese ebenfalls nicht automatisch gelöst werden. Eine weitere Funktion, die die Klasse Robot bietet, ist das Erstellen von Screenshots. Zu diesem Zweck existiert die Methode createscreencapture(rectangle screenrect). Der Parameter gibt dabei den Ausschnitt des Bildschirmes an, welcher abgegriffen werden

36 4 Robot 30 soll. Ein Objekt der Klasse Rectangle stellt einen rechteckigen Ausschnitt dar und enthält Informationen über X/Y-Koordinate der oberen linke Ecke sowie Breite und Höhe des Rechtecks. Von der Methode wird ein Objekt von BufferedImage zurückgeliefert, welches die Bilddaten enthält. Ein Nachteil, der sich aus dieser Art der Screenshot-Erstellung ergibt, ist, dass mit steigender Größe der Vorgang sehr lange dauern kann. Zusätzlich kann je nach Schnelligkeit des verwendeten PCs die Leistung erheblich variieren und unter Umständen das System stocken. Da mobile Geräte meist ein kleines Display mit einer verhältnismäßig geringen Auflösung besitzen, fällt dieser Nachteil in den meisten Fällen jedoch nicht ins Gewicht.

37 5 Entwurf und Implementierung Abbildung 5.1. Client-Server-Anwendung Das folgende Kapitel dreht sich um den Entwurf und die Implementierung der Software. Dabei werden Übertragungsprotokoll, Client (mobiles Gerät) und Server (PC) getrennt betrachtet (Abbildung 5.1). Hauptsächlich wurde das Entwurfsmuster MVC angewandt. Es finden sich aber auch einige Klassen, welche das Singleton- Muster aufweisen.

38 5.1 Übertragungsprotokoll und Kommunikation Übertragungsprotokoll und Kommunikation Zur Kommunikation zwischen Server und Client wurde ein eigenes Übertragungsprotokoll entworfen und implementiert. Dies war nötig auf Grund der verschiedenen Datentypen, welche vom Server an den Client gesendet werden. Da nur ein einziger Byte-Datenstrom durch das GCF bei einem Verbindungsaufbau zurückgeliefert wird, muss eine Möglichkeit implementiert werden um die Datentypen über diesen Strom zu senden und später auf dem Client wieder auseinander halten zu können. Abbildung 5.2 zeigt den Aufbau des Container-Pakets, in welchem die eigentlichen Nutzdaten bei der Übertragung verpackt werden. Abbildung 5.2. Schema des Container-Datenpakets Das Paket hat keine vordefinierte, maximale Länge, um zu gewährleisten, dass mit einem Paket beispielsweise ein komplettes Bild (dessen Größe von der Größe des Anzeigegerätes abhängig ist und daher stark variieren kann) gesendet werden kann. Das erste Byte (DataType, in Abbildung rot hervorgehoben) gibt dabei den Typ der Daten an, die verpackt sind. Folgende Liste liefert einen Überblick über die definierten Datentypen: 0x00 Kommando 0x01 Text 0x02 Bilddaten Der zweite Teil des Containers (grün) hat eine variable Länge, die von der Länge der Nutzdaten abhängt. Abgeschlossen wird ein Paket mit einen Control Character (CC, weiss) gefolgt von einem Boundary Character (BC, grau). Diese beiden Zeichen dürfen nicht identisch sein, da nur so exakt das Ende eines Datenpaketes markiert werden kann. Um das Vorkommen dieser Zeichenkombination in den Nutzdaten zu verhindern und so falschen Endmarkierungen entgegenzuwirken, findet eine Verdopplung jedes Vorkommens eines Control Characters in den Nutzdaten statt. Um diese Verdoppelung zu veranschaulichen, sollen die Nutzdaten ACBACAA betrachtet werden. C repräsentiert dabei das Kontrollzeichen (Control Character), B das Trennzeichen (Boundary Char) und A ein beliebiges anderes Zeichen ungleich C oder B. Aus Abbildung 5.3 kann man herauslesen, wie sich die verpackten Nutzdaten von den originalen Nutzdaten unterscheiden. Durch die Verdoppelung entsteht aus ACBACAA die Zeichenfolge ACCBACCAA. Der Client interpretiert ein aufeinanderfolgendes Vorkommen des Kontrollzeichens als ein einziges Zeichen. Damit ist eine Kombination von ACBA in den verpackten Nutzdaten nicht mehr möglich, da diese stets ACCBA lauten würde.

39 5.1 Übertragungsprotokoll und Kommunikation 33 Abbildung 5.3. Verdoppelung des Control Characters in den Nutzdaten Je nach dem, welche Nutzdaten übertragen werden, hat dieser Anteil des Datenpaketes ein anderes Format. Wie dieser Bereich in den einzelnen Fällen aussieht, wird in den folgenden Abschnitten erläutert. Kommandos (Server zu Client) Um dem Client Anweisungen zu geben, bedient sich der Server Kommandos. Kommandos sind z.b. Anweisungen den Bildschirm zu löschen oder die Verbindung zu trennen. Ein Kommando hat die Typenbezeichnung 0x00, besitzt einen eindeutigen String als Namen und kann beliebig viele Paramter haben (ebenfalls Strings). Abbildung 5.4. Format eines Kommando-Pakets Jeder Teil eines Kommandos besitzt eine beliebige Länge (siehe Abbildung 5.4). Der erste Teil (CMD, orange) gibt dabei den Namen des Kommandos an, welches ausgeführt werden soll. Die weiteren Teile sind Parameter (PARAMx, gelb). Um diese voneinander zu trennen wird derselbe Mechanismus, wie bereits oben bei dem Containerpaket erläutert, angewandt. Ein Kontrollzeichen (CCC), Trennzeichen (CBC) und die Verdoppelung des Kontrollzeichens finden hier daher ebenfalls entsprechende Anwendung. Wichtig ist, dass bei der Auswahl dieser Zeichen darauf geachtet wird, dass sie sich von den Zeichen, die beim Kontainerpaket verwendet werden, möglichst unterscheiden. Wird dies nicht beachtet, entstehen unnötige Zusatzkosten (Overhead) beim Senden, da die Kontrollzeichen verdoppelt werden müssen.

40 5.1 Übertragungsprotokoll und Kommunikation 34 Texte Ein weiterer Datentyp, der übertragen werden kann, sind Textdaten mit der Typenbezeichnung 0x01. Ein Text ist ein String, welcher eine beliebige Länge besitzt und an einer bestimmten (X/Y-) Koordinate auf der Anzeige des mobilen Gerätes positioniert werden kann (obere linke Ecke). Darüber hinaus kann bestimmt werden, in welcher Farbe er dargestellt wird. Die folgende Abbildung (5.5) gibt eine Übersicht über das Format bei der Übertragung. Abbildung 5.5. Format eines Text-Pakets Die Positionskoordinaten werden jeweils durch 2 Bytes ausgedrückt. Dies ist nötig, da durch die Nutzung lediglich eines Bytes nur eine maximale Adressierung von 256x256 Bildpunkten möglich wäre, was jedoch für die meisten Geräte viel zu wenig ist. Durch 2 Bytes wird diese Anzahl auf 65536x65536 (256 * 256) Punkte erhöht. Dabei repräsentiert das erste Byte (X1 und Y1) die oberen 8 Bit der Zahl, das zweite Byte (X2 und Y2) die hinteren 8 Bit. Die Koordinaten lassen sich durch folgende Terme berechnen: X = 256 X1 + X2, Y = 256 Y1 + Y2. Der Wertebereich ist also [0;65535] für beide Koordinaten, da der Punkt (0,0) auch ausgewählt werden kann. Die Farbe des Textes wird durch einen RGB-Wert ohne Alpha-Kanal bestimmt. Jeder Farbkanal (Rot R, Grün G, Blau B) besitzt einen Wert im Interval [0;255], wobei 255 für einen hundertprozentigen Anteil und 0 für keinen Anteil an der Endfarbe steht. Durch eine Mischung der Werte kann eine (fast) beliebige Farbe erreicht werden. Aufgrund des eingeschränkten Wertebereiches kann jeder Farbkanal durch ein Byte ausgedrückt werden. Wie in Abbildung 5.5 erkennbar ist, folgen die dazu nötigen 3 Bytes direkt auf die Koordinatenangaben. An diese schließen sich die Bytes des Textes an, welche die Buchstaben repräsentieren. Bilder Ebenfalls unterstützt wird die Übertragung von Bilddaten mit der Typenbezeichnung 0x02. Die Bilddaten können in einem beliebigen Format vorliegen, jedoch muss es von der Java Micro Edition auf dem mobilen Gerät unterstützt werden. Wie auch bei einem Text kann eine Positionsangabe der oberen linken Ecke des Bildes gemacht werden, ab welcher es dargestellt wird. Das Format eines Paketes mit Bilddaten lässt sich aus der Abbildung 5.6 entnehmen.

41 5.1 Übertragungsprotokoll und Kommunikation 35 Abbildung 5.6. Format eines Bild-Pakets Auch bei Bildern erfolgt eine Positionsangabe im Interval [0;65535] für jede Koordinate und ermöglicht damit eine maximale Auflösung von 65536x65536 Bildpunkten. Wie bereits erwähnt repräsentiert das erste Byte (X1 und Y1) die oberen 8 Bit der Zahl, das zweite Byte (X2 und Y2) die hinteren 8 Bit. Damit können die gleichen Formeln wie bei den Texten zur Berechnung der Positionsangaben auch hier eingesetzt werden. Kommandos (Client zu Server) Die einzige Möglichkeit des Clients Daten an den Server zu senden besteht in der Form von Kommandos. Wichtig zu beachten ist, dass diese Kommandos keinerlei Beziehung du den bereits angesprochenen Kommandos besitzen, die der Server dem Client sendet. Die Kommunikation von Client zu Server beschränkt sich auf ein einfaches Textformat für die Kommandos. Das Format sieht in etwas wie folgt aus: KOMMANDO PARAMETER1 PARAMETER2... Als Trennzeichen zwischen dem Kommandonamen und den einzelnen Parametern (beliebig viele) wird hier ein einfaches Leerzeichen benutzt. Das Trennzeichen für die Kommandos ist ein Zeilenumbruch. Es ist nicht nötig ein komplexeres Protokoll für diese Übertragungsrichtung zu verwenden, da lediglich der Server beim Drücken und Loslassen einer Taste benachrichtigt werden muss. Das Format des Kommandos für die Benachrichtigung beim Drücken einer Taste ist PRESS x und für das Loslassen RELEASE x. x steht dabei für den Tastencode der Taste des mobilen Gerätes und ist ein numerischer Wert. Ein Leerzeichen oder Zeilenumbruch kommt daher von Natur aus nicht in einem Parameter vor und es muss deshalb auch keine Prüfung durchgeführt werden. Die Klassen RemoteControlConnection und RemoteServerConnection Die Klassen RemoteControlConnection und RemoteServerConnection kapseln die komplette Kommunikation in sich. RemoteControlConnection ist dabei auf dem Server anzutreffen, während sich RemoteServerConnection auf dem mobilen Gerät befindet. Beide Klassen stellen Methoden zur Verfügung um zwischen ihnen eine Verbindung aufzubauen und die oben angesprochenen Datentypen zu übertragen. Sie sind beide nach

42 5.1 Übertragungsprotokoll und Kommunikation 36 dem MVC-Modell modelliert und bieten dadurch Methoden an um Listener anzumelden, die bei Ereignissen benachrichtigt werden sollen. Sie sind weitestgehend unabhängig von der eigentlichen Server- bzw. Clientanwendung und können auch für andere Zwecke eingesetzt werden. Abbildung 5.7. Das Package de.dm.remotecontrol.server.connection Auf Seiten des Servers (RemoteControlConnection) wird zwischen 2 Arten von Listener unterschieden: Listener, die nur bei Benutzerinteraktionen benachrichtigt werden und Listener, denen Änderungen an der Verbindung (Trennung) mitgeteilt werden. Abbildung 5.7 gibt eine Übersicht über die Hierarchie der Interfaces für die Listenertypen. Method Summary void keypressed(int keycode) Diese Methode wird ausgeführt, wenn eine Taste auf dem mobilen Gerät gedrückt wurde void keyreleased(int keycode) Diese Methode wird ausgeführt, wenn eine (gedrückte) Taste auf dem mobilen Gerät losgelassen wurde Abbildung 5.8. Das Interface RemoteControlKeyListener RemoteControlKeyListener schreibt dabei Methoden für Klassen vor, die beim Drücken oder Loslassen von Tasten benachrichtigt werden sollen (Abbildung 5.8). Der Para-

43 5.1 Übertragungsprotokoll und Kommunikation 37 meter keycode ist dabei der Wert der Taste, welche auf dem mobilen Gerät betätigt wurde. Im Gegensatz zum PC, wo die Tastencodes positiv sind, kann es bei mobilen Geräten vorkommen, dass im speziellen die Sonder- und Zusatztasten, neben den normalen Tasten für die Nummern, negative Werte vorweisen. Method Summary void connectionclosed() Diese Methode wird aufgerufen, falls die Verbindung zum Client getrennt wurde void pongreceived(string id, long time) Diese Methode wird aufgerufen, wenn eine Antwort auf einen PING empfangen wurde Abbildung 5.9. Das Interface RemoteControlConnectionListener Das Interface RemoteControlConnectionListener (siehe Abbildung 5.9) muss von Klassen implementiert werden, welche über die Verbindung zum Clientgerät ansich informiert werden möchten. Zur Zeit werden lediglich 2 Funktionen angeboten: Das Benachrichtigen bei Verbindungsabbruch/-trennung und beim Empfang der Antwort auf einen gesendeten PING. Ein PING kann durch die Methode ping(string id) gesendet werden. Parameter ist dabei ein frei wählbarer String, der den Sender des PING-Befehls identifizieren soll. Diese ID wird in der Listenermethode als String wieder übergeben. Durch einen Vergleich kann der Sender herausfinden, ob es eine Antwort auf den von ihm gesandten PING ist. Als zweiten Parameter wird die Latenzzeit übergeben. Ein drittes Interface (RemoteControlListener) erweitert beide erwähnten Interfaces und ermöglicht es so Klassen durch Implementierung eines einzigen Interfaces sowohl als RemoteControlKeyListener als auch als RemoteControlConnectionListener zu agieren. Für jedes der angesprochenen Listenertypen gibt es eigene An- und Abmeldemethoden in der Klasse RemoteControlConnection. Method Summary void commandreceived(string command, String[] parameter) Wird aufgerufen, wenn ein Kommando empfangen wurde void connectionclosed() Wird aufgerufen, wenn die Verbindung zum Server getrennt wurde void imagereceived(image img, int posx, int posy) Wird aufgerufen, wenn ein Bild empfangen wurde void textreceived(string text, int color, int posx, int posy) Wird aufgerufen, wenn ein Text empfangen wurde Abbildung Das Interface RemoteServerActionListener

44 5.1 Übertragungsprotokoll und Kommunikation 38 Auf dem Client hingegen existiert nur ein Listener-Interface: RemoteServerActionListener (Abbildung 5.10). Es schreibt alle benötigten Methoden vor, um die Datentypen empfangen und über Änderungen der Verbindung benachrichtigt werden zu können. Neben der Aufgabe Daten zu versenden und Listener zu benachrichtigen, hat RemoteControlConnection noch dafür Sorge zu tragen, dass es nicht zu einer Vermischung von Daten über den einzigen Ausgabestrom kommt, wenn gleichzeitig mehrere Datenpakete versendet werden sollen. Aus diesem Grund wird der Versand eines Paketes immer zuerst vollständig beendet, bevor das nächste Paket an die Reihe kommt. Zu diesem Zweck ist die zentrale Methode des Datenversands sendpacket(byte[] data, byte type) synchronisiert.

45 5.2 Client Client Die Client-Applikation läuft auf dem mobilen Gerät und wurde daher auf Basis der Java Micro Edition entwickelt. Folgende Anforderungen werden an sie gestellt: Suche nach Geräten Anzeige der sich in Reichweite befindlichen Geräte Verbinden zu einem vom Benutzer gewählten Gerät Anzeigen von Texten und Bildern, welche vom Server gesendet werden Weiterleiten Benutzereingaben (Drücken/Loslassen von Tasten) an den Server Verarbeiten von vom Server gesendeten Kommandos Programmablauf Aus den angeführten Punkten lässt sich der in Abbildung 5.11 dargestellte Programmablauf herleiten. Nachdem der Client gestartet wurde, wird geprüft, ob ein Bluetooth-Gerät zur Verfügung steht. Sollte dies nicht der Fall sein, so können keine Geräte für die Verbindung zur Auswahl gestellt werden und dem Benutzer wird eine Fehlermeldung angezeigt. Falls keine Probleme auftreten, wird zunächst eine schnelle Suche nach Geräten durchgeführt. Dabei findet nur eine Suche nach bereits bekannten und gepaarten Geräten statt (siehe Abschnitt 3.2, Pairing), die sich möglicherweise in Reichweite befinden. Der Benutzer kann jedoch eine vollständige Suche anstoßen. Diese dauert erheblich länger als die schnelle Suche, findet aber auch bisher unbekannte Geräte. Die Suche nach Bluetooth-Geräten wurde bereits in Abschnitt erläutert und wird daher hier nicht weiter ausgeführt. Die Ergebnisse beider Sucharten werden dem Anwender in einer Liste präsentiert, aus der er einen Eintrag auswählen kann. Sofern das gefundene Bluetooth-Gerät seinen Namen zurücksendet, wird dieser als Eintrag der Liste angezeigt, sonst die Bluetooth- Hardwareadresse. Wurde eine Auswahl getroffen, findet ein Verbindungsaufbau zum Server statt. Tritt an dieser Stelle ein Fehler auf, wird dies dem Benutzer mitgeteilt und die Liste der gefundenen Geräte erscheint wieder auf dem Display. War der Vorgang erfolgreich, ist der Client ab diesem Moment einsatzbereit. Sämtliche Benutzereingaben auf dem mobilen Gerät werden an den Server weitergeleitet. Des Weiteren werden Bilder und Texte, die vom Server empfangen werden, auf dem Display angezeigt. Es ist daneben möglich Kommandos an den Server zu senden, die keine Daten zum Anzeigen enthalten. Weitere Informationen über die Datenübertragung zwischen Server und Client finden sich im Kapitel 5.1. Die Verbindung kann nur durch den Server getrennt werden oder durch Abschießen des Client-Prozesses. Letztere Möglichkeit wird normalerweise durch jede Java- Installation angeboten und das betreffende Menü lässt sich häufig durch längeres Betätigen einer bestimmten Taste aufrufen. Es ist möglich über den Profile Switcher (nähere Informationen dazu in Abschnitt 5.3.6) den Server zu veranlassen die Verbindung zu trennen. Diese Vorgehensweise ist erwünscht, da sonst eine der

46 5.2 Client 40 Abbildung Programmablauf Client wenigen vorhandenen Tasten standardmäßig belegt wäre und daher nicht für andere Zwecke zur Verfügung stünde. Wird die Verbindung durch den Server beendet, kehrt der Client wieder zur Geräteauswahl zurück. Der Benutzer hat nun durch das Menü die Möglichkeit die Clientanwendung zu beenden, weitere Geräte zu suchen oder erneut eine Verbidung herzustellen Geräteauswahl Die Geräteauswahl ist der erste (virtuelle) Bildschirm (siehe Abschnitt 2.3.2), der dem Benutzer angezeigt wird. In der aktuellen Implementierung existiert nur eine Instanz der Klasse DeviceChooser (Abbildung 5.12), zu der nach einer Gerätesuche

47 5.2 Client 41 Abbildung Klassendiagram Client (mobiles Gerät) oder Verbindungsabbruch zurückgekehrt wird. Sie erweitert List und ist damit ein Displayable-Objekt. Weiter wird das Interface DiscorveryListener implementiert, sodass das Objekt die Ergebnisse einer Bluetooth-Gerätesuche erhalten kann. Gefundene Geräte werden dieser Liste über die Methode append(object o) hinzugefügt. Der Benutzer kann mit Hilfe bestimmter Tasten des mobilen Gerätes einen Eintrag aus dieser Liste auswählen. Um diese Auswahl zu ermöglichen, müssen der Geräteauswahl Kommandos zugeordnet werden (siehe Abschnitt 2.3.2). Neben der Auswahl existieren Kommandos um eine lange Suche nach Geräten durchzuführen, eine kurze Hilfe anzuzeigen, Geräteinformationen aufzulisten oder das Programm zu beenden. Aus diesem Grund wird ebenfalls das Interface CommandListener vom DeviceChooser implementiert. Wurde ein Gerät gewählt, so erfolgt eine Instanziierung der Klasse RemoteController, welcher das Zielgerät mitgeteilt wird und die den Verbindungsaufbau sowie den weiteren Programmablauf kontrolliert Verbindungsaufbau Nach der Wahl des Gerätes werden die Informationen über dieses an ein Objekt der Klasse RemoteController übergeben. Daraufhin wird eine Dienstsuche (siehe Abschnitt 3.4.3) durchgeführt, um sicherzustellen, dass das gefundene Gerät auch tatsächlich als Server dienen kann. Wird bei der Suche der Dienst mit der entsprechenden Service-UUID gefunden, so bietet das Gerät den Serverdienst an und es kann eine Verbindung hergestellt werden. Ist dies nicht der Fall, so wird dem Benutzer ein Hinweis (Alert) eingeblendet, dass die Verbindung nicht hergestellt werden konnte

48 5.2 Client 42 und die Anzeige kehrt wieder zur Geräteauswahl zurück. Mit Hilfe des Generic Connection Framework (siehe Abschnitt 2.2.1) findet nun der eigentliche Verbindungsaufbau statt. Nachdem die Verbindung etabliert ist, wird ein Objekt der Klasse RemoteServerConnection angelegt (siehe Abschnitt 5.1) und die vom GCF erhaltene StreamConnection diesem übergeben. Zusätzlich meldet sich das RemoteController-Objekt als Listener an das RemoteServerConnection-Objekt an Eingabe und Anzeige Zentrales Objekt des Clients ist der RemoteController. Diese Klasse ist ein Displayable vom Typ Canvas (siehe Abschnitt 2.3.2). Ein Canvas-Objekt besitzt die Methoden keypressed(int keycode) und keyreleased(int keycode), welche (entsprechend ihrem Namen) beim Drücken bzw. Loslassen einer Taste des mobilen Gerätes aufgerufen werden, sofern das Displayable-Objekt die Anzeige besitzt. Der Parameter keycode ist dabei ein numerischer Wert, der (abhängig vom Gerät) eine bestimmte Taste identifiziert. Abbildung Drücken einer Taste Erfolgt ein Aufruf dieser Methoden, wird ein Kommando generiert und an den Server gesendet (Abbildung 5.13, analog keyreleased(int keycode)). Dabei wird dem Server quasi stur mitgeteilt, dass eine Taste gedrückt oder losgelassen wurde und welchen Keycode sie besitzt. Ein RemoteController kann neben den Eingaben auch Bilder und Texte, welche vom Server gesendet wurden, anzeigen. Durch Implementierung des Interfaces RemoteServerActionListener stehen Methoden bereit (siehe Abbildung 5.10) um beim Empfang von Daten benachrichtigt zu werden. Die Anzeige ist in 2 Ebenen aufgeteilt: Die untere Ebene ist für die Darstellung von Bildern gedacht und eine darüberliegende Ebene für Texte. Durch Überschreiben der Methode paint(graphics g) von Canvas lässt sich dies leicht realisieren. Es existiert ein Image-Objekt, in welches empfangene Bilder an den angegebenen X/Y-Koordinaten eingefügt werden. Empfangene Texte werden ebenfalls gespeichert. Die für diese Aufgabe vorhandene Klasse XYString bietet neben dem Hinterlegen des Textes auch die Möglichkeit der Speicherung der Positionsangaben und der Textfarbe. In der paint-methode wird zunächst das zwischengespeicherte Bild angezeigt und danach

49 5.2 Client 43 die Texte darüber gelegt. Dadurch erreicht man, dass ein Text immer im Vordergrund steht und nicht von einem Bild überdeckt wird. Um alle Texte zu entfernen, existiert das Kommando CLEARALLTEXTS, das vom Server gesendet werden kann. Ein solches Kommando gibt es für Bilder nicht. Dies kann jedoch einfach durch das Senden eines Bildes, welches die Ausmaße des Anzeigebereiches hat und nur eine Farbe besitzt, erreicht werden.

50 5.3 Server Server Der Server ist der zweite Teil der Projektarbeit und am umfangreichsten. Auch an ihn werden grundlegende Anforderungen gestellt, welche der folgenden Aufzählung entnommen werden können: Annahme und Verwaltung von mehreren Verbindungen Simulieren von Benutzerinteraktionen auf Betriebssystemebene Konfiguration von Tastenkombinationen (STRG + ALT +...) Assoziation der Tasten des mobilen Gerätes mit einer simulierten Benutzereingabe Bildübertragung zum mobilen Gerät Mit fortschreitender Recherche wurde jedoch klar, dass diese Anforderungen allein nicht genügen. Es kann nicht davon ausgegangen werden, dass bei der Benutzung der Tastencodes mobiler Geräte diese auf allen (von unterschiedlichen Herstellern) Geräten die gleiche Taste darstellen. Tatsächlich ist es so, dass bis auf die Codes der Zahlentasten (welche der ASCII-Tabelle entsprechen) es dem Hersteller vollkommen freigestellt ist, welche Codes er verwendet. Des Weiteren ist es für den Benutzer kompliziert mit Tastencodes eine Konfiguration durchzuführen, da es auf Grund der Anzahl an Tasten und der nicht zwingend nach einem Schema vergebenen Codes schwierig ist, sich zu behalten, welcher Wert welcher Taste zugeordnet ist. Aus diesem Grund wurden weitere Anforderungen nötig: Unterschiedliche Konfigurationen pro Gerät Vergabe von Namen (Aliase) für die Tasten mobiler Geräte Aber damit waren noch nicht alle Probleme beseitigt. Da die Steuerung einiger Anwendungen viele Tastenkombinationen vorraussetzt und mobile Geräte über weitaus weniger Tasten als eine normale Tastatur verfügen, musste für dieses Problem ebenfalls eine Lösung gefunden werden. Alleine die Steuerung der Maus würde für alle Richtungen (hinauf, hinunter, links und rechts) sowie jeweils für Links- und Rechtsklick eine Taste beanspruchen. Damit würden alleine bei der Benutzung der Maus 6 Tasten nicht mehr für andere Zwecke zur Verfügung stehen. Anders herum ist die Maus für einige Anwendungen nicht erforderlich und so würden die Tasten unnötig belegt sein. Daher wurde der Ansatz weiter verfolgt für verschiedene Anwendungen (Anwendungsbereiche) jeweils eine andere Tastenkonfiguration des mobilen Gerätes zu ermöglichen, zwischen welchen während des Betriebs gewechselt werden kann. Dies führte zu der Einführung von Profilen, welche eine Konfiguration für eine bestimmte Anwendung darstellt. Dabei geht ein Profil noch einen Schritt weiter und ermöglicht das komplette Weglassen von Serverfunktionalität. Genauer gesagt: Ist in einem Programm keine Maus notwendig, werden einfach die für die Mauskontrolle benötigten Klassen nicht geladen. Um dies zu realisieren und außerdem den Server für die Zukunft erweiterbar zu halten wurde ein Pluginsystem entworfen. Der eigentliche Server kümmert sich nur noch um die Verbindung zum Client und die Konfiguration. Die Simulation von Benutzereingaben und andere durch den Client nutzbare Funktionen werden in Plugins

51 5.3 Server 45 ausgelagert die bei Bedarf dynamisch zur Laufzeit (bei Aktivierung des betrffenden Profils) nachgeladen werden können. Zu den bereits erwähnten Anforderungen kommen also noch folgende hinzu: Profile für verschiedene Anwendungen (Anwendungsgebiete) Pluginsystem Repräsentation der Konfigurationsdaten Um die Konfiguration des Servers möglichst flexibel und skalierbar zu halten stand von Anfang an fest, dass diese im XML-Format hinterlegt werden würde. Im Gegensatz zu einem eigenen Format existieren bereits Implementierungen für das Parsen und Serialisieren vom XML-Dateien. Sämtliche Daten werden in der Konfigurationsdatei config.xml im Hauptverzeichnis des Servers hinterlegt. Programmintern wird ein DOM-Baum verwaltet, welcher Zugriff auf die Konfigurationsdaten ermöglicht. Um diesen manipulieren und erweitern zu können wird dabei auf das XML-Framework dom4j zurückgegriffen (für weitere Informationen zu dom4j siehe [DOM]). Obwohl die Klassen und Interfaces von dom4j denen von jdom extrem ähneln und sogar die gleichen Namen besitzen, sind die beiden DOM-Implementierungen nicht kompatibel zueinander. Trotz der nahezu identischen Bedienung (Programmierweise) lässt sich dom4j leichter handhaben als jdom und unterstützt zusätzlich XPATH [XPA]. Die dafür nötige XPATH-Engine wird durch das Projekt jaxen [JAX] geliefert. Mit Hilfe von XPATH ist es möglich, einen oder mehrere Knoten im DOM-Baum gezielt auszuwählen. 1 <W> 2 <AAA> 3 <BBB a t t r = abc /> //1 4 <CCC /> 5 <BBB /> //2 6 </AAA> 7 </W> Listing 5.1. XML Beispiel Da XPATH sehr mächtig ist und es zum genaueren Verständnis einer längeren Anleitung bedarf, werden hier in aller Kürze die Grundlagen geschildert. Die Angabe des Pfades gleicht einer URL. / wählt dabei den Wurzelknoten aus. Die Angabe von /W/* würde alle direkten Kindknoten von <W> aus dem Beispiel 5.1 auswählen. Um einen bestimmten Knoten auszuwählen kann auch dessen Index angegeben werden: /W/AAA/BBB[2] selektiert dabei das zweite Vorkommen von <BBB> unter <W> und <AAA> (mit //2 mar- kiert). Aber auch an Hand von Attributen ist es möglich Knoten gezielt zu adressieren. Der folgende Pfad zeigt dabei auf den im Beispiel mit //1 markierten Knoten: abc ]. Diese Pfade werden in den Methoden selectnodes(string xpathexpression) und selectsinglenode(string xpathexpression) des dom4j -

52 5.3 Server 46 Interfaces Node angegeben, die eine Liste von Node-Objekten bzw. nur eines zurückliefern (das erste Vorkommen, sofern mehrere Knoten gefunden werden, die den XPATH-Kriterien entsprechen). Die in den folgenden Abschnitten erläuterten Klassen sind weitestgehend eine Fassade für den DOM-Baum. Viele Getter- und Setter-Methoden greifen direkt auf den Baum zu um Daten zu lesen bzw. zu hinterlegen. Die Referenz auf einen Knoten liegt bei diesen Klassen in Form eines Objektes der dom4j -Klasse Element vor und wird als Konstruktorparameter übergeben. Da Element nicht Thread-sicher ist, muss an diesen Stellen auf eine notwendige Synchronisation geachtet werden. Abbildung Aufbau der Konfigurationsdatei Abbildung 5.14 gibt einen Überblick über den Aufbau der XML-Konfigurationsdatei. Die einzelnen Elemente werden in den folgenden Abschnitten näher erläutert. Ein gekürzter Auszug einer XML-Konfigurationsdatei, die diesem Aufbau genügt, ist im folgenden Listing 5.2 zu sehen.

53 5.3 Server 47 1 <?xml v e r s i o n = 1.0 encoding= UTF 8?> 2 3 <c o n f i g > 4 <s e r v e r /> 5 <p l u g i n s > 6 <p l u g i n i d= MouseController name= MouseController 7 mainclass= mouse. MouseController 8 c o n f i g C l a s s = mouse. MouseControllerConfigPanel /> </p l u g i n s > 11 <d e v i c e s > 12 <d e v i c e btaddr = AB name= Mein Handy > 13 <a l i a s e s > 14 <a l i a s name= UP remotekey= 1 /> 15 <a l i a s name= 1 remotekey= 49 /> 16 <a l i a s name= 2 remotekey= 50 /> </ a l i a s e s > 19 <s w i t c h e r a l i a s = CAM > 20 <map name= NEXTPAGE a l i a s = RIGHT /> 21 <map name= PREVPAGE a l i a s = LEFT /> 22 <map name= SELECT1 a l i a s = 1 /> <map name= DISCONNECT a l i a s = 0 /> 25 </s w i t c h e r > 26 <p r o f i l e s > 27 < p r o f i l e name= P r o f i l 1 d e f a u l t = t r u e > 28 <useplugin i d= MouseController > </useplugin > </ p r o f i l e > </ p r o f i l e s > 35 </device > </d e v i c e s > 38 </c o n f i g > Listing 5.2. Auszug einer XML-Konfigurationsdatei Geräte Zu Anfang wurde ein sinnvolles Konzept für die Konfiguration des Servers gesucht. Zunächst sollte ein einfaches Mapping zwischen Tastencode des mobilen Gerätes und einer Tastenkombination bzw. Mausinteraktion realisiert werden. Auf Grund der fehlenden Flexibilität wurde dieser Ansatz schnell wieder verworfen. Wie bereits angesprochen ist nicht sicherzustellen, dass bei der Benutzung mehrerer Geräte die gleichen Tastencodes verwendet werden. Außerdem kann es sein, dass eine Tastenbelegung (z.b. zur Steuerung eines Audiosielers mit Start / Stop / Vor / Zurück...) auf einem Gerät sinnvoll, auf einem anderen mit unterschiedlichem Tastenlayout aber nur umständlich zu bedienen ist. Als Beispiel könnten die Tasten für die Aktionen Vorspulen und Zurückspulen dort ihre Plätze tauschen und würden dadurch die (logische) Bedienung erschweren, da ein Umdenken erforderlich wäre. Um dieser Problematik entgegenzuwirken musste eine unabhängige Konfiguration pro Gerät möglich gemacht werden. Abbildung 5.15 zeigt die Aufteilung

54 5.3 Server 48 Abbildung Geräte, Profile und Aliase der Konfiguration pro Gerät. Unterscheidungskriterium ist dabei die Bluetooth- Hardwareadresse, da diese für jedes Gerät unterschiedlich und damit eindeutig ist. Abbildung Klassen der Gerätekonfiguration Geräte werden durch die Klasse RemoteControlDevice repräsentiert und durch die Klasse RemoteDeviceManager verwaltet (siehe Abbildung 5.16). Diese Manager-Klasse richtet sich nach dem Entwurfsmuster Singleton, da es nur einen Manager für Geräte pro Server geben kann. Über ihn erhält man Zugriff auf die vorhandenen Geräte, kann diese entfernen oder neue hinzufügen (Abbildung 5.17). Jedes Gerät besitzt Aliase und Profile. Diese können über entsprechende Factory-Methoden der Klasse RemoteControlDevice (siehe Abbildung 5.18) hinzugefügt oder entfernt werden. Die Klasse spielt aber noch aus einem anderen Grund eine wichtige Rolle im Server: Durch die Methode is ( int keycode, String id) wird abgefragt, ob ein Mapping des Keycodes keycode auf den Namen id existiert. Damit ist sie der zentrale Punkt zur Bestimmung, welche Taste des mobilen Gerätes gedrückt oder

55 5.3 Server 49 Method Summary RemoteControlDevice createdevice(string btaddr, String name) Erstellt ein neues Gerät und fügt es der Liste der vorhandenen Geräte hinzu RemoteControlDevice getdevice(string btaddr) Liefert das Gerät mit der angegebenen Bluetooth-Adresse zurück RemoteControlDevice[] getdevicelist() Liefert eine Liste der vorhandenen Geräte zurück Static RemoteDeviceManager getremotedevicemanager() Liefert die Referenz auf das RemoteDeviceManager-Objekt zurück void removedevice(remotecontroldevice device) Entfernt ein Gerät Abbildung Methoden der Klasse RemoteDeviceManager losgelassen wurde (siehe Abschnitt 5.3.3). Method Summary Alias createalias(int keycode, String name) Erzeugt ein neues Alias-Objekt und fügt es zu der internen Alias-Liste sowie der Konfiguration hinzu. Profile createprofile(string name) Erstellt ein neues Profil für das mobile Gerät Profile createprofile(string name, boolean isdefault) Erstellt ein neues Profil für das mobile Gerät String getbluetoothaddress() Liefert die Bluetooth-Adresse des mobilen Gerätes zurück String getname() Liefert den Namen des mobilen Gerätes zurück. boolean is(int keycode, String id) Prüft, ob ein Tasten-Code des mobilen Gerätes mit einem bestimmten Alias assoziiert ist. Abbildung Methoden der Klasse RemoteControlDevice (Auszug) Geräte werden in der Konfigurationsdatei direkt unterhalb der Wurzel unter dem Tag <devices> zusammengefasst (siehe Listing 5.2). Jedes Gerät besitzt ein eigenes <device>-element, welches die Attribute btaddr (Bluetoothgeräteadresse) und name (interner Name des Gerätes) hat Aliase Aliase stellen ein Mapping eines Tastencodes des betreffenden mobilen Gerätes auf einen Namen dar. Der Name kann vom Benutzer frei gewählt werden und soll es ihm erleichtern, Tasten einer Aktion zuzuordnen. Jedes Gerät kann mehrere Aliase für eine Taste besitzen. Die Abbildung Name auf Tastencode muss dabei surjektiv sein, da anstatt der Angabe des Tastencodes in der Konfiguration stets auf

56 5.3 Server 50 den Namen zurückgegriffen wird. D.h. der Name, der einem Tastencode zugeordnet ist, muss eindeutig sein, wenn die entsprechendende Taste verwendet werden soll. Umgekehrt aber kann ein Tastencode mehrere verschiedene (eindeutige) Namen besitzen. Auf diese Art und Weise kann z.b. eine Funktionstaste des mobilen Gerätes Play genannt und einer Tastenkombination der Aktion Abspielen starten eines Audiospielers zugeordnet werden. Aliase werden durch die Klasse Alias repräsentiert. Sie können mit Hilfe der Factory-Methode createalias( int keycode, String name) der Klasse RemoteControlDevice erstellt werden (Abbildung 5.18). Die oben bereits angesprochene Methode is () macht von der Methode compare(int keycode, String name) der Alias-Klasse Gebrauch. Hier findet die eigentliche Überprüfung auf Übereinstimmung statt. Die Idee dahinter ist die folgende: Wird eine Taste auf dem mobilen Gerät gedrückt oder losgelassen, empfängt der Server den entsprechenden Tastencode. Der Server besitzt außerdem die Information darüber, welcher Tastencode welche Namen besitzt (Aliase). Plugins, welche noch näher im Kapitel behandelt werden, ordnen diese Aliasnamen Aktionen zu (in der Konfigurationsdatei). Sie sind zusätzlich als RemoteControlKeyListener an das Verbindungsobjekt angemeldet (siehe Abbildung 5.7) und erhalten somit den Tastencode der gedrückten oder losgelassenen Taste. Um zu entscheiden, ob eine Aktion ausgeführt werden soll, wird der empfangene Tastencode mit dem der Aktion zugeteilten Aliasnamen über oben genannte Methode verglichen (siehe Sequenzdiagram 5.19). Stimmen diese überein und liefert diese true zurück, darf die Aktion ausgeführt werden. Bei der Überprüfung kann es durchaus vorkommen, dass mehrere Aliase betrachtet werden müssen bis eine Übereinstimmung gefunden werden kann. Abbildung Überprüfen eines Alias Aliase findet man in der Konfigurationsdatei unterhalb von Geräten im Element <aliases> zusammengefasst (siehe Listing 5.2). Für jeden Alias existiert ein <alias>- Tag mit den Attributen name für den Namen des Alias und remotekey für den Keycode der Taste des eingebetteten Gerätes.

57 5.3 Server Profile Um den Server auf die Steuerung einer bestimmten Anwendung oder eines bestimmten Anwendungsgebietes anpassen zu können wurden Profile entwickelt. Profile sind gerätespezifische Konfigurationen zu einem bestimmten Zweck. Ein Profil besitzt Informationen über die zu verwendenden Plugins und deren Einstellungen. Pro Gerät können mehrere Profile existieren, die durch einen eindeutigen Namen identifiziert werden. Eines der Profile ist dabei das Standardprofil. Das Standardprofil ist das erste aktive Profil, nachdem eine Verbindung des mobilen Gerätes mit dem Server hergestellt wird. Falls keins festgelegt wurde oder es entfernt wird, tritt das erste verfügbare Profil als temporäres Standardprofil an dessen Stelle. Wie für die Aliase besitzt die Klasse RemoteControlDevice Factory-Methoden (Abbildung 5.18), die ein Objekt der Klasse Profile zurückliefern. Über die Methode useplugin(string pluginid) kann ein Plugin hinzugefügt werden, das bei Aktivierung des Profils geladen wird (für Informationen zu Plugins siehe Abschnitt 5.3.7). Die Methode liefert ein Element-Objekt zurück, das auf den neu erstellten Knoten im DOM-Baum zeigt, unterhalb welchem das Plugin seine profilspezifische Konfiguration ablegen soll. Diese Knoten sind alle unter dem Konfigurationsknoten des Profils zusammengefasst, sodass das Entfernen des Profils (und dessen Wurzelknoten) zur Löschung aller verknüpften Plugineinstellungen führt. Da Profile auch gerätegebunden sind, werden diese in der Konfigurationsdatei ebenfalls pro Gerät unter dem Element <profiles> abgelegt (siehe Listing 5.2). Für jedes Profil existiert dort ein <profile>-tag mit den Attributen name für den Namen des Profils und default für die Angabe, ob es sich um das Standardprofil handelt. Einzig erlaubter Wert für default ist true. Ist ein anderer Wert angegeben oder das Attribut nicht vorhanden, so wird dies als false interpretiert Programmstart und Verbindungsannahme Die Klasse Server (Abbildung 5.20) ist die Einstiegsklasse der Serveranwendung und führt alle nötigen Vorgänge durch, um den Server betriebsbereit zu machen. Ferner kümmert sich diese Klasse um die Annahme von Verbindungen und das Laden und Speichern der Serverkonfiguration. Die Klasse Server ist ein Singleton. Zunächst wird die grafische Oberfläche des Servers erstellt und angezeigt (Klasse ServerUI). Sie dient zur Ausgabe von Informationen über Vorgänge und Serverstatus, ermöglicht den Zugriff auf die Konfigurationsoberfläche des Server und kann verwendet werden um Verbindungen mit den Client-Geräten zu trennen. Außerdem ist es möglich den Server über sie zu beenden. Der zweite Vorgang nach dem Start der Anwendung ist das Einlesen der Konfigurationsdatei. Dabei bedient sich der Server der Klassen SAXReader sowie Document des Packages dom4j. Der SAX-Parser verarbeitet die XML-Daten der Konfigurationsdatei, welche zum Erstellen des DOM-Baums verwendet werden. Wurzel des Baumes ist das Objekt der Klasse Document, das vom SAXReader geliefert und als

58 5.3 Server 52 Abbildung Übersicht Server Attribut im Server-Objekt abgelegt wird. Auf dessen Grundlage erhalten alle nötigen Objekte Zugriff auf ihre Konfigurationsknoten (Geräte, Aliase, Profile, Plugins...). Sollte keine Konfigurationsdatei existieren, wird der Server eine leere Konfiguration erstellen um allen seinen Bestandteilen einen Knoten zum Ablegen ihrer Konfiguration anbieten zu können. Nachdem die Konfiguration geladen wurde, können die Manager-Objekte, Gerätemanager (RemoteDeviceManager) und Plugin-Manager (PluginManager), erstellt werden. Diese besorgen sich den Knoten, unterhalb welchem sich ihre Konfigurationen befinden, und verarbeiten diese selbstständig weiter. So werden iterativ für alle konfigurierten Geräte entsprechende RemoteControlDevice-Objekte erzeugt, welche wiederum alle nötigen Alias- und Profile-Objekte erstellen. Auch die vorhandenen Plugins werden in Form von PluginInfo-Objekten durch den PluginManager zugänglich gemacht (Näheres dazu siehe Abschnitt 5.3.7). Einen weiteren Schritt stellt die Initialisierung eines Robot-Objektes dar. Wie bereits in Kapitel 4 beschrieben, können durch diese Klasse Benutzereingaben simuliert werden. Im Konzept des Servers ist vorgesehen, dass nur ein einziges Robot-Objekt verwendet werden soll. Dies hat den Grund, dass, falls nötig, ein abgeleitetes Objekt an dessen Stelle treten kann, um beispielsweise eine Liste über alle gedrückten

59 5.3 Server 53 Tasten zu führen und beim Beenden des Servers sicherzustellen, dass diese wieder losgelassen werden. Momentan jedoch besteht dazu keine erkennbare Notwendigkeit, da in den Plugins diese Sicherung realisiert ist. Außerdem kann auf diese Weise geprüft werden, ob das Betriebssystem überhaupt die Vorraussetzungen anbietet Eingaben zu simulieren. Ist dies nicht der Fall, so kann kein Objekt erstellt werden und es wird eine AWTException geworfen. Der Server reagiert darauf mit einer entsprechenden Fehlermeldung. Weitere Vorbereitungsvorgänge werden darauf nicht mehr durchgeführt und der Server ist nicht lauffähig. Tritt kein Problem auf, kann Zugriff auf das Robot-Objekt durch die Methode getrobot() der Klasse Server erlangt werden. Letzter Schritt stellt die Initialisierung des Bluetooth-Gerätes dar. Ist kein Gerät verfügbar oder kann aus irgendeinem Grund nicht verwendet werden, wird dies durch eine IOException signalisiert. Der Server fängt die möglichen Exceptions ab und wird in der grafischen Oberfläche eine Meldung ausgeben, die nähere Informationen über den Fehler enthält. Mit Hilfe des Generic Connection Frameworks wird bei der Bluetooth-Implementierung der Service angemeldet. Die UUID des Services lautet: 47C4FF3E F9B34FB Ab diesem Moment können mobile Geräte eine Verbindung zum Server herstellen und der Server ist damit betriebsbereit. Die Verbindungsannahme ist in einen eigenen Thread ausgelagert. Neben dem Einlesen der Konfigurationsdatei ist die Klasse Server auch für das Serialisieren des DOM-Baumes in die XML-Datei zuständig. Durch einen Aufruf der Methode saveconfig() kann diese Serialisierung jederzeit angestoßen werden. Der eigentliche Vorgang wird von der Klasse XMLWriter ausgeführt. Um den Server zu beenden kann die Methode shutdown() verwendet werden. Bevor sich der Server richtig beendet, wird versucht alle aktiven Verbindungen zu trennen, was unter Umständen einige Sekunden dauern kann Sessions Um mehrere Verbindungen gleichzeitig behandeln zu können, wird für jede Verbindungsanfrage eine eigene Session angelegt. Eine Session fasst alle nötigen Komponenten zusammen, die für die Kommunikation zwischen Server und mobilem Gerät notwendig sind (siehe Abbildung 5.21). Sie verwaltet daneben die aktiven Plugins und ermöglicht das Umschalten von Profilen. Die Klasse Server erstellt für jede Anfrage ein neues Session-Objekt und übergibt diesem die Verbindung in Form eines Objektes der Klasse StreamConnection. Auf dieses Verbindungsobjekt wird vom Session-Objekt das in Abschnitt 5.1 beschriebene Übertragungsprotokoll aufgesetzt, was durch die Erstellung eines Objektes von RemoteControlConnection geschieht. Von da an wird nur noch dieses Objekt zur Übertragung der Daten verwendet und Plugins erhalten durch Aufruf der Metho-

60 5.3 Server 54 Abbildung Das Package de.dm.remotecontrol.server.session und Abhängigkeiten de getconntection() eine Referenz darauf. Sessions werden im Server-Objekt registriert, um später die Verbindungen trennen zu können. Neben der Verbindung zum mobilen Gerät besitzt eine Session auch eine Referenz auf das Konfigurationsobjekt des Gerätes (RemoteControlDevice). Um das Gerät zu identifizieren wird die Hardwareadresse des Bluetoothgerätes verwendet. Diese kann über die Methode getbluetoothaddress() der Klasse RemoteControlConnection als String besorgt werden. Das Gerätemanagerobjekt ist über die statische Methode getdevicemanagerinstance() zugänglich und besitzt die Methode getdevice(string btaddr), welche das zugehörige RemoteControlDevice-Objekt liefert. Mit der Referenz auf dieses Objekt kann eine Session auf die Profile eines Gerätes zugreifen. Da eine Session immer über ein aktives Profil verfügen muss, wird zunächst das Standardprofil aktiviert. Ist keins festgelegt, wird das erste verfügbare Profil verwendet. Sollte kein Profil vorhanden sein, wird die Verbindung wieder getrennt, da nichts ausgeführt werden kann. Bei Aktivierung eines Profils werden alle mit ihm assoziierten Plugins geladen, konfiguriert und gestartet. Um zwischen den Profilen zu wechseln besitzt jede Session eine Profilauswahl (Klasse ProfileSwitcher). Ein Objekt der Klasse wird pro Session erstellt und als Listener für Benutzereingaben an das RemoteControlDevice angemeldet. Über eine an das Gerät (RemoteControlDevice) gebundene Taste des mobilen Gerätes kann diese Auswahl aufgerufen werden. Wird die Taste betätigt, wird dies dem ProfileSwitcher-Objekt mitgeteilt, welches darauf alle laufenden Plugins der Session anhält (siehe Abschnitt und Abbildung 5.25) und die Auswahl an das mobile Gerät sendet. Der Benutzer kann nun aus einer Liste auf dem Anzeigegerät des mobilen Gerätes ein anderes Profil auswählen oder den Vorgang abbrechen. Bei einem Abbruch wer-

61 5.3 Server 55 den die angehaltenen Plugins wieder gestartet. Wird ein anderes Profil ausgewählt, führt dies zum Beenden der Plugins und zum Laden und Konfigurieren der Plugins des neuen Profils (siehe Sequenzdiagramm 5.23). Eine weitere Option im Auswahlmenü ist das Trennen der Verbindung. Für alle diese Vorgänge besitzt die Klasse Session Methoden, die aus Abbildung 5.22 entnommen werden können. Method Summary void close() Trennt die Verbindung zum mobilen Gerät und beendet die Session void destroyplugins() Zerstört alle mit dem aktiven Profil verbundenen Plugins RemoteControlConnection getconnection() Liefert die Verbindung zum mobilen Gerät zurück RemoteControlDevice getdevice() Liefert das Gerät zurück zu dem eine Verbindung besteht void pauseplugins() Pausiert alle mit dem aktiven Profil verbundenen Plugins void startplugins() Startet alle mit dem aktiven Profil verbundenen Plugins boolean switchtoprofile(profile profile) Wechselt zu dem angegebenen Profil, lädt alle nötigen Plugins und startet diese Abbildung Methoden der Klasse Session (Auszug) Die Konfiguration für die Profilauswahl befindet sich in der Konfigurationsdatei (siehe Listing 5.2) unterhalb der Geräteelemente. Das Element <switcher> hat als einziges Attribut alias, welches den Aliasnamen der Taste aufnimmt, durch deren Drücken die Auswahl angezeigt werden soll. Es besitzt mehrere Kindelemente die angeben, welche Taste für welche Aktion verwendet werden soll. Diese <map>-tags haben 2 Attribute: name nimmt einen festgelegten String für die Aktion auf und alias gibt den Namen des Tastenaliases an. Werte für name können sein: NEXTPAGE - Eine Seite vorblättern PREVPAGE - Eine Seite zurückblättern SELECT1 bis SELECT9 - Auswahl des 1. bis 9. Eintrags der Seite DISCONNECT - Trennen der Verbindung

62 5.3 Server 56 Abbildung Umschalten von Profilen und Laden von Plugins

63 5.3 Server Plugins Um Funktionalität anzubieten, bedient sich der Server Plugins. Plugins sind Programmfragmente, die speziell für die Benutzung in Verbindung mit dem Server entworfen wurden und selbstständig nicht lauffähig sind. Um den Server möglichst flexibel und für die Zukunft erweiterbar zu halten erschien die Idee, die eigentliche Serverfunktionalität in Plugins auszulagern, am sinnvollsten. In Verbindung mit den bereits erläuterten Profilen ergibt sich außerdem die Möglichkeit Plugins nur dann zu laden, wenn diese benötigt werden. Ein Plugin besteht aus mindestens 2 Klassen: Einer Hauptklasse, die Aktionen ausführt, und einer Klasse zur Integration in die Konfigurationsoberfläche des Servers (siehe dazu Abschnitt ). Hauptklasse Method Summary void destroyplugin() Zerstört das Plugin und gibt die angeforderten Ressourcen frei String getpluginname() Liefert den Namen des Plugins zurück void pauseplugin() Hält das Plugin an void startplugin() Startet die Ausführung des Plugins Abbildung Methoden des Interfaces Plugin Obwohl es keine Vorschriften gibt, wie ein Plugin implementiert sein muss (z.b. eigenständiger Thread), müssen Plugins eine bestimmte Signatur aufweisen. Dazu zählt die Implementierung des Interfaces Plugin. Dieses schreibt mehrere Methoden zur Steuerung des Plugins vor (Abbildung 5.24). Ähnlich Midlets oder Applets muss ein Plugin gestartet, angehalten, fortgesetzt und zerstört werden können. Des Weiteren müssen Plugins einen bestimmten Konstruktor vorweisen: Plugin(Session session, Element confignode). Der erste Parameter identifiziert die Clientverbindung (siehe dazu Abschnitt 5.3.6). Der Zweite ist eine Referenz auf den Knoten im DOM-Baum, welcher die Wurzel der Konfiguration des Plugins darstellt. Wie ein Plugin die Konfiguration ablegt und wieder einliest, ist dem Autor des Plugins überlassen. Um dies zu erreichen sollte vorzugsweise auf die API von dom4j zurückgegriffen werden. Im Konstruktor des Plugins sollten alle nötigen Ressourcen angefordert und Initialisierungen durchgeführt werden. Nachdem ein Plugin-Objekt erstellt wurde, befindet es sich im Zustand pausiert (Abbildung 5.25). Aus diesem Zustand kann es durch einen Aufruf der Methode startplugin() in den Zustand laufend wechseln. In dieser Methode sollten alle Maßnahmen ergriffen werden, damit das Plugin seine Aufgabe ausführt. Dazu kann beispielsweise das Starten eines Threads und das Anmelden als Listener an

64 5.3 Server 58 Abbildung Lebenszyklus eines Plugins alle nötigen Objekte gehören. Entgegen der von Applets und Midlets bekannten Möglichkeiten ist in der aktuellen Implementierung des Servers nicht vorgesehen, dass ein Plugin aus dem Zustand laufend nach zerstört wechseln kann. Lediglich auf dem Umweg über pausiert ist dies möglich. Eine Ausführung der Methode pauseplugin() soll bewirken, dass ein Plugin sich schlafen legt. Dies bedeutet, dass es nicht mehr auf Ereignisse reagiert und auch keine Aktionen mehr ausführt. Beispielsweise kann dies durch die Abmeldung der Listener und Pausieren des Thread erreicht werden. Ein erneuter Aufruf von startplugin() bewirkt, dass das Addon wieder seinen Dienst aufnimmt und nahtlos an seine letzte Aktivität anknüpft. Es muss daher in dieser Methode unterschieden werden, ob es sich um einen erstmaligen oder wiederkehrenden Aufruf handelt. In der Methode destroyplugin() müssen alle angeforderten Ressourcen freigegeben und Abhängigkeiten gelöst werden. Hat das Plugin einmal in den Zustand zerstört gewechselt, kann es nicht mehr gestartet werden und muss durch den Garbage Collector entfernt werden können. Konfigurationsklasse Neben der Hauptklasse existiert eine Konfigurationsklasse für jedes Plugin. Sie stellt eine Oberfläche zur Konfiguration des Plugins bereit, welche in die Konfigurationsoberfläche des Servers integriert wird und vom Benutzer verwendet werden kann. Da es keine generische Eingabemaske für alle Plugins auf Grund der Vielfalt geben kann, ist diese Einrichtung notwendig. Die Konfigurationsklasse muss die abstrakte Klasse PluginConfigPanel erweitern. Dabei handelt es sich um eine von JPanel abgeleitete Klasse, die jedoch keine weiteren Methoden oder Attribute besitzt. Sollte dies in Zukunft nötig sein, kann die Klasse erweitert werden. Zur Zeit trägt sie lediglich zur besseren Benennung bei. Auch Konfigurationsklassen müssen über einen sepziellen Konstruktor verfügen: PluginConfigPanel(RemoteControlDevice device, Profile profile, Element confignode) Über ihn erfolgt die Angabe aller für die Konfiguration des Plugins notwendigen Daten. Um Zugriff auf die vorhandenen Aliase eines Gerätes zu bekommen

65 5.3 Server 59 wird das entsprechende RemoteControlDevice-Objekt als erster Parameter übergeben. Als weiteren Parameter erhält das Objekt eine Referenz auf das Profil, in dessen Rahmen das Plugin verwendet werden soll. Letzter Parameter ist die Referenz auf den Knoten im DOM-Baum, welcher die Wurzel der Pluginkonfiguration darstellt. Weitere Informationen über die Konfiguration des Servers befinden sich im Abschnitt Plugins legen ihre Einstellungen in der Konfigurationsdatei unter den Profilen in den Elementen <useplugin> ab (siehe 5.2). Das Element besitzt nur ein Attribut id, das die ID des Plugins enthält, zu dem die Konfiguration gehört. Erstellung und Konfiguration von Plugininstanzen Abbildung Das Package de.dm.remotecontrol.server.plugins Um die Verwaltung installierter Plugins kümmert sich die Klasse PluginManager. Wie die anderen Manager-Klassen handelt es sich bei dieser ebenfalls um ein Singleton. Um dynamisch zur Laufzeit weitere Klassen zu laden wird der System- Classloader verwendet. Des Weiteren bedient sich der Plugin Manager der Reflection API von Java, um Klassen auf gültige Signatur zu prüfen und Objekte von ihnen zu erstellen. Ein Plugin besitzt neben den absoluten Pfaden zur Haupt- und Konfigurationsklasse eine interne ID, über welche das Plugin in der Konfigurationsdatei referenziert werden kann. Außerdem wird ein (verständlicher) Name für die Anzeige in der Konfigurationsoberfläche benötigt. Diese Informationen werden in Objekten

66 5.3 Server 60 der Klasse PluginInfo hinterlegt, auf welche der Plugin-Manager Referenzen besitzt (siehe Abbildung 5.26). Method Summary PluginInfo createplugin(string pluginid, String pluginname, String mainclassname, String configclassname) Fügt ein neues Plugin hinzu Plugin loadandconfigure(string pluginid, Session session, Profile profile) Instanziiert das angegebene Plugin (Hauptklasse) und konfiguriert das neue Objekt PluginConfigPanel loadandconfigurepluginconfigpanel(string pluginid, RemoteControlDevice device, Profile profile) Instanziiert die Konfigurationsklasse des angegebenen Plugins und konfiguriert das neue Objekt boolean removeplugin(plugininfo info) Entfernt ein Plugin Abbildung Methoden der Klasse PluginManager (Auszug) Unter Angabe der oben genannten Informationen kann mit Hilfe der Methode createplugin (...) (siehe 5.27) ein neues Plugin eingetragen werden. Dabei wird geprüft, ob die ID und der Name gültig sind. Ferner muss sichergestellt werden, dass die angegebenen Klassen den Anforderungen für ein Plugin entsprechen und die nötige Signatur vorweisen. Weitere Probleme können fehlende Abhängigkeiten (weitere Klassen) oder nicht vorhandene Zugriffsrechte darstellen. Tritt ein Problem auf, so wird eine PluginLoadException mit einer entsprechenden Fehlermeldung geworfen. Neue Instanzen eines Plugins oder dessen Konfigurationsklasse werden mittels der Methoden loadandconfigure(..) bzw. loadandconfigurepluginconfigpanel(..) erstellt. Dabei wird das Plugin durch die zuvor festgelegte Plugin-ID identifiziert. Das Objekt der Hauptklasse eines Plugins muss mit Informationen über die Verbindung (Session), zu der es gehört, und das Profil, durch welches es aufgerufen wurde, versorgt werden. Nur so kann es sich als Listener für Benutzereingaben des mobilen Gerätes anmelden und auf das bereitgestellte Robot-Objekt des Servers zugreifen. Im Falle des Objektes der Konfigurationsklasse werden Referenzen auf das Gerät und das Profil benötigt. Über das Gerät erhält die Konfigurationsklasse Zugriff auf die konfigurierten Aliase des mobilen Gerätes und kann diese somit ihren Aktionen zuordnen Das Plugin ImageCapturer Die Klasse ImageCapturer ist für das Abgreifen des Computerbildschirms und das Senden des Ausschnittes an das mobile Gerät zuständig. Die Übertragung des gesamten Bildschirmes würde zum einen zu einem zu großen Datenvolumen führen und zum anderen besitzen die meisten Displays der mobilen Geräte eine viel zu geringe Auflösung zur Darstellung. Deswegen wird nur der Bereich um den Mauszeiger herum betrachtet. Die Größe dieses Bereiches kann variieren und hängt von

67 5.3 Server 61 den verfügbaren Ausmaßen des Anzeigegerätes des mobilen Gerätes ab. Diese Vorgehensweise ist für die meisten Situationen ausreichend, da nur genau sichtbar sein muss, an welche Stelle geklickt wird. Das Plugin ermittelt die Größe der Anzeige des mobilen Gerätes durch die Klasse RemoteControlConnection. Während des Verbindungsaufbaus werden vom Client die Dimensionen an den Server gesendet und können über die Methoden getscreenwidth() und getscreenheight() abgefragt werden. Anhand dieser Informationen und der Position des Mauszeigers, welcher über die Klasse MouseInfo bestimmt werden kann, lässt sich ein Ausschnitt mit dem Mauszeiger als Mittelpunkt errechnen. Dieser wird mit Hilfe der Methode createscreencapture(rectangle screenrect) des Java-Robots abgegriffen, komprimiert und an den Client gesendet. Problematisch wird die Berechnung an den Rändern des Bildschirms, da außerhalb des Computerbildschirmes nichts vorhanden ist und dort auch nichts abgegriffen werden kann. Um in diesen Spezialfällen ein brauchbares Ergebnis zu erhalten, wurde der Algorithmus zur Berechnung des Ausschnittes so modifiziert, dass der Mauszeiger nicht mehr als Mittelpunkt dargestellt wird, sondern dem betreffenden Rand entgegenwandert (siehe 5.28). Abbildung Berechnung des abzugreifenden Ausschnittes Um Zeit bei der Übertragung zu sparen, werden die Bilddaten in das JPEG- Format überführt. Zur Auswahl standen die Formate PNG, JPEG und GIF, die alle von den Java-Editionen unterstützt werden. PNG hat dabei die beste Qualität zu bieten, da es verlustfrei komprimiert. Der Nachteil daran ist jedoch, dass das Format zu große Dateien liefert. Im Gegensatz zu JPEG verbraucht das gleiche Bild ca. 5 bis 10 Mal mehr Speicher. Die Entscheidung fiel auch gegen GIF aus, da die Nutzung von Lizenzen in diesem Format umstritten ist und die Unterstützung in einer neueren Javaversion entfernt werden könnte. Des Weiteren bietet das Format lediglich 256 Farben an, was im Vergleich zu 24-Bit-Farbtiefen eines Computers doch recht lächerlich erscheint. Für diesen Anwendungsfall blieb also nur das JPEG-Format übrig, welches sich aber sehr gut eignet. Der Server stellt eine Hilfsklasse ImageEncoder zur Verfügung, welche die statischen Metho-

68 5.3 Server 62 den tojpegimage(bufferedimage img, Float qual) und topngimage(bufferedimage img) besitzt. Beide bedienen sich der von Java gelieferten Bildwandlern um das BufferedImage in das betreffende Format zu überführen. Rückgabe ist in beiden Fällen ein Byte- Array, das direkt an die Methode sendimage(byte[] imagedata) des Verbindungsobjektes (RemoteControlConnection) für den Versand übergeben werden kann. Im Laufe einiger Testreihen wurde festgestellt, dass durch ständiges Abgreifen des Bildschirms und die Übertragung zum mobilen Gerät die Latenzzeit erheblich anstieg, sodass eine Mausbewegung erst einige Sekunden später auf dem Display des Handys sichtbar wurde. Durch das ständige Abgreifen des Bildschirms entsteht ein Datenstau, wenn die Puffer der Streams voll laufen. Da die Bandbreite zum Clientgerät (Testgerät) nur ca. 40 bis 50 KB/s beträgt und ein Bild ca. 6 KB groß ist, wurde eine Limitierung der Schnappschüsse pro Sekunde auf ca. 6 Bilder pro Sekunde als sinnvoll erachtet. Dadurch werden unnötige Bilder, die keine Änderungen zu ihrem Vorgängerbild besitzen, vermieden. Diese Limitierung wurde durch ein Pausieren des Thread, in dem der ImageCapturere seine Tätigkeit verrichtet, realisiert. Tatsächlich konnte durch diese Maßnahme die Reaktionsgeschwindigkeit, mit einigen Einbußen bei der flüssigen Darstellung, erheblich verbessert werden. Aus diesem Ansatz heraus wurde eine weitere Maßnahme entwickelt: Durch einen Vergleich auf Pixelbasis des aktuellen Bildes mit dem Vorgängerbild kann herausgefunden werden, ob diese sich unterscheiden. Ist dies nicht der Fall, so wird überhaupt kein Bild mehr übertragen, bis sich wieder etwas ändert. Neben der nochmals verringerten Latenz wird durch dieses Verhalten der Energiebedarf der Bluetoothgeräte herabgesetzt, da nur, wenn nötig, eine Funkübertragung stattfindet. Zur weiteren Steigerung der Reaktionszeit wurde zusätzlich eine dynamische Anpassung der JPEG-Qualität implementiert. Werden viele Bilder übertragen und steigt die Latenz an, so wird die Grafikqualität stufenweise herabgesetzt. Dadurch sinkt auch das nötige Datenvolumen auf ca. 4 KB pro Bild. Werden weniger Bilder übertragen und sinkt die Latenz, dann verbessert sich die Qualität wieder. Zur Bestimmung der Latzenzzeit wird die Methode ping(string id) der Klasse RemoteControlConnection verwendet. 1 <useplugin i d= ImageCapturer > 2 <switch a l i a s = # /> 3 <q u a l i t y min= 0.1 max= 0.6 /> 4 <l i m i t f p s = 5 /> 5 </useplugin > Listing 5.3. XML-Konfiguration ImageCapturer Das Plugin bietet die Möglichkeit, den Bereich, in dem es dynamisch die Qualitätsanpassung durchführen soll und die Anzahl an Bildern pro Sekunde festzulegen. In den Profilen im Tag <useplugin> werden die Daten abgelegt (Listing 5.3). <switch> besitzt das Attribut alias, welches auf die Taste des mobilen Gerätes verweist, um die Bildübertragung an- bzw. auszuschalten, wenn das Plugin aktiv ist. Das Element <quality> legt im Attribut min die Mindestqualität und in max die

69 5.3 Server 63 Höchstqualität fest, die für die dynamische Anpassung verwendet werden dürfen. Zulässige Werte sind dabei Werte im Intervall von 0.0 bis 1.0 (in Schritten von 0.1). Im letzten Element limit kann im Attribut fps die Bildrate festgelegt werden. Alle diese Einstellungen sind auch über die Konfigurationsoberfläche des Servers zugänglich (siehe Abschnitt ). Die oben aufgeführten Angaben entsprechenden denen des Testsystem und können sich erheblich von denen anderer Geräte unterscheiden. Wichtigster Faktor ist dabei die Größe des Anzeigegerätes, mit dessen Größe auch die Bildgrößen steigen Das Plugin MouseController Ein weiteres Plugin des Servers ist der MouseController, der für die Steuerung der Maus verantwortlich ist. Er bietet die Möglichkeit die Maus hinauf, hinunter, links und rechts sowie diagonal zu bewegen. Zusätzlich können Klicks (Rechts- und Linksklick) ausgeführt werden. Die Steuerung der Maus geschieht in einem eigenen Thread, da der Java-Robot es nur erlaubt den Mauszeiger an eine bestimmte Koordinate zu setzen. Weil für eine Bewegung keine Koordinaten angegeben werden, sondern nur eine Richtung bestimmt wird (durch Drücken der entsprechendenen Taste des mobilen Gerätes), muss der Zeiger so lange wie gewünscht bewegt werden. Nachdem die Taste für eine bestimmte Richtung betätigt wurde, wird der Zeiger sofort um einen Schritt in die entsprechende Richtung bewegt. Um eine genaue Steuerung zu ermöglichen, wird darauf eine halbe Sekunde gewartet. Ist die Taste danach immer noch gedrückt, startet eine Bewegung um mehrere Schritte pro Sekunde in einer Schleife, bis die Taste losgelassen wird. Wie bereits bekannt werden die Einstellungen des Plugins in das entsprechende <useplugin>-element des Profils abgelegt. Der MouseController verwendet zur Assoziation von Aktionen mit Aliasen mehrere <map>-tags. Jedes besitzt ein Attribut name für den Namen der Aktion und ein Attribut alias für den Namen des damit verbundenen Aliases. Mögliche Aktionen sind: MOUSE UP - Maus nach oben bewegen MOUSE DOWN - Maus nach unten bewegen MOUSE LEFT - Maus nach links bewegen MOUSE RIGHT - Maus nach rechts bewegen MOUSE LBUTTON - Linke Maustaste MOUSE RBUTTON - Rechte Maustaste Das Plugin KeyController Das dritte mitgelieferte Plugin ist für die Simulation von Tastatureingaben vorgesehen. Die Klasse KeyController besitzt Referenzen auf Objekte der Klasse KeyCombination.

70 5.3 Server 64 KeyCombination-Objekte stellen Tastenkombinationen dar, die bei Bedarf eingegeben werden können. Jede Taste besitzt einen Tastencode. Über die Methode setkeys(int [] codes) kann eine Liste von Tastencodes festgelegt werden und somit die Tasten der Kombination. Daneben besitzt jede Kombination einen Namen, der frei gewählt werden kann, und einen Alias, der als Auslöser dient. Unter Windows-Betriebssystemen verhält sich die Simulation eines Tastendrucks nicht so wie das wirkliche Drücken einer Taste auf der Tastatur. Die von einem Texteditor bekannten Wiederholungen bei länger gehaltener Taste werden vom Java-Robot nicht automatisch generiert. Daher implementiert KeyCombination das Interface Runnable und startet beim Simulieren des Tastendrucks einen neuen Thread. Nach einer einstellbaren Verzögerung beginnt eine Schleife zu laufen, welche die Tasten kurzzeitig loslässt und sofort wieder drückt. Dadurch kann eine durchgehend gedrückte Taste vorgetäuscht und das gewohnte Verhalten erzielt werden. Die (optional) konfigurierbare Verzögerung zwischen erstmaligem Auslösen der Kombination und dem Start der Wiederholungen soll verhindern, dass selbst bei kurzem Betätigen der entsprechenden Taste des mobilen Gerätes es durch die Verzögerung bei der Übertragung zu einer mehrfachen Eingabe auf dem Computer kommt. Zusätzlich kann festgelegt werden, wie oft pro Sekunde die Tastenkombination erneut betätigt werden soll. Die Klasse KeyCombination besitzt zur Steuerung die Methoden press(robot robot) und release (), die von der Klasse KeyController verwendet werden. press löst den Tastendruck über den als Parameter angegebenen Robot aus und release () lässt die Tasten wieder los. Es wird sichergestellt, dass auch beim Abbruch der oben erläuterten Schleife alle Tasten losgelassen werden. KeyController meldet sich als Listener für Benutzereingaben beim Verbindungsobjekt an und überprüft die empfangenen Eingaben mit den Aliasen der vorhandenen Tastenkombinationen. Bei Übereinstimmung wird von den Steuerungsmethoden Gebrauch gemacht. Tastenkombinationen werden in der Konfigurationsdatei unter den Elementen <combination> abgelegt. Mögliche Attribute sind name für den Namen der Kombination, alias für den Namen des Aliases, welcher der Kombination zugeordnet ist, sowie delay und freq für Verzögerung bzw. Wiederholungen pro Sekunde. Die Angabe von delay erfolgt dabei in Millisekunden. <combination> besitzt ein bis mehrere Kinder von <key>. Deren einziges Attribut code gibt den Tastencode der zu drückenden Taste an Konfigurationsoberfläche Der Server bietet eine Konfigurationsoberfläche (Abbildung 5.29) an, über die Geräte, Profile, Aliase und Plugins konfiguriert werden können. Da sie direkte Manipulationen am DOM-Baum durchführt, sollte die Benutzung während des Bestehens aktiver Verbindungen unterlassen werden, weil es sonst zu inkonsistenten Zuständen kommen kann. Auf der anderen Seite jedoch, kann es von Zeit zu Zeit nützlich sein on-the-fly eine Einstellung zu ändern und deren Auswirkung

71 5.3 Server 65 sofort zu spüren (z.b. neues Profil anlegen). Abbildung Konfigurationsoberfläche Das Konfigurations-Userinterface ist ein eigener JFrame (Klasse ConfigFrame), welcher in 2 Teile unterteilt ist: Rechts werden auf einer größeren Fläche die einzelnen Konfigurationsseiten (JComponents) angezeigt, die in das dortige JPanel eingefügt werden. Komponenten können aus dem Panel auch wieder entfernt werden, sodass ein Umschalten zwischen den einzelnen Konfigurationsseiten möglich ist. Diese Seiten sind über einen sich links befindlichen JTree zugänglich, der die hierarchische Struktur der Konfigurationsdatei widerspiegelt. Jeder Knoten und jedes Blatt stellen eine Seite dar. Alle Elemente des Baums (Abbildung 5.30) sind von der Klasse ConfigTreeNode abgeleitet. Damit besitzen alle die Möglichkeit eine Referenz auf ein JComponent zu speichern. Diese Components sind die Konfigurationsseiten, die als JPanel, JTabbedPane oder einer anderen von JComponent abgeleiteten Klasse vorliegen. Der ConfigFrame ist als TreeSelectionListener an den JTree angemeldet und wird bei Änderungen der Auswahl im Baum benachrichtigt. Er ermittelt darauf das neu ausgewählt Element und kann von diesem über die Methode getconfigpanel() die Konfigurationsseite zurückgeliefert bekommen. Die alte, zur Zeit angezeigte Seite, wird darauf ausgeblendet und durch die neue ersetzt.

72 5.3 Server 66 Abbildung Elemente des Auswahlbaums Der Server stellt eine spezielle JComboBox für die Auswahl eines Alias eines Gerätes bereit. Durch Angabe des Gerätes in Form eines RemoteControlDevice-Objektes im Konstruktor kann die AliasComboBox auf die Aliase des Gerätes zugreifen. Um über das Hinzufügen und Entfernen von Aliasen informiert zu werden, wird die ComboBox als AliasListener an das Geräteobjekt angemeldet. Diese Einrichtung ist ausschließlich für diesen Verwendungszweck vorgesehen und sollte nicht von anderen Klassen verwendet werden. Neben einer Liste aller vorhandenen Aliase wird auch ein Eintrag für kein Alias zur Auswahl gestellt, um ggf. eine Funktion zu deaktivieren. Über die bekannte Methode getselecteditem() kann eine Referenz auf das ausgewählte Alias-Objekt besorgt werden. Im Falle von kein Alias zeigt die Referenz auf ein Dummy-Objekt der Klasse AliasDummy, welches zwar von Alias abgeleitet ist, jedoch keinen Namen oder Tastencode besitzt und keinem Gerät angehört. Das Dummy-Objekt wird von AliasComboBox erstellt, welches auch durch die Methode selectdummy() explizit ausgewählt werden kann. Sollte der ausgewählte Alias gelöscht werden und ist damit nicht mehr zur Auswahl vorhanden, wird der Eintrag kein Alias automatisch selektiert. Dabei werden alle an die ComboBox angemeldeten SelectionListener informiert, wodurch eine Aktualisierung aller vorhandenen Einstellungen, in denen der Alias benutzt wurde, geschehen kann. Umgekehrt wird allen AliasComboBoxen das Hinzufügen eines neuen Alias mitgeteilt, welcher darauf sofort überall ausgewählt werden kann.

73 5.4 Tests Tests Client Tests von Programmen auf Basis der Java Micro Edition können mit Hilfe des im Wireless Toolkits von Sun mitgelieferten Emulators durchgeführt werden. Dieser simuliert die Umgebung, wie sie auf einem Handy anzutreffen ist und stellt ein grafisches Interface zur Verfügung, welches dem Aussehen eines Handys nachempfunden ist und alle gängigen Tasten bietet. Durch Anklicken dieser Tasten werden die gleichen Ereignisse ausgelöst, wie es auf einem echten mobilen Gerät durch Betätigen einer Taste geschehen würde. Dadurch konnte geprüft werden, ob der Client sich im Großen und Ganzen so verhält, wie es von ihm erwartet wird. Das Debuggen auf einem echten eingebetteten Gerät ist nur schwer möglich, da es keine Konsole gibt, auf der eventuell auftretende Exceptions ausgegeben werden. Der Emulator bietet dagegen genau diese Funktion an. Nachteil bei der Verwendung des Emulators ist jedoch, dass keine Bluetooth- Verbindungen unterstützt werden. Zwar wird eine Bluetooth-API angeboten um den Start von Bluetooth-Anwendungen zu ermöglichen, diese bietet aber nur die Klassen und Methoden ohne konkrete Implementierung. Daher konnte ein Großteil des Clients nur anhand seines Verhaltens unter realen Bedingungen auf dem Test-Handy überprüft werden Verbindungsprotokoll Um das Verbindungsprotokoll ausführlich zu testen, musste auf Grund der fehlenden Bluetooth-Unterstützung des Emulators eine spezielle Testumgebung konstruiert werden. Anstatt über eine Bluetooth-Verbindung zu übertragen, wurde auf eine normale Socket-Verbindung über TCP/IP zurückgegriffen. Im Grunde verhält sich eine Übertragung auf diese Art und Weise genauso wie eine über Bluetooth. Die einzige Änderung, die an den Klassen RemoteControlConnection und RemoteServerConnection durchgeführt wurde, war die Übergabe eines InputStream bzw. OutputStream anstatt der StreamConnection im Konstruktor. Es wurden diverse Testübertragungen durchgeführt und die gesendeten Daten mit den empfangenen abgeglichen, bis eine fehlerfreie Übertragung nach einigen Korrekturen stattfand Server Bei der Überprüfung des Servers wurde auf keine Testumgebung, wie z.b. junit, zurückgegriffen. Kritische Stellen des Servers wurden mit gezielten Falschangaben konfrontiert, um zu ermitteln, ob Ausnahmen entsprechend abgefangen und behandelt werden. Für einige Mechanismen wurden spezielle Testfälle konzipiert und implementiert um das Verhalten der Software zu überprüfen und ggf. zu korrigieren. Das Plugin ImageCapturer wurde zu Testzwecken so modifiziert, dass es die abgegriffenen und komprimierten Bilder als Dateien ablegte. Die übrigen Plugins

74 5.4 Tests 68 wurden durch Benutzung und Simulation von verschiedenen möglichen Anwendungsfällen ausgiebig auf das Auftreten von Fehlern getestet. Während den Tests wurde u.a. festgestellt, dass die verwendete JSR-82 Implementierung BlueCove beim Aufruf der close ()-Methode der Streams den Thread endlos blockieren kann. Die Spezifikation sieht vor, schnellstmöglich aus der Methode wieder zurückzukehren. Daher wurde dieses Verhalten als Fehler in BlueCove aufgefasst. Ein Workaround, welcher diese Methodenaufrufe in einen eigenen Thread auslagert, wurde daraufhin implementiert. Auf diese Weise kann eine Zeit lang auf das Ende des Threads gewartet werden, ohne dass das gesamte Programm stehen bleibt.

75 6 Bedienung 6.1 Server Systenanforderungen Um den Server betreiben zu können, müssen die folgenden Vorraussetzungen erfüllt werden: Microsoft Windows XP oder Vista Java 2 Standard oder Enterprise Edition ab Version 5.0 JSR-82 Implementierung dom4j (http://www.dom4j.org) und jaxen (http://www.jaxen.org) Funktionsfähiges Bluetooth-Gerät Als JSR-82 Implementierung kann BlueCove (http://www.bluecove.org) unter Windows und Mac OS verwendet werden. Unter Linux ist der Betrieb mit avetana (http://www.avetana-gmbh.de/), jedoch mit einigen Einschränkungen, ebenfalls möglich Vorbereitung und Programmstart Der Server setzt eine vorhandene Java-Laufzeitumgebung ab Version 5.0 und ein benutzbares Bluetooth-Gerät vorraus. Bevor der Server gestartet werden kann, muss sichergestellt werden, dass eine JSR-82 Implementierung, dom4j und jaxen zur Verfügung stehen (im Classpath vorhanden sind). Sollte dies nicht der Fall sein, können Klassenabhängigkeiten nicht aufgelöst werden und das Ausführen wird mit einer NoClassDefFoundException abgebrochen Konfiguration Die Konfigurationsoberfläche ist über den Menüpunkt Einstellungen des Hautpfensters zugänglich. Die Daten der Konfigurationsdatei ( config.xml ) werden beim Start des Server einmalig eingelesen. Änderungen an der Datei haben daher erst nach dem Neustart des Servers Auswirkungen. Obwohl Änderungen, die durch die Konfigurationsoberfläche gemacht werden, sofort wirksam sind, werden diese nicht automatisch gespeichert. Dies muss vom Benutzer explizit durch einen Klick auf die Schaltfläche Konfiguration speichern erledigt werden.

76 6.1 Server 70 Plugins Abbildung 6.1. Konfigurationsoberfläche für Serverplugins Im Auswahlbaum ist unter Konfiguration -> Plugins die Konfigurationsseite für die Serverplugins zu finden (siehe Abbildung 6.1). Hier können Plugins für den Server hinzugefügt und wieder entfernt werden. Die Liste zeigt alle vorhandenen und verknüpften Plugins an. Um ein neues Plugin hinzuzufügen, werden eine eindeutige interne ID (interner Name), ein Name für das Plugin sowie Klassenname der Hauptklasse (mit vollständigem Package) und Konfigurationsklasse (ebenfalls mit vollständiger Packageangabe) benötigt. Diese können in die entsprechenden Felder eingegeben werden. Mit einem abschließenden Klick auf Hinzufügen wird das Plugin geladen und ist ab nun den Profilen zuteilbar. Sollten die Angaben falsch sein oder ein Fehler bei der Überprüfung der Gültigkeit des Plugins auftreten, wird eine entsprechende Fehlermeldung angezeigt. Um ein Plugin zu entfernen, muss dieses in der Auswahlliste markiert und das Löschen durch einen Klick auf den Button Löschen bestätigt werden. Das Entfernen eines Plugins führt dazu, dass auch alle Einstellungen, die in den Profilen in Bezug auf das Plugin vorgenommen wurden, gelöscht werden. Daher sollten hier Änderungen nur dann durchgeführt werden, wenn kein Gerät verbunden ist!

77 6.1 Server 71 Geräte Abbildung 6.2. Konfigurationsoberfläche für Geräte Bevor ein mobiles Gerät eine Verbindung zum Server aufbauen kann, muss es konfiguriert werden. Verbindungsanfragen von Geräten, deren Bluetooth-Adresse dem Server unbekannt ist, werden abgelehnt. Daher muss unter Konfiguration -> Geräte für jedes Gerät ein Eintrag erstellt werden (siehe Abbildung 6.2). Benötigte Informationen sind Bluetooth-Geräteadresse und ein frei wählbarer Name für das Gerät. Die Bluetooth-Adresse ist eine 12-stellige, alphanumerische Zeichenfolge, die über den Client ermittelt werden kann (siehe 6.2.4). Der Name muss nicht mit dem Bluetooth-Namen des mobilen Gerätes identisch sein und dient nur der besseren Übersicht in der Serverkonfiguration. Vorhandene Geräte werden in der Liste angezeigt. Um ein Gerät wieder zu entfernen, muss der betreffende Eintrag in der Liste der vorhandenen Geräte markiert und danach auf die Schaltfläche Löschen geklickt werden. Ein Gerät sollte nur dann entfernt werden, wenn keine Verbindung zu diesem zur Zeit besteht. Es ist zwar jederzeit möglich, jedoch führt ein Entfernen bei aktiver Verbindung zu Problemen und unvorhersehbarem Verhalten! Im Auswahlbaum wird für jedes hinzugefügte Gerät ein neuer Knoten erstellt, unter welchem gerätespezifische Einstellung durchgeführt werden können:

78 6.1 Server 72 Aliase Abbildung 6.3. Konfigurationsoberfläche für Aliase Um die Verknüpfung von Gerätetasten mit Aktionen des Servers (bzw. der Plugins) leichter zu gestalten, werden die Tasten des mobilen Gerätes benannt. Die Verwaltung dieser Aliase ist über die Registerkarte Aliase möglich (siehe Abbildung 6.3). Um eine Taste des Clients benutzen zu können, muss zunächst deren Tastencode ermittelt werden (siehe dazu 6.2.4). Der Tastencode ist eine Zahl, welche eine bestimmte Taste identifiziert und vom Client bei deren Betätigung an den Server gesandt wird. Diese Zahl wird in das Feld KeyCode eingegeben. Der Name kann frei gewählt werden, sollte aber zu der Tastenfunktion (oder deren Symbol) passen um Irritationen zu vermeiden (z.b. Name Stern für die Taste * ). Die Tabelle auf der Konfigurationsseite zeigt alle vorhandenen Aliase an. Diese können durch einen Doppelklick auf die entsprechende Tabellenzelle dort direkt geändert werden. Aliase werden durch Auswahl ihres Eintrags in der Tabelle und einem Klick auf den Button Löschen gelöscht. Bei bestehenden Verbindungen zu dem Gerät sollte jedoch keine Änderung an den Aliasen vorgenommen werden, da möglicherweise Plugins nicht auf Änderungen während des Betriebs reagieren und Aktionen nicht mehr ausgeführt werden können!

79 6.1 Server 73 Switcher (Profilauswahl) Abbildung 6.4. Konfigurationsoberfläche für Profilauswahl Die Registerkarte Switcher konfiguriert die Profilauswahl (siehe Abbildung 6.4). Hier werden alle nötigen Tasten zur Steuerung festgelegt. Dabei können nur Tasten ausgewählt werden, für die es bereits einen Alias gibt. Die Profilauswahl stellt die zentrale Steuerung der Verbindung und der Profile des Servers durch den Client dar. Daher ist eine vollständige Konfiguration noch vor dem ersten Verbindungsaufbau unbedingt notwendig. Die Profilauswahl wird eine Liste aller verfügbaren Profile anzeigen. Diese sind über die eingestellten Tasten auswählbar.

80 6.1 Server 74 Profile Abbildung 6.5. Konfigurationsoberfläche für die Verwaltung von Profilen Profile geben an, welche Plugins mit welchen Einstellungen für ein bestimmtes Anwendungsgebiet geladen werden sollen. Darunter fällt die Steuerung bestimmter Programme oder allgemeine Aufgaben wie die Bedienung des Betriebssystems (Starten von Anwendungen, PC neustarten, etc.). Profile werden über die Registerkarte Profile verwaltet (siehe Abbildung 6.5). Sie besitzen einen frei wählbaren Namen und können als Standardprofil markiert werden. Es kann pro Gerät nur ein einziges Standardprofil geben. Dies ist das erste Profil, das immer geladen wird, wenn das betreffende Gerät eine Verbindung herstellt. Sollte bereits ein anderes Profil als Standard festgelegt sein, so wird diese Markierung aufgehoben. Das Standardprofil wird in der Liste der vorhandenen Profile durch <Profilname> hervorgehoben. Um ein Profil als Standard zu setzen, kann die CheckBox beim Hinzufügen markiert oder ein Eintrag aus der Liste ausgewählt und mit einem Klick auf die Schaltfläche Standard festgelegt werden. Um ein Profil zu entfernen steht die Schaltfläche Löschen zur Verfügung. Ein Klick auf diese entfernt den in der Liste ausgewählten Eintrag. Profile können jederzeit gelöscht werden, auch dann, wenn sie gerade in Benutzung sind. Obwohl dies keine Auswirkungen auf den Programmablauf hat, ist ein Zurückschalten auf das gelöschte Profil nach einem Profilwechsel nicht mehr möglich.

81 6.1 Server 75 Abbildung 6.6. Konfigurationsoberfläche für die Zuteilung von Plugins zu Profilen Da Profilen mehrere Plugins zugeteilt werden können, gibt es eine eigene Konfigurationsseite dafür (siehe Abbildung 6.6). Diese ist zugänglich über den Auswahlbaum der Konfigurationsoberfläche. Für jedes Profil wird dort ein neuer Eintrag erstellt, durch dessen Auswahl eine Liste mit verfügbaren Plugins und eine weitere Liste mit den zugeordneten erscheint. Über die Buttons zwischen den beiden Listen kann ein ausgewähltes Plugin entweder dem Profil hinzugefügt (von links nach rechts) oder aus dem Profil entfernt werden (von rechts nach links). Neu hinzugefügte Plugins erscheinen (siehe Abschnitt 6.1.3) sofort in der Liste der verfügbaren Plugins. Im Auswahlbaum erscheint für jedes Plugin ein weiterer Eintrag, der zur dessen Konfigurationsseite führt.

82 6.1 Server 76 Plugin: ImageCapturer Abbildung 6.7. Konfigurationsoberfläche für ImageCapturer Die Aufgabe des Plugins ImageCapturer ist die Bildübertragung zum mobilen Gerät. Über dessen Konfigurationsseite (Abbildung 6.7) kann eine Taste bestimmt werden, um die Bildübertragung ein- und auszuschalten. Eine weitere Einstellungsmöglichkeit ist die maximale Anzahl an Bildern pro Sekunde, die übertragen werden soll. Um eine gute Reaktionszeit beim Betätigen einer Taste zu erreichen, sollte dieser Wert nicht zu hoch angesetzt werden (Standard: 6 Bilder pro Sekunde). Das Plugin passt außerdem die Qualität der Bilder dynamisch an um eine schnelle Datenübertragung zu gewährleisten. Die unterste bzw. oberste Bildqualitätsstufe, die bei der dynamischen Anpassung verwendet werden soll, kann über die entsprechenden Regler bestimmt werden.

83 6.1 Server 77 Plugin: MouseController Abbildung 6.8. Konfigurationsoberfläche für MouseController Über die Eingabemaske des MouseControllers (Abbildung 6.8) können die Tasten festgelegt werden, die zur Steuerung der Maus verwendet werden sollen.

84 6.1 Server 78 Plugin: KeyController Abbildung 6.9. Konfigurationsoberfläche für KeyController Das Plugin KeyController simuliert das Drücken von Tasten bzw. Tastenkombinationen. Einzelne Tasten werden dabei ebenfalls als Tastenkombination gehandhabt. Die an einer Kombination beteiligten Tasten können bequem durch Auswahl des Eingabefeldes Tasten der Konfigurationsmaske (siehe Abbildung 6.9) angegeben werden. Dazu reicht ein Klick darauf. Anschließend kann durch Drücken der entsprechenden Tasten (nacheinander, nicht alle gleichzeitig) auf der Tastatur die Tastenkombination eingegeben werden. Bei Benutzung der ALT-Taste ist darauf zu achten, dass nach deren Betätigung ein erneuter Klick auf das Eingabefeld nötig ist, bevor weitere Tasten hinzugefügt werden können. Um Falscheingaben zu berichtigen existiert der Button Eingabe löschen, der das Feld Tasten komplett leert und eine Neueingabe möglich macht. Jede Tastenkombination benötigt eine zugeordnete Taste des mobilen Gerätes. Diese kann aus der Liste der Aliase ausgewählt werden. Ein Name für die Tastenkombination ist ebenfalls nötig. Dieser kann frei gewählt werden und sollte die Auswirkung widerspiegeln (z.b. Fenster schließen für ALT+F4). Das Feld Verzögerung gibt den Wert in Millisekunden an, die gewartet werden sollen, bevor die Wiederholungen des Tastendrucks gestartet werden. In das Feld Frequenz wird die Anzahl an Wiederholungen pro Sekunde eingegeben. Ein abschließender Klick auf den Button Hinzufügen fügt

85 6.1 Server 79 die Kombination in die Liste der vorhandenen Tastenkombinationen ein. Damit ein mobiles Gerät von einer neuen Tastenkombination Gebrauch machen kann, ist ein Neustart des Plugin unumgänglich. Dies kann durch Herstellen einer neuen Verbindung oder eines Profilwechsels erreicht werden. Eine Tastenkombination kann bearbeitet werden, indem man den Eintrag aus der Liste auswählt. Die mit ihm verknüpften Angaben werden in die Eingabemaske eingefügt und können dort geändert werden. Um die neuen Werte zu speichern steht die Schaltfläche Änderungen speichern zur Verfügung. Auch diese Änderungen werden erst nach Neustart des Plugins aktiv. Um eine Kombination zu löschen, muss der Eintrag in der Liste angewählt und auf den Button Löschen geklickt werden.

86 6.2 Client Client Systemanforderungen Um die Clientanwendung ausführen zu können, muss das eingebettete Gerät die folgenden Anforderungen erfüllen: Bluetooth-fähiges mobiles Gerät Java-Unterstützung (CLDC 1.1 und MIDP 2.0) Installation Da sich die Installationsmethoden von Gerät zu Gerät erheblich unterscheiden können, muss in der jeweiligen Anleitung des Gerätes die Installationsprozedur für Java-Anwendungen nachgelesen werden Geräteauswahl Abbildung Geräteauswahl Die Geräteauswahl (siehe Abbildung 6.10) ist der erste Bildschirm, der nach Programmstart angezeigt wird. Nach einigen Sekunden werden alle bekannten Geräte (gepaarten Geräte) in einer Liste angezeigt, zu denen eine Verbindung hergestellt werden kann. Sollte das gewünschte Gerät nicht in der Liste erscheinen, kann eine erweiterte Suche über den Eintrag Suchen im Menü ausgeführt werden. Damit unbekannte Geräte gefunden werden können, müssen diese sichtbar sein, da unsichtbare Geräte nicht auf Suchanfragen antworten. Die Sichtbarkeit kann in den Bluetooth-Einstellungen des betreffenden Gerätes geändert werden. Mit den Auswahltasten des Gerätes kann ein Eintrag in der Liste angewählt werden. Durch den

87 6.2 Client 81 Menüpunkt Verbinden wird eine Verbindung zu dem betreffenden Gerät hergestellt. Weitere Auswahlmöglichkeiten des Menüs sind eine kurze Hilfe anzeigen, die Geräteinformationsseite aufrufen oder die Anwendung beenden Geräteinformationen Abbildung Geräteinformationen Auf dieser Seite können die zur Konfiguration des Server nötigen Daten über ein Gerät ermittelt werden (siehe Abbildung 6.11). Hier wird neben der Bluetooth- Adresse des Gerätes auch die Tastencodes der Tasten angezeigt. Dazu muss lediglich die gewünschte Taste gedrückt werden. Weitere Anweisungen sind auf dem Bildschirm vorhanden. Bei der Benutzung der Tasten des mobilen Gerätes ist darauf zu achten, dass es spezielle Tasten geben kann, die mit einer Sonderfunktion belegt sind (z.b. Internetverbindung herstellen). Diese Tasten sind nicht auf jedem Gerät vorhanden und die Anzahl ist ebenfalls von Gerät zu Gerät unterschiedlich. Das Betätigen dieser Tasten löst meist ein anderes Verhalten aus, als gewüscht ist. So kann es sein, dass beispielsweise eine bestimmte Funktionstaste ein Einstellungsmenü des Gerätes oder eine bestimmte vordefinierte Anwendung aufruft. Oft wird trotzdem der Tastendruck registriert und an den Server geleitet. Es ist jedoch möglich, dass dem Client der Bildschirm entzogen wird und die neu aufgerufene Anwendung diesen zugeteilt bekommt.

88 6.2 Client 82 Abbildung Anzeige der Bildübertragung Fernsteuern Sobald eine Verbindung aufgebaut wurde, schaltet der Client in den Fernsteuerungsmodus. Ab diesem Zeitpunkt werden alle Benutzereingaben an den Server weitergeleitet und empfangene Bilder und Texte werden auf dem Display des Gerätes ausgegeben (Abbildung 6.12). Abbildung Menü zum Umschalten der Profile

Java Micro Edition. Entwicklung mobiler JavaME-Anwendungen mit CLDC und MIDP. von Klaus D. Schmatz. 2., aktualis. u. erw. Aufl.

Java Micro Edition. Entwicklung mobiler JavaME-Anwendungen mit CLDC und MIDP. von Klaus D. Schmatz. 2., aktualis. u. erw. Aufl. Java Micro Edition Entwicklung mobiler JavaME-Anwendungen mit CLDC und MIDP von Klaus D. Schmatz 2., aktualis. u. erw. Aufl. Java Micro Edition Schmatz schnell und portofrei erhältlich bei beck-shop.de

Mehr

Tipps und Tricks zur Installation von Java-basierten Programmen auf Handys

Tipps und Tricks zur Installation von Java-basierten Programmen auf Handys Tipps und Tricks zur Installation von Java-basierten Programmen auf Handys VORLÄUFIG Inhaltsverzeichnis 1.0 Allgemein...3 1.1 Voraussetzungen für die MODESCO BT-HandeySec Programme...3 2.0 Installation...3

Mehr

Die Hifidelio App Beschreibung

Die Hifidelio App Beschreibung Die Hifidelio App Beschreibung Copyright Hermstedt 2010 Version 1.0 Seite 1 Inhalt 1. Zusammenfassung 2. Die Umgebung für die Benutzung 3. Der erste Start 4. Die Ansicht Remote Control RC 5. Die Ansicht

Mehr

Mobile Betriebsysteme

Mobile Betriebsysteme Mobile Betriebsysteme Ueli Hofstetter, Philippe Hungerbühler, Anil Kandrical Seminar in Mobile Communication Systems WS 06/07 1 1.1 Kleingeräte für mobile Betriebsysteme Embedded System Personal Digital

Mehr

iid software tools QuickStartGuide iid RFID read write unit 13.56 MHz closed coupling RFID iid interface configuration tool

iid software tools QuickStartGuide iid RFID read write unit 13.56 MHz closed coupling RFID iid interface configuration tool iid software tools QuickStartGuide iid software tools RFID read write unit 13.56 MHz closed coupling RFID iid interface configuration tool microsensys Feb 2014 Einleitung Das iid interface configuration

Mehr

Mobile Application Development

Mobile Application Development Mobile Application Development Android: Einführung Jürg Luthiger University of Applied Sciences Northwestern Switzerland Institute for Mobile and Distributed Systems Lernziele Der/die Kursbesucher/in kann

Mehr

Zeiterfassung-Konnektor Handbuch

Zeiterfassung-Konnektor Handbuch Zeiterfassung-Konnektor Handbuch Inhalt In diesem Handbuch werden Sie den Konnektor kennen sowie verstehen lernen. Es wird beschrieben wie Sie den Konnektor einstellen und wie das System funktioniert,

Mehr

Java in der Welt der Handys. Matthias Hemetsberger Joseph Erlinger Erwin Schwab Rudi Dittrich

Java in der Welt der Handys. Matthias Hemetsberger Joseph Erlinger Erwin Schwab Rudi Dittrich Java in der Welt der Handys Matthias Hemetsberger Joseph Erlinger Erwin Schwab Rudi Dittrich Überblick Einführung in MIDP Zusatzpackages: WMA (wireless messaging API) MMA (mobile media API) MIDP = Mobile

Mehr

White Paper. Embedded Treiberframework. Einführung

White Paper. Embedded Treiberframework. Einführung Embedded Treiberframework Einführung White Paper Dieses White Paper beschreibt die Architektur einer Laufzeitumgebung für Gerätetreiber im embedded Umfeld. Dieses Treiberframework ist dabei auf jede embedded

Mehr

Hochschule Darmstadt - Fachbereich Informatik - Fachschaft des Fachbereiches

Hochschule Darmstadt - Fachbereich Informatik - Fachschaft des Fachbereiches Hochschule Darmstadt - Fachbereich Informatik - Fachschaft des Fachbereiches Verwendung der bereitgestellten Virtuellen Maschinen»Einrichten einer Virtuellen Maschine mittels VirtualBox sowie Zugriff auf

Mehr

Usability-Test für mobile Java-Anwendungen

Usability-Test für mobile Java-Anwendungen Usability-Test für mobile Java-Anwendungen Problemstellung / Abgrenzung Usability Engineering / Patterns Usability Test Tool-Kette Fazit Roland Petrasch Usability-Test für mobile Java-Anwendungen Problemstellung

Mehr

CompuLok Zentrale. Software Interface. Digitalzentrale für DCC und Motorola Format

CompuLok Zentrale. Software Interface. Digitalzentrale für DCC und Motorola Format CompuLok Zentrale Software Interface Digitalzentrale für DCC und Motorola Format Inhalt CompuLok Software Interface... 3 Das Software Interface... 3 Installation... 3 Treiber installieren.... 3 Hinweis

Mehr

KURZANLEITUNG FÜR DIE. Installation von Nokia Connectivity Cable Drivers

KURZANLEITUNG FÜR DIE. Installation von Nokia Connectivity Cable Drivers KURZANLEITUNG FÜR DIE Installation von Nokia Connectivity Cable Drivers Inhalt 1. Einführung...1 2. Voraussetzungen...1 3. Installation von Nokia Connectivity Cable Drivers...2 3.1 Vor der Installation...2

Mehr

C# Tutorial Part 1. Inhalt Part 1. Einleitung. Vorbereitung. Eagle Eye Studios. Einleitung Vorbereitung Das erste Projekt

C# Tutorial Part 1. Inhalt Part 1. Einleitung. Vorbereitung. Eagle Eye Studios. Einleitung Vorbereitung Das erste Projekt Eagle Eye Studios C# Tutorial Part 1 Inhalt Part 1 Einleitung Vorbereitung Das erste Projekt Einleitung Wer sich mit dem Programmieren schon einigermaßen auskennt, kann diesen Abschnitt überspringen. Programmieren,

Mehr

Einsatz von Java-fähigen GPRS-Terminals

Einsatz von Java-fähigen GPRS-Terminals Einsatz von Java-fähigen GPRS-Terminals Ein Bericht aus der Praxis Dr. Fred Könemann INSIDE M2M GmbH 15. VDE/ITG Fachtagung Mobilkommunikation Osnabrück 19.-20. Mai 2010 Dr. Fred Könemann, INSIDE M2M GmbH

Mehr

GeoShop Netzwerkhandbuch

GeoShop Netzwerkhandbuch Technoparkstrasse 1 8005 Zürich Tel.: 044 / 350 10 10 Fax.: 044 / 350 10 19 GeoShop Netzwerkhandbuch Zusammenfassung Diese Dokumentation beschreibt die Einbindung des GeoShop in bestehende Netzwerkumgebungen.

Mehr

Systemanforderungen und Installationsanleitung für Internet Security. Inhalt

Systemanforderungen und Installationsanleitung für Internet Security. Inhalt Systemanforderungen und Installationsanleitung für Internet Security Inhalt 1 Systemanforderungen für Internet Security...2 2 Installationsanleitung: Internet Security für einen Test auf einem Computer

Mehr

Online Help StruxureWare Data Center Expert

Online Help StruxureWare Data Center Expert Online Help StruxureWare Data Center Expert Version 7.2.7 Virtuelle StruxureWare Data Center Expert-Appliance Der StruxureWare Data Center Expert-7.2-Server ist als virtuelle Appliance verfügbar, die auf

Mehr

Kapitel 6. Vererbung

Kapitel 6. Vererbung 1 Kapitel 6 2 Ziele Das sprinzip der objektorientierten Programmierung verstehen Und in Java umsetzen können Insbesondere folgende Begriffe verstehen und anwenden können: Ober/Unterklassen Subtyping Überschreiben

Mehr

Mobile Anwendungen WS 07/08 Sebastian Grund [ 746841 ]

Mobile Anwendungen WS 07/08 Sebastian Grund [ 746841 ] Mobile Anwendungen WS 07/08 Sebastian Grund [ 746841 ] Inhaltsverzeichnis 1. Wireless Messaging Überblick...3 2. Aufbau einer SMS...4 3. Wireless Messaging API...5 4. Senden einer Nachricht...6 5. Empfangen

Mehr

Aufbau einer Testumgebung mit VMware Server

Aufbau einer Testumgebung mit VMware Server Aufbau einer Testumgebung mit VMware Server 1. Download des kostenlosen VMware Servers / Registrierung... 2 2. Installation der Software... 2 2.1 VMware Server Windows client package... 3 3. Einrichten

Mehr

Kapitel 6. Vererbung

Kapitel 6. Vererbung 1 Kapitel 6 2 Ziele Das sprinzip der objektorientierten Programmierung verstehen Und in Java umsetzen können Insbesondere folgende Begriffe verstehen und anwenden können: Ober/Unterklassen Subtyping Überschreiben

Mehr

SX3 PC Software rev. 0.99c

SX3 PC Software rev. 0.99c SX3 PC Software rev. 0.99c SX3 ist ein Programm zur Steuerung einer Selectrix Digitalzentrale unter Linux bzw. Windows. Mit SX3 haben Sie die Möglichkeit Selectrix -Loks zu fahren, Weichen zu Schalten

Mehr

Benutzerdokumentation Web-Portal

Benutzerdokumentation Web-Portal GRUPP: SWT0822 Benutzerdokumentation Web-Portal Yet Another Reversi Game Martin Gielow, Stephan Mennicke, Daniel Moos, Christine Schröder, Christine Stüve, Christian Sura 05. Mai 2009 Inhalt 1. Einleitung...3

Mehr

Netzwerk Technologien in LabVIEW

Netzwerk Technologien in LabVIEW Netzwerk Technologien in LabVIEW von Dirk Wieprecht NI Germany Hier sind wir: Agenda Agenda Bedeutung des Ethernet für die Messtechnik Ethernet-basierende Technologien in LabVIEW Low Level- TCP/IP Objekt

Mehr

Anwenderdokumentation PersoSim

Anwenderdokumentation PersoSim Anwenderdokumentation PersoSim Die nachfolgende Anwenderdokumentation soll dem Anwender bei der Installation und den ersten Schritten im Umgang mit PersoSim helfen. Installation Grundvoraussetzung für

Mehr

Das Bluetooth Handbuch

Das Bluetooth Handbuch Telekommunikation Jörg Franz Wollert Das Bluetooth Handbuch Technologie Software Einsatzfelder Systementwicklung Wettbewerb Mit 213 Abbildungen Franzis Inhalt 1 Bluetooth - Übersicht 15 1.1 Wo steht Bluetooth?

Mehr

Win7Deploy Seite 2 von 17. Was ist Win7Deploy?

Win7Deploy Seite 2 von 17. Was ist Win7Deploy? Win7Deploy Seite 1 von 17 Win7Deploy Eine einfache, passgenaue und kostengünstige Lösung um Windows 7 in Ihrem Unternehmen einzuführen [ www.win7deploy.de ] Ablauf einer Win7Deploy Installation am Beispiel

Mehr

3. Konzepte der objektorientierten Programmierung

3. Konzepte der objektorientierten Programmierung 3. Konzepte der objektorientierten Programmierung 3.1 Basiskonzepte 3.2 Generalisierung / Spezialisierung 3.3 Aggregation 3.4 Assoziation 3.5 Nachrichten 3.6 Polymorphismus 3. Konzepte der Objektorientierung

Mehr

In 15 einfachen Schritten zum mobilen PC mit Paragon Drive Copy 10 und Microsoft Windows Virtual PC

In 15 einfachen Schritten zum mobilen PC mit Paragon Drive Copy 10 und Microsoft Windows Virtual PC PARAGON Technologie GmbH, Systemprogrammierung Heinrich-von-Stephan-Str. 5c 79100 Freiburg, Germany Tel. +49 (0) 761 59018201 Fax +49 (0) 761 59018130 Internet www.paragon-software.com Email sales@paragon-software.com

Mehr

bluelino 4G/ 4G+ Konfigurationssoftware

bluelino 4G/ 4G+ Konfigurationssoftware LinTech Bedienungsanleitung bluelino 4G/ 4G+ Konfigurationssoftware Revision 1.42 Inhalt 1 Konfiguration des bluelino 4G oder 4G+ ändern... 3 1.1 Voraussetzungen... 3 1.2 Start/Inbetriebnahme Konfigurationssoftware...

Mehr

Gefahren aus dem Internet 1 Grundwissen April 2010

Gefahren aus dem Internet 1 Grundwissen April 2010 1 Grundwissen Voraussetzungen Sie haben das Internet bereits zuhause oder an der Schule genutzt. Sie wissen, was ein Provider ist. Sie wissen, was eine URL ist. Lernziele Sie wissen, was es braucht, damit

Mehr

Baqué und Lauter GmbH 02255 / 950300 Falkenweg 3 Fax 02255 / 950303 53881 Euskirchen

Baqué und Lauter GmbH 02255 / 950300 Falkenweg 3 Fax 02255 / 950303 53881 Euskirchen Baqué und Lauter GmbH 02255 / 950300 Falkenweg 3 Fax 02255 / 950303 53881 Euskirchen Anleitung für die Installation ein Netzwerks unter Windows 95,98,Me,2000. Netzwerke können auf sehr unterschiedliche

Mehr

Bedienungsanleitung WR ConfigTool für DuoFern Handzentrale (9493) DuoFern Umweltsensor (9475)

Bedienungsanleitung WR ConfigTool für DuoFern Handzentrale (9493) DuoFern Umweltsensor (9475) Bedienungsanleitung WR ConfigTool für DuoFern Handzentrale (949) DuoFern Umweltsensor (9475) / Inhaltsverzeichnis Einleitung.... Standard Layout... 4 Handzentrale... 5. Daten laden... 5. Einstellungen

Mehr

Programmieren was ist das genau?

Programmieren was ist das genau? Programmieren was ist das genau? Programmieren heisst Computerprogramme herstellen (von griechisch programma für Vorschrift). Ein Computerprogramm ist Teil der Software eines Computers. Als Software bezeichnet

Mehr

Kurzanleitung zu WinZeit und dem Scanndy

Kurzanleitung zu WinZeit und dem Scanndy Kurzanleitung zu WinZeit und dem Scanndy Inhaltsverzeichnis Benötigte Materialien Seite 3 Grundlegende Bedienung des Scanndys Seite 4 Die Hauptmenü Punkte Seite 5 Das Drucken mit Barcode Seite 6 Zuordnen

Mehr

Byte-Taxi. Bedienungsanleitung. Seite 1 von 8

Byte-Taxi. Bedienungsanleitung. Seite 1 von 8 Byte-Taxi Bedienungsanleitung Seite 1 von 8 Inhaltsverzeichnis 1. Beschreibung 3 2. Systemvoraussetzungen 4 3. Installationsanleitung 5 4. Bedienung 6 5. Infos & Kontakt 8 Seite 2 von 8 1. Beschreibung

Mehr

Scalera Mailplattform Dokumentation für den Anwender Installation und Konfiguration des Outlook Connectors

Scalera Mailplattform Dokumentation für den Anwender Installation und Konfiguration des Outlook Connectors Installation und Konfiguration des Outlook Connectors Vertraulichkeit Die vorliegende Dokumentation beinhaltet vertrauliche Informationen und darf nicht an etwelche Konkurrenten der EveryWare AG weitergereicht

Mehr

Userhandbuch. Version B-1-0-2 M

Userhandbuch. Version B-1-0-2 M Userhandbuch Version B-1-0-2 M Inhaltsverzeichnis 1.0 Was bietet mir SERVRACK?... 3 1.1 Anmeldung... 3 1.2 Passwort vergessen?... 3 1.3 Einstellungen werden in Realtime übernommen... 4 2.0 Die SERVRACK

Mehr

JAVA. Ein kurzer Überblick. Thomas Karp

JAVA. Ein kurzer Überblick. Thomas Karp JAVA Ein kurzer Überblick Thomas Karp WAS IST JAVA? Java ist eine fast rein objektorientierte Sprache nicht JavaScript eine professionelle Sprache eine im Unterricht weit verbreitete Sprache für verschiedene

Mehr

USB in Embedded Systemen. Referat von Peter Voser Embedded Development GmbH

USB in Embedded Systemen. Referat von Peter Voser Embedded Development GmbH USB in Embedded Systemen Referat von Peter Voser Embedded Development GmbH Embedded Development GmbH Engineering and Development System Engineering Hardware/Software Co-Design Embedded Software Entwicklung

Mehr

Glossar. Launching auf.

Glossar. Launching auf. 243 Ad Hoc Distribution Die Ad Hoc Distribution ist eine Möglichkeit, um Ihre entwickelte Anwendung auf anderen Endgeräten zu verteilen. Diese Art der Verteilung erfolgt ohne den App Store. Die Anzahl

Mehr

Hyper-V Server 2008 R2

Hyper-V Server 2008 R2 Hyper-V Server 2008 R2 1 Einrichtung und Installation des Hyper-V-Servers 1.1 Download und Installation 4 1.2 Die Administration auf dem Client 9 1.3 Eine VM aufsetzen 16 1.4 Weiterführende Hinweise 22

Mehr

CDE-13xBT & CDE-W235BT & CDA-137BTi

CDE-13xBT & CDE-W235BT & CDA-137BTi Bluetooth Software Update Manual mit Windows 7 Für Geräte aus dem Modelljahr 2012 CDE-13xBT & CDE-W235BT & CDA-137BTi 1 Einleitung In der Anleitung wird die Vorgehensweise zum aktualisieren der Radio Bluetooth

Mehr

Smartphone Entwicklung mit Android und Java

Smartphone Entwicklung mit Android und Java Smartphone Entwicklung mit Android und Java predic8 GmbH Moltkestr. 40 53173 Bonn Tel: (0228)5552576-0 www.predic8.de info@predic8.de Was ist Android Offene Plattform für mobile Geräte Software Kompletter

Mehr

Einrichtung des NVS Calender-Google-Sync-Servers. Installation des NVS Calender-Google-Sync Servers (Bei Neuinstallation)

Einrichtung des NVS Calender-Google-Sync-Servers. Installation des NVS Calender-Google-Sync Servers (Bei Neuinstallation) Einrichtung des NVS Calender-Google-Sync-Servers Folgende Aktionen werden in dieser Dokumentation beschrieben und sind zur Installation und Konfiguration des NVS Calender-Google-Sync-Servers notwendig.

Mehr

Securepoint Security Systems

Securepoint Security Systems HowTo: Virtuelle Maschine in VMware für eine Securepoint Firewall einrichten Securepoint Security Systems Version 2007nx Release 3 Inhalt 1 VMware Server Console installieren... 4 2 VMware Server Console

Mehr

Beschreibung Mobile Office

Beschreibung Mobile Office Beschreibung Mobile Office 1. Internet / Netz Zugriff Für die Benutzung von Mobile Office ist lediglich eine Internet oder Corporate Netz Verbindung erforderlich. Nach der Verbindungsherstellung kann über

Mehr

Software ubiquitärer Systeme

Software ubiquitärer Systeme Software ubiquitärer Systeme Anwendungsentwicklung mit Java Olaf Spinczyk Arbeitsgruppe Eingebettete Systemsoftware Lehrstuhl für Informatik 12 TU Dortmund Olaf.Spinczyk@tu-dortmund.de http://ess.cs.uni-dortmund.de/~os/

Mehr

Die Implementierung des ROB-Clients

Die Implementierung des ROB-Clients Die Implementierung des ROB-Clients a. Vorwort Nach der anfänglichen Suche nach der bestmöglichen Lösung der Umsetzung des ROB-Clients war schnell klar, dass dies in Java erfolgen würde. Die meisten der

Mehr

Installationsführer für den SIP Video Client Linphone

Installationsführer für den SIP Video Client Linphone Installationsführer für den SIP Video Client Linphone Stand: 10.04.2010 1. Einleitung Dieses Dokument beschreibt die Vorgehensweise für den Download, die Installation und Inbetriebnahme eines SIP Videoclients

Mehr

NetBeans Installation für Handy-Programmierung

NetBeans Installation für Handy-Programmierung Netbeans-Installation für Handy-Programmierung Seite 1 NetBeans Installation für Handy-Programmierung 1. Installation Die Netbeans-Installation setzt voraus, dass JDK 6 bereits auf dem Rechner installiert

Mehr

Installation und Bedienung. Repeater N/G

Installation und Bedienung. Repeater N/G Installation und Bedienung Repeater N/G Das ist der FRITZ!WLAN Repeater N/G Der FRITZ!WLAN Repeater erweitert die WLAN-Reichweite Ihres Funknetzwerks. Für die Erweiterung eines Netzwerks wird der FRITZ!WLAN

Mehr

C# - PROGRAMME MIT PLUGINS ERWEITERN

C# - PROGRAMME MIT PLUGINS ERWEITERN C# - PROGRAMME MIT PLUGINS ERWEITERN Schreibt man ein Programm welches erweiterbar sein soll, dann gibt es häufig mehrere Möglichkeiten dies umzusetzen. Die Objektorientierung ist dabei der erste Schritt,

Mehr

LEHR-SYSTEM für die Fahrschule der Zukunft

LEHR-SYSTEM für die Fahrschule der Zukunft Das LEHR-SYSTEM für die Fahrschule der Zukunft Installationsanleitung für SCAN & TEACH next generation 2.0 Basissoftware, Klassen und Service Packs Sehr geehrte Kundin, sehr geehrter Kunde, Ihnen liegt

Mehr

Bluetooth* RS232 Adapter Artikelnummer: 1406

Bluetooth* RS232 Adapter Artikelnummer: 1406 Bluetooth* RS232 Adapter Artikelnummer: 1406 Benutzerhandbuch (Version 1.0) Inhaltsverzeichnis 1.EINLEITUNG... 3 1.1 Lieferumfang...3 1.2 Geräteansicht...4 2. INBETRIEBNAHME... 4 3.SOFTWARE - RS323 CONFIGTOOL...

Mehr

Matthias Hofherr. WLAN-Sicherheit. Professionelle Absicherung von 802.11-Netzen. Heise

Matthias Hofherr. WLAN-Sicherheit. Professionelle Absicherung von 802.11-Netzen. Heise Matthias Hofherr WLAN-Sicherheit Professionelle Absicherung von 802.11-Netzen Heise 5 Bevor man einen genaueren Blick auf die Sicherheitsmechanismen von Netzwerken auf Basis des Standards 802.11 wirft,

Mehr

2 Virtualisierung mit Hyper-V

2 Virtualisierung mit Hyper-V Virtualisierung mit Hyper-V 2 Virtualisierung mit Hyper-V 2.1 Übersicht: Virtualisierungstechnologien von Microsoft Virtualisierung bezieht sich nicht nur auf Hardware-Virtualisierung, wie folgende Darstellung

Mehr

1. Software-Plattform Android Android. Was ist Android? Bibliotheken, Laufzeitumgebung, Application Framework

1. Software-Plattform Android Android. Was ist Android? Bibliotheken, Laufzeitumgebung, Application Framework 1. Software-Plattform Android Android Was ist Android? Plattform und Betriebssystem für mobile Geräte (Smartphones, Mobiltelefone, Netbooks), Open-Source Linux-Kernel 2.6 Managed Code, Angepasste Java

Mehr

Einführung in Android. 9. Dezember 2014

Einführung in Android. 9. Dezember 2014 Einführung in Android 9. Dezember 2014 Was ist Android? Software für mobile Geräte: Betriebssystem Middleware Kernanwendungen Android SDK: Tools und APIs zur Entwicklung von Anwendungen auf der Android-Plattform

Mehr

Präsentation. homevisu Familie. Peter Beck. Juni 2011. www.p-b-e.de. 2011 p b e Peter Beck 1

Präsentation. homevisu Familie. Peter Beck. Juni 2011. www.p-b-e.de. 2011 p b e Peter Beck 1 Präsentation homevisu Familie Peter Beck Juni 2011 2011 p b e Peter Beck 1 Funktionensumfang Der Funktionsumfang das provisu Framework. Modular und durch Plug-In erweiterbar / anpassbar. Plug-In Schnittstelle

Mehr

Einführung in die Informatik: Programmierung und Software-Entwicklung, WS 11/12. Kapitel 7. Grafische Benutzeroberflächen

Einführung in die Informatik: Programmierung und Software-Entwicklung, WS 11/12. Kapitel 7. Grafische Benutzeroberflächen 1 Kapitel 7 Ziele 2 (Graphical User Interfaces) als Anwendungsbeispiel für die objektorientierte Programmierung kennenlernen Benutzung von Vererbung zur Erstellung individueller GUI-Klassen durch Erweiterung

Mehr

In 12 Schritten zum mobilen PC mit Paragon Drive Copy 11 und Microsoft Windows Virtual PC

In 12 Schritten zum mobilen PC mit Paragon Drive Copy 11 und Microsoft Windows Virtual PC PARAGON Technologie GmbH, Systemprogrammierung Heinrich-von-Stephan-Str. 5c 79100 Freiburg, Germany Tel. +49 (0) 761 59018201 Fax +49 (0) 761 59018130 Internet www.paragon-software.com Email sales@paragon-software.com

Mehr

Das Interceptor Muster

Das Interceptor Muster Das Interceptor Muster Implementierung des Interceptor Musters basierend auf OSGi and Friends Benjamin Friedrich Hochschule für Technik und Wirtschaft des Saarlandes Praktische Informatik - Entwurfsmuster

Mehr

Wie fängt man an. Fortgeschrittene Kontakt Verwaltung

Wie fängt man an. Fortgeschrittene Kontakt Verwaltung Wie fängt man an Um alle Vorzüge der iphone TBird Anwendung zu nutzen, sollten nachfolgende Hinweise gelesen werden. Fortgeschrittene Kontakt Verwaltung Mit der TBird iphone Anwendung ist es möglich Kontakte

Mehr

FOPT 5: Eigenständige Client-Server-Anwendungen (Programmierung verteilter Anwendungen in Java 1)

FOPT 5: Eigenständige Client-Server-Anwendungen (Programmierung verteilter Anwendungen in Java 1) 1 FOPT 5: Eigenständige Client-Server-Anwendungen (Programmierung verteilter Anwendungen in Java 1) In dieser Kurseinheit geht es um verteilte Anwendungen, bei denen wir sowohl ein Client- als auch ein

Mehr

Hinweise zur Datenübertragung mit. Bluetooth is a registered trademark of Bluetooth SIG, Inc.

Hinweise zur Datenübertragung mit. Bluetooth is a registered trademark of Bluetooth SIG, Inc. Hinweise zur Datenübertragung mit Bluetooth is a registered trademark of Bluetooth SIG, Inc. Information Diese Anleitung hilft Ihnen, das smartlab Bluetooth Modul in Ihr smartlab genie Blutzuckermessgerät

Mehr

Marketing Update. Enabler / ENABLER aqua / Maestro II

Marketing Update. Enabler / ENABLER aqua / Maestro II Marketing Update Enabler / ENABLER aqua / Maestro II Quartal 01/2013 1 Kommentar des Herausgebers Liebe Kunden und Partner, dieser Marketing Update gibt Ihnen einen kurzen Überblick über die aktuell verfügbaren

Mehr

Inhaltsverzeichnis Bluetooth

Inhaltsverzeichnis Bluetooth Bluetooth Inhaltsverzeichnis 3 Das ausführliche Inhaltsverzeichnis finden Sie auf den letzten Seiten dieses Katalogs (ab Seite 5). Erstellt am 4.5.2010. www.brinco.de info@brinco.de Tel.: Fax.: 069 / 53

Mehr

Linux Terminal mit Ethernet und Java. Eine dynamische Plattform für Automatisierungsapplikationen?

Linux Terminal mit Ethernet und Java. Eine dynamische Plattform für Automatisierungsapplikationen? Linux Terminal mit Ethernet und Java. Eine dynamische Plattform für Automatisierungsapplikationen? JULIA SCHILLING SSV EMBEDDED SYSTEMS HEISTERBERGALLEE 72 D-30453 HANNOVER WWW.SSV-EMBEDDED.DE Ethernet

Mehr

Leica DISTO Transfer Wie verbinde ich meinen Leica DISTO mit meinem PC

Leica DISTO Transfer Wie verbinde ich meinen Leica DISTO mit meinem PC Wie verbinde ich meinen Leica DISTO mit meinem PC PC, Labtop 2 Tablet PC, UMPC Installation 1. Bitte laden Sie die aktuellste Version der Leica DISTO Transfer Software auf unserer Homepage herunter: http://ptd.leica-geosystems.com/en/support-downloads_6598.htm?cid=11104

Mehr

3827260108 Private Homepage vermarkten So laden Sie Ihre Website auf den Server Das lernen Sie in diesem Kapitel: n So funktioniert FTP n Diese FTP-Programme gibt es n So laden Sie Ihre Website mit WS-FTP

Mehr

Technische Beschreibung: EPOD Server

Technische Beschreibung: EPOD Server EPOD Encrypted Private Online Disc Technische Beschreibung: EPOD Server Fördergeber Förderprogramm Fördernehmer Projektleitung Projekt Metadaten Internet Foundation Austria netidee JKU Linz Institut für

Mehr

Installation von BitKinex 3.1.1- ein alternativer WebDAV-Client

Installation von BitKinex 3.1.1- ein alternativer WebDAV-Client Musterlösung für Schulen in Baden-Württemberg Windows 2003 Installation von BitKinex 3.1.1- ein alternativer WebDAV-Client Stand: 13.01.10 /1. Version Impressum Autor Johannes Kühn Endredaktion Johannes

Mehr

Programmieren I. Die Programmiersprache Java. www.kit.edu. Institut für Angewandte Informatik

Programmieren I. Die Programmiersprache Java. www.kit.edu. Institut für Angewandte Informatik Programmieren I Die Programmiersprache Java KIT Universität des Landes Baden-Württemberg und nationales Großforschungszentrum in der Helmholtz-Gemeinschaft www.kit.edu Eigenschaften von Java Java ist eine

Mehr

Integrating Architecture Apps for the Enterprise

Integrating Architecture Apps for the Enterprise Integrating Architecture Apps for the Enterprise Ein einheitliches Modulsystem für verteilte Unternehmensanwendungen Motivation und Grundkonzept Inhalt Problem Ursache Herausforderung Grundgedanke Architektur

Mehr

Datensicherung. Beschreibung der Datensicherung

Datensicherung. Beschreibung der Datensicherung Datensicherung Mit dem Datensicherungsprogramm können Sie Ihre persönlichen Daten problemlos Sichern. Es ist möglich eine komplette Datensicherung durchzuführen, aber auch nur die neuen und geänderten

Mehr

6 Blueprints. 6.1 Einführung in Blueprints

6 Blueprints. 6.1 Einführung in Blueprints 93 Nachdem wir Ihnen in den vorigen Kapiteln gezeigt haben, wie Sie vrealize Automation installieren und konfigurieren, zeigen wir nun, wie Maschinen mit vrealize Automation provisioniert werden können.

Mehr

Willkommen zur Vorlesung. Objektorientierte Programmierung Vertiefung - Java

Willkommen zur Vorlesung. Objektorientierte Programmierung Vertiefung - Java Willkommen zur Vorlesung Objektorientierte Programmierung Vertiefung - Java Zum Dozenten Mein Name: Andreas Berndt Diplom-Informatiker (TU Darmstadt) Derzeit Software-Entwickler für Web- Applikationen

Mehr

SchlieSSen Sie Ihren Lemur an

SchlieSSen Sie Ihren Lemur an 1 SchlieSSen Sie Ihren Lemur an Der Lemur ist nicht irgendein durchschnittlicher MIDI-Controller. Er spricht 1000 Mal schneller und mit der 4-fachen Auflösung. Also finden Sie auf der Rückseite auch nicht

Mehr

RWE Cloud Services. RWE Cloud Services Global Access Erste Schritte

RWE Cloud Services. RWE Cloud Services Global Access Erste Schritte Global Access Erste Schritte Copyright RWE IT. Any use or form of reproduction, in whole or part, of any material whether by photocopying or storing in any medium by electronic means or otherwise requires

Mehr

25. Februar 2009, Version 1.0. Installationsanleitung Tivoli Storage Manager für Windows. Verwaltungsdirektion. Informatikdienste

25. Februar 2009, Version 1.0. Installationsanleitung Tivoli Storage Manager für Windows. Verwaltungsdirektion. Informatikdienste 25. Februar 2009, Version 1.0 Installationsanleitung für Windows Verwaltungsdirektion Informatikdienste Installationsanleitung für Windows Inhaltsverzeichnis...1 Installation... 1 Voraussetzungen...1 Ablauf

Mehr

FTP HOWTO. zum Upload von Dateien auf Webserver. Stand: 01.01.2011

FTP HOWTO. zum Upload von Dateien auf Webserver. Stand: 01.01.2011 FTP HOWTO zum Upload von Dateien auf Webserver Stand: 01.01.2011 Copyright 2002 by manitu. Alle Rechte vorbehalten. Alle verwendeten Bezeichnungen dienen lediglich der Kennzeichnung und können z.t. eingetragene

Mehr

Remote Communications

Remote Communications HELP.BCFESDEI Release 4.6C SAP AG Copyright Copyright 2001 SAP AG. Alle Rechte vorbehalten. Weitergabe und Vervielfältigung dieser Publikation oder von Teilen daraus sind, zu welchem Zweck und in welcher

Mehr

Avigilon Control Center Virtual Matrix Benutzerhandbuch

Avigilon Control Center Virtual Matrix Benutzerhandbuch Avigilon Control Center Virtual Matrix Benutzerhandbuch Version 5.0 PDF-ACCVM-A-Rev1_DE Copyright 2013 Avigilon. Alle Rechte vorbehalten. Änderungen der vorliegenden Informationen vorbehalten. Ohne ausdrückliche

Mehr

Installation des USB HD-Audio Treibers 24/192 im asynchronen Mode (XMOS-Plattform) Einstellungen des Betriebssystems

Installation des USB HD-Audio Treibers 24/192 im asynchronen Mode (XMOS-Plattform) Einstellungen des Betriebssystems Installation des USB HD-Audio Treibers 24/192 im asynchronen Mode (XMOS-Plattform) Einstellungen des Betriebssystems 1 Mac OS X 2 Windows 7 3 Windows Vista 4 Windows XP 5 Tipps Installationsanleitung XMOS

Mehr

4D Server v12 64-bit Version BETA VERSION

4D Server v12 64-bit Version BETA VERSION 4D Server v12 64-bit Version BETA VERSION 4D Server v12 unterstützt jetzt das Windows 64-bit Betriebssystem. Hauptvorteil der 64-bit Technologie ist die rundum verbesserte Performance der Anwendungen und

Mehr

Anleitung zur Installation eines Clusters unter VMWare 4.0 (Built 4460)

Anleitung zur Installation eines Clusters unter VMWare 4.0 (Built 4460) Anleitung zur Installation eines Clusters unter VMWare 4.0 (Built 4460) Schritt 1: Erstellen der virtuellen Maschinen 1. Menü File, New, New Virtual Machine... wählen. 2. Auf Weiter > klicken. 3. Die Option

Mehr

eytron VMS Webanwendung Fehlersuche und -Behebung

eytron VMS Webanwendung Fehlersuche und -Behebung eytron VMS Webanwendung Fehlersuche und -Behebung 2009 ABUS Security-Center GmbH & Co. KG, Alle Rechte vorbehalten Diese Anleitung soll Ihnen Unterstützung für den Fall geben, dass die Webanwendung nach

Mehr

Bedienungsanleitung Modbus-LAN Gateway

Bedienungsanleitung Modbus-LAN Gateway Bedienungsanleitung Modbus-LAN Gateway Bedienungsanleitung Modbus-LAN Gateway Inhalt 1. Starten der Konfigurationsoberfläche des MLG... 3 2. Konfiguration MLG... 4 2.1. Network Settings... 4 2.1.1 Statische

Mehr

BENUTZERHANDBUCH APP INTERCALL REMOTE VIP

BENUTZERHANDBUCH APP INTERCALL REMOTE VIP DE TECHNISCHES HANDBUCH BENUTZERHANDBUCH APP INTERCALL REMOTE VIP FÜR GERÄTE: www.comelitgroup.com Installation App Intercall Remote ViP... Konfiguration der Anwendung... 4 Ruf entgegennehmen... 6 UNBEANTWORTETE

Mehr

FileMaker Pro 14. Verwenden einer Remotedesktopverbindung mit FileMaker Pro 14

FileMaker Pro 14. Verwenden einer Remotedesktopverbindung mit FileMaker Pro 14 FileMaker Pro 14 Verwenden einer Remotedesktopverbindung mit FileMaker Pro 14 2007-2015 FileMaker, Inc. Alle Rechte vorbehalten. FileMaker, Inc. 5201 Patrick Henry Drive Santa Clara, California 95054,

Mehr

Leitfaden zur Installation von Bitbyters.WinShutdown

Leitfaden zur Installation von Bitbyters.WinShutdown Leitfaden zur Installation von Bitbyters.WinShutdown für Windows 32 Bit 98/NT/2000/XP/2003/2008 Der BitByters.WinShutDown ist ein Tool mit dem Sie Programme beim Herunterfahren Ihres Systems ausführen

Mehr

Tapps mit XP-Mode unter Windows 7 64 bit (V2.0)

Tapps mit XP-Mode unter Windows 7 64 bit (V2.0) Tapps mit XP-Mode unter Windows 7 64 bit (V2.0) 1 Einleitung... 2 2 Download und Installation... 3 2.1 Installation von WindowsXPMode_de-de.exe... 4 2.2 Installation von Windows6.1-KB958559-x64.msu...

Mehr

Geschäftsbereich Mobile Services Was ist Android?

Geschäftsbereich Mobile Services Was ist Android? Geschäftsbereich Mobile Services Was ist Android? Hinter Hoben 149 53129 Bonn www.visionera.de Ansprechpartner: Arno Becker arno.becker@visionera.de +49 228 555 1111 +49 160 98965856 Einleitung Android

Mehr

Acer WLAN 11b USB Dongle. Kurzanleitung

Acer WLAN 11b USB Dongle. Kurzanleitung Acer WLAN 11b USB Dongle Kurzanleitung 1 Acer WLAN 11b USB Dongle Kurzanleitung Lesen Sie diese Kurzanleitung vor der Installation des Acer WLAN 11b USB Dongles. Für ausführliche Informationen über Sicherheitsmaßnahmen

Mehr

CORBA. Systemprogrammierung WS 2006-2007

CORBA. Systemprogrammierung WS 2006-2007 CORBA Systemprogrammierung WS 2006-2007 Teilnehmer: Bahareh Akherattalab Babak Akherattalab Inhaltsverzeichnis: Verteilte Systeme Vergleich zwischen lokale und verteilte Systeme Verteilte Anwendungen CORBA

Mehr

Remote Administration von Windows Servern mit Microsoft Terminal Services und OpenSSH

Remote Administration von Windows Servern mit Microsoft Terminal Services und OpenSSH Remote Administration von Windows Servern mit Microsoft Terminal Services und OpenSSH von Dominick Baier (dbaier@ernw.de) und Jens Franke (jfranke@ernw.de) 1 Einleitung Dieses Dokument behandelt die flexible

Mehr

Software Bedienungsanleitung. ENiQ Access Management: Online-Inbetriebnahme

Software Bedienungsanleitung. ENiQ Access Management: Online-Inbetriebnahme Software Bedienungsanleitung ENiQ Access Management: Online-Inbetriebnahme V1.0 April 2015 Inhaltsverzeichnis 1 Voraussetzungen... 3 2 Allgemeine Hinweise... 3 3 Generelle Einstellungen... 3 4 Dienste

Mehr

Sind Ihre Anwendungen auf mobilen Endgeräten sicher? Karsten Sohr Technologie-Zentrum Informatik Universität Bremen

Sind Ihre Anwendungen auf mobilen Endgeräten sicher? Karsten Sohr Technologie-Zentrum Informatik Universität Bremen Sind Ihre Anwendungen auf mobilen Endgeräten sicher? Karsten Sohr Technologie-Zentrum Informatik Universität Bremen Inhalt Motivation allgemeine Bedrohungen für mobile Endgeräte bösartige Anwendungen für

Mehr