Der folgende Artikel befasst sich mit der Nutzung von iBeacons als Bluetooth Low Energy Lokalisierungshilfsmittel fürAndroid-Geräten. Nach einer kurzen Einführung in die grundsätzliche Funktionsweise von iBeacons werden Installationsanleitungen sowie Codebeispiele zur Verwendung von iBeacons mittels Estimote-SDK und AltBeacon bereitgestellt. 

Begriff iBeacons

Der Begriff iBeacon wurde von Apple 2013 eingeführt und steht als Markenname für ein auf Bluetooth Low Energy (BLE) bzw. Bluetooth 4.0 basierendes Produkt, das z.B. zur Indoor-Navigation genutzt werden kann. Hierbei stellt das iBeacon einen Sender dar, der in kontinuierlichen Zeitabständen Daten an entsprechende Empfangsgeräte (Smartphone, Tablet, …) sendet. Diese Daten können mittels einer speziellen App genutzt werden, um beispielsweise die eigene Position zu ermitteln. Ein iBeacon zeichnet sich durch seine lange Laufzeit und vergleichsweise hohen Reichweite aus. Die Technologie wird von verschiedenen Herstellern angeboten, wobei die im Weiteren aufgeführten Tests und Beispiele unter Verwendung von Estimote-iBeacons durchgeführt wurden.

Schematische Darstellung zu iBeacons ¹

Nutzung

Im folgenden Abschnitt werden die Vorraussetzungen für die Nutzung sowie die wesentlichen Daten und Begriffe, die für die Arbeit mit iBeacons relevant sind, aufgeführt.

Voraussetzung

Die Nutzung von iBeacons kann nur unter bestimmten Voraussetzungen erfolgen. Das jeweilige Mobile Device muss BLE / Bluetooth 4.0 unterstützen, was somit Geräte ab iOS7 und Android 4.3 umfasst.

Entsprechende Bibliotheken werden für IOS von Apple bereitgestellt. Android-Entwickler müssen hingegen auf Bibliotheken der jeweiligen Hersteller zurückgreifen, da Google keine offiziellen zur Verfügung stellt.

Daten eines iBeacons

Die Daten, die ein iBeacons sendet, sind im Folgenden Beispielhaft aufgeführt.

• UUID: B9407F30-F5F8-466E-AFF9-25556B57FE6D
• Minor: 1
• Major: 2
• RSSI: -55
• measuredPower: 62

Die nachfolgende Abbildung stellt die Funktion der jeweiligen Werte schematisch dar:

iBeacons Major, Minor und RSSI

Ein beispielhafter Anwendungsfall ist die Kennzeichnung von Bereichen in einem Unternehmen mit mehreren Standorten. So würde jedes iBeacon des Unternehmens mit der gleichen UUID initialisiert werden. Jeder Standort erhält einen entsprechenden Major-Wert und ein eine Abteilung an einem Standort einen Minor-Wert. Unternehmen X verwendet also die UUID „B9407F30-F5F8-466E-AFF9-25556B57FE6D“ und Standort A und B jeweils die Major-Werte  „1“ bzw. „2“. Die Abteilung „I“ und „J“ werden jeweils mit den Minor „1“ und „2“ verknüpft. So ist nun Abteilung I an Standort B des Unternehmens X mit den entsprechenden Werten(UUID: „B9407F30-F5F8-466E-AFF9-25556B57FE6D“, Major: „2“, Minor: „1“) eindeutig identifizierbar. Die Distanz zu einem iBeacon lässt sich aus den Werten RSSI und measuredPower berechnen

Monitoring, Ranging und Region

Die Begriffe Monitoring und Ranging beschreiben die zwei Kommunikationsweisen zwischen iBeacons und Empfangsgeräten. Eine Region ist ein Bereich, der sich durch festgelegte Werte (UUID, Major und Minor) definiert. Eine Region umfasst je nach Initialisierung ein bis beliebig viele iBeacons.

Beim Monitoring wird überprüft, ob ein bestimmter Bereich (Region) betreten oder verlassen wurde. Hierbei wird in zeitlichen Abständen getrackt, ob bzw. ob keine iBeacons einer Region empfangen werden; dementsprechend können Programmabschnitte aufgerufen werden. Monitoring ist speziell für Hintergrundprozesse geeignet, da nur beim Eintreten der zuvor erwähnten Ereignisse ein Aufruf entsprechender Methoden erfolgt.

Im Gegensatz zum Monitoring handelt es sich beim Ranging um einen kontinuierlichen Aufruf von entsprechenden Methoden, da dauerhaft eine Aktualisierung der empfangenen iBeacons erfolgt. Ranging eignet sich daher für Vordergrundprozesse, in denen eine Aktualisierung der entsprechenden Daten (z.B. Distanz zum iBeacon) erforderlich ist.

Verwendung unter Android

Wie zu Beginn dieses Beitrags erwähnt, müssen bei für Android-Anwendung die SDKs der jeweiligen Hersteller verwendet werden, z.B. das von Estimote. Alternativ dazu wird mit dem OpenSource-Projekt AltBeacon ein entsprechendes SDK zur allgemein gültigen Nutzung bereitgestellt, das weiter unten ebenfalls betrachtet wird.

Estimote

Eine Beispielanwendung, die Monitoring und Ranging verwendet, ist im Folgenden dokumentiert.

Zunächst muss die estimote-sdk-preview.jar in das /libs Verzeichniss des Projekts kopiert werden. Im build.gradle File muss nun folgende Abhängigkeit hinzugefügt werden:

 dependencies {
   compile files('libs/estimote-sdk-preview.jar')
 }

Folgende Zeilen müssen im Manifest (AndroidManifest.xml) ergänzt werden:

<uses-permission android:name="android.permission.BLUETOOTH" />
<uses-permission android:name="android.permission.BLUETOOTH_ADMIN" />

Anschließend muss der Service in der selben Datei deklariert werden. Dies geschieht innerhalb des Application Tags.

<service android:name="com.estimote.sdk.service.BeaconService" android:exported="false" />

Nun wird eine neue Activity erstellt und eine neue Region erzeugt, die alle Estimote-iBeacons umfasst. Außerdem wird ein BeaconManager erzeugt:

private static final String ESTIMOTE_PROXIMITY_UUID = "B9407F30-F5F8-466E-AFF9-25556B57FE6D";
private static final Region ALL_ESTIMOTE_BEACONS = new Region("regionId",ESTIMOTE_PROXIMITY_UUID, null, null);
private BeaconManager beaconManager = new BeaconManager(this);

Als nächstes wird in der onStart()-Methode der BeaconManager mit dem Service verbunden und je nach Bedarf das Ranging bzw. Monitoring gestartet.

@Override
protected void onStart() {
  super.onStart();
  beaconManager.connect(new BeaconManager.ServiceReadyCallback() {
    @Override public void onServiceReady() {
      try {
        beaconManager.startRanging(ALL_ESTIMOTE_BEACONS);
      } catch (RemoteException e) {
      }
    }
  });
}

Nun kann ein entsprechender Listener erzeugt und dem BeaconManager zugewiesen werden:

beaconManager.setRangingListener(new BeaconManager.RangingListener() {
  @Override public void onBeaconsDiscovered(Region region, List<Beacon> beacons) {
    System.out.println(beacons);
  }
});

AltBeacon

Radius-Networks stellt mit AltBeacon eine gut dokumentierte Open-Source Lösung zu Apples iBeacons zur Verfügung. Standardmäßig erkennt die Bibliothek nur iBeacons, die nach dem AltBeacon Standard spezifiziert sind. Zur Interaktion mit z.B. iBeacons von Estimote oder anderer Hersteller muss der enthaltene BeaconParser ² verwendet werden. Beispiele zur Verwendung der Bibliothek können auf der entsprechenden GitHub-Seite eingesehen werden.

Vergleich der Frameworks

Die Konfiguration des Estimote-SDK ³ ist im Gegensatz zur Alternative AltBeacon einfacher, jedoch nur auf die entsprechenden iBeacons ausgelegt, sodass für den Einsatz anderer Hardware zusätzliche Bibliotheken eingebunden werden müssen. Zudem fehlen Methoden zur Entfernungsbestimmung, sodass die Berechnung selbst durchgeführt werden muss.

AltBeacon zeichnet sich durch seine Flexibilität und guten Dokumentation aus, jedoch muss zunächst der entsprechende BeaconParser erzeugt werden (siehe oben).

Probleme der Technologie

Die RSSI-Werte variieren sehr stark. Zum einen wird das empfangene Signal durch die Haltung des Device (Tablet, Smartphone) beeinträchtigt und zum anderen ist die Position des jeweiligen iBeacons entscheidend. Positioniert man dieses beispielsweise zwischen Regalen, so leidet das Signal je nach Position des Empfängers.

Aufgrund der Ungenauigkeit des Signals, sollten mehrere iBeacons möglichst mit größerem Abstand eingesetzt werden, um mögliche Störungen oder Überscheidungen der Signale zu vermeiden.

Fazit

Die Verwendung von iBeacons unter Android ist mit den entsprechenden Frameworks, die von den Herstellern bereitgestellt werden, mit geringem Aufwand möglich. Jedoch umfasst der Funktionsumfang der SDKs, die in diesem Beispiel zum Einsatz gekommen sind, nicht den der iOS-Bibliotheken.

Die Technologie könnte beispielsweise für die Kennzeichnung von bestimmten Bereichen in Gebäuden verwendet werden, sofern die iBeacons bzw. die Bereiche einen ausreichenden Abstand zu einander haben. Eine zufriedenstellende Indoor-Navigation ist jedoch nur schwer umsetzbar, da die Signale bisher zu störanfällig sind.

Dieser Artikel stellt den Auftakt einer Serie weiterer Berichte zu „ersten Schritten“ mit aktuell verfügbaren Multitouch-Entwicklungsumgebungen dar. Innerhalb dieser Serie liefert der vorliegene Bericht einen Überblick über die Entwicklung von Multitouch-Anwendungen mit Multitouch for Java (MT4j). Das Framework bietet umfangreiche Funktionalität für das Arbeiten mit Multitouch-Hardware und einfach adaptierbare Konzepte zur Entwicklung eigener Anwendungen. Im Folgenden wird nach einer kurzen Einführung die Einrichtung mit Eclipse erläutert, einige Beispielanwendungen vorgestellt sowie ein Minimal-Beispiel implementiert.

Einführung

• Java-Framework zur Entwicklung von Multitouch-Anwendungen
• Verwendung verschiedener Komponenten (Bilder, Videos, 3D-Objekte)
• Anbindung unterschiedlicher Hardware und Protokolle
• 10 vorhandene Multitouch-Gesten sowie Möglichkeit zur Erstellung von eigenen Gesten
• Performante Darstellung durch OpenGL

Demo

Um vor der Vorstellung der technischen Details einen ersten Eindruck zu schaffen, demonstriert das folgende Beispielvideo die Funktionalität der mitgelieferten Kartenapplikation:

Historie

Das MT4j-Framework wird vom Fraunhofer-Institut für Arbeitswirtschaft und Organisation (IAO) entwickelt und basiert (wie der Name schon sagt) auf der weit verbreiteten objektorientierten Programmiersprache Java. Im Herbst 2009 wurde das Framework unter Open Source-Lizenz veröffentlicht und wird seitdem durch die OpenSource-Gemeinde weiterentwickelt. Die Multitouch-Plattform übernimmt alle benötigten Aufgaben, wie beispielsweise die Erkennung von Multitouch-Gesten, deren Umsetzung in Events sowie die erforderliche Grafikausgabe. Es bietet eine umfangreiche Bibliothek mit vorgefertigten Grafiken, Gesten und Schriften und ist sehr generisch implementiert, sodass eigene Gesten und Grafiken problemlos hinzugefügt werden können. Das Framework ist prinzipiell kompatibel zu allen Multitouch Geräten, da es die Inputs der Hardware abstrahiert.  Als Grundlage hierfür wird die Anbindung an verschiedene APIs (z.B. TUIO) bereitgestellt, welche die Eingaben des Touchscreens interpretieren. Die Darstellung erfolgt über die Grafikschnittstelle OpenGL, sodass die Anwendungen auf entsprechender Hardware sehr performant sind.

Komponenten und Aufbau

Die nachfolgende Tabelle gibt einen Überblick über die technischen Eigenschaften sowie bereitgestellten Gesten und Komponenten des Frameworks:

Installation

Das MT4j Framework steht als quelloffener Download, derzeit in Version 0.95 zur Verfügung und ist bereits als ein Eclipse-Projekt strukturiert.

MT4j läuft derzeit nur mit der 32bit-Variante von Java. Soll ein 64bit System eingesetzt werden, muss trotzdem der 32bit JDK installiert werden. Unter Eclipse muss entsprechend die 32bit Variante von Java zum Ausführen der MT4j Anwendungen ausgewählt werden!

1. Java Development Kit 32bit (gekennzeichnet als x86) herunterladen und installieren
2. Die heruntergeladene ZIP-Datei entpacken (MT4j 0.95 full release)
3. Im Paketexplorer von Eclipse mit Rechtsklick importieren wählen
4. In dem Importfenster ein „bereits existierendes Projekt“ auswählen
5. Den unter 2. entpackten Ordner auswählen und importieren

Import Schritt 2

Import Schritt 3

Import Schritt 1

Eclispe mit MT4j

Mitgelieferte Beispiele

Das MT4j-Paket enthält 19 einfache Beispielanwendungen. Diese sind unterteilt in die Pakete „basic“ und „advanced“ und sind im Ordner „examples“ zu finden. Die Basic Examples dienen zum Verstehen und Testen der grundlegenden Techniken in sehr einfach gehaltenen Applikationen. Die Advanced Examples demonstrieren die Leistungsfähigkeit des Frameworks, indem beispielsweise 3D Modelle verwendet werden. Jede Anwendung befindet sich in einem eigenen Paket. Es ist keine weitere Konfiguration erforderlich, da das Framework alle benötigte Komponenten automatisch sucht und auswählt. Zum Starten ist jeweils eine „Start…Example.java“ Datei hinterlegt, die als „Java Application“ in Eclipse ausgeführt werden kann. Nach dem Start öffnet sich ein neues Fenster innerhalb dessen die Multitouch-Interaktion möglich ist.

Basic-Anwendungen

css

helloworld

javagui

mtgestures

scenes

svgexample

Advanced-Anwendungen

drawing

flickrmt

fluidsimulator

models3d

modestmapsmt

mtShell

physics

puzzle

simpleparticles

space3d

touchtail

water

Minimalimplementierung

Eine Multitouch-Anwendung mit MT4j zu schreiben ist denkbar einfach, da sie nur zwei Klassen (Scene und MTApplication) benötigt. Die folgenden beiden Abschnitte geben einen Überblick über die Implementierung eine einfachen Applikation zur Bildmanipulation. Die Anwendung, die zum Selbsttest ebenfalls als Download verfügbar ist, ermöglicht es, ein Bild anzuzeigen und dieses mit Standard-Multitouch-Gesten zu manipulieren.

Scene

Eine „Scene als erste benötigte Bestandteil der Anwendung muss die abstrakte Klasse „AbstractScene“ erweitern. In dieser Klasse wird festgelegt, welche Komponenten angezeigt werden. Es gibt viele vorgefertigte Elemente, die insbesondere Standard-Multitouch-Gesten bereits beherrschen. Hierzu gehören beispielsweise Grafiken, Textfelder und Rahmen für verschiedene andere Objekte. Für unser Minimalbeispiel benötigen wir folgenden Code für die Scene-Klasse:

package MinimalExample;

import org.mt4j.MTApplication;
import org.mt4j.components.TransformSpace;
import org.mt4j.components.visibleComponents.widgets.MTImage;
import org.mt4j.input.gestureAction.InertiaDragAction;
import org.mt4j.input.inputProcessors.componentProcessors.dragProcessor.DragProcessor;
import org.mt4j.sceneManagement.AbstractScene;
import org.mt4j.util.math.Vector3D;

import processing.core.PImage;

public class PictureScene extends AbstractScene
{
  private String picturePath =  "MinimalExample" + MTApplication.separator + "data" + MTApplication.separator;

  public PictureScene (MTApplication mtApplication, String name)
  {
    super(mtApplication, name);

    MTApplication app = mtApplication;
    PImage img = app.loadImage(picturePath + "pic.jpg");
    MTImage image = new MTImage(img,app);
    image.setUseDirectGL(true);
    image.setPositionGlobal(new Vector3D(400,400,0));
    image.scale(0.2f, 0.2f, 0.2f, image.getCenterPointLocal(), TransformSpace.LOCAL);
    image.addGestureListener(DragProcessor.class, new InertiaDragAction());
    this.getCanvas().addChild(image);
  }

  @Override
  public void init() {}

  @Override
  public void shutDown() {}
}

Datei ist zu beachten, dass sich das entsprechende Bild im Paket „MinimalExample.data“ (gekennzeichnet als „picturePath“) befinden muss, damit es geladen werden kann!

MTApplication

Die „Application“-Klasse dient zum Starten der Anwendung und muss die abstrakte Klasse „MTApplication“ erweitern. Die vorher beschriebene Scene wird lediglich hinzugefügt. Anschließend wird die Anwendung mit dem Methodenaufruf „initialize()“ gestartet. Dazu sind lediglich die Folgenden Codezeilen erforderlich:

package MinimalExample;

import org.mt4j.MTApplication;

public class StartMinimalExample extends MTApplication
{
  private static final long serialVersionUID = 1L;

  public static void main(String args[])
  {
    initialize();
  }

  @Override
  public void startUp()
  {
    this.addScene(new PictureScene(this, "Picture scene"));
  }
}

Das CommuntiyMashup ist eine Integrationslösung für Daten aus sozialen Diensten. Es vereinheitlicht und verbindet Daten aus den unterschiedlichsten Quellen. Hierbei steht im Sinne des „Social Web“ die Person im Vordergrund. Eine definierte Schnittstelle mit vorgefertigen Anwendungskompenten lässt eine einfache Verwendung der Daten in verschiedensten Anwendungsszenarien zu. Diese Seite gibt einen Überblick über die dem CommunityMashup zugrundeliegenden Konzepte und vermittelt einen Einblick in seine vielfältigen Verwendungsmöglichkeiten.

Ausgangssituation

Mit dem Erfolg von Web 2.0 im privaten und Enterprise 2.0 im unternehmensweiten Bereich veränderte sich die Art und Weise wie Informationen strukturiert und kosumiert werden.

Social Networking

Auswirkungen des Erfolg von Social Software

Im Zuge des immer verbreiteteren Einsatzes von Social Software auch im Unternehmenskontext vollzieht sich eine Entwicklung von einer datenzentrischen Systemsicht hin zu einer personzentrischen Perspektive. Soziale Netzwerke wie Facebook oder Microblogging Dienste wie Twitter sind nur zwei Arten von Diensten die Einzug in unser tägliches Leben gefunden haben. Insgesamt lässt sich beoachten, dass fast jeder Nutzer inzwischen mehr als einen Dienst benutzt, sei es wegen spezieller Funktionalitäten, den Personen die über den jeweiligen Dienst erreichbar sind oder schlichtweg um private und berufliche Nutzung zu trennen. So sind wir unter anderem gezwungen den richtigen Kanal zu wählen um Informationen zu konsumieren bzw. zu verteilen. Dies nährt den Wunsch nach einer Integrationslösung, die unsere Daten aus unterschiedlichen Diensten vereint ohne dabei ein neues zentralisiertes System zu schaffen. Insbesondere muss uns die Wahl der Dienste und die Art und Weise, wie wir diese nutzen wollen offen bleiben.

Mobile und ubiquitäre Nutzung

Eine weitere Veränderung der letzten Jahre lässt sich in der Nutzung verschiedenster Geräte, mit denen wir Informationen konsumieren, festhalten. Sei es mit dem Tablet zuhause im Wohnzimmer, unterwegs per Smartphone oder klassisch im Büro mit dem Desktoprechner. Hinzukommen ubiquitäre Systeme wie interaktive Wandbildschirme, welche die letzten Lücken unserer Informationsversorgung schließen. Eine zukunftsfähige Integrationslösung muss daher dem Nutzer die Möglichkeiten der freien Geräte- und Plattformwahl offen lassen.

Nutzerzentrische Aggregation verschiedener Quellen

Der Grundgedanke des Web 2.0 beinhaltet die starke Einbeziehung aller Nutzer bei der Erstellung von Inhalten und die Möglichkeit diese mit anderen Personen zu teilen. Mit der Integration von Daten aus uterschiedlichen Diensten entsteht der Wunsch diese untereinander mit zusätzlichen Informationen zu Verknüpfen und diese wiederum mit anderen zu teilen. Hierin liegt auch ein Kritikpunkt an aktuellen Integrationssystemen, die meist nur aus einer Single-User Perspektive getrieben sind. Beispielsweise ist die Verteilung der Information innerhalb einer Gruppe, wer welche Artikel zu einem gemeinsamen Interessensgebiet gelesen hat, aus dieser Perspektive unmöglich. Wobei die Artikel natürlich aus verschiedensten Quellen stammen können. Zusammen mit der personenzentrischen Sicht auf Daten, der Vielzahl verschiedenster genutzer Dienste und der Verwendung unterschiedlichster Geräte führt dies zum Wunsch einer neuen Integrationslösung für die wir im folgenden die Konzepte und Lösungsansätze vorstellen.

Grundidee

Das CommunityMashup verbindet die Inhalte aus verschiedensten sozialen Diensten. Dazu zählen beispielsweise Soziale Netzwerke wie facebook, Microblogging Dienste wie twitter oder Bild-Dienste wie flickr, aber auch spezielere wie beispielsweise der Referenzmanagement-Dienst Mendeley für wissenschaftliche Veröffentlichungen. Die Daten aus diesen Diensten werden über die Schnittstellen der Services abgerufen und über spezielle Adapter vereinheitlicht, so dass sie miteinander vermischt und verbunden werden können („mashup“). Die vereinheitlichten Daten werden anschließen wieder über spezielle Schnittstellen bereitgestellt. Hierbei wird auf unterschiedliche Anwendungsszenarien und deren spezielle Anforderung eingegangen, die insbesondere durch verschiedene Geräte und Plattformen beeinflusst sind. Wir unterscheiden ganz allgemein zwischen Web-Anwendungen, Desktop-Anwendungen und Anwendungen für mobile Geräte. Die folgende Grafik visualisiert diese Zusammenhänge noch einmal grafisch. Hierbei ist vorallem zu beachten, dass Daten nicht nur von den angebunden Diensten zu den Endbenutzer Anwendungen fließen, sondern auch in umgekehrter Richtung.

Grundidee des CommunityMashup

Model Driven Approach

Ausgehend von der Grundidee einer Integrationslösung für soziale Dienste, die Daten vereinheitlicht und über spezielle Schnittstellen wieder bereitstellt, stellt sich die Frage nach dem passenden Entwicklungsansatz. Erfahrungen haben gezeigt, dass Internetdienste sowie ihre ggf. vorhandenen Schnittstellen einer permanenten Änderung und Weiterentwicklung unterworfen sind. Dienste kommen und gehen bzw. sind populären oder unpopulärer ebenso verhält es sich mit ihren Funktionen und Schnittstellen. Um flexibel auf diesen kontinuierlichen Wandel reagieren zu können und dabei eine stetige Evolution der Integrationslösung zu ermöglichen, schlagen wir einen modellgetriebenen Ansatz vor. Dieser basiert auf einem dafür konzipierten personenzentrischen Datenmodell, das die Zusammenhänge in sozialen Diensten wiedergibt. Dieses Datenmodell und die darauf aufbauenden Anwendungskomponenten stellen wir im weiteren Verlauf näher vor.

Datenmodell

Untenstehende Abbildung zeigt die Kernelemente des personenzentrischen CommunityMashup-Datenmodells. Es enthält die drei Kernelmente Person, Organisation und Inhalt (Content). Organisationen wie auch Inhalte können hierarchisch strukturiert werden. Inhalte werden über eine Autor-Beziehung mit Personen verknüpft, diese wiederum können über Organisationen gruppiert werden. Personen-Objekte spiegeln jeweils reale Menschen wieder, d. h. für eine Person wird nicht ein eigenes Element für je benutzten Dienst erzeugt werden, vielmehr bilden alle verteilten Profile zusammen eine digitale Identität ab. Das Selbe gilt auch für die Profile von Organisationen. Jeder weitere Dienst trägt seine zusätzlichen Profilinformationen über Erweiterungs-Objekte (Extensions) bei. So bleibt auch der Bezug zur ursprünglichen Quelle erhalten.

Kernelemente des CommunityMashup Datenmodells

Ein Kernkonzept des Datenmodells ist die bewusst offene Verwendung von Tags für Metainformationen, um ein Minimum von zusätzlichen Attributen für die einzelnen Daten-Objekte fix speichern zu müssen. Beispielsweise erhält eine Person nicht mehr zwei Attribute für die private und die berufliche E-Mail-Adresse, sondern Referenzen zu zwei E-Mail Objekten getaggt mit privat bzw. beruflich. Ein E-Mail Objekt lässt sich dann beispielsweise noch facebook taggen um so deren Verwendung auszuzeichnen. Dieses Verfahren wird auf alle Objekte des Datenmodells angewandt und erlaubt sehr flexible Such- und Filtermethoden und ermöglicht dadurch letztlich eine nutzungsoffene Verwendung der Integrationslösung.

Anwendungskomponenten

Mit der aus dem Datenmodell hervorgehend Abbildungsvorschrift, die es erlaubt Daten aus sozialen Diensten zu vereinheitlichen und miteinander zu verbinden, stellt sich die Frage, welche Teile einer konkreten Anwendung direkt vom vorliegenden Datenmodell abängen und somit ebenfalls automatisch aus dem Modell generiert werden können. Um eine nachhaltige und erweiterbare Lösung zu ermöglichen, ist es quasi ein Muss, dass alle diese direkt ableitbaren Teile automatisch bzw. zumindest semi-automatisch generiert werden. Die folgende Grafik gibt einen Überblick über die für das CommunityMashup relevanten, automatisch generierbaren Anwendungskomponenten:

Modell-Getriebene-Entwicklung

Viele UML-Werkzeuge unterstützen mittlerweile die automatische Erzeugung einer (Java) Schnittstelle mit zugehörigen leeren Klassen und Methoden. Für eine durchgängige Lösung wird allerdings ausführbare Code mit einer Laufzeitumgebung (RunTime) benötigt. Diese kümmert sich beispielsweise um die Erzeugung von Objekten bzw. um die Bereitstellung von Methoden zur Manipulation solcher Instanzen. Ein zusätzlicher Event-Mechanismus erlaubt das Verfolgen dieser Änderungen. Eine weitere wichtige Anwendungskomponente stellt die Persistierung dar. Diese wird beispielsweise für Caching benötigt. Für die Persistierung von Daten ist eine Serialisierung und Deserialisierung der Objekte notwendig. Diese wird ebenfalls für den Datenaustaustausch über Web-Schnittstellen im XML-Format benötigt. Im Rahmen des CommunityMashup-Projektes wird aktuell eine durchgängige Werkzeugkette aufgebaut, die die automatische Erstellung dieser Komponenten ermöglicht. Wir wenden den gleichen modellgetrieben Ansatz auch auf ein Meta-Modell an, das die möglichen Konfigurationen des CommunityMashup beschreibt. Hierfür werden viele identische Komponenten benötigt, allerdings jeweils bezogen auf ein anderes Modell. Die Verwendung des Meta-Modells erlaubt es, Konfigurationen speichern und laden zu lassen (Persitierung) und beispielsweise aus Gründen der Fernwartung auch über eine Web-Schnittstelle abfragen und verändern zu lassen.

Service-Orientierte-Architektur

Alleine durch die oben beschrieben, aus einem Modell erzeugbaren Komponenten lässt sich noch keine gesamte Integrationslösung erstellen. Ziel des CommunityMashups ist nicht nur ein flexibles Entwicklungskonzept das durch den modellgetriebenen Ansatz erreicht wird, sondern auch eine flexible Systemarchitektur die aufgrund von Anforderungen wie Skalierbarkeit, Performance und Ausfallsicherheit eine Verteilung von Systemkomponenten zulässt. Diese Service-Orientierte-Architektur, muss sich dadurch auszeichnen, dass definierte Systemkomponenten als eigenständige Services mit definierten Schnittstellen realisiert werden. So lassen sich selbst zur Laufzeit einzelne Komponenten aktualisieren bzw. austauschen ohne die Verfügbarkeit des Gesamtsystems zu beeinflussen. Nachfolgende Abbildung zeigt ein exemplarisches verteiltes Szenario mit Client- und Server Komponenten.

Verteilte Umgebung

Die Verbindung der Daten aus den eizelnen Quelldiensten (Source 1 bis Source n) wird auf einem Server durchgeführt und durch eine Konfiguration gesteuert. Jede dieser Quellkomponenten wird als eigener Service realisiert, der sich sich einzeln aktualiseren lässt, beispielsweise um auf die Änderung einer entfernten Schnittstelle zu reagieren.Java Intern überführen die dargestellten Quellkomponenten Daten der externen Dienste in das dem personenzentrische CommunityMashup-Datenmodell und tragen diese hierdurch sukzessive zu einem gemeinsamen Datensatz zusammen. Die zentrale CommunityMashup-Komponente stellt diesen Datensatz (ggf. je nach Bedarf gefiltert) wieder über eine Java Schnittstelle bereit. Darauf aufbauend lässt sich eine REST Schnittstelle hinzufügen, die die aggregierten und gefilterten Daten (zugriffsbeschränkt) über das Web verfügbar macht. Spezielle Anwendungskomponenten lassen nun eine Verwendung der Daten auf Client-Seite über eine identische Java API zu. Die je nach Client-Typ (im oben abgebildeten Beispiel eine klassische Desktop Anwendung in Kombination mit einem Android Mobile Device) speziell ausgeprägten Anwendungskomponenten kümmern sich im Hintergrund transparent um den Datenaustausch und verlagern je nach Client rechenintensive Aufgaben auf den Server.

Das CommunityMashup stellt Anwendungen eine auf Web2.0-Inhalte spezialisierte und auf einem personenzentrischen Datenmodell basierende Datenbasis zur Verfügung. Um Anwendern/Entwicklern generische Zugriffsmöglichkeiten auf diese Datenbasis zu ermöglichen, wurde im Rahmen einer Masterarbeit eine REST-Schnittstelle für das CommunityMashup entwickelt, die nachfolgend kurz vorgestellt wird

Problemstellung

Zu Beginn der Entwicklung des CommunityMashups wurde der Zugriff auf die Daten des Frameworks lediglich über eine Java-Schnittstelle ermöglicht, d.h. eine es nutzende Anwendung musste in Java implementiert sein und auf der gleichen Maschine wie das CommunityMashup laufen.Eine auf verschiedene Geräte oder Architekturen verteilte Nutzung wurde somit starkt erschwert (vgl. Abbildung links).

Aufbau des CommunityMashups

Verwendung der REST-Schnittstelle

Um diesem Problem zu begegnen, wurde das CommunityMashup im Rahmen einer Masterarbeit um eine REST-Schnittstelle erweitert. Mit Hilfe dieser Schnittstelle können verschiedenste Arten von Anwendungen (z.B. normale Anwendungen, Smartphone-Apps oder Widgets) auf unterschiedlichen Geräten auf die Daten eines oder mehrerer CommunityMashups zugreifen und diese verwenden sowie manipulieren (vgl. Abbildung rechts).

Verwendung der Schnittstelle

Die Schnittstelle kann prinzipiell von jeder Anwendung verwendet werden, die entsprechend der Schnittstellen-Dokumentation erstellt/konfiguriert wurde:

Aufbau des erweiterten CommunityMashups

Da die Kommunikation mit der REST-Schnittstelle über das HTTP-Protokoll und damit potentiell dem gesamten Internet geschehen kann, ist die Anwendungsentwicklung sowohl was den Ort als auch die Architektur des Zielsystems betrifft vom CommunityMashup unabhängig.

Die REST-Schnittstelle wird vom CommunityMashup in Form eines Java-Servlets bereitgestellt, welches ebenfalls die Dokumentation der Schnittstelle enthält.

Beide können über die URL des CommunityMashup-REST-Services erreicht werden, der eine selbsterklärende Beschreibung der angebotenen Dienste bereithält. Unter anderem kann die Syntax der REST-Anfragen nachgeschlagen werden und die Anfragen können im Browser getestet werden, was bei der Entwicklung kompatibler Anwendungen hilft.

Webeinstieg der REST-Schnittstelle

Dokumentation der Schnittstelle

Technische Umsetzung

Um die REST-Schnittstelle mit der modellgetriebenen Entwicklung des CommunityMashups ¹ im Einklang zu halten, werden die dynamischen (vom Datenmodell des CommunityMashups anhängigen) Methoden und Funktionen mit Hilfe angepasster JET-Templates automatisch aus dem Modell generiert, was eine spätere manuelle Anpassung der Schnittstelle an Änderungen des CommunityMashups überflüssig macht:

Die Verwendung von JET-Templates

Um den unauthorisierten Zugriff auf das CommunityMashup einzuschränken, wurde ein Sicherheitssystem entwickelt, das nur registrierten Anwendungen den Zugriff auf die Daten und Funktionen des CommunityMashups gestattet. Die Absicherung der REST-Anfragen geschieht durch eine Signatur, welche die Anfrage vor einer Manipulation schützt und den Absender der Anfrage eindeutig identifiziert.

Sicherheitssystem der Schnittstelle

Die Sicherheit der Daten des CommunityMashups wird durch die Verwendung sogenannter Message Authentication Codes (MAC) sichergestellt, welche auch bei anderen (REST)-Schnittstellen namhafter Online-Dienstanbieter wie Amazon, GoogleMaps oder Flickr verwendet wird. Dabeiwird neben der eigentlichen Anfrage der Hashcode der Anfrage und eines geheimen Schlüssels übermittelt, wodurch zum einen die Integrität der Nachricht und zum anderen die Identität des Absenders sichergestellt sind.

REST-Zugriff

Die folgenden Prozessdiagramme liefern einen kurzen Überblick über die Zugriffsmöglichkeiten auf das CommunityMashup über die REST-Schnittstelle, darunter auch über den Ablauf einer gesicherten REST-Anfrage:

Zugriff über die REST-Schnittstelle

Gesicherter Zugriff über die REST-Schnittstelle

Gesicherter Zugriff über die REST-Schnittstelle

Unauthorisierter Zugriff auf die REST-Schnittstelle

In diesem Howto wird gezeigt wie Interaktionskomponenten für Touchscreen Systeme mit Adobe Illustrator erstellt werden können, um diese mittels JavaFX interaktiv in einer GUI einzubinden. Dies geschieht exemplarisch anhand des in einer Bachelorarbeit entwickelten GUI-Entwurfs für ein Fussgänger-Navigationssystems der UnibwM.

Wichtige Elemente für die GUI eines Touchscreen Systems sind neben Buttons v.a. Elemente zur Auswahl von Listenelementen und Einstellungen. Aus diesem Grund zeigt das vorliegende Howto neben Buttons auch das Erstellen von Dropdown-Elementen und Layern für Texte. Dabei ist der grundlegen Aufbau dieser Elemete gleich, nur im Aussehen unterscheiden sie sich.

Zunächst betrachten wir einen Screenshot der GUI des oben verlinkten Navigationssystems.

Fussgängernavigation Startscreen ¹

Grundsätzlich muss zwischen zwei Arten von Elementen unterschieden werden, zum Einen die, die zur Laufzeit erst erstellt werden und zum Andern die Elemente, die aus bestehenden Dateien gelanden werden. In dieser GUI sind die grauen Elemente des Hintergrunds sowie alle Button-Texte durch den Programmcode erzeugt. Bei den Hintergrundelementen geschieht dies, da sie sehr simple sind und so variabel an die Fenstergröße anpasst werden können. Die Texte werden durch den Namen der Buttons bestimmt und sind daher durch den Programmcode realisiert.

Erstellen von Hintergrundelementen einer Gui

Zunächst werfen wir einen Blick auf die einfachen Element, die nicht interaktiv verwendet werden, und ihre Realisierung in JavaFX.

GUI - Hintergrund ¹

Die Hintergrundfläche wird durch ein einfaches graues Rechteck realisiert. Dabei muss jedes Element das in der GUI angezeigt wird einem „content“ zugeordnet werden. Was es damit genau auf sich hat wird später genauer erklärt.

var rect = Rectangle {
	x: 0  y: 0
	width: FWIDTH  height: FHRaster*(1+4*BLayer)
	fill: Color.LIGHTGRAY
}
insert rect into gui.content;

Linien oder Texte können einer Oberfläche direkt oder einem anderen Objekt zugeordnet werden.

var ddbHline = Line {
	startX: 0  startY: FHRaster*(1+3+4*BLayer)
	endX: FWIDTH  endY: FHRaster*(1+3+4*BLayer)
}
insert ddbHline into ddbFrame.content;

var text = Text {
	font: Font { size: 16 *rate }
	content: BTitle[type]
}
insert text into buttons.content;

Komplexere Elemente können mithilfe der von Sun bzw. inzwischen Oracle bereitgestellten JavaFX Production Suit in Adobe Illustrator erstellt werden und nach dem Exportieren als „FXZ-Datei“ eingebunden werden ². Im Beispiel der GUI des Fussgänger- Navigationssystems wurden die Buttons zur Auswahl der Navigation sowie zur Steuerung der Karte in AI erstellt. Wie diese nach dem Export in das Programm eingebunden werden, beschriebt der letzte Abschnitt dieses Howtos. Zunächst wird jedoch erklärt, wie solche Elemente in AI erzeugt werden.

Erstellung der Buttons für das Fussgängernavigationssystem

Zunächst wurde ein erster Entwurf der erforderlichen grafischen Elemente von einer Designerin anhand von GUI Mock-Ups erstellt. Diese Elemente wurden anschließend weiter bearbeitet und an die Vorstellungen der grafischen Oberfläche angepasst.

Normale Buttons

Die Abbildung zeigt den Button aus dem Mock-Up links, sowie den von der Grafikerin erstellten Button, mit zwei unterschiedlichen Zuständen (Mitte). Rechts befinden sich die Zustände, nachdem sie an das vorgegebene Farbschema angepasst wurden.

Umsetzung der Mock- Ups ¹

Die Buttons besitzen eine Grundfläche und entsprechende Layer. Durch einen mehrfarbigen Hintergrund und weitere Effekte können verschiedene Abstufungen geschafft werden. Hierzu muss es einen Layer geben, in dem Texte oder Symbole eingefügt werden können. Die nachfolgende Abbildung zeigt eine sinnvolle Anordnung der Layer und ihre Bezeichnung, um sie in der GUI zu verwenden.

Aufbau der Button-Ebenen ³

Die Buttons benötigen sinnvollerweise aussagekräftigen Icons, um ihrer Funktionalität zu beschreiben. Die meisten der hier verwendeten Icons stammen von der Internetseite „The Noun Projekt“. Diese Seite sammelt spezielle Symbole, auch Piktogramme genannt, die auf der ganzen Welt einheitlich verwendet werden, um einen bestimmten Zweck auszudrücken. Bei dem sehr hilfreichen Projekt geht es im Prinzip darum, eine visuelle Sprache zu erzeugen, die es ermöglicht, jkulturunabhängig ausschließlich anhand der verwendeten Symbole zu kommunizieren.

Verwendete Piktogramme ⁴

Die Problematik einer nicht fest definierten Sprache ist jedoch, dass man sie schnell missverstehen kann. Die verwendeten Icons müssen daher gut überlegt sein. Im Falle der zu Grunde liegenden Bachelor Arbeit wurden zu jeder Aktion mehrere unterschiedliche Buttons erstellt, die dann durch eine kurze Benutzerstudie bewertet wurden. Fall keines der Standard-Icons ausreichend gut wiedererkannt wird, kann es durchaus notwendig sein, eigne Icons zu entwickeln. Dies geschah im vorliegenden Fall beispielsweise für den Button „militärisch“ der Navigationssoftware, da die Seite „The Noun Projekt“ keine sinnvollen Möglichkeiten bat. Die folgende Abbildung zeigt einige der erstellten Icons.

Button Icons ¹

Dropdown Listen

Für die GUI des Navigationssystem wurde eine eigene Dropdown Box entwickelt. Das Konzept der Dropdown Boxen ist in den folgenden Abbildungen gezeigt. Die Form und Anordnung der Elemente ist an die der Navigationsführung der Cityterminals 2.0 angelehnt. Die linke Abbildung zeigt die Umsetzung auf einem Cityterminal. In der rechten Abbildung ist das entwickelte Mock-Up-Konzept und die grafisch verfeinerte Realisierung zu sehen.

Dropdown Elemente ¹

Institution auswählen (1) ¹

Institution auswählen (2) ¹

Institution auswählen (3) ¹

Institution auswählen (4) ¹

Navigationsfuhrung Cityterminal ¹

Alle Dropdown Elemente sind im Grunde aufgebaut wie ein normaler Button. Durch die verschiedenen Formen ist es möglich die Zustände, wie geschlossene oder geöffnete Boxen, voneinander abzuheben. Wie bereits beim Button, kann als Inhalt hier genauso zwischen Text oder Symbolen gewählt werden.

Leiste zum Zoomen

Zoom Leiste ¹

Die in der Abbildung gezeigte Leiste zum Zoomen der Lagekarte funktioniert über zwei Buttons sowie den Schiebregler in der Mitte. Derartige Elemente sind mit JavaFX natürlich individuell erstellbar und können der GUI eine Vielzahl neuer Funktionen geben.

Sowohl die Textfelder als auch die Leiste wurden an Farben und Formen des vorgegebenen Designs angepasst und fügen sich somit gut in das Gesamtbild. Die einfachen Buttons der GUI haben dabei zwei verschieden abgestufte Orangetöne. Die Textfelder sind grau und können auch durch orange hervorgehoben zu werden (z.B. für einen aktiven Zustand). Alle Elemente dieser Abbildung zusammen erzeugen die GUI der Navigationssoftware. Wie diese in JavaFX eingebunden werden, zeigt der folgende Abschnitt.

Elemente der GUI des Navigationssystems ¹

Einbinden exportierter FXZ-Dateien

Um nach einem Export die Daten verwenden zu können müssen sie in JavaFX geladen werden und entsprechend dem „content“ zugeordnet werden. Das Laden der Elemente wird durch folgendes Codefragment realisiert.

fxdGUI = FXDNode {
	url: "{__DIR__}GUI.fxz"
	backgroundLoading: true
	placeholder: Text { x: 10 y: 10 content: "Loading Gui ..."}
	loader: FXDLoader {
		onDone: function() {
			//Aufruf der Funktion zur Erstellung der GUI
			loadGUI();
		}
	}
};

Das Positionieren in der GUI sowie das endgültige Hinzufügen geschieht durch folgende Ausschnitte aus dem Programmcode:

var button = fxdGUI.getNode(BTitle[type]);
var duplicate = Duplicator.duplicate(button);

//Button wird zuerst an die Koodinate 0,0 gesetzt
duplicate.translateX = -(duplicate.impl_getPivotX()-(duplicate.layoutBounds.width/2)*duplicate.scaleX);
duplicate.translateY = -(duplicate.impl_getPivotY()-(duplicate.layoutBounds.height/2)*duplicate.scaleY);
duplicate.onMouseClicked=buttonpressed;

insert duplicate into buttons.content;
insert text into buttons.content;

Ein wesentlicher Vorteil einer Umsetzung der GUI mit JavaFX und Adobe Illustrator ist die Trennung zwischen Programmierer und Designer. So kann bei guter Programm-Realisierung die GUI vom Designer verändert werden ohne das dabei der Quellcode geändert werden muss. Beispielsweise reicht es, wenn der Designer einen neuen Button erzeugt und ihn nach einem gegeben Muster benennt. Beim nächsten Erneuern der GUI übernimmt der Code den Button einfach und fügt ihn zum „content“ hinzu.

Abschließend noch ein kurzer Einblick in den Aufbau und die Komponenten einer JavaFX Oberfläche. Der gesamte Frame einer Anwendung in JavaFX ist vom Typ „Stage“. Diese ist einzigartig und definiert Aussehen und Eigenschaften des Frames. Weiterhin beinhaltet die „Stage“ genau eine „Scene“, welche sozusagen den Inhalt der Oberfläche bestimmt. Alle Elemente die in der GUI zu sehen sein sollen, müssen entweder direkt in dieser „Scene“ aufgeführt sein oder in einem anderen Element (Container), welches sich in der „Scene“ befindet.

Für jede Klasse, die einen Knotenpunkt darstellt, ist die Variable „content“ die Referenz auf alle Folgeknoten. Somit ist die „Stage“ quasi das Programmfenster und die Scene der Wurzelknoten zu einem Baum, der alle Elemente der GUI beinhaltet. Zur Verdeutlichung dient findet sich unten noch die folgende Grafik der Oracle-Website. Alle starren Elemente der GUI werden dabei dem „content“ der gleichnamigen Variablen hinzugefügt, welche direkt in der Scene auftaucht:

Aufbau JavaFX Frame ⁵

Dieser Artikel beschreibt die wesentlichen Ergebnisse der Bachelorarbeit „Konzeption und Umsetzung eines Touchscreen-basierten Campus-Navigationssystems für die Universität der Bundeswehr München“ von Markus Schran. Ziel der Bachelorarbeit war die Konzeption und prototypische Umsetzung eines stationären Navigationssystems auf einem Outdoor-Kiosk-Terminal. Hierzu wurde zunächst zur Verfügung stehendes Kartenmaterial gesammelt und anwendungsspezifisch bewertet. Anschließend wurde der Besucherverkehr der Universität über mehrerer Tage protokolliert, bevor verschiedene Umsetzungsmöglichkeiten im Bezug auf Programmiersprache und Software Entwicklungstools gegeneinander abgewogen werden konnten. Das Ziel der praktischen Arbeit bestand darin, ein benutzerfreundliches und übersichtliches Programm für das touchscreen-basierte Terminal  zu programmieren. Neben den Grundfunktionen des Programms befasste sich die Arbeit vor allem mit späteren Weiterentwicklungsmöglichkeiten. Nach einer kurzen Einführung in die grundlegende Problematik werden in diesem Artikel die wichtigsten Schritte der Arbeit sowie die erzeugten Artefakte vorgestellt.

Problemstellung

Die Universität der Bundeswehr München ist darum bemüht, für ihre Besucher trotz ihres stetigen strukturellen Wandels eine hervorragende Infrastruktur zu bieten. Für externe Besucher ist die geografische Aufteilung der Universität zum Teil sehr unübersichtlich, da Fakultäten und Verwaltungsstellen auf unterschiedliche Gebäude aufgeteilt oder weit über das Gelände disloziert sind. Ähnlich verhält es sich mit Sportstätten auf dem Universitätsgelände, die von vielen Gästen genutzt werden. Aus diesem Grund wurde im Jahr 2010 an der Universität ein neues Schilder-Leitsystem errichtet, das es Universitätsangehörigen und Besuchern ermöglicht, sich einfacher auf dem Universitätsgelände zu orientieren. Aufgrund seines statischen Charakters schafft es jedoch auch dieses neue Leitsystem nicht, alle Anliegen potenzieller Besucher bestmöglich zu unterstützen. Das Leitsystem kann sich nicht optimal darauf einstellen, ob sich die Gäste mit dem Auto, zu Fuß oder vielleicht mit einem Fahrrad über das Gelände bewegen. Eine weitere Problemantik besteht darin, dass dieses Leitsystem dem Hauptanliegen der Besucher nicht entgegenkommen kann. Die meisten Besucher suchen eine bestimmte Person an der Universität, haben jedoch oft keine weiteren Informationen zum geografischen Aufenthalt der gesuchten Person. Da kein statisches Wegeleitsystem die Vielzahl der Personen an der Universität direkt abbilden kann, musste hierfür eine alternative Lösung gefunden werden.

Zielsetzung

Im Zuge der Installation des Leitsystems wurde auch das im Bild gezeigte Terminal „arctic 32“ der Firma Friendlyway an der Wache aufgestellt.

Terminal und Lageplan ¹

Aus den in der Problemstellung beschriebenen Gründen beschäftigte sich die nachfolgend beschriebene Bachelorarbeit damit, für dieses Terminal eine interaktive aktionsbasierte Ergänzung des statischen Stelenleitsystems zu entwickeln, das die Besucher je nach individuellen Präferenzen und Zielwünschen optimal bei ihrer Navigation auf dem Campus unterstützt.

Im Verlauf der Arbeit wurde ermittelt welche Funktionen eine mögliche Anwendung auf diesem Terminal bereitstellen muss und auf welchen Informationen diese Funktionen basieren. So wurde im ersten Schritt der Arbeit, durch Umfragen und Protokolle, erfasst, worin der Informationsbedarf unter den Besuchern liegt. Des Weiteren ist festgestellt worden wie sich der akademische und militärische Bereich der Universität nach außen präsentierten kann und welche Informationen Sie über diese Plattform teilen möchten. Im Zweiten Schritt muss festgestellt werden, woher das System diese Informationen bezieht und welche Art gewählt wird, diese später dem Nutzer zu präsentieren. Nachdem dann eine angemessene Möglichkeit gefunden wurde, diese geplante Benutzeroberfläche zu erzeugen, galt es im vorletzten Schritt diese zu implementieren und auf dem Terminal in Betrieb zu nehmen. Das zu entwickelnde Programm muss später durch Dritte einfach zu warten und erweiterbar sein, um somit auch der Verwaltung zu ermöglichen Veränderungen vorzunehmen. Im letzten Schritt gibt die Arbeit einen Ausblick auf mögliche Erweiterungen und Zusatzfunktionen, die später einmal in die Software mit aufgenommen werden könnten.

Vorgehen bei der Umsetzung

Das folgende Kapitel beschriebt die einzellnen Schritte der Bachelorarbeit. Hierzu fasst jeder Absatz einen Schritte zur Umsetzung zusammen.

Vorstudie – Analyse Besucherverkehr

Um eine Software zu erstellen, die konkret auf die Anliegen der Besucher der Universität eingeht, wurde das Besucherverhalten erst genauer erforscht. Dazu wurden der Besucherverkehr an einem Dienstag und einem Mittwoch von 7:00 bis 20:00 Uhr protokolliert. Dabei wurde genauestens notiert, aus welchem Grund die Besucher das Gelände aussuchen und welches Ziel sie haben. Da alle Besucher das Gelände über das Westtor betreten müssen, um sich dort bei der militärischen Wache auszuweisen, war es einfach, den gesamten Besucherstrom zu erfassen.  Dabei war es sogar möglich, die wichtigsten Informationen zu erfassen, ohne dabei die Besucher aufzuhalten. ² Aus Gründen der Geheimhaltung und des Datenschutzes ist hier nur das Diagramm über die zeitliche Verteilung der Gäste abgebildet.

Zeitliche Verteilung der Besucher ¹

Kartenmaterial

Im nachsten Schritt wurden die Anforderungen an das Kartenmaterial spezifiziert. Die daraufhin gesammelten Karten der Universität wurden anhand dieser Anforderungen bewertet um eine geeignete Karte für die Software zu finden. Alle untersuchten Karten werden an dieser Stelle kurz mit ihren Merkmalen beschrieben. ³

3D- Karte eines FH- Studenten

3D Lageplan ⁴

Die gezeigte Karte ist von einem externen Fachhochschulstudenten vor fast 40 Jahren erstellt worden. Diese zeigt die Universität der Bundeswehr in einer Art Vogelperspektive aus nord-östlicher Sicht des Geländes. Sie zeigt auserdem alle Gebäude des damaligen Geländes in drei Dimensionen, sowie die vorhanden Sportstätten, den Parkplatz an der östlichen Seite, sowie die Grünflächen. Die Vorteile dieser Karte liegen ganz klar in der drei dimensionalen Darstellung der Gebäude. Diese hilft den Besuchern bei der Orientierung auf dem Gelände, weil es ihnen einfacher fällt ein Gebäude anhand des Aussehens zu identifizieren. Die Karte enthält neben den Formen der Gebäude auch noch Informationen über weitere Merkmale, wie z. B. die Farbe oder die Fassade.

3D-Modelierung in Google Earth

Google Earth UniBwM ⁵

Im Rahmen einer Bachelorarbeit entstand Anfang 2010, dieses 3D-Modell der Universität. Dieses ist für die Plattform von Google Earth ausgelegt worden und alle zugänglichen Daten sind im programmeigenen Format. Die Idee hierbei war es, die Modelle zu exportieren, in einer anderen Umgebung nachzubauen und sie dann für die Navigationssoftware zu nutzen. Die Vorteile die Darstellung wären wieder in der drei-dimensionalen Darstellung. Zudem könnte man flexibel agieren und z.B. Probleme wie verdeckte Informationen umgehen, würde man diese Modelle selbst exportieren und auf eigener Entwicklungsumgebung wiederverwenden.

2D-Karte des Stelen Leitsystems

2D Lageplan(alt) ⁶

Diese Karte wurde im Rahmen der Beschaffung eines Leitsystems für die UniBwM erstellt. Sie zeigt alle Gebäude des Universitätsgeländes in zwei Dimensionen sowie alle Straßen und weitere wichtige Objekte. So sind neben Parkplätzen auch Straßennamen auch einige Sportstätten verzeichnet. Der wesentliche Vorteil, der zur endgültigen Verwendung der Karte in der Navigationssoftware führte, ist die Darstellung in Form einer Vektorgrafik. Diese ermöglicht entscheidende Implementierungsvorteile mit der verwendeten Programmiersprache JavaFX ⁷, auf die an späterer Stelle eingegangen wird. Denn durch den Zugriff auf die Vektordaten ist es möglich, Gebäude und Straßen separat zu verändern. Dies ermöglicht es im Programm, das Zielgebäude farblich hervorzuheben oder die Route zum Ziel direkt zu markieren. Weiterhin können einzelne Objekte ein- oder ausgeblendet, verschoben oder in Größe und Form verändert werden. Durch das Vorliegen der Quelldaten ist auch gewährleistet, dass die Karte bei weiteren Veränderungen an der Universität aktualisiert wird. ⁸

Realisierungsmöglichkeit – JavaFX und Production Suite

Zur Umsetzung des Navigationssystems bieten sich verschiedene Programmiersprachen und Erweiterungen an. In der Arbeit wurde zwischen der Realisierung durch Java mithilfe von Baltik SVG Tool oder JavaFX mit Produktion Suite abgewogen.  An dieser Stelle wird nun die zur Realisierung verwendete Möglichkeit über JavaFX aufgezeigt.

JavaFX ist ein recht neues Framework für plattformübergreifende Internetapplikationen. Es basiert auf JavaScript und kann auf Funktionen und Schnittstellen der Java-Klassenbibliothek zurückgreifen. Somit verbindet JavaFX die objektorientierten Vorteile der Programmiersprache Java und die einer webbasierten Applikationssprache wie JavaScript. Zusätzlich schafft JavaFX mit der Production Suite eine Verbindung zwischen Designer und Entwickler. Es stellt Plugins für Adobe Illustrator und Adobe Photoshop zur Verfügung. FXZ-Grafiken können zur Laufzeit mit JavaFX sehr einfach verändert werden. Einzelne Bestandteile können zum Beispiel über eine im SVG-Programm oder in Illustrator zugewiesene ID angesprochen werden und es lassen sich damit sehr einfach Eigenschaften, wie Transparenz, Position, Größe oder Form des Objekts ändern. Die Funktionsweise von JavaFX und Produktion Suite wird im Artikel „Howto zum Export von JavaFX Dateien durch Production Suite“ beschrieben.

Programm Design

Bei der Gestaltung des Programm Designs wurden sehr viele Entwürfe angefertigt die immer wieder die Benutzeroberfläche verfeinert haben, um sie möglichst intuitiv und einfach zu gestalten. Dabei war es wichtig den vorhandenen Platz optimal auszunutzen, und trotzdem keine Informationen zu überdenken oder Bedienelemente an ungünstigen Stellen anzuordnen. Hierbei muss berücksichtigt werden, dass es sich um ein vertikales Display mit kapazitiver Thoughglass Touchscreen Technologie handelt. Dies schränkt zum Einen den effektiv zu nutzenden Bereich ein, in dem Touchscreen-Eingaben getätigt werden können. Zum Anderen müssen die Eingabeelemente eine gewisse Größe besitzen, da die Technologie eine gewisse Ungenauigkeit besitzt. Durch einige Experimente an Modeloberflächen, wurden die Fläche des Displays in gewisse Bereiche eingeteilt, sowie Mindestgrößen für Schrift und Eingabeelemente festgelegt. Diese sind in der folgenden Abbildung  eingezeichnet. ⁹

Bereiche im Display ¹

• Die Rote Fläche zeigt den Bereich in dem eine Touchscreen Eingabe schwer umzusetzen ist und somit nur zur Anzeige genutzt wird.
• Die Blaue Fläche zeigt den zu nutzende Bereich des  Touchscreen Displays.
• Die Grüne Fläche markiert den Bereich in dem der Focus des Nutzers liegt. Alle Hauptfunktionalitäten sowie Programminteraktionen werden in diesem Bereich ausgeführt.
• Die Gelben Objekte zeigen die Größen umzusetzender Bedienelemente, sie besitzen eine Kantenlänge von 50/60/75 Pixel
• Der Text zeigt die zu verwendende Größe einer Überschrift und eines normalen Textes (Arial, Schriftgröße 24/12)

Unter Berücksichtigung dieser Bereiche ergaben sich nach wiederholter Analyse und Überarbeitung das untern abgebildete Model der Benutzeroberfläche. Darin sind im Focus die Suchfunktionen wiederzufinden, sowie die Buttons zum Zoomen und Zurücksetzen der Karte. Im unteren Display-Bereich sind die weitern Funktionen angeordnet, um Informationen ein und auszublenden. Es wurde hier in der Abbildung auf eine zusätzliche Beschriftung verzichtet, da die Button-Titel sehr aussagekräftig sind und dies die Darstellung nicht zu verfälschen. ¹⁰

Fussgängernavigation MockUp V2 ¹

Fussgängernavigation MockUp V3 ¹

Fussgängernavigation MockUp V5 ¹

Fussgängernavigation MockUp V7 ¹

Fussgängernavigation Startscreen ¹

Anpassung der Vektordaten

Die gelieferten Daten Vektordaten mussten im ersten Schritt der Realisierung nun soweit angepasst werden, dass diese mit Hilfe der JavaFX Produktion Suite in das FXZ- Format umgewandelt werden konnten. Da ein Designer die Elemente einer Vektordatei oftmals nur auf das Nötigste gruppiert und in Ebenen separiert, war an dieser Stelle viel Aufwand notwendig. Die erhaltene Adobe Illustrator Datei enthielt jeweils eine Ebene für die Symbole der Karte, die Gebäude, deren Schatten, die Straßen und die Grundfläche im Hintergrund. In diesen Ebenen waren die einzelnen Elemente jedoch nicht weiter sortiert oder beschriftet worden. Ohne eine solche Beschriftung und Gruppierung wäre es nicht möglich, später im Programm, die Objekte anzusprechen und zu verändern. Somit bestand die erste Aufgabe darin, diese Ebenen und Gruppen, neu zu strukturieren.

In der Ebene der Gebäude musste die meiste Arbeit geleistet werden. Hier wurden zuerst alle Pfade die zu einem Gebäude gehören gruppiert. Die Beschriftung der einzelnen Bauteile der Gebäude wurde auch mit aufgenommen, da es bisher sehr wenige Karten des Geländes gibt die auch diese mit abbilden. Nachdem alle diese neuen Informationen in die Karte mit eingezeichnet wurden, mussten dies auch entsprechend benannt und gruppiert werden. Nach dieser erneuten Gruppierung umfasst jedes Gebäude drei Untergruppen. Den Aufbau dieser Gruppe und der Untergruppen Label, Shape und Shadow zeigt die folgende Abbildung.

AI Ebenen ¹

2D Lageplan(neu) ¹

Zusammenfassung und Ausblick

Die Arbeit begann im Oktober 2010 mit der Aussicht auf eine lauffähige Navigationssoftware für das Gelände der Bundeswehruniversität. Dabei haben die Recherchen und Analysen der Problemstellung ergeben, dass diese Software, neben einer einfachen Grundfunktion, eine Vielzahl von nützlichen Zusatzfunktionen beinhalten könnte. Jede dieser Funktionen wäre dabei eine große Bereicherung, sowohl im Bereich der Benutzerfreundlichkeit, wie auch im Hinblick auf die Wartung. Sie könnten helfen die Universität der Bundeswehr positiv nach außen zu präsentieren. Zunächst blieb der Fokus jedoch auf einer gut konzeptionierten Analyse der genauen Anforderungen an die Software. Um möglichst viele Erkenntnisse zur Problematik zu sammeln wurden unterschiedlichste Forschungsbereiche beleuchtet.

Die Auswertungen bezüglich des Kartenmaterials waren äußerst ernüchternd, da sie im Grunde keine Auswahlmöglichkeit lassen. Die Wahl des Realisierungsverfahrens hingegen blieb unterer den vorgestellten Möglichkeiten ausgeglichen. Auch wenn sich die Umstellung auf JavaFX schwerer als zunächst angenommen erwies, bleib es die richtige Entscheidung und wird sich auch an späterer Stelle weiter auszahlen. Dies hatte sich bei der Anpassung der Vektordaten von gezeigt. Dieser vorher nicht bedachte Arbeitsabschnitt hat bei weitem am meisten Zeit in Anspruch genommen. Die Entscheidung, sich an dieser Stelle intensiver mit der Umstrukturierung und Aufbereitung der Vektordaten zu befassen und vorerst von einer vollständigen Realisierung des Programmes abzusehen, war vollkommen richtig. Die eigentlichen Vorteile, die zur Auswahl von JavaFX und einer vektorbasierten Karte geführt haben, werden dabei eigentlich erst an späterer Stelle deutlich. Denn zurzeit beschränken sich die Funktionen des Programms sowie ein Zusammenspiel der angesprochenen Komponenten noch auf ein Minimum, doch nun gilt es dies umgehend zu einer Version zu erweitern, die auf dem Terminal in Betrieb genommen werden kann.

In diesem Howto wird gezeigt, wie aus einer Vektorgrafik in Adobe Illustrator eine FXZ-Datei erstellt werden kann, die zur Programmierung einer entsprechenden Oberfläche in JavaFX benötigt wird. Dazu wird das Plugin der JavaFX Production Suite verwendet, das als Integrationslösung zur Unterstützung solcher Anwendungsfälle von Oracle bereitgestellt wird.

Falls bisher noch keine Runtime-Umgebung für JavaFX installiert wurde, zeigt der zuvor in dieser Serie erschienene Artikel Howto – Erste Schritte mit JavaFX 2.0 alle erforderlichen Voraussetzungen, die für das Programmieren mit JavaFX benötigt werden, sowie allgemeine grundlegende Begriffe und Befehle. Die nachfolgend vorgestellten Schritte stammen z.T. aus dem Getting Started Tutorial zur Production Suite und wurden für den Kontext der Artikelserie zu JavaFX entsprechend angepasst.

Vektorgrafik in Adobe Illustrator

Zunächst betrachten wir eine Grafik mit ihrer Ebenenstruktur in Adobe Illustrator. Bereits beim Erstellen der Grafik muss auf Ebenen und Benennung geachtet werden. Rechts im Bild sind die Ebene mit ihren jeweiligen Gruppierungen gut zu erkennen.

Struktur einer Vektorgrafik ¹

In der abgebildeten Grafik sind alle Zahlen mit ihrem quadratischen Rahmen gruppiert und durchnummeriert. An der Benennung der Elemente kann man ableiten, welche Komponenten später im Programm angesprochen können werden sollen. Alle Objekte, die in JavaFX über ihre ID (Ebenennamen) aufrufbar sein sollen, sollten in Adobe Illustrator mit dem Präfix „JFX:“ versehen werden. Dies bietet sich insbesondere bei Grafiken an, die viele Objekte bzw. Ebenen besitzen, von denen aber nur ein gewisser Teil später im Programm explizit angesprochen werden muss.

Über den Punkt „Datei“ in der Menüleiste erreicht man unter „Save for JavaFX…“ das Plugin. Es öffnet sich das unten abgebildete Exportfenster mit den möglichen Ausgabeoptionen. Wenn später alle Objekte über eine ID angesprochen werden sollen, kann dies in den Ausgabeeinstellungen festgelegt werden.

Exportbeispiel mit Ausgabe optionen ¹

Tranformation in JavaFX-Quelltext

Das Speichern erzeugt die FXZ-Datei zur geöffneten Grafik. Beim Vergleich der originalen Adobe Illustrator Grafik und der exportierten FXZ-Datei ist gut zu erkennen, wie die Benennung im Quelltext der Ausgabedatei in der folgenden Grafik wiederzufinden ist.

Struktur einer FXZ-Datei ²

Zum Ausgabeformat ist noch zu sagen, dass die JavaFX-Ausgabedatei, wie schon angesprochen, im FXZ-Format vorliegt. Dieses beinhaltet eine FXD-Datei, in der die eigentliche textuelle Beschreibung der Grafik enhalten ist. Die textuelle Beschreibung basiert auf XML und beschreibt Element für Element, gegliedert nach den jeweiligen Ebenen. Somit besteht die Ausgabedatei (.fxz) aus der Grafik an sich und der textuellen Beschriebung (.fxd), was sich auch im Wurzeltag „FXD“ in  der Abbildung oben widerspiegelt.

Weiterführenden Informationen zu JavaFX und der JavaFX Production Suite finden sich u.a. auf den Oracle-Seiten JavaFX Tutorials und JavaFX Howtos.

In diesem Howto wird kurz erklärt, welche Software für das Arbeiten mit JavaFX 2.0 benötigt wird und wo diese erhältlich ist. Dabei orientiert sich das Tutorial an den aktuellsten Komponenten, die mit der Veröffentlichung der neuen Version 2.0 von JavaFX erschienen sind. Die Software ist zum Verfassungszeitpunkt dieses Artikels nur für 32-Bit-Windows Betriebssysteme erhältlich.

Im Mai 2011 ist die neue Version von JavaFX erschienen, nachdem der Umgebung in der jüngsten Vergangenheit immer größere Anwendung zuteil wurde. Dieses Howto stellt alle benötigten Komponten, die zum Entwickeln mit JavaFX 2.0 erforderlich sind, mit einer minimalistischen Konfigurationsanleitung zusammen.

Installation

Bevor im nächsten Abschnitt eine minimalistische Beispielsanwendung erstellt wird, müssen zunächst alle erforderlichen Komponenten installiert werden.

Java SE 6 JDK

Für das Arbeiten mit JavaFX  2.0 ist mind. Java SE 6 JDK Update 24 ¹ erforderlich.

1. Java SE 6 Update 25 JDK downloaden.
2. Zur Installation .exe-Datei ausführen.

JavaFX 2.0 SDK (inkl. Runtime)

Zusätzlich zur Java-Entwicklungsumgebung wird das JavaFX SDK benötigt.

1. JavaFX SDK  Zip-Archiv downloaden.
2. Archive auf lokalem System entpacken und darin befindliche .exe-Datei entsprechend nachfolgendem Screenshot ausführen.

Install SDK ²

Netbeans 7.0 und JavaFX Plugin

Als integrierte Entwicklungsumgebung wird aktuell lediglich die Netbeans IDE, nicht aber Eclipse unterstützt. Zur Integration von JavaFX wird ein zusätzliches Plugin benötigt.

1. Aktuellen Netbeans 7.0 Installer (Java SE/EE/all) downloaden.
2. Installer für die Basis Version von Netbeans ausführen.
3. Zip-Archiv JavaFX Plugin für Netbeans downloaden
4. Archive auf dem lokalen System entpacken.
5. Netbeans IDE starten.
6. In der Menü-Leiste „Tools“ wählen und  auf „Plugins“ klicken, vgl. Abb. Install Plugin 1.
7. Register“ Downloaded“ wählen und auf „Add Plugins…“ klicken, vgl. Abb. Install Plugin 2.
8. Im neu geöffneten Fenster zu den zuvor entpacketen Dateien navigieren, vgl. Abb. Install Plugin 3 & 4.
9. Alle entpackten NBM-Dateien auswählen und „Open“ klicken, vgl. Abb. Install Plugin 5.
10. Abschließend auf „Install“ klicken und den Anweisungen des Netbeans Installer folgen, vgl. Abb. Install Plugin 6.

Die notwendigen Komponenten zum Arbeiten mit JavaFX sind damit installiert und eingerichtet.

Adobe Integration – JavaFX Production Suite

Neben der Standardentwicklungsumgebung ist das Arbeiten mit Adobe Illustrator in Kombination mit der JavaFX Plugin Production Suite für vektorbasierten Grafiken sehr empfehlenswert, da die Vektordaten ohne Qualitätsverlust übernommen werden können. Eine Testversion der verschiedenen Adobe Produkt kann bei Bedarf auf der Adobe Produktseite heruntergeladen werden.

Die Production Suite ist zur Zeit noch nicht expliziet für JavaFX 2.0 verfügbar, zur älteren Version 1.3.1 gibt es hier eine Downloadmöglichkeit. Nach der Installation findet sich die Exportmöglichkeit des Plugins in Adobe Illustator unter Datei > Save for JavaFX… .

Hallo Welt! Beispielanwendung

Nachdem alle Voraussetzungen geschaffen sind, zeigt dieser Abschnitt kurz den groben Aufbau einer Anwendung mit JavaFX 2.0 anhand eines beispielhaften Hallo Welt! Programms. Bei der Verwendung von Netbeans muss der Code hierfür noch nicht einmal selbst geschrieben werden, da dieser bei jedem Erzeugen einer JavaFX Main Class automatisch mit erstellt wird.

Als erstes wird eine Class Datei erzeugt, um zu sehen wie das von Netbeans erstellte Programm aussieht:

1. Netbeans starten, sofern nicht noch geöffnet.
2. Unter „File“ auf „New Projekt“ bzw. auf den orangnen Ordner unter der Menüleiste klicken, vgl. Abb.“New Projekt 1.
3. In der Kategorie „Java“ „Java FX Application“ auswählen und dann „Next“ klicken, vgl. Abb. New Projekt 2.
4. Unter „Project Name“ kann ein beliebiger Name gewählt werden.
5. „Finish“ klicken, vgl. Abb. New Projekt 3.

Anschließend öffnet sich eine neue Main Class mit dem neu erstellten Hello World! Beispielprogramm.

Die neue Version von JavaFX versucht sich wieder mehr an der ursprünglichen Java Programmierung zu orientieren. So ist zum Beispiel die Main Class von Typ „.java“ und nicht wie früher von Typ „.fx“. Weiterhin gibt es nun auch wieder eine echte main Methode wie schon in Java.

    public static void main(String[] args) {
        Application.launch(HelloWorld.class, args);
    }

Der „Lauch“- Befehl in der Main Methode führt die statische Methode „Start“ der darin angegebenen Klasse aus. Gleich geblieben im Vergleich zu früheren Versionen von JavaFx ist der Aufbau im Sinne einer „Stage“ und der beinhalteten „Scene“, wie die folgende Abbildung zeigt:

Aufbau JavaFX Frame ³

Die nachfolgenden Befehle erzeugen die angesprochene Stage und ihre Scene sowie eine Variable, die später den Inhalt der Application beinhalten soll. Alle Objekte, die der Variable „root“ zugeordnet werden, sind später auch im Programm zu sehen.

        primaryStage.setTitle("Hello World");
        Group root = new Group();
        Scene scene = new Scene(root, 300, 250, Color.LIGHTGREEN);

Dies trifft zum Beispiel auf den folgenden Button „btn“ zu, der zunächst definiert und dann mit einer Aktion belegt wird. Durch das Hinzufügen zu den Kindern des Wurzelelements taucht er im später sichtbaren Content-Bereich auf.

        Button btn = new Button();
        btn.setLayoutX(100);
        btn.setLayoutY(80);
        btn.setText("Hello World");
        btn.setOnAction(new EventHandler<ActionEvent>() {
            public void handle(ActionEvent event) {
                System.out.println("Hello World");
            }
        });
        root.getChildren().add(btn);

Durch drücken von „F6″ oder dem grünen Pfeil unter der Menüleiste kann das Programm gestartet werden.