Erweiterung der csxPOI-Anwendung um
Event-basierte Points of Interests
Daniel Schmeiß
Institute for Computer ScienceUniversity of Koblenz-Landau
Zusammenfassung
Ziel dieser Studienarbeit ist es, die mobile POI-Verwaltungssoft-ware csxPOI um POIs mit zeitlicher Ausdehnung – Events – zu erwei-tern. Dabei geht es um die Modellierung der Events und die
Entwick-lung eines Konzeptes f¨ur die ¨ubersichtliche Darstellung der Events auf
dem mobilem Endger¨at. Hierf¨ur wurde eine neuartige
Interaktionsme-tapher f¨ur das Einstellen und Browsen des Zeitaspektes implementiert
und in die bestehende Anwendung integriert. F¨ur die Erweiterung um
Events wurden die zugrunde liegenden Konzepte, die Ontologie und die Benutzungsschnittstelle erweitert und angepasst. Mit dem
Ergeb-nis dieser Arbeit ist es nun m¨oglich mit der csxPOI-Anwendung Events
Studienarbeit
vorgelegt von Daniel Schmeiß im Januar 2010 zum Thema
Erweiterung der csxPOI-Anwendung um Event-basierte Points of Interests
an der Universit¨at Koblenz-Landau.
Gutachter
Prof. Dr. Steffen Staab Dr. Ansgar Scherp Institut WeST Fachbereich 4
Universit¨at Koblenz-Landau
Erkl¨
arung
Ich versichere, dass ich die vorliegende Arbeit selbst¨andig verfasst und keine
anderen als die angegebenen Quellen und Hilfsmittel benutzt habe. Mit der Einstellung dieser Arbeit in die Bibliothek bin ich einverstanden.
Der Ver¨offentlichung dieser Arbeit im Internet stimme ich zu.
Koblenz, den 31. Januar 2010
Inhaltsverzeichnis
Abbildungsverzeichniss 1 1 Einf¨uhrung 2 2 Szenarien 3 2.1 Notfallmanagement . . . 3 2.2 Urlaubsplanung . . . 3 2.3 Ausstellungsbesuch . . . 4 3 Verwandte Arbeiten 5 3.1 Events und Objekte . . . 53.2 Zeitdarstellung auf mobilen Endger¨aten . . . 5
3.3 Zusammenfassung . . . 8 4 Anforderungen 9 4.1 Funktionale Anforderungen . . . 9 4.2 Nichtfunktionale Anforderungen . . . 10 4.3 Weitere Anforderungen . . . 10 5 Konzept 13 5.1 Event-basierte POIs . . . 13
5.2 Visualisierung von Events . . . 16
6 Implementierung 21 6.1 Erweiterung von csxPOI um Events . . . 21
6.1.1 Client-seitig . . . 21
6.1.2 Server-seitig . . . 22
6.2 Zeitauswahl-Widget . . . 25
6.3 Anzeige der Events . . . 29
6.4 Grafische Benutzungsoberfl¨ache . . . 32
7 Prototyp 34 7.1 Zeitauswahl-Widget . . . 34
7.2 Events anlegen und editieren . . . 35
7.3 Events suchen und anzeigen . . . 36
7.4 Fazit des Prototyps . . . 38
8 Zusammenfassung 39
9 Ausblick 40
1
Abbildungsverzeichnis
1 TimeZoom-Zeitleiste mit verschiedenen Granularit¨aten [4] . . 6
2 Zeitleistenansicht im Photobrowser [6] . . . 7
3 Links: Suche nach POIs - Rechts: Erstellen eines POIs . . . . 11
4 Links: Detail-Ansicht eines POIs - Rechts: Ontologie-Editor . . 12
5 geo located event Ontologie, welche einen Event mit Start-und Enddatum Start-und einer gle:belongsTo-Beziehung, visualisiert 14 6 Erster Entwurf der Zeitleistenansicht . . . 16
7 Zweiter Entwurf der Zeitleistenansicht . . . 17
8 Dritter Entwurf der Zeitvisualisierung- und auswahl . . . 18
9 Verfeinerung des Konzepts des Zeitauswahl-Widgets . . . 20
10 SeekBar-Widget des Android SDK . . . 25
11 Angepasste SeekBar . . . 26
12 Abstufungen der Event-Symbole nach Zeit . . . 30
13 Hauptansicht (links), Popup zum W¨ahlen des Datums (rechts) 34 14 Erstellen eines Events (links), Ge¨andertes Datum (rechts) . . . 35
15 Suchdialog (links), In Abbildung 14 erstellter Event (rechts) . 36 16 Erl¨auterung der Symbole (links), Visualisierung sehr vieler POIs und Events (rechts) . . . 37
1 EINF ¨UHRUNG 2
1
Einf¨
uhrung
In seiner Diplomarbeit [3] hat Max Braun die csxPOI
Android-Smartphone-Anwendung entwickelt, welche es dem Benutzer erm¨oglicht auf einer Karte
Points of Interest zu platzieren und mit anderen Benutzern zu tauschen. Die Besonderheit liegt darin, dass diese POIs mit semantischen Konzepten
annotiert werden k¨onnen. Die zugrunde liegende Ontologie kann ebenfalls
von den Anwendern kollaborativ editiert und erweitert werden, so dass diese Anwendung durch die Benutzer beliebig um Konzepte erweitert werden kann
und somit auch f¨ur spezielle Einsatzgebiete interessant macht.
Diese POIs zeichnen sich durch einen Namen, den Ort an dem sie plat-ziert wurden und durch die annotierten Konzepte aus. Jedoch wird dabei
nicht die zeitliche Dimension der Punkte in Betracht gezogen. Dies w¨urde
der Anwendung einen erheblichen Mehrwert liefern und es so dem Anwender
erm¨oglichen, nicht nur nach zeitlich konstanten Points of Interest zu suchen,
sondern auch nach Events.
Diese Erweiterung soll im Rahmen dieser Studienarbeit umgesetzt
wer-den. Wobei zuerst Szenarien in Kapitel 2 f¨ur die Nutzung einer solchen
An-wendung betrachtet werden, aus denen dann die Anforderungen aus Kapitel
4 abgeleitet werden. Gleichzeitig werden ¨ahnliche Anwendungen und Ans¨atze
beleuchtet um somit einen ¨Uberblick und Anregungen zu erhalten (siehe
Ka-pitel 3). Dann soll ein Konzept in KaKa-pitel 5 f¨ur die Umsetzung geschaffen
werden. Anschließend soll die bestehende Anwendung so erweitert werden,
dass sich die Erweiterung nahtlos in die Anwendung einf¨ugt und der
Be-nutzer mit Events arbeiten kann. Besondere Aspekte der Implementierung werden dann in einem separaten Kapitel 6 beschrieben. Abschließend wird dann der in Rahmen dieser Arbeit weiterentwickelte Prototyp (siehe Kapitel 7) in Bezug auf die neuen Funktionen vorgestellt.
2 SZENARIEN 3
2
Szenarien
Im Folgenden sollen nun einige Szenarien f¨ur die m¨ogliche Verwendung der
um Events erweiterten csxPOI-Anwendung vorgestellt werden. Daraus sollen
dann Anforderungen f¨ur die Anwendung generiert werden. Die beiden
Sze-narien
”Notfallmanagement“ und ”Urlaubsplanung“ sind angelehnt an die
Szenarien des WeKnowIt-Projektes1.
2.1
Notfallmanagement
Im Notfallmanagement-Szenario liegt der Fokus auf der schnellen und
einfa-chen Erstellung von Events. Die Anwendung k¨onnte auf mobilen Endger¨aten
von Polizei-und Feuerwehrmitarbeitern installiert sein und sie so in die Lage
versetzen Notf¨alle schnell zu melden und im System einzutragen. Somit
lie-gen die Anforderunlie-gen hier auf einem einfachen Hinzuf¨ugen von Events und
deren Visualisierung auf einer Karte. Folgender Ablauf ist hier denkbar:
• Ein mobiler Mitarbeiter der Polizei entdeckt ein Feuer.
• Er markiert dies in seiner Notfallmanagement-Anwendung auf seinem
mobilen Endger¨at. Dazu platziert er einen
”Feuer-Event“ an seiner
ak-tuellen Stelle und f¨ugt zus¨atzlich einen Zeitstempel f¨ur Log-Zwecke
hin-zu.
• Nun k¨onnen weitere Mitarbeiter, mit Zugriff auf dieses System, ¨uber
dieses Feuer informiert werden.
• Jedoch sollte auch die M¨oglichkeit bestehen nach gewissen Begriffen, wie zum Beispiel
”Feuer“, in der Anwendung zu suchen und sich so
einen ¨Uberblick zu verschaffen ¨uber Vorkommnisse in Zeitr¨aumen in
der Vergangenheit.
2.2
Urlaubsplanung
Das zweite Szenario – Urlaubsplanung – beschreibt, wie eine Gruppe von Per-sonen einen Urlaubstrip in eine fremde Stadt planen. Dabei wollen sie sich ¨
uber m¨ogliche Aktivit¨aten und Ereignisse, die w¨ahrend ihres Aufenthalts in
der Stadt angeboten werden, informieren. Aber auch eine Verwendung der
2 SZENARIEN 4
Anwendung vor Ort, um einen schnellen und einfachen ¨Uberblick ¨uber
Ver-anstaltungen zu bekommen, sollte m¨oglich sein. Somit ist dieses Szenario
nicht so kurzfristig wie das Notfallmanagement-Szenario zu sehen, sondern es fokussiert sich auf die Planung in der Zukunft.
Folgender Ablauf ist hier denkbar:
• Ein Mitglied der Reisegruppe sucht in der Anwendung die Stadt aus und navigiert dort hin.
• Nun setzt er den Zeitraum auf den Reisezeitraum, also auf einen Zeit-raum in der Zukunft.
• Anschließend sollte es ihm m¨oglich sein nach eingetragenen Events und
Aktivit¨aten, die w¨ahrend dem ausgesuchten Zeitraum stattfinden, zu
suchen und ihm die Ergebnisse auf der Karte pr¨asentiert werden.
• Wenn die Reisegruppe dann vor Ort ist, sollte es m¨oglich sein mit der
mobilen Anwendung sich nochmals ¨uber Ereignisse am aktuellen Ort
zu informieren.
2.3
Ausstellungsbesuch
Das nun letzte, hier aufgef¨uhrte Szenario soll ein Ausstellungsbesuch sein.
Hierbei besucht eine Person eine Ausstellung und m¨ochte diese in seiner
csxPOI-Anwendung vor Ort eintragen. Folgender Ablauf ist nun hier denkbar:
• Nach dem Besuch einer Ausstellung m¨ochte die Person diese in cxsPOI abspeichern.
• Daf¨ur erstellt er nach dem ¨ublichem Muster einen Event und platziert
ihn auf der Karte.
• Jedoch kann es nun sein, dass er weder das Anfangs- noch das Endda-tum der Ausstellung kennt. Nun sollte dies aber kein Problem bei der
Erstellung des Events sein. Er w¨ahlt einfach ab
”heute“ und l¨asst das
Enddatum offen. Dieses kann dann zum Beispiel ein weiterer Besucher nachtragen.
3 VERWANDTE ARBEITEN 5
3
Verwandte Arbeiten
Dieses Kapitel soll einen ¨Uberblick ¨uber die bereits bestehenden Konzepte
zu den einzelnen Teilen dieser Arbeit geben – Events und die Zeitdarstellung
auf mobilen Endger¨aten.
3.1
Events und Objekte
Eine Grundlage f¨ur die Erweiterung der csxPOI-Anwendung um Events ist
es, zu kl¨aren wie wir Events definieren. Dies kann man zum Beispiel ¨uber
einen Zeitpunkt oder ein Zeitintervall definieren [1]. Anhand unserer
Anwen-dungsf¨alle aus Kapitel 2 wird aber ein Zeitintervall ben¨otigt, so dass wir f¨ur
diese Arbeit folgende Festlegung treffen:
Festlegung 1 (Event) Ein Event in unserem Sinne ist eine Entit¨at, welche
sich ¨uber einen Zeitraum erstreckt. Dabei besitzt sie einen Start- und einen
Endzeitpunkt.
H¨aufige Aufgaben, die im Zusammenhang mit Events vorkommen sind
das Finden von Events vor, nach oder w¨ahrend eines Zeitraums oder
Zeit-punktes [9]. Diese Aufgaben fallen genau in die beschriebenen
Anwendungs-f¨alle und sind somit in den Anforderungen in Kapitel 4 zu finden.
Komplexere Modellierungen von Events, wie zum Beispiel das
”Event
Mo-del F“ [7], welches die Korrelation von Events und auch ihre beteiligten
En-tit¨aten modelliert, ben¨otigen wir f¨ur die Erweiterung der csxPOI-Anwendung
nicht. Events sind im Kontext dieser Arbeit also nur als Ereignisse, die ” pas-sieren“, zu sehen. Die beteiligten Objekte, werden nicht modelliert [7]. Jedoch
haben Events einen Ortsbezug ¨uber die entsprechende Geokoordinate auf der
Karte.
3.2
Zeitdarstellung auf mobilen Endger¨
aten
Um innerhalb der Anwendung einen ¨Uberblick ¨uber die zeitliche Anordnung
der Events zu erhalten eignet sich eine Zeitleistenansicht. Diese wird dann
zus¨atzlich zur bestehenden Kartenansicht angeboten und der Anwender hat
die Wahl zwischen diesen beiden Ansichten.
Tufte [11] beschreibt Zeitleisten als ¨ubliche und hilfreiche Form der
Dar-stellung von chronologischen Daten. Dabei repr¨asentiert bei seinen vielen
Beispielen die horizontale Achse die Zeit und in der vertikalen Achse werden
die Events aufgetragen. Eine Verwendung dieser Zeitleiste ist somit f¨ur den
3 VERWANDTE ARBEITEN 6
Abbildung 1: TimeZoom-Zeitleiste mit verschiedenen Granularit¨aten [4]
Diese Zeitleisten sind in vielen Anwendungen zu finden. So stellt zum Beispiel TimeZoom [4] eine solche dar. Der Fokus liegt hierbei auf dem Design der Zeitleiste und nicht, wie man mit ihr Daten darstellt. Die TimeZoom-Zeitleiste ist horizontal angeordnet. In der Vertikalen bietet sie verschiedene
zeitliche Granularit¨aten. Diese reichen von Jahren bis zu Stunden und sind
flexibel (siehe Abbildung 1).
Als Interaktionsm¨oglichkeit mit dieser Zeitleiste stellen die Autoren das
horizontale Scrollen in einer Region der Zeitleiste heraus. Somit kann der
Anwender genau den Zeitraum ausw¨ahlen, den er sucht und die Anwendung
ist einfach zu bedienen. Problematisch bei der TimeZoom-Zeitleiste ist die
Komplexit¨at dieser und die Abbildung dieser auf einem kleinen Display eines
mobilen Endger¨ats. Außerdem bleibt die Darstellung der Daten bei dieser
Arbeit außen vor.
David Fran¸cois Huynh vom Massachusetts Institute of Technology stellt mit
”TimeLine“ [5] eine Webanwendung vor, die es erm¨oglicht Events zu
vi-sualisieren. Es gibt einerseits eine kleinere Scrollleiste am unteren Rand der Anwendung, mit der der Anwender schnell durch die Zeitleiste scrollen kann. Wenn er dies tut, passt sich die chronologische Anzeige der Events an und zeigt die Events als kleine Punkte mit Beschreibung an. Beim Anklicken eines
Events erh¨alt der Benutzer weitere Informationen. Der grundlegende Ansatz
ist ¨ahnlich wie bei TimeZoom. Es gibt verschiedene Granularit¨aten von Zeit
und der Anwender kann je nach seinen Bed¨urfnissen Scrollen und
Brow-sen. Jedoch ist dies eine Webanwendung und verbraucht sehr viel Fl¨ache auf
dem Bildschirm. Auf einem kleinen Bildschirm eines Mobiltelefons
funktio-niert diese Darstellung nicht. Gut funktiofunktio-niert hierbei aber das ¨ubersichtliche
Browsen durch die Anzeige der verschiedenen Granularit¨aten von Zeit und
man erh¨alt schnell einen ¨Uberblick ¨uber die vorhandenen Events.
3 VERWANDTE ARBEITEN 7
Abbildung 2: Zeitleistenansicht im Photobrowser [6]
der PhotoBrowser [6]. Hier stellen die Autoren eine Anwendung vor, die auch eine Zeitleistenansicht der Photos beinhaltet. Die Zeitleiste ist hier nicht – wie
sonst ¨ublich – horizontal, sondern vertikal angeordnet. Links und rechts von
ihr befinden sich geclusterte Sammlungen von Photos, die einen bestimmten Zeitraum abdecken (siehe Abbildung 2).
Bei dieser Darstellung wird dem Benutzer sofort ersichtlich, welchen Zeit-raum er gerade sieht und welche zeitliche Ausdehnung die einzelnen Photo-alben haben. Die Photos werden zu Alben geclustert, damit nur maximal zehn Alben gleichzeitig angezeigt werden. Diese geclusterte Visualisierung
der Photos k¨onnte man auch auf Events ¨ubertragen und so auch viele Events
auf einem begrenzten Bildschirm darstellen.
F¨ur die Darstellung der Zeitleiste auf einem mobilem Endger¨at mit
be-schr¨ankter Bildschirmgr¨oße bedarf es jedoch weiterer konzeptueller ¨
Uberle-gungen. Denn einerseits muss die Anwendung ¨ubersichtlich dargestellt
wer-den, andererseits auch gut mit dem Finger bedienbar sein. Die einfache Be-dienung mit einem Finger ist die Grundlage des Betriebssystems Android
3 VERWANDTE ARBEITEN 8
3.3
Zusammenfassung
Um die bestehende csxPOI-Anwendung um Events zu erweitern werden die
Ereignisse, wie wir sie soeben festgelegt haben, in die Anwendung ¨ubertragen.
Dabei soll die Zeitleisten-Darstellung einen ¨Uberblick ¨uber die Events geben.
Es gibt die M¨oglichkeit diese Zeitleiste horizontal oder vertikal anzuordnen.
Wir haben uns nach einem iterativem Entscheidungsprozess und der
Erstel-lung verschiedener alternativer Varianten f¨ur die horizontale Ansicht
ent-schieden, wie sie von Tufte empfohlen und von weiteren Arbeiten verwendet wird. Das Design der Anwendung wird an die Darstellung von TimeZoom angelehnt (siehe Konzept 5.2).
4 ANFORDERUNGEN 9
4
Anforderungen
Anhand der Anwendungsf¨alle aus Kapitel 2 und der Vorstellung der
ver-wandten Arbeiten in Kapitel 3 ergeben sich bestimmte Anforderungen f¨ur
die Umsetzung der Erweiterung der csxPOI-Anwendung. Diese Anforderun-gen sind unterteilt in AnforderunAnforderun-gen, die die Erweiterung der Anwendung um
Events betreffen und in Anforderungen f¨ur die allgemeine Verfeinerung der
Anwendung. Diese sind jeweils in funktionale und nichtfunktionale Require-ments unterteilt [10]. Desweiteren sind die Anforderungen als obligatorisch
mit einem Pluszeichen (+) oder als optional mit einem Minuszeichen (−)
gekennzeichnet.
4.1
Funktionale Anforderungen
Die funktionalen Anforderungen beschreiben die Anforderungen an die
Be-nutzungsoberfl¨ache, um die Erstellung, Anzeige und Manipulation von Events
zu erm¨oglichen.
R1+ Der Anwender kann zu einem POI einen Zeitraum hinzuf¨ugen,
in-dem er Datum und Zeit ausw¨ahlt.
R2+ Die Auswahl von Datum und Zeit wird auf die Bedienung mit dem
Finger auf einem Touchscreen optimiert.
R3+ Es gibt die M¨oglichkeit, die Daten – Datum und Zeit – sowohl
mittels der Benutzungsoberfl¨ache, als auch direkt mit der Tastatur
einzugeben.
R4+ Events unterscheiden sich auf der Karte anhand des Icons von
nor-malen POIs.
R5+ Wenn man Events innerhalb eines bestimmten Zeitraums gesucht
hat, sollte dieser Suchzeitraum auch stets angezeigt werden (zum Beispiel oberhalb der Karte).
R6+ Innerhalb der Informationen eines Events sollte dieser als solcher
klar gemacht werden und auch der Zeitraum angezeigt werden.
R7+ Bei einem Klick auf einen Event erscheinen weitere Informationen
in einem Fenster.
R8+ Der Anwender kann den Zeitraum eines Events editieren und
4 ANFORDERUNGEN 10
R9+ Das Zeitauswahl-Widget blendet sich ein, wenn man auf die Karte
tippt und blendet sich nach einer gewissen Zeit der Nichtbenutzung wieder aus.
R10+ Beim Starten der Anwendung wird der anzuzeigende Zeitpunkt
auf den aktuellen Tag gesetzt.
4.2
Nichtfunktionale Anforderungen
Die nichtfunktionalen Anforderungen legen fest, wie die Anwendung erweitert
werden muss, um mit Events umgehen zu k¨onnen.
R11+ Ein Zeitraum besteht aus Start- und Endzeitpunkt, welche ¨uber
das Datum und die Zeit (nur Stunden und Minuten) genau be-stimmt sind.
R12+ Ein Event besitzt die Eigenschaften eines Points of Interest, der
um einen Zeitraum erweitert wurde.
R13+ Die Zeit wird im 24-Stunden-Format angezeigt und gespeichert
und das Datum nach britischer Norm (dd-mm-yyyy) angezeigt.
R14+ Die Ontologien werden erweitert, um Events zu erm¨oglichen.
• Zur POI-Ontologie werden die Attribute hasStartDateTime
und hasEndDateTime zu einem POI hinzugef¨ugt, falls er einen
Event darstellt.
• Zur Base-Ontologie werden hasStartDateTime und hasEnd-DateTime zur Range des base:changesPoiProperty damit
der Zeitraum eines Events ge¨andert werden kann.
R15+ Anpassung der Methoden des Servers um Anfragen mit zeitlichem
Kontext durchzuf¨uhren.
4.3
Weitere Anforderungen
Die Anwendung soll an mehreren Stellen verfeinert werden, um die Anwen-dung besser benutzbar zu machen und den Anwender bei den einzelnen
4 ANFORDERUNGEN 11
Abbildung 3: Links: Suche nach POIs - Rechts: Erstellen eines POIs
R16+ In der POI-Suche ist es m¨oglich nach allen POIs im
Kartenaus-schnitt zu suchen, indem man das Suchfeld frei l¨asst. Dies ist nicht
intuitiv und so w¨are hier ein zus¨atzlicher Button
”Show all POIs“
angebracht (siehe Abbildung 3, linke Seite). Zudem sollte bei der Suche nach allen POIs ab einer bestimmten Zoomstufe eine War-nung an den Benutzer gegeben werden, dass nicht mehr alle Points of Interest angezeigt werden.
R17+ Nach dem Erstellen des POIs kann man in einer Detail-Ansicht
die zugeh¨origen Kategorien ansehen. Nicht klar wird hierbei, dass
es sich um Links handelt. So ¨offnet zum Beispiel ein Klick auf
” sta-dium“ den Ontologie-Editor. Diese Hyperlinks innerhalb der An-wendung sollten klarer hervorgehoben werden (siehe Abbildung 4,
linke Seite). Außerdem k¨onnte zum Beispiel ein zus¨atzliches Favicon
dem Benutzer anzeigen, wohin er mit dem Link springt.
R18+ Ein bestimmtes Konzept im Ontologie-Editor zu suchen ist
rela-tiv schwierig, da man eine sehr lange, zu scrollende Liste vorfindet (siehe Abbildung 4, rechte Seite). Hier sollte entweder eine textuelle
Suche m¨oglich sein, oder das Einschr¨anken durch Eingabe einzelner
4 ANFORDERUNGEN 12
Abbildung 4: Links: Detail-Ansicht eines POIs - Rechts: Ontologie-Editor
R19+ An der aktuellen Position - also der Mitte der Karte - sollte zur
Orientierung f¨ur den Benutzer ein Fadenkreuz eingeblendet werden.
R20+ All¨ubergreifend soll noch die Erh¨ohung der Stabilit¨at der
Anwen-dung im Fokus stehen. So dass zum Beispiel nicht beim kurzen Ver-bindungsabbruch des Internets die Anwendung sich komplett neu
synchronisiert und so den Arbeitsfluss des Anwenders st¨ort oder
komplett abbricht.
R21− Beim Erstellen eines Point of Interest k¨onnte eine Liste von
pas-senden Konzepten anhand des eingegebenen Namens vorgeschlagen werden. So dass in diesem Beispiel beim Klick in das leere
”
Ca-tegory“-Feld die Konzepte
”Soccer“ und ”Stadium“ aus dem
csx-Vokabular am Anfang der Vorschlagliste erscheinen (siehe Abbil-dung 3, rechte Seite).
R22− Auf Instanzdatenebene k¨onnte man eine Verkn¨upfung von POIs
mit weiteren Hintergrundinformation realisieren. So dass man f¨ur
Instanzen, wie zum Beispiel das Stadion aus dem obigen Beispiel
mit einem Link zur DBPedia mit weiteren Informationen f¨ur den
Benutzer anzureichern. Diese w¨urde man dann ¨uber die
sameAs-Beziehung mit den Instanzdaten verkn¨upfen (zum Beispiel: poi:
5 KONZEPT 13
5
Konzept
In diesem Kapitel werden die konzeptuellen Grundlagen f¨ur die Umsetzung
der Anforderungen festgelegt und erl¨autert. Der Fokus liegt auf der
Umset-zung der Events und der Entwurf der Zeitleistenansicht.
5.1
Event-basierte POIs
In Kapitel 3 haben wir festgelegt, dass sich Events ¨uber einen Zeitraum
defi-nieren. Dieser besteht aus einem Start- und einen Endpunkt. Sie bestehen aus
einem Datum und einer Uhrzeit, wobei die Granularit¨at der Zeit auf Stunden
und Minuten beschr¨ankt wird. Es entspricht keinem Szenario Sekunden oder
noch kleinere Zeiteinheiten zu bestimmen, w¨are jedoch problemlos m¨oglich,
da wir die ISO8601-Kodierungsstandard2f¨ur das Speichern eines Zeitpunktes
verwenden.
Um die Events von den bisher ¨ublichen Points of Interest abzuheben und
deutlich zu machen, dass es sich um eine Erweiterung handelt, f¨uhren wir den
neuen Namespace gle, was f¨ur
”geo located event“ steht, ein. Dabei soll dies
klar machen, dass es sich um einen Event handelt, der sowohl eine zeitliche
Ausdehnung besitzt, als auch r¨aumlich klar definiert ist. F¨ur die r¨aumliche
Ausdehnung und die weiteren bestehenden Eigenschaften eines bisherigen
POIs ¨ubernehmen wir die bisherigen Attribute. Neu hinzu kommt die
zeitli-che Ausdehnung und dies modellieren wir, indem wir zu einem POI zwei neue
Attribute gle:hasStartDateTime und gle:hasEndDateTime hinzuf¨ugen.
Festlegung 2 (Unterscheidung POI - Event) Wenn ein Point of Inte-rest die beiden Attribute gle: hasStartDateTime und gle: hasEndDateTime besitzt, so handelt es sich um einen Event. Er kann entweder keines der At-tribute besitzen oder beide.
In der Abbildung 5 ist eine Instanz eines Events dargestellt. Dort sind die
bisherigen Attribute eines Points of Interest vorhanden und zus¨atzlich der
Start- und Endzeitpunkt. Die Abfrage, ob ein POI ein Event ist wird somit ¨
uber das Vorhandensein eines der beiden Attribute gepr¨uft. Die zeitlichen
Attribute zeigen auf xsd:dateTime-Knoten, welche nach ISO 8601 Norm formatiert sind2.
Dadurch, dass die ¨Anderungen nur zus¨atzlich sind, bedarf es keiner
An-passung bei der Verwendung von bisherigen POIs. Auch wenn die ¨Anderungen
nur aus zwei zus¨atzlichen Attributen bestehen, bieten sie den vollen
Funkti-onsumfang, den wir in den Anforderungen definiert haben.
5 KONZEPT 14
... gle:199 gle:200 gle:201 … "62.40"^^xsd:decimal
"7.605639696"^^xsd:decimal
"50.364100268"^^xsd:decimal „2009-11-01 08:00:00"^^xsd:dateTime
"Gauklerfest am deutschen Eck"^^xsd:string http://linkedgeodata.org/triplify/way/27426031#id voc:Celebration „2009-12-01 08:00:00"^^xsd:dateTime geo:lat geo:long geo:alt gle:hasStartDateTime rdf:type owl:sameAs rdfs:label gle:hasEndDateTime gle:141 gle:hasSubevent
Abbildung 5: geo located event Ontologie, welche einen Event mit Start- und Enddatum und einer gle:belongsTo-Beziehung, visualisiert
Falls f¨ur einen Event eines der beiden Daten unbekannt ist und der
An-wender aber trotzdem einen Zeitraum angeben m¨ochte (siehe 2.3), wird der
Startzeitpunk auf das Jahr 0 gesetzt bzw. der Endzeitpunkt auf das Jahr 3000, welche als Konstanten im System abgelegt sind. Damit ist sicherge-stellt, dass die allgemeine Festlegung eingehalten wird, aber auch Events
mit maximal einem offenen Zeitpunkt angelegt werden k¨onnen. Innerhalb
der Anwendung und auch der Visualisierung m¨ussen diese Events jedoch
be-sonders behandelt werden. So sollte zum Beispiel bei der Visualisierung des Zeitraums nicht angezeigt werden, dass dieser Event den Endpunkt im Jahr 3000 besitzt, sondern, dass dieser unbestimmt ist.
M¨oglich ist es aber auch, einen Event anzulegen, der keine zeitliche
Aus-dehnung besitzt, sondern nur einen Zeitpunkt markiert. Dies wird in der
An-wendung dadurch erm¨oglicht, dass der Benutzer nur einen Zeitpunkt eingibt.
Dieser Zeitpunkt wird dann sowohl in den Start- als auch in den Endzeit-punkt eingetragen.
Durch diese Konzipierung der Events sind alle Szenarien abgedeckt und
es ergeben sich f¨ur den Anwender beliebige M¨oglichkeiten den
Zeitpunkt-bzw. Raum festzulegen.
Eine Erweiterung dieses Konzeptes der Events ist m¨oglich, indem
5 KONZEPT 15
So k¨onnte man als Beispiel ein Festival mit mehreren B¨uhnen und
Veranstal-tungsorten annehmen, welches aus mehreren Auftritten und Shows besteht und so einen großen Event, der die einzelnen Events beinhaltet, darstellt. Die Umsetzung dieser Idee auf Ontologie-Basis sieht dann so aus, dass ein Event
ein optionales Attribut gle:hasSubevent erh¨alt, welches auf einen weiteren
Event zeigt (siehe Abbildung 5). Durch die Anordnung der Teile Subjekt,
Pr¨adikat und Objekt eines Tripels kann man eine Richtung ablesen. So geh¨ort
der Teilevent im Subjekt zu dem gr¨oßeren Event im Objekt. Somit ist auch
eine ¨Uberpr¨ufung, welches der Teilevent ist und welches der ¨ubergeordnete
Event ist, m¨oglich. Die Kardinalit¨at des Attributs gle:hasSubevent ist
be-liebig. Das heißt, dass ein Event keine bis unendlich viele solcher Beziehungen
haben kann. Wobei nat¨urlich eine große Anzahl von diesen Beziehungen f¨ur
5 KONZEPT 16 csxPOI-TimeLine 8:35 PM 1/1/ 2008 20091/1/ < > < > Back to mapview
Abbildung 6: Erster Entwurf der Zeitleistenansicht
5.2
Visualisierung von Events
Um Events zu visualisieren und mit ihnen zu interagieren bedarf es einer
In-tegration dieser in csxPOI. Daf¨ur wurde eine
”Zeitleistenansicht“ entwickelt,
die dem Benutzer eine chronologische ¨Ubersicht ¨uber gesuchte Ereignisse
lie-fern soll. Folgende Eigenschaften sollen beim Konzipieren im Vordergrund stehen:
• Schneller ¨Uberblick ¨uber die gesuchten Events.
• Darstellung der Events entsprechend ihrer zeitlichen Ausdehnung.
• Einfache Bedienung der Zeitleiste und keine ¨Uberfrachtung mit
Be-dienelementen.
Um diesen Anforderungen an die Zeitleiste gerecht zu werden, wurden
mehrere Entw¨urfe f¨ur diese erstellt. Der erste Entwurf ist in Abbildung 6
zu sehen. Es wurde nach dem Grundsatz
”Overview first, zoom and filter,
details on demand“ von Shneiderman [8] konzipiert. Dies wird klar, da zuerst
eine ¨Ubersicht ¨uber alle Events im gesuchten Zeitraum dargestellt wird und
der Anwender mit den Bedienelementen weiter nach seinen Bed¨urfnissen die
Ansicht einschr¨anken kann. Die Zeitleistenansicht besteht aus einem großen
Visualisierungsbereich und einer Zeitleiste mit Bedienelementen. Die Zeitlei-ste am unteren Rand beZeitlei-steht aus dem Start- und Endpunkt und dazwischen
einer Skala. Die Bedienelemente zur Einstellung der Zeitpunkte f¨ur Start
5 KONZEPT 17
Abbildung 7: Zweiter Entwurf der Zeitleistenansicht
man den Zeitpunkt einfach verschieben kann. Das aktuelle Datum wird im mittleren Button angezeigt. Bei einem Druck auf den Button mit der Zeit ¨
offnet sich ein Popup, welches es erm¨oglicht, Datum und Zeit mittels der
Android-Widgets DatePicker3 und TimePicker4 genau einzugeben. Oberhalb
dieser Skala befinden sich die Events, welche mit einem Stern gekennzeichnet
sind und ¨uber einen Balken die L¨ange des Zeitraums darstellen. Durch einen
Klick auf einen Event ist es m¨oglich weitere Details abzufragen. Die vertikale
Anordnung der Events besitzt keine Semantik und ist so nicht logisch. Des-weiteren ist es schwierig die Bedienelemente der Zeitleiste mit einem Finger
auf einem kleinen Display zu bet¨atigen. So dass sich dieser Designentwurf f¨ur
die Umsetzung der Zeitleiste nicht eignet.
Ein weiterer Entwurf, der die Schw¨achen des ersten Ansatzes beachtet
und probiert diese zu vermeiden ist in Abbildung 7 zu finden. Diese An-sicht ist zweigeteilt. Im oberen Teil befindet sich der Zeitstrahl, auf dem die Events platziert sind. Die Ausdehnung des Zeitstrahls ist flexibel und
um-fasst in diesem Beispiel einen Tag. Unter dem Zeitstrahl sind drei gr¨oßere
Bedienelemente zu sehen, welche einem Rad nachempfunden sind und sich
nach links und rechts unbegrenzt scrollen lassen. Sie stehen f¨ur die Auswahl
des Monats, der Woche oder des Tages, der auf dem Zeitstrahl angezeigt wird. Diese Dreiteilung ist der TimeZoom-Anwendung [4] nachempfunden,
3
http://developer.android.com/reference/android/widget/DatePicker.html
4
5 KONZEPT 18 csxPOI 8:35 PM 04 Feb Jan Mar 03 05 2010
Abbildung 8: Dritter Entwurf der Zeitvisualisierung- und auswahl
welche auch eine vertikale Anordnung der verschiedenen Granularit¨aten
be-sitzt. Somit l¨asst sich die Aufl¨osung des Zeitstrahls anpassen und kann also
einen dieser Zeitr¨aume umfassen. Die jeweils aktuelle Zeitspanne wird
farb-lich markiert. Die einzelnen Scrollbalken sind aneinander gekoppelt, so dass wenn man zum Beispiel das Monatsrad um einen Monat weiterdreht, das
Wochenrad sich anpasst. Links neben den Scrollr¨adern ist die Anzeige des
aktuell eingestellten Wertes zu finden. Dieser Ansatz l¨asst sich durch die
gr¨oßeren Bedienelemente leichter bedienen und ist somit f¨ur die Darstellung
auf einem mobilem Endger¨at besser geeignet. Jedoch kann man die zu
vi-sualisierende Zeitspanne nicht mehr so genau einstellen und ist auf die drei
vordefinierten Zeitr¨aume Tag, Woche, Monat angewiesen. Außerdem kann
es problematisch werden, sehr viele Events auf dieser Zeitleiste darzustellen,
da diese sich dann ¨uberlappen und eine genaue Auswahl eines Events sehr
schwer m¨oglich sein wird. Die Dauer eines Events wird in diesem Entwurf
auch nicht mehr dargestellt, l¨asst sich aber ¨uber einen Klick auf den Event
anzeigen.
Jedoch beherbergt auch dieser zweite Entwurf, wie eben erw¨ahnt, einige
Probleme, so dass das dritte Design die Zeitleistenansicht in die Kartenan-sicht integriert (siehe Abbildung 8). In dieser AnKartenan-sicht sind nun die Karten-und Zeitansicht verschmolzen. Wenn man mit dem Finger auf den oberen
Bereich der Karte klickt, erscheinen die Zeitr¨ader am oberen Rand des
5 KONZEPT 19
wieder. Diese Zeitr¨ader sind Bedienelemente, die sich beliebig schnell und
weit horizontal in beide Richtungen drehen lassen. Innerhalb dieser wird der
aktuell gew¨ahlte Zeitpunkt visualisiert. Dabei ist die eingestellte Zeitspanne
immer die, die auf dem unteren R¨adchen zu erkennen ist. In dem Beispiel
aus der Abbildung 8 w¨are dies nun der Zeitraum von Januar bis M¨arz 2010.
Points of Interest – als Punkte ohne Zeitausdehnung – werden wie gewohnt
als gelbe Sterne dargestellt und ¨andern sich auch nicht bei der Ver¨anderung
des Zeitraums am oberen Rand.
Die Events unterscheiden sich von den POIs auf der Karte durch die unterschiedliche Farbe. Sie sind blau dargestellt und je nach zeitlicher Di-stanz zum eingestellten Zeitraum opak bis transparent. Wobei Events, die vor dem eingestellten Zeitraum beginnen, nicht dargestellt werden. Durch
diese Kodierung kann der Benutzer ein Gef¨uhl daf¨ur bekommen, wann ein
Event stattfindet. Außerdem ist die Lage des Events gleich ersichtlich.
Also haben wir in diesem Entwurf die St¨arken des ersten Entwurfs – ¨
uber-sichtliche Darstellung der Events und Visualisierung des Zeitpunkts und des
Zeitraums eines Events – und die St¨arken des zweiten Entwurfs – einfache
Bedienung und eine klare ¨ubersichtliche Darstellung – vereint. Außerdem
be-steht f¨ur den Anwender nun nicht mehr die Notwendigkeit zwischen mehreren
Ansichten zu wechseln und erm¨oglicht damit einen runderen Arbeitsablauf.
Es gibt aber immer noch Schwachstellen, wie zum Beispiel die unflexiblere
Einstellung des Anzeigezeitraums. Diesen k¨onnte man aber als eine
Einstel-lung im Optionenmen¨u f¨ur den Anwender ausw¨ahlbar machen.
Somit ist die Zeitleistenansicht – urspr¨unglich als eigene Ansicht gedacht
– mit der Kartenansicht verschmolzen und bietet nach dieser Evolution der
Ansichten einen guten Kompromiss f¨ur den Anwender zwischen Bedienung,
Visualisierung und Einfachheit.
Bei der prototypischen Entwicklung dieses Widgets wurde ersichtlich, dass das dritte, soeben vorgestellte Konzept nicht gut zu bedienen ist. So zeigte
sich, dass die r¨aumlich nahe Anzeige des ausgew¨ahlten Zeitpunktes auf dem
Touchscreen unpraktikabel ist. Der Benutzer verdeckt mit seinem Finger die
Anzeige des Datums und kann somit die R¨uckmeldung nicht sehen.
Bes-ser ist es hier, die R¨uckkopplung getrennt von der Eingabe anzuzeigen. Aus
demselben Grund – dass man die R¨uckmeldung nicht sehen kann – ist es
nicht praktikabel, das Zeitauswahl-Widget am oberen Rand der Anwendung zu platzieren. Denn der Anwender verdeckt dann die Karte und kann somit nicht die, sich bei Interaktion erneuernde, Anzeige der Events wahrnehmen.
5 KONZEPT 20
Abbildung 9: Verfeinerung des Konzepts des Zeitauswahl-Widgets Also wurde das Zeitauswahl-Widget an den unteren Rand der Anwendung
verschoben, wobei die Anzeige des aktuell gew¨ahlten Datums am oberen
Rand bestehen bleibt. Dadurch kann der Benutzer den aktuellen Zeitpunkt
ausw¨ahlen und gleichzeitig die sich aktualisierende Anzeige der Events und
die R¨uckkopplung der Anzeige in Form des gew¨ahlten Datums wahrnehmen.
Der Einfachheit und der Anwenderfreundlichkeit halber besteht das Zeit-auswahl-Widget nur noch aus einem Balken (siehe Abbildung 9). Denn der
zweite Balken bietet dem Benutzer keine zus¨atzliche Funktionalit¨at, sondern
verbraucht nur zus¨atzlichen Anzeigeraum. Außerdem ist es auf dem
Touchs-creen schwer zu bedienen, wenn man zwei solche Bereiche ¨ubereinander setzt.
So kann es vorkommen, dass man aus Versehen den falschen Bereich scrollt. Letztendlich besteht das Zeitauswahl-Widget also nur noch aus einem sensitivem Balken, mit dem man einen Zeitpunkt festlegen kann. Auf der Karte werden die Events dargestellt, die innerhalb von 30 Tagen nach diesem
Zeitpunkt stattfinden. Das aktuell gew¨ahlte Datum wird am oberen Rand
6 IMPLEMENTIERUNG 21
6
Implementierung
In diesem Kapitel wird die Implementierung und Umsetzung des Konzep-tes beschrieben. Dabei wird auf interessante Teile des Quellcodes genauer
eingegangen und dieser erl¨autert.
6.1
Erweiterung von csxPOI um Events
Dieser erste Teil der Implementierung besch¨aftigt sich mit der grundlegenden
Erweiterung der Anwendung – sowohl auf Client- als auch auf Serverseite
– um die M¨oglichkeit Events anzulegen, zu speichern, darzustellen und zu
ver¨andern.
6.1.1 Client-seitig
In Kapitel 3.1 wurde festgelegt, dass Events sich durch einen Start- und End-zeitpunkt auszeichnen. Nicht klar ist jedoch bis jetzt, wie dieser Java-seitig gespeichert wird. Hier in diesem Fall werden sie als private String-Attribute
der PoiWrapper-Klasse gespeichert. Dies ist deswegen so gew¨ahlt worden,
damit das Datum leicht per Http und innerhalb der Android-Anwendung als
primitiver Datentyp ¨ubertragen werden kann. Damit innerhalb der
Anwen-dung mit den Daten gearbeitet werden kann, gibt es die Helfermethoden:
1 p u b l i c s t a t i c S t r i n g f o r m a t T o I s o D a t e T i m e S t r i n g (int year , int month , int
day , int hour , int m i n u t e s )
2 p u b l i c s t a t i c S t r i n g f o r m a t I s o S t r i n g T o N i c e F o r m a t ( S t r i n g i s o S t r i n g )
3 p u b l i c s t a t i c C a l e n d a r g e t C a l e n d a r O f I s o S t r i n g ( S t r i n g i s o S t r i n g )
Diese formatieren entweder einzelne Datumsangaben zu einem String in ISO8601-Norm, einen solchen String in ein menschenlesbares Format oder ex-trahieren ein java.util.Calendar-Objekt aus einem ISO-formatierten String. Mithilfe dieser Methoden werden die Datums-Aufgaben innerhalb der
An-wendung gel¨ost. Zu beachten ist hierbei jedoch, dass die Monate eines
Calen-dar-Objekts von 0 (Januar) bis 11 (Dezember) laufen5.
Jede PoiWrapper-Instanz besitzt nun also die beiden Attribute
mStart-Date und mEndmStart-Date, welche standardm¨aßig mit einem leeren String
initia-lisiert werden.
Die csxPOI-Anwendung besteht aus mehreren Activities, welche die ein-zelnen Bestandteile – zum Beispiel die Kartenansicht, der POI-Inspector und der POI-Editor – der Anwendung ausmachen. Activities stellen die
Schnitt-stelle der Anwendung zum Benutzer dar: sie Schnitt-stellen Oberfl¨achen dar, k¨ummern
5
6 IMPLEMENTIERUNG 22
sich um Anwendereingaben und behandeln diese [2]. Um zwischen diesen
Ac-tivities die aktuelle Instanz des POIs zu ¨ubertragen, muss die
PoiWrapper-Klasse das Parcelable-Interface6 implementieren. Mit diesem Mechanismus
wird ein komplexes Objekt, hier in unserem Beispiel eine PoiWrapper-Instanz, in ihre Grunddatentypen aufgesplittet und kann so zwischen den Activities versendet werden. Hier musste also auch eine Erweiterung um die Start- und Endzeitpunkte vorgenommen werden.
Beim Speichern eines POIs m¨ussen nun auch Start- und Endzeitpunkt zur
HTTP-POST-Anfrage hinzugef¨ugt werden. Daf¨ur werden die Daten zwischen
den Geokoordinaten und den Kategorien eines Events mittels der Schl¨
ussel-w¨orter
”start“ und ”end“ hinzugef¨ugt:
1 S t r i n g u r l S t r i n g = C o n s t a n t s . R E S T _ A D D R E S S + " p o i s " + " ? n a m e = "
2 + E n c o d e r . u r l E n c o d e ( m N e w P o i . g e t N a m e () ) + " & u s e r = "
3 + E n c o d e r . u r l E n c o d e ( m U s e r I d ) + " & lat = " + m N e w P o i . g e t L a t i t u d e ()
4 + " & l o n g = " + m N e w P o i . g e t L o n g i t u d e () + " & alt = " + a l t i t u d e
5 + " & s t a r t = " + m N e w P o i . g e t S t a r t D a t e () + " & end = " + m N e w P o i . g e t E n d D a t e () ;
Also k¨onnen jetzt die Event-Daten in einer PoiWrapper-Instanz als
lo-kale Variablen gespeichert werden, mithilfe des Parcelable-Interfaces
zwi-schen den Activities der Anwendung ¨ubertragen werden und nun auch zum
Server hin ¨ubermittelt werden. Auf Client-Seite fehlt f¨ur die grundlegende
Erweiterung der Anwendung um Events noch das Empfangen von Server-Nachrichten. Hier wurde die Klasse PoiResponseHandler um zwei weitere
Abfragen bez¨uglich des Start- und Endzeitpunktes erweitert. Damit ist die
Erweiterung um Events auf Client-Seite vollst¨andig.
6.1.2 Server-seitig
Auch Teile des Servers mussten erweitert werden, um mit Events umgehen
zu k¨onnen. Auf dem Server csxpoi.isweb.uni-koblenz.de l¨auft ein
Apa-che Tomcat Servlet Container, welApa-cher die csxPOI-Serverkomponente und das Sesame Repository beinhaltet. Diese csxPOI-Serverkomponente kann per
HTTP-REST-Interface angefragt werden. Daf¨ur gibt es definierte Interfaces:
• GET Anfordern einer Ressource vom Server
• POST Neue Daten zu einer Ressource hinzuf¨ugen
• PUT Anlegen oder ¨Andern einer Ressource
• DELETE L¨oschen einer Ressource
6
6 IMPLEMENTIERUNG 23
Diese Anfragen werden mittels HTTP ¨ubertragen und die Antwort an den
Client wird als XML-Struktur ¨ubermittelt. F¨ur das Speichern eines Events
muss die doPost-Methode des Servlets angepasst werden. So werden die Da-ten des Events aus dem HttpServletRequest extrahiert und dann in der aktu-ellen PoiWrapper-Instanz auf dem Server gespeichert. Sind diese Daten
un-gleich dem leeren String – wurden also Zeitpunkte ¨ubertragen – werden die
Tripel f¨ur das Sesame-Repository generiert und der RepositoryConnection
hinzugef¨ugt. Somit sind die Zeitpunkte eines Events im Repository
gespei-chert.
Das ¨Andern eines Zeitpunktes bedurfte keiner Anpassung, da aufgrund
des kollaborativen Ansatzes der Anwendung vorhandene Attribute nicht
ge-l¨oscht werden, sondern nur das neue Attribut zus¨atzlich gespeichert wird.
Ei-ne zentrale Methode des Servers ist die intern h¨aufig benutzte
createFromUri-Methode: 1 p u b l i c s t a t i c P o i W r a p p e r c r e a t e F r o m U r i ( S t r i n g uri , 2 R e p o s i t o r y C o n n e c t i o n c o n n e c t i o n ) t h r o w s R e p o s i t o r y E x c e p t i o n , 3 M a l f o r m e d Q u e r y E x c e p t i o n , Q u e r y E v a l u a t i o n E x c e p t i o n , 4 N u m b e r F o r m a t E x c e p t i o n { 6 P o i W r a p p e r poi = n u l l; 8 // R e t r i e v e name , l a t i t u d e , l o n g i t u d e , a l t i t u d e , and o p t i o n a l e v e n t 9 // s t a r t and end : 10 T u p l e Q u e r y q u e r y = c o n n e c t i o n . p r e p a r e T u p l e Q u e r y ( Q u e r y L a n g u a g e . SPARQL , 11 " P R E F I X b a s e : < " + C o n s t a n t s . N S _ B A S E + " > " + " P R E F I X geo : < " 12 + C o n s t a n t s . N S _ G E O + " > " + " P R E F I X r d f s : < " 13 + C o n s t a n t s . N S _ R D F S + " > " + " P R E F I X gle : < " 14 + C o n s t a n t s . N S _ G L E + " > "
15 + " S E L E C T ? n a m e ? lat ? l o n g ? alt ? s t a r t ? end "
16 + " W H E R E { " + " ? poi a b a s e : Poi ; "
17 + " r d f s : l a b e l ? n a m e ; " + " geo : lat ? lat ; "
18 + " geo : l o n g ? l o n g ; " + " geo : alt ? alt . "
19 + " O P T I O N A L { ? poi gle : h a s S t a r t D a t e T i m e ? s t a r t . } "
20 + " O P T I O N A L { ? poi gle : h a s E n d D a t e T i m e ? end . } "
21 + " O P T I O N A L { ? r e m o v a l a b a s e : P o i R e m o v a l ; " 22 + " b a s e : a f f e c t s P o i ? poi . } " 23 + " F I L T E R (! b o u n d (? r e m o v a l ) ) " + " F I L T E R (? poi = < " 24 + uri + " >) } " + " L I M I T 1 ") ; 25 T u p l e Q u e r y R e s u l t r e s u l t = q u e r y . e v a l u a t e () ; 26 try { 27 if ( r e s u l t . h a s N e x t () ) { 28 B i n d i n g S e t b i n d i n g S e t = r e s u l t . n e x t () ; 29 poi = new P o i W r a p p e r () ; 30 poi . s e t U r i ( uri ) ; 31 poi . s e t N a m e ( b i n d i n g S e t . g e t V a l u e (" n a m e ") . s t r i n g V a l u e () ) ; 32 poi . s e t L a t i t u d e ( D o u b l e . v a l u e O f ( b i n d i n g S e t . g e t V a l u e (" lat ") 33 . s t r i n g V a l u e () ) ) ; 34 poi . s e t L o n g i t u d e ( D o u b l e . v a l u e O f ( b i n d i n g S e t . g e t V a l u e (" l o n g ") 35 . s t r i n g V a l u e () ) ) ; 36 poi . s e t A l t i t u d e ( D o u b l e . v a l u e O f ( b i n d i n g S e t . g e t V a l u e (" alt ") 37 . s t r i n g V a l u e () ) ) ; 38 if ( b i n d i n g S e t . h a s B i n d i n g (" s t a r t ") ) 39 poi . s e t S t a r t D a t e ( b i n d i n g S e t . g e t V a l u e (" s t a r t ") . s t r i n g V a l u e () ) ; 40 if ( b i n d i n g S e t . h a s B i n d i n g (" end ") )
6 IMPLEMENTIERUNG 24 41 poi . s e t E n d D a t e ( b i n d i n g S e t . g e t V a l u e (" end ") . s t r i n g V a l u e () ) ; 42 } 43 } f i n a l l y { 44 r e s u l t . c l o s e () ; 45 }
Zur SPARQL-Query wurden nun die optionalen Statement-Abfragen f¨ur
den Start- und den Endzeitpunkt hinzugef¨ugt. Diese m¨ussen mit dem Schl¨
ussel-wort
”OPTIONAL“ markiert sein, damit auch weiterhin POIs, welche genau
diese Attribute gle:hasStartDateTime und gle:hasEndDateTime nicht besit-zen trotzdem mit der Query gefunden werden. Und nur wenn die Variablen start oder end bei der Query gebunden worden sind, werden sie auch gespei-chert.
Als Antworten des Servers an den Client werden XML-Dateien verschickt. Diese beinhalten alle Daten, die der Client angefordert hat. Die Struktur die-ser XML-Dateien wird mittels eines
”Document Type Definition“-Dokumentes
(DTD) festgelegt. Auch dieses musste angepasst werden, so dass es nun wie-folgt aussieht:
1 < !E L E M E N T poi ( id , name , lat , long , alt , start , end , c a t e g o r i e s , e q u i v a l e n t s )? >
2 < !A T T L I S T poi s t a t u s ( s u c c e s s | f a i l u r e ) #R E Q U I R E D> 3 < !E L E M E N T id (#P C D A T A) > 4 < !E L E M E N T n a m e (#P C D A T A) > 5 < !E L E M E N T lat (#P C D A T A) > 6 < !E L E M E N T l o n g (#P C D A T A) > 7 < !E L E M E N T alt (#P C D A T A) > 8 < !E L E M E N T s t a r t (#P C D A T A) > 9 < !E L E M E N T end (#P C D A T A) > 10 < !E L E M E N T c a t e g o r i e s ( c a t e g o r y *) > 11 < !E L E M E N T c a t e g o r y ( n a m e ) > 12 < !A T T L I S T c a t e g o r y id C D A T A #R E Q U I R E D> 13 < !E L E M E N T e q u i v a l e n t s ( e q u i v a l e n t *) > 14 < !E L E M E N T e q u i v a l e n t E M P T Y> 15 < !A T T L I S T e q u i v a l e n t id C D A T A #R E Q U I R E D>
Hierbei werden die beiden Attribute start und end als zwingend voraus-gesetzt. Dies ist deswegen der Fall, da, auch wenn ein POI weder Start- noch Endzeitpunkt besitzt, diese mit einem leeren String vorinitialisiert worden
sind und hier dieser einfach ¨ubertragen wird. Dies bedeutet nicht viel
Over-head, aber erspart in der Programmierung etliche Abfragen auf den Wert
null. Außerdem k¨onnen so viele Methoden einfacher umgesetzt werden, da
diese lokalen Attribute immer vorhanden sind, jedoch halt dem leeren String entsprechen, wenn sie nicht vorhanden sein sollen.
Dies waren nun die gr¨oßeren Anpassungen auf Server-Seite. Events werden
mittels der doPost-Anfrage gespeichert und als Tripel im Sesame Repository
abgelegt. Außerdem k¨onnen diese nun aus der Datenbank gelesen und per
6 IMPLEMENTIERUNG 25
6.2
Zeitauswahl-Widget
Das Zeitauswahlwidget soll es dem Benutzer erm¨oglichen auf der
Kartenan-sicht nicht nur den Kartenausschnitt mit dem Finger zu scrollen, sondern auch
”durch die Zeit“ zu scrollen. Dies soll m¨oglichst intuitiv und einfach f¨ur
den Benutzer zu bedienen sein.
Dieses in Kapitel 5.2 beschriebene Zeitauswahl-Widget ist in dieser Form nicht im Android SDK vorhanden. Deswegen muss es selbst entwickelt
wer-den. Daf¨ur bietet es sich an, ein vorhandenes Widget zu erweitern um die
gew¨unschte Funktionalit¨at zu erreichen.
Die Anforderung an dieses Widget ist ein Balken, der vom Benutzer
ge-scrollt werden kann. Den Anforderungen am n¨achsten kommt das
SeekBar-Widget (siehe Abbildung 10). Diese SeekBar-Klasse wird erweitert und stellt dann die neue Klasse DateSeekBar dar.
Abbildung 10: SeekBar-Widget des Android SDK
Diese SeekBar7 verf¨ugt ¨uber einen aktuell gew¨ahlten Wert und einen
Be-reich, aus dem die Werte kommen. Der Benutzer kann den Knopf auf der
SeekBar verschieben und somit den gew¨ahlten Wert ver¨andern. F¨ur unsere
Anwendung ist es nicht sinnvoll, das Datum ¨uber einen begrenzten Slider
darzustellen. Denn das Datum soll ja beliebig weit ver¨andert werden und
nicht nur bis zu einem bestimmten Punkt, wie es die Ansicht der SeekBar suggeriert.
Somit bedarf es also zuerst einer grafischen Anpassung dieser SeekBar. Der Knopf soll nicht dargestellt werden und der Hintergrund angepasst wer-den. Dies kann mit den Befehlen aus Listing 1 erreicht werwer-den.
Listing 1: Anpassung der Darstellung der SeekBar
1 // set b a c k g r o u n d i m a g e 2 D r a w a b l e d = g e t R e s o u r c e s (). g e t D r a w a b l e ( R . d r a w a b l e . d a t e _ c h o o s e r ); 3 t h i s. s e t P r o g r e s s D r a w a b l e ( d ); 5 // r e m o v e t h u m b i m a g e 6 t h i s. s e t T h u m b (n u l l); 8 // set m a x i m u m v a l u e 9 t h i s. s e t M a x ( C o n s t a n t s . S E E K B A R _ R E S O L U T I O N );
In Abbildung 11 ist die Auswirkung dieser Anpassung der Darstellung zu sehen.
7
6 IMPLEMENTIERUNG 26
Abbildung 11: Angepasste SeekBar
Was nun noch fehlt ist die Implementierung der Funktionalit¨at. Dabei soll
es dem Anwender m¨oglich sein, auf einem beliebigen Punkt der angepassten
SeekBar eine
”Wischbewegung“ bzw. ein Scrollen in eine beliebige Richtung
vorzunehmen. Bei jedem ver¨anderten Wert soll die Karte aktualisiert und die
Darstellung der Events dem aktuell gew¨ahlten angepasst werden. Um diese
Interaktion mit der SeekBar zu verwirklichen, implementiert die angepasste
SeekBar-Klasse das OnSeekBarChangeListener-Interface8.
Listing 2: Implementierung des OnSeekBarChangeListener-Interface
1 p r i v a t e b o o l e a n f i r s t ; 2 p r i v a t e int s t a r t ; 4 @ O v e r r i d e 5 p u b l i c v o i d o n P r o g r e s s C h a n g e d ( S e e k B a r seekBar , int p r o g r e s s , 6 b o o l e a n f r o m U s e r ) { 7 // o n l y r e a c t to u s e r i n p u t 8 if ( f r o m U s e r ) { 9 // if it is the f i r s t c h a n g e of p r o g r e s s , r e m e m b e r the s t a r t p o i n t 10 if ( f i r s t ) { 11 f i r s t = f a l s e; 12 }
13 // a f t e r the f i r s t change , a d j u s t the c a l e n d a r and u p d a t e the v i e w
14 e l s e { 15 C s x P o i A c t i v i t y . m C a l . add ( C a l e n d a r . D A Y _ O F _ Y E A R , p r o g r e s s - s t a r t ); 16 C s x P o i A c t i v i t y . u p d a t e M a p O v e r l a y (); 17 C s x P o i A c t i v i t y . u p d a t e D a t e T e x t (); 18 } 19 s t a r t = p r o g r e s s ; 20 } 21 } 23 @ O v e r r i d e 24 p u b l i c v o i d o n S t a r t T r a c k i n g T o u c h ( S e e k B a r s e e k B a r ) { 25 f i r s t = t r u e; 26 }
F¨ur die Implementierung der Funktionalit¨at werden die drei Methoden
des OnSeekBarChangeListener-Interfaces onProgressChanged,
onStartTrack-ingTouch und onStopTrackonStartTrack-ingTouch ¨uberschrieben. Die Funktion
onProgress-Changed wird immer aufgerufen, wenn der Wert der SeekBar aktualisiert
wurde, jedoch aber auch beim ersten Ber¨uhren. Deswegen muss in der
Me-thode onStartTrackingTouch das Flag first auf wahr gesetzt werden. Wenn nun die Methode onStartTrackingTouch aufgerufen wird, muss dieses Flag abgefragt werden und falls es wahr ist, soll nur der Startwert gemerkt
wer-8
http://developer.android.com/reference/android/widget/SeekBar. OnSeekBarChangeListener.html
6 IMPLEMENTIERUNG 27
den. Bei jedem weiteren Ver¨andern des SeekBar-Wertes ist das Flag dann auf
falsch gesetzt und es wird die java.util.Calendar-Instanz der
CsxPoiActivi-ty, welche das aktuelle Datum beinhaltet, ver¨andert. Anschließend wird das
MapOverlay, welches die Grafiken f¨ur die POIs und Events darstellt, und die
Anzeige des Datums aktualisiert.
Somit ist sichergestellt, dass die Anzeige der Events bei jeder ¨Anderung
der SeekBar neu gezeichnet wird. Außerdem kann der Benutzer nun an einem beliebigen Punkt der SeekBar mit dem Scrollen starten und beliebig nach rechts oder links scrollen.
Um dann diese DateSeekBar auf der Kartenansicht darzustellen bedarf es einer Anpassung der Layout-XML-Datei der Kartenansicht. Mittels dieser Datei wird das Layout der einzelnen Activities von Android festgelegt. Die Anpassung des Layouts ist in Listing 3 dargestellt.
Listing 3: XML-Layout der Kartenansicht
1 ... 2 < de . u n i k o b l e n z . i s w e b . c s x p o i . I n t e r a c t i v e M a p V i e w 3 a n d r o i d : l a y o u t _ w i d t h =" f i l l _ p a r e n t " 4 a n d r o i d : l a y o u t _ h e i g h t =" f i l l _ p a r e n t " 5 a n d r o i d : e n a b l e d =" t r u e " 6 a n d r o i d : c l i c k a b l e =" t r u e " 7 a n d r o i d : i d =" @ + id / m a p _ v i e w " 8 a n d r o i d : a p i K e y =" 09 V 5 9 5 d I G r G S M P c 2 u b o - b q H 3 g v O o x q 0 t k E v F R O w "/ > 10 < R e l a t i v e L a y o u t x m l n s : a n d r o i d =
11 " h t t p : // s c h e m a s . a n d r o i d . com / apk / res / a n d r o i d "
12 a n d r o i d : o r i e n t a t i o n =" v e r t i c a l " 13 a n d r o i d : l a y o u t _ w i d t h =" f i l l _ p a r e n t " 14 a n d r o i d : l a y o u t _ h e i g h t =" w r a p _ c o n t e n t " 15 a n d r o i d : b a c k g r o u n d =" @ a n d r o i d : c o l o r / t r a n s p a r e n t " 16 a n d r o i d : p a d d i n g =" 5 px "> 17 < R e l a t i v e L a y o u t 18 a n d r o i d : o r i e n t a t i o n =" h o r i z o n t a l " 19 a n d r o i d : l a y o u t _ w i d t h =" f i l l _ p a r e n t " 20 a n d r o i d : l a y o u t _ h e i g h t =" w r a p _ c o n t e n t " 21 a n d r o i d : l a y o u t _ a l i g n P a r e n t T o p =" t r u e "> 22 < B u t t o n 23 a n d r o i d : i d =" @ + id / t e x t D a t e " 24 a n d r o i d : g r a v i t y =" c e n t e r _ h o r i z o n t a l " 25 a n d r o i d : l a y o u t _ w i d t h =" w r a p _ c o n t e n t " 26 a n d r o i d : l a y o u t _ h e i g h t =" w r a p _ c o n t e n t " 27 a n d r o i d : t e x t C o l o r =" @ a n d r o i d : c o l o r / b l a c k " 28 a n d r o i d : t e x t S i z e =" 9 pt " 29 a n d r o i d : l a y o u t _ a l i g n P a r e n t L e f t =" t r u e "/ > 30 < de . u n i k o b l e n z . i s w e b . c s x p o i . H e l p B u t t o n 31 a n d r o i d : i d =" @ + id / h e l p B u t t o n " 32 a n d r o i d : g r a v i t y =" c e n t e r _ h o r i z o n t a l " 33 a n d r o i d : l a y o u t _ w i d t h =" w r a p _ c o n t e n t " 34 a n d r o i d : l a y o u t _ h e i g h t =" w r a p _ c o n t e n t " 35 a n d r o i d : l a y o u t _ a l i g n P a r e n t R i g h t =" t r u e " 36 a n d r o i d : v i s i b i l i t y =" i n v i s i b l e "/ > 37 < / R e l a t i v e L a y o u t > 38 < S e e k B a r 39 a n d r o i d : i d =" @ + id / p l a c e h o l d e r S e e k b a r " 40 a n d r o i d : l a y o u t _ w i d t h =" w r a p _ c o n t e n t "
6 IMPLEMENTIERUNG 28 41 a n d r o i d : l a y o u t _ h e i g h t =" 40 px " 42 a n d r o i d : l a y o u t _ a l i g n P a r e n t B o t t o m =" t r u e "/ > 43 < de . u n i k o b l e n z . i s w e b . c s x p o i . D a t e S e e k B a r 44 a n d r o i d : i d =" @ + id / d a t e S e e k b a r " 45 a n d r o i d : l a y o u t _ w i d t h =" f i l l _ p a r e n t " 46 a n d r o i d : l a y o u t _ h e i g h t =" 45 px " 47 a n d r o i d : p a d d i n g T o p =" 5 px " 48 a n d r o i d : p a d d i n g B o t t o m =" 10 px " 49 a n d r o i d : m a x =" 20 " 50 a n d r o i d : p r o g r e s s =" 0 " 51 a n d r o i d : l a y o u t _ a b o v e =" @ + id / p l a c e h o l d e r S e e k b a r "/ > 52 < / R e l a t i v e L a y o u t > 53 ...
Die MapView kann um maximal ein Child-Element erweitert werden, so
dass als Child-Element ein RelativeLayout9 verwendet wird, welches die
wei-teren Bestandteile kapselt. Dies sind ein weiteres RelativeLayout-Element, welches am oberen Rand angeordnet ist (android:layout_alignParentTop= "true"). Dieses beinhaltet den Button, der das Datum anzeigt und einen
Button, der Informationen f¨ur den Benutzer bereit h¨alt. Anschließend folgt
ein SeekBar-Element, welches am unteren Rand angeordnet ist (android:
layout_alignParentBottom="true") und¨uber diesem befindet sich die
Da-teSeekBar. Die SeekBar, die am unteren Ende platziert ist, ist nur ein Platz-halter und wird in der Anwendung auf nicht sichtbar gestellt. Denn am unte-ren Ende der Karte befinden sich die Buttons zum Zoomen der Karte. Damit
diese nicht von der DateSeekBar ¨uberlagert werden, wurde dieser Platzhalter
hinzugef¨ugt.
9
http://developer.android.com/reference/android/widget/RelativeLayout. html
6 IMPLEMENTIERUNG 29
6.3
Anzeige der Events
Nachdem nun die Infrastruktur in Kapitel 6.1 um Events erweitert wurde
und in Kapitel 6.2 die M¨oglichkeit geschaffen wurde, auf der Kartenansicht
ein Datum einzustellen, sollen Events nun auch entsprechend auf der Karte dargestellt werden.
Eines der Anforderungen lautete, dass die Events sich auf der Karte von
POIs unterscheiden sollen. Dies wird so umgesetzt, dass f¨ur Events ein
an-deres OverlayItem10 auf der Karte dargestellt wird. Die Grafiken der POIs
und Events, die auf der Karte angezeigt werden, sind in einem
Itemized-Overlay11 zusammengefasst. Dieses organisiert das Anordnen, Sortieren und
Zeichnen der hinzugef¨ugten OverlayItems. Das entsprechende OverlayItem
erzeugt jedoch jeder einzelne PoiWrapper f¨ur sich.
Dies wurde nun ausgenutzt, um das ItemizedOverlay (fast) unangetastet zu lassen und nur die getOverlayItem-Methode der PoiWrapper-Klasse an-zupassen (siehe Listing 4).
Listing 4: getOverlayItem() der PoiWrapper-Klasse
1 /* *
2 * G e t s a map o v e r l a y i t e m r e p r e s e n t i n g the POI or the e v e n t .
3 *
4 * @ r e t u r n a map o v e r l a y i t e m r e p r e s e n t i n g the POI
5 */ 6 p u b l i c O v e r l a y I t e m g e t O v e r l a y I t e m () { 7 if (t h i s. i s E v e n t ()) { 8 r e t u r n new E v e n t O v e r l a y I t e m (new G e o P o i n t ( 9 (int) ( m L a t i t u d e C o n s t a n t s . M D _ F A C T O R ) , 10 (int) ( m L o n g i t u d e C o n s t a n t s . M D _ F A C T O R )) , mName , n u l l); 11 } e l s e { 12 r e t u r n new P o i O v e r l a y I t e m (new G e o P o i n t ( 13 (int) ( m L a t i t u d e C o n s t a n t s . M D _ F A C T O R ) , 14 (int) ( m L o n g i t u d e C o n s t a n t s . M D _ F A C T O R )) , mName , n u l l); 15 } 16 }
Die Methode getOverlayItem() liefert ein EventOverlayItem zur¨uck, falls
die aktuelle PoiWrapper-Instanz ein Start- oder ein Endzeitpunkt hat, also einen Event darstellt. Falls dies nicht der Fall ist, wird ein PoiOverlayItem –
wie bisher – zur¨uckgegeben. POIs werden auf der Karte als gelbe, konstante
Sterne angezeigt. Dagegen wird f¨ur Events eins von elf m¨oglichen
Stern-Symbolen dargestellt. Und zwar wird je nach Distanz des Event-Startdatums
zum gerade eingestellten Datum die Tranzparenz des Symbols ver¨andert.
Daf¨ur gibt es zehn verschiedene Abstufungen – von komplett opak bis zu
10 http://code.google.com/intl/de-DE/android/add-ons/google-apis/ reference/com/google/android/maps/OverlayItem.html 11 http://code.google.com/intl/de-DE/android/add-ons/google-apis/ reference/com/google/android/maps/ItemizedOverlay.html
6 IMPLEMENTIERUNG 30
Abbildung 12: Abstufungen der Event-Symbole nach Zeit
komplett transparent (siehe Abbildung 12). Findet ein Event jedoch gerade statt, liegt also das Startdatum vor dem aktuellen Datum und das Enddatum
danach, wird ein besonderer Marker f¨ur diesen Event dargestellt: ein Stern
mit einem Verlauf von Blau zu Rot.
Die Klasse EventOverlayItem berechnet die Differenz zwischen den bei-den java.util.Calendar-Instanzen: das mit dem Zeitauswahl-Widget aktuelle Datum und das Startdatum des Events. Anhand der Differenz wird dann das passende Symbol ausgesucht und als Marker gesetzt. Wenn nun das Start-Datum vor dem aktuellen Start-Datum liegt, aber das Enddatum noch nach dem Datum liegt, wird der Event mit einem opaken Stern, der einen Verlauf von Blau zu Rot beinhaltet, dargestellt. Wichtig hierbei anzumerken ist, dass im Listing 5 auch das Flag mActive gesetzt wird. Dieses Flag gibt an, ob ein
OverlayItem auf der Karte angeklickt werden kann. Dies soll n¨amlich nicht
der Fall sein, wenn ein Event entweder vor oder mehr als eine bestimmte An-zahl von Tagen nach dem aktuellen Datum startet. Ist dies der Fall, wird der Alpha-Wert auf 0 gesetzt und das Flag mActive auf false. Somit wird es nicht
angezeigt und beim Klicken auf der Karte nicht ber¨ucksichtigt. Somit kann
nun ein Datum mittels des Zeitauswahl-Widgets ausgew¨ahlt werden und die
6 IMPLEMENTIERUNG 31 Listing 5: EventOverlayItem-Klasse 1 p u b l i c c l a s s E v e n t O v e r l a y I t e m e x t e n d s O v e r l a y I t e m { 2 p u b l i c E v e n t O v e r l a y I t e m ( G e o P o i n t point , S t r i n g title , S t r i n g s n i p p e t ) { 3 s u p e r( point , title , s n i p p e t ); 4 C a l e n d a r cal = ( C a l e n d a r ) C s x P o i A c t i v i t y . m C a l . c l o n e (); 5 C a l e n d a r p o i S t a r t C a l = H e l p e r s . g e t C a l e n d a r O f I s o S t r i n g ( m S t a r t D a t e );
6 int d e l t a S t a r t D a y s = (int) H e l p e r s . d a y s B e t w e e n ( cal , p o i S t a r t C a l );
7 D r a w a b l e m a r k e r = n u l l;
8 // e v e n t s t a r t d a t e is a f t e r the c u r r e n t set d a t e and l e s s t h e n
9 // D E L T A _ D A Y S off 10 if ( d e l t a S t a r t D a y s != -1 && d e l t a D a y s < C o n s t a n t s . D E L T A _ D A Y S ) { 11 int s t a r I n d e x = (int) M a t h . f l o o r ( d e l t a D a y s * 10 / 3 0 ) ; 12 s w i t c h ( s t a r I n d e x ) { 13 c a s e 0: 14 m a r k e r = ( D r a w a b l e ) I n t e r a c t i v e M a p V i e w . g e t M a p C o n t e x t () 15 . g e t R e s o u r c e s (). g e t D r a w a b l e ( R . d r a w a b l e . b t n _ s t a r _ 0 ); 16 b r e a k; 17 ... 18 c a s e 9: 19 m a r k e r = ( D r a w a b l e ) I n t e r a c t i v e M a p V i e w . g e t M a p C o n t e x t () 20 . g e t R e s o u r c e s (). g e t D r a w a b l e ( R . d r a w a b l e . b t n _ s t a r _ 9 ); 21 b r e a k; 22 } 23 m A c t i v e = t r u e; 24 }
25 // s t a r t d a t e is b e f o r e the c u r r e n t set date , but the end d a t e is
26 // a f t e r the c u r r e n t date , so the e v e n t d o e s c u r r e n t l y o c c u r
27 e l s e if ( H e l p e r s . d a y s B e t w e e n ( cal , H e l p e r s 28 . g e t C a l e n d a r O f I s o S t r i n g ( m E n d D a t e )) != -1) { 29 m a r k e r = ( D r a w a b l e ) I n t e r a c t i v e M a p V i e w . g e t M a p C o n t e x t () 30 . g e t R e s o u r c e s (). g e t D r a w a b l e ( R . d r a w a b l e . b t n _ s t a r _ 0 ); 31 m A c t i v e = t r u e; 32 }
33 // s t a r t and end d a t e of the e v e n t are b e f o r e the c u r r e n t set date ,
34 // so don ’ t s h o w t h i s e v e n t 35 e l s e { 36 m a r k e r = ( D r a w a b l e ) I n t e r a c t i v e M a p V i e w . g e t M a p C o n t e x t () 37 . g e t R e s o u r c e s (). g e t D r a w a b l e ( R . d r a w a b l e . b t n _ c i r c l e ); 38 m a r k e r . s e t A l p h a ( 0 ) ; 39 m A c t i v e = f a l s e; 40 } 41 m a r k e r . s e t B o u n d s (0 , 0 , m a r k e r . g e t I n t r i n s i c H e i g h t () , m a r k e r 42 . g e t I n t r i n s i c W i d t h ( ) ) ; 43 t h i s. s e t M a r k e r ( m a r k e r ); 44 } 45 }
6 IMPLEMENTIERUNG 32
6.4
Grafische Benutzungsoberfl¨
ache
Um mit den Events zu interagieren muss auch die Benutzungsoberfl¨ache um
einige Teile erweitert werden. So muss es die M¨oglichkeit geben Events zu
erstellen, zu editieren und auch wieder zu l¨oschen. Außerdem soll es m¨oglich
sein, zu einem POI den Zeitaspekt hinzuzuf¨ugen und aber auch bei einem
Event diesen Zeitaspekt wieder zu entfernen.
Implementiert wurde dies gr¨oßtenteils durch Erweitern der vorhandenen
Activities und Views. Neu entwickelte Activities sind die DatePickerActivity und die DateTimePickerActivity, wobei hierbei nun exemplarisch die
Date-PickerActivity vorgestellt wird. Wie der Name schon suggeriert, erm¨oglicht
diese Activity das Ausw¨ahlen eines Datums. Dabei soll dies durch einen
mo-dalen Dialog geschehen, der ¨uber der aufrufenden Activity erscheint. Die
Implementierung des Widgets ist so realisiert, dass die aufrufende Activity das aktuelle Datum versendet und dies dann im DatePicker gesetzt wird. Bei einem Klick auf
”Save“ wird das aktuell eingestellte Datum an die aufrufende
Activity zur¨uckgesandt und dort aktualisiert. ¨Ahnlich l¨auft es bei der
Date-TimePickerActivity, nur dass hier noch die M¨oglichkeit zum Einstellen einer
Uhrzeit besteht.
Um den weiteren Anforderungen aus Kapitel 4.3 gerecht zu werden,
wur-den noch zus¨atzliche Ver¨anderungen an der Benutzungsoberfl¨ache vollzogen.
So sind Links im POI-Editor und im Ontology-Browser nun unterstrichen dargestellt. Die statische Methode getUnderlinedString der Helpers-Klasse
aus Listing 6 liefert ein SpannableString-Objekt12, welches im Android-Kontext
einen formatierten String darstellt, den man einfach als Text setzen kann (sie-he Listing 7).
Listing 6: Erstellen eines unterstrichenen String
1 p u b l i c s t a t i c S p a n n a b l e S t r i n g g e t U n d e r l i n e d S t r i n g ( S t r i n g t o U n d e r l i n e ) {
2 S p a n n a b l e S t r i n g str = S p a n n a b l e S t r i n g . v a l u e O f ( t o U n d e r l i n e );
3 str . s e t S p a n (new U n d e r l i n e S p a n () , 0 , t o U n d e r l i n e . l e n g t h () , 0);
4 r e t u r n str ;
5 }
Listing 7: Setzen des unterstrichenen Strings
1 c a t e g o r y I t e m V i e w . s e t T e x t ( H e l p e r s . g e t U n d e r l i n e d S t r i n g ( c a t e g o r y . g e t N a m e ( ) ) ) ;
Eine weitere Anforderung war, dass sich die csxPOI-Anwendung zum Bei-spiel beim Drehen des Bildschirms nicht neu synchronisiert und dann dabei
h¨angen bleibt. Dies geschah deswegen, weil das Android-Betriebssystem bei
bestimmten Systemereignissen die aktuelle Anwendung schließt und anschlie-ßend neu startet. Dadurch wurde die Anwendung beim Drehen des Bild-schirms neu gestartet und hat sich aufgehangen. Damit dies nicht mehr der
12
6 IMPLEMENTIERUNG 33
Fall ist kann man im Android Manifest festlegen, welche Systemereignisse das Betriebssystem und welche die Anwendung behandeln soll. Beim Drehen des Bildschirms soll die Anwendung nicht neu gestartet werden, so dass dieses Ereignis von der Anwendung behandelt werden kann. Dazu wurde nun die CsxPoiActivity im Android Manifest wie in Listing 8 erweitert.
Listing 8: Festlegen der selbst zu behandelnden Ereignisse
1 < a c t i v i t y a n d r o i d : n a m e =" . C s x P o i A c t i v i t y " a n d r o i d :l a b e l=" @ s t r i n g / a p p _ n a m e " a n d r o i d : c o n f i g C h a n g e s =" o r i e n t a t i o n | k e y b o a r d | k e y b o a r d H i d d e n ">
Nun behandelt die csxPOI-Anwendung das Wechseln der Orientierung
des Ger¨ats selber, wobei dabei aber einfach nichts unternommen wird. Somit
7 PROTOTYP 34
Abbildung 13: Hauptansicht (links), Popup zum W¨ahlen des Datums (rechts)
7
Prototyp
Nachdem nun das Konzept der Erweiterung und dessen Implementierung vorgestellt wurden, soll nun der bei der Arbeit erweiterte Prototyp vorgestellt
werden. Dabei geht es darum, einen ¨Uberblick ¨uber die neuen Funktionen und
deren Umsetzung zu bekommen.
7.1
Zeitauswahl-Widget
Nach dem Starten der csxPOI-Anwendung sieht der Anwender die Karte als Hauptansicht (siehe Abbildung 13 links). Auf dem Button in der linken obe-ren Ecke ist das aktuelle Datum dargestellt. Events vor dem Datum oder mehr als 30 Tage nach diesem Datum werden auf der Karte nicht angezeigt. Die Darstellung des aktuellen Datums ist deswegen auf einem Button
dar-gestellt, damit es f¨ur den Benutzer klar wird, dass er auch auf das Datum
klicken kann. Durch einen Klick darauf ¨offnet sich ein Fenster um das Datum
einzustellen (siehe Abbildung 13 rechts). Dies stellt eine weitere M¨oglichkeit
dar, das Datum einzustellen und aber auch einfach zum heutigen Datum
zur¨uckzukehren. Wenn der Anwender das Datum um ein Jahr in die Zukunft
verschieben m¨ochte, m¨usste er auf dem Zeitauswahl-Widget sehr oft
7 PROTOTYP 35
Abbildung 14: Erstellen eines Events (links), Ge¨andertes Datum (rechts)
Bedienung und Umsetzung des Zeitauswahl-Widgets wurde schon in Kapitel 5.2 hinreichend beschrieben. Damit kann der Benutzer mit einem Finger das
Datum ver¨andern und gleichzeitig die sich aktualisierenden Events auf der
Karte betrachten.
7.2
Events anlegen und editieren
Um einen Event, respektive POI mit Zeitangabe, anzulegen tippt der
Benut-zer im Hauptmen¨u der Anwendung auf die Schaltfl¨ache
”Create POI“. Diese
Bezeichnung ist darauf zur¨uckzuf¨uhren, dass im mobilen Kontext nach wie
vor der Ort die dominante Rolle einnimmt. Außerdem gibt es f¨ur den
Anwen-der keine Einf¨uhrung von Events, sondern die Einf¨uhrung von Zeitaspekten
f¨ur Points of Interest. Somit ist die Bezeichnung der Schaltfl¨ache weiterhin
angebracht und sollte beim Anwender nicht f¨ur Verwirrung sorgen.
Wenn der Benutzer nun auf
”Create POI“ getippt hat, ¨offnet sich das
bisherige Fenster zum Anlegen eines POIs. Man kann hier nun einen Namen und Kategorien angeben. Nach einen Klick auf
”with date / time“ bietet sich
dem Benutzer ein ¨ahnliches Bild wie in Abbildung 14 links. Das Startdatum
ist vorausgef¨ullt mit dem aktuellen Datum und Uhrzeit und das Enddatum
24 Stunden sp¨ater. In dem Beispiel aus der Abbildung m¨ochten wir eine
