- Fischfauna

Transcrição

- Fischfauna

Fachbereich Elektrotechnik und Informatik der Hochschule Bremen
Internationaler Frauenstudiengang Informatik B.Sc.
Entwicklung einer mobilen Anwendung zur
Erfassung und Visualisierung von
Biodiversitätsdaten
Eine Erweiterung des Fachinformationssystems „Biodiversitätsatlas“
Bachelor-Thesis
von
Konstanze Magdalena Steinhausen
Matrikelnummer: 216589
Prangenstr. 85, 28203 Bremen
Tel.: 0421-84797074
E-Mail: [email protected]
Erstgutachterin:
Prof. Dr.-Ing. Heide-Rose Vatterrott
Zweitgutachter:
Prof. Dr. Heiko Brunken
Ausgabedatum:
28. November 2011
Abgabedatum:
30. Januar 2012
Kurzfassung
II
Kurzfassung
Der Internationale Studiengang Technische und Angewandte Biologie der Hochschule
Bremen betreut das Joomla!-basierte Fachinformationssystem Biodiversitätsatlas, welches
2006 dort entstand. Das Projekt wurde in den letzten Jahren weiterentwickelt und die
eingesetzte Technik aktualisiert.
Der Atlas kommt für diverse Lebensarten als Katalogisierungswerkzeug über mehrere
Länder hinweg zum Einsatz. Da das Frontend des Systems lediglich als Webanwendung für
den PC umgesetzt wurde, fehlt es an einer mobilen Lösung zur Erfassung und Visualisierung
von Biodiversitätsdaten, die dies schnell und anwenderfreundlich auch im Gelände
ermöglicht. Da Smartphones und Tablet-PCs verstärkt im Lebensalltag Einzug finden, bietet
sich eine mobile Anwendung für den Biodiversitätsatlas auf einer oder mehrerer der hier zur
Verfügung stehenden Betriebssystemplattformen an. Die prototypische Entwicklung dieser
Anwendung und die Schaffung einer Schnittstelle zum Atlas sind die Ziele dieser Arbeit. Die
mobile Anwendung soll wie das bereits implementierte Frontend des Biodiversitätsatlas die
Erfassung und Visualisierung von Biodiversitätsdaten ermöglichen. Dies soll um weitere
Smartphone spezifische Funktionen, wie der Ortungsfunktion oder dem Zugriff auf die
Kamera, ergänzt werden.
Einen theoretischen Schwerpunkt werden die Validierung der vorhandenen Entwicklungstools für die diversen Plattformen und die Analyse der umzusetzenden Softwarearchitektur
bilden. Die Ergebnisse dieser Studien bilden die Grundlage für das Realisierungskonzept
und die Implementierung der geplanten Anwendung.
Inhaltsverzeichnis
III
Inhaltsverzeichnis
Kurzfassung ................................................................................................................................ II
Inhaltsverzeichnis ...................................................................................................................... III
Abbildungsverzeichnis .............................................................................................................. VI
Tabellenverzeichnis ................................................................................................................ VIII
Abkürzungsverzeichnis ............................................................................................................ IX
Glossar...................................................................................................................................... XI
1.
2.
3.
Einleitung ............................................................................................................................. 1
1.1.
Motivation und Zielsetzung .......................................................................................... 1
1.2.
Gliederung der Arbeit ................................................................................................... 2
Der Biodiversitätsatlas ........................................................................................................ 3
2.1.
Architektur des Systems .............................................................................................. 3
2.2.
Nutzerrollen und Zugriffsberechtigungen..................................................................... 5
2.3.
Logischer Aufbau von Biodiversitätsdaten................................................................... 7
2.4.
Methoden der Erfassung von gesammelten Biodiversitätsdaten ................................ 9
Anforderungsanalyse ........................................................................................................ 10
3.1.
Allgemeine Übersicht und Voraussetzungen ............................................................. 10
3.1.1.
Nutzercharakterisierung ..................................................................................... 12
3.1.2.
Anwendungsszenario ......................................................................................... 13
3.2.
Funktionale Anforderung ............................................................................................ 14
3.2.1.
Erfassung eines Fundes ..................................................................................... 15
3.2.2.
Verwaltung von Funden ..................................................................................... 17
3.2.3.
Erfassung eines Fundortes ................................................................................ 17
3.2.4.
Visualisierung der GIS-Komponenten ................................................................ 18
3.2.5.
Nutzerauthentifizierung ...................................................................................... 19
3.2.6.
Optionale Einstellungen ..................................................................................... 19
3.3.
Nichtfunktionale Anforderungen................................................................................. 20
3.3.1.
Generelle nichtfunktionale Anforderungen......................................................... 20
3.3.2.
Datenübertragung ............................................................................................... 21
Inhaltsverzeichnis
4.
IV
3.3.3.
Distribution und Installation des Systems .......................................................... 22
3.3.4.
Mehrsprachigkeit ................................................................................................ 23
3.3.5.
Einzusetzende Technologien ............................................................................. 24
Aktuelle Techniken und Plattformen der mobilen Programmierung................................. 26
4.1.
Mobile Betriebssysteme ............................................................................................. 27
4.2.
Strukturen der mobilen Programmierung................................................................... 34
4.2.1.
Native Anwendungen ......................................................................................... 34
4.2.2.
Webanwendungen.............................................................................................. 35
4.2.3.
Hybride Anwendungen ....................................................................................... 37
4.2.4.
Mobile Widgets ................................................................................................... 37
4.2.5.
Plattformunabhängige Entwicklungstools .......................................................... 38
4.3.
Unterschiede in der Programmierung von Smartphone- und Tablet-PCAnwendungen............................................................................................................. 39
5.
Realisierungskonzept ........................................................................................................ 40
5.1.
Systemaufbau............................................................................................................. 40
5.1.1.
Zielplattform ........................................................................................................ 40
5.1.2.
Zielstruktur .......................................................................................................... 41
5.1.3.
Entwicklungsumgebung ..................................................................................... 41
5.1.4.
Client-Server Architektur .................................................................................... 42
5.1.5.
Einsatz von GIS .................................................................................................. 44
5.2.
Nutzerschnittstelle ...................................................................................................... 45
5.2.1.
Einsatz von UI Patterns ...................................................................................... 47
5.2.2.
Navigationspfad .................................................................................................. 48
5.3.
Funktionaler Aufbau ................................................................................................... 50
5.3.1.
Datenerfassung .................................................................................................. 50
5.3.2.
Schnittstelle zum Server..................................................................................... 53
5.3.3.
Nutzerauthentifizierung ...................................................................................... 55
5.3.4.
Mehrsprachigkeit ................................................................................................ 57
5.3.5.
Datenspeicherung .............................................................................................. 59
5.3.6.
Verwaltung der Daten ......................................................................................... 61
Inhaltsverzeichnis
5.3.7.
5.4.
6.
7.
V
Benutzerspezifische Konfiguration ..................................................................... 61
Grenzen und Einschränkungen ................................................................................. 62
Realisierung ...................................................................................................................... 63
6.1.
Aufbau des Android-Projektes ................................................................................... 63
6.2.
Erfassung eines Fundes ............................................................................................ 65
6.3.
Auswahl einer Spezies ............................................................................................... 67
6.4.
Einbindung von OSM ................................................................................................. 68
6.5.
Ermittlung der GPS-Koordinate ................................................................................. 69
6.6.
Meldung von Bildern ................................................................................................... 70
6.7.
Datenbank .................................................................................................................. 73
Zusammenfassung und Ausblick ...................................................................................... 76
Anhang A .................................................................................................................................. 78
Literaturverzeichnis .................................................................................................................. 79
Anmerkung: Auf Grund der besseren Lesbarkeit wird im Text dieser Arbeit der Einfachheit
halber nur die männliche Form der Bezeichnung „Nutzer“ verwendet. Die weibliche Form ist
selbstverständlich immer mit eingeschlossen.
Abbildungsverzeichnis
VI
Abbildung 1: 3-Schichtenarchitektur des Biodiversitätsatlas ..................................................... 4
Abbildung 2: Nutzertypen des Biodiversitätsatlas in Bezug auf ihre Rechte ............................ 6
Abbildung 3: Logische Zusammensetzung eines Fundes ......................................................... 8
Abbildung 4: Einordnung des mobilen Clients in das Gesamtsystem ..................................... 11
Abbildung 5: Anwendungsprozess ........................................................................................... 14
Abbildung 6: Erfassungsprozess.............................................................................................. 14
Abbildung 7: Überblick über den Vertrieb und die Nähe zur Plattform der mobilen
Anwendungsarten ............................................................................................... 26
Abbildung 8: Android Architecture............................................................................................ 29
Abbildung 9: Dauer der Einarbeitung in die verschiedenen Plattformen ................................ 30
Abbildung 10: Marktverteilung der Android-Versionen (Stand: 01. Dezember 2011)............. 31
Abbildung 11: Architektur von iOS ........................................................................................... 33
Abbildung 12: Neue Gesamtarchitektur ................................................................................... 42
Abbildung 13: Direkte Client-Server-Kommunikation über Sockets ........................................ 43
Abbildung 14: Alternative Client-Server-Kommunikation unter Nutzung eines Wrappers ...... 44
Abbildung 15: Lebenszyklus einer Activity ............................................................................... 46
Abbildung 16: Dashboard (UI Patterns) ................................................................................... 47
Abbildung 17: Action Bar (UI Patterns) .................................................................................... 48
Abbildung 18: Nutzerpfad der mobilen Anwendung ................................................................ 49
Abbildung 19: Struktur eines gespeicherten Passwortes in Joomla! ...................................... 56
Abbildung 20: Speicherung von Ressourcen (Beispiel 1) ....................................................... 58
Abbildung 21: Speicherung von Ressourcen (Beispiel 2) ....................................................... 58
Abbildung 22: Struktur des Android-Projektes ......................................................................... 64
Abbildung 23: Deklarierung der Main-Activity HomeDashboard ............................................. 65
Abbildung 24: RecordNewActivity ............................................................................................ 66
Abbildung 25: Strukturierung eines Fundes mittels Java-Klassen .......................................... 67
Abbildung 26: SpeciesLIstActivity ............................................................................................ 68
Abbildung 27: LocationMapActivity .......................................................................................... 69
VII
Abbildung 28: Initialisierung der Ermittlung der aktuellen Position über GPS ........................ 70
Abbildung 29: Aufruf der Kamerafunktion ................................................................................ 70
Abbildung 30: Aufruf der Bildergalerie ..................................................................................... 71
Abbildung 31: Auswertung des Intents (Bildergalerie) ............................................................. 71
Abbildung 32: Zuordnung von Bildern zu einem Fund ............................................................ 72
Abbildung 33: Struktur des Anforderungsstrings zum Senden von Bildern ............................ 72
Abbildung 34: Datenbankmodell .............................................................................................. 73
Abbildung 35: Einfügen eines Datensatzes in die Datenbank................................................. 74
Abbildung 36: Abrufen von Datenbankeinträgen ..................................................................... 75
Tabellenverzeichnis
VIII
Tabellenverzeichnis
Tabelle 1: Status eines Fundes ................................................................................................ 54
Tabelle 2: Methoden zur Speicherung von Daten in Android .................................................. 60
Abkürzungsverzeichnis
ADT
Android Development Tools
API
Application Programming Interface, Programmierschnittstelle
CMS
Content Management System, Inhaltsverwaltungssystem
CSS
Cascading Style Sheets
GIS
Geoinformationssystem
GNU GPL
GNU General Public License
GPS
Global Positioning System
INI
Initialisierungsdatei
ISO
Internationale Organisation für Normung
JSON
JavaScript Object Notation
MD5
Message Digest
MIME
Multipurpose Internet Mail Extensions
NFC
Near Field Communication
OSM
OpenStreetMap
PDA
Personal Digital Assistant
REST
Representational State Transfer
RPC
Remote Procedure Call
SDK
Software Development Kit
SLF4J
Simple Logging Facade for Java
SOAP
Simple Object Access Protocol
SSL
Secure Sockets Layer
TLS
Transport Layer Security
UI
User Interface, Benutzerschnittstelle
IX
W3C
World Wide Web Consortium
WGS84
World Geodetic System 1984
XML
Extensible Markup Language
X
Glossar
XI
Glossar
Biodiversität
bezeichnet die „Vielfalt des Lebens“ bzw. die „biologische
Vielfalt“, welche umfasst:
- die Artenvielfalt (Reichtum an Tieren, Pflanzen, Pilzen und
Mikroorganismen),
- die genetische Vielfalt (erblich bedingte Variation innerhalb
von Arten und Populationen)
- und die ökosystemare Vielfalt (Systemeigenschaften von
Lebensräumen
(Biotope),
Lebensgemeinschaften
den
und
darin
existierenden
deren
individuellen
Bedürfnissen einschließlich der Vernetzung dieser Biotope
untereinander)
Daten über die räumliche und zeitliche Verbreitung von
Lebensräumen, Arten und Individuen, ggf. ergänzt um weitere
Objektinformationen wie Statusangaben, Autorenschaft oder
Qualität der Beobachtung; Biodiversitätsdaten ermöglichen
weitergehende räumliche, zeitliche oder kausale Analysen und
bilden eine wesentliche Grundlage in der Umweltforschung
Messung
gezielte floristisch-faunistische Datenerfassung mit definiertem
Ort und Zeitpunkt
Verbreitungspunkt
Nachweis des Vorkommens einer Art an einem bestimmten
Ort (im Idealfall mit Angabe geografischer Koordinaten) und zu
einem definierten Zeitpunkt
Einleitung
1
1. Einleitung
1.1. Motivation und Zielsetzung
Mobilität nimmt im digitalen Zeitalter einen immer größeren Stellenwert ein und verbreitet
sich zunehmend sowohl im Lebensalltag als auch in der Arbeitswelt.1 Allseits anwesender
Helfer ist dabei das Smartphone, dessen Erfolgsgeschichte mit der Einführung des iPhones
2007 begann.2 Mit ihnen ist es möglich, fast überall online und erreichbar zu sein. Sie dienen
u. a. sowohl als Informationsstelle für Nachrichtendienste als auch als Mediaplayer, ermöglichen eine intensive Beteiligung in sozialen Netzwerken und werden als Navigationshilfen
eingesetzt. Des Weiteren bieten sie die Möglichkeit, bestehende Dienste auf eine ganz neue
Weise an den Nutzer zu bringen und können Aufgaben umsetzen, die zuvor aufgrund der
fehlenden Mobilität nicht zu bewerkstelligen waren.
Unter der Trägerschaft der Gesellschaft für Ichthyologie wird an der Hochschule Bremen im
Internationalen Studiengang Technische und Angewandte Biologie das Fachinformationssystem Biodiversitätsatlas entwickelt. Seit 2010 werden sie durch das Institut für Informatik
und Automation mit Beteiligung des Internationalen Frauenstudiengangs Informatik (beide
gehören ebenfalls der Hochschule Bremen an) unterstützt. Der Biodiversitätsatlas dient als
Informations- und Erfassungsportal von Biodiversitätsdaten und ist universell für verschiedene Tierklassen einsetzbar. So sind bereits entsprechende Angebote für Fische und
Reptilien vorhanden. Der Atlas trägt zur Erkennung von Gefährdungspotentialen, der
Entwicklung von Schutzkonzepten sowie zur Umweltbildung bei.3 Auf den Einsatz von
Geoinformationssystemen (GIS) zur Visualisierung der Biodiversitätsdaten wird dabei ein
wesentlicher Schwerpunkt des Atlas gesetzt.
Biodiversitätsdaten werden für einen Atlas durch privat interessierte Personen mit entsprechenden floristisch-faunistischen Kenntnissen sowie Experten und Katasterämtern oder
durch Redakteure in das System eingepflegt. Zeitlich liegen dabei zwischen der Sichtung
eines Lebewesens und der Erfassung im System große Abstände, sodass die Aktualität der
Daten häufig nicht gewährleistet werden kann. Dies wäre besser zu erreichen, wenn ein
Fund umgehend nach der Sichtung gemeldet werden könnte. Da dadurch dieser Vorgang
zumeist im Freiland durchgeführt werden muss, wird eine mobile Anwendung zur Lösung der
genannten Aufgabe benötigt. Mit Hilfe von Smartphones ist es möglich, dies zu realisieren.
1
Vergleiche [Linnhoff-Popien, 2012], S. 110f.
Vergleiche [Spiering, 2011], S. 11.
3
Brunken, H., pers. Mitt. 2012.
2
Einleitung
2
Aufgrund dessen ist es das Ziel der vorliegenden Arbeit, eine mobile Anwendung für den
Einsatz auf Smartphones zu entwickeln, die den Biodiversitätsatlas um einen schnellen Weg,
Daten zu erfassen, ergänzt. Ein Schwerpunkt soll dabei ebenfalls auf die Visualisierung der
Erfassung durch GIS gesetzt werden, da dies ein wesentliches Charakteristika des Biodiversitätsatlas ist. Des Weiteren ermöglicht der Einsatz von Smartphones die Nutzung von
Hardwarefeatures wie der Kamera oder dem GPS-Sensor.
1.2. Gliederung der Arbeit
Die vorliegende Bachelor-Thesis gliedert sich in sieben Hauptkapitel. Anschließend an diese
Einleitung wird in Kapitel 2 der Biodiversitätsatlas sowie dessen Struktur näher vorgestellt.
Außerdem wird die oben bereits kurz beschriebene Problematik, die zu dieser Arbeit geführt
hat, ausführlicher thematisiert. Das Kapitel bildet die Wissensgrundlage für die Ergebnisse
der Anforderungsanalyse, welche im dritten Teil der Arbeit dargestellt werden. Die Anforderungen an das zu realisierende System wurden in Zusammenarbeit mit Heiko Brunken4
und Heide-Rose Vatterrott5 ermittelt.
In Kapitel 4 werden aktuelle Techniken und Plattformen der mobilen Programmierung
untersucht. Dies beinhaltet einen Vergleich von Betriebssystemen, für die die Anwendung
programmiert werden könnte, sowie die Präsentation von Anwendungsstrukturen, die
umgesetzt werden könnten. Darauf aufbauend wird in Kapitel 5 ein Realisierungskonzept
vorgestellt, welches eine mögliche Umsetzung der mobilen Anwendung veranschaulicht. Die
auf Basis des Konzeptes durchgeführte Implementierung wird in Kapitel 6 erläutert.
Abschließend werden die Ergebnisse dieser Arbeit in Kapitel 7 zusammengefasst sowie ein
Ausblick auf denkbare Entwicklungen gegeben.
4
Prof. Dr. Heiko Brunken: zuständig für Ökologie und Naturschutz sowie Fischökologie im
Internationalen Studiengang Technische und Angewandte Biologie der Fakultät 5 Natur und Technik
an der Hochschule Bremen und Betreuer des Projektes Biodiversitätsatlas.
5
Prof. Dr.-Ing. Heide-Rose Vatterrott: Leiterin des Masterstudiengangs Komplexe Softwaresysteme,
Professorin des Internationalen Frauenstudiengangs Informatik der Fakultät 4 Elektrotechnik und
Informatik und Mitglied des Projektteams des Biodiversitätsalas.
Der Biodiversitätsatlas
3
2. Der Biodiversitätsatlas
Der Biodiversitätsatlas ist eine Informationsplattform, die die Erfassung und Kommunikation
von raumbezogenen Biodiversitätsdaten (z. B. Verbreitung von Tier- und Pflanzenarten) auf
Basis von User Generated Content ermöglicht. Ausgehend von der Idee, die Vorkommen
von Fischen im deutschsprachigen Raum mit Hilfe von Experten aufzuzeichnen und
allgemein zugänglich zu machen, wird seit ca. 10 Jahren unter der Trägerschaft der
Gesellschaft für Ichthyologie an der Hochschule Bremen an dessen Umsetzung gearbeitet. 6
Ziel hinter diesem System ist es, die Daten für die nachhaltige Nutzung und das
Management von Ökosystemen zu verwenden. Ausgehend davon können Gefährdungspotentiale erkannt, Schutzkonzepte entwickelt und ein wesentlicher Beitrag zur Umweltbildung geleistet werden.
Mittlerweile wird der Atlas nicht nur für den Nachweis von Fischen verwendet, sondern für
die Katalogisierung von verschiedenen Tierklassen (wie z. B. Säugetiere und Reptilien)
genutzt. Das Projekt ist international im Einsatz (u. a. besteht eine Kooperation mit den
Universitäten von Pernambuco und Recife, Brasilien) und legt Wert auf die Verwendung von
frei verfügbarer Software.
2.1. Architektur des Systems
Für die
Umsetzung
des
Fachinformationssystems
werden
im
Wesentlichen
zwei
grundlegende Technologien genutzt. Dies ist zum einen ein Inhaltsverwaltungssystem (engl.
Content Management System, Abk. CMS), das sowohl die Daten als auch die
Nutzerschnittstellen für den Zugriff auf die Informationen bereitstellt. Mit dem grundlegenden
Prinzip, Open Source-Software als Basis für den Atlas einzusetzen, wird das unter der GNU
General Public License (GNU GPL) stehende CMS Joomla! (Version 1.5) verwendet. Zum
anderen liegt ein großer Schwerpunkt auf der Nutzung von Geoinformationssystemen (GIS),
mit Hilfe derer die zu den Biodiversitätsdaten gehörigen räumlichen Angaben erfasst und
präsentiert werden. Als Kartenbasis werden Geodaten des unter der Creative Commons
Attribution-ShareAlike Lizenz stehenden Projektes OpenStreetMap (OSM) genutzt. Über die
Javascript-Bibliothek
OpenLayers7
werden
die
Karten
eingebunden
und
mit
den
Biodiversitätsdaten des Atlas verknüpft. Aufgrund dieser Basis ergibt sich die folgende
Systemarchitektur:
6
Siehe [GFI].
OpenLayers bietet eine einheitliche Schnittstelle für die Einbindung verschiedenster Kartenmaterialien an. Dies hat den großen Vorteil, dass aufgrund des durch den Dienst gebotenen
modularen Aufbaus, Kartendaten auf schnellem Weg ausgetauscht werden können.
7
4
Abbildung 1: 3-Schichtenarchitektur des Biodiversitätsatlas
Sie teilt sich zuerst in die Bereiche des Clients und des Servers. Der Nutzer erhält über einen
Browser Zugriff auf das System. Für ein CMS typisch werden als Nutzerschnittstelle dabei
zwei Bereiche angeboten – das Frontend für normale Nutzer und das Backend für die
Administration des Dienstes und der Inhalte. Innerhalb des Browsers werden diese Inhalte
präsentiert. Unterteilt man die Komponenten des Systems in die Schichten einer DreiSchichten-Architektur, so stellt demnach der Browser-Client die Präsentationsschicht der
Gesamtarchitektur dar. Unterstützt wird er bei der Darstellung der vom Server abgerufenen
Geoinformationen durch OpenLayers. Die Bibliothek liegt clientseitig vor bzw. wird vom
Client zur Laufzeit aus dem Internet bezogen.
Die Schichten der Logik und Persistenz werden durch mehrere Server, die für das CMS und
GIS zuständig sind, realisiert. Frontend und Backend werden über einen Webserver
abgerufen. Dieser enthält die Anwendungslogik des Biodiversitätsatlas, die mit Hilfe von
PHP-Skripten die darzustellenden HTML-Seiten inklusive der Verknüpfung mit den
benötigten Daten generiert. Der CMS-Server ist somit wesentlicher Bestandteil der
Logikschicht. Zu dieser gehört des Weiteren der Tile-Rendering-Server von OSM, der auf
Anforderung von OpenLayers Karten rendert und an den Client schickt.
Die Persistenzschicht, in der die Daten gehalten werden, beinhaltet ebenfalls zwei Server.
Der erste ist ein Datenbankserver, der an das CMS angebunden ist und mit dem
Datenbankmanagementsystem
MySQL
verwaltet
wird.
Hier
werden
Fachinformationssystem zugehörigen Biodiversitätsdaten gespeichert.
die
zu
dem
5
OSM bietet vektorbasierte Karten an, deren Datengrundlage weitestgehend durch freiwillige
Mitarbeit unter dem Einsatz von GPS-Geräten zusammengetragen wird. Die dadurch
entstehenden Informationen liegen als Vektordaten auf dem OSM-eigenen Server. Dieser
gehört demzufolge als zweiter Server ebenso zu der Persistenzschicht.
Die aktuelle Implementation des Biodiversitätsatlas kann für unterschiedliche biodiverse
Gruppen eingesetzt werden. Die Modellierung des Systems ist dafür vollständig von den
Inhalten getrennt und auf allgemeine Attribute reduziert worden. Genauso ist der Atlas
unabhängig von räumlichen Ausrichtungen der Daten, sodass er weltweit genutzt werden
kann.
2.2. Nutzerrollen und Zugriffsberechtigungen
Joomla! bietet die zwei Bereiche Frontend und Backend, auf die über den Browser
zugegriffen werden kann, an. Über das Backend können die in der Datenbank enthaltenen
Daten bearbeitet, neue Meldungen von erfassten Verbreitungspunkten validiert und das
System verwaltet werden. Dieser Bereich ist nur Redakteuren zugänglich. Innerhalb dieser
Nutzergruppe gibt es zusätzlich bestimmte Mitglieder, die die Befugnis für Änderungen am
System haben. Das Frontend bietet die Visualisierung der in der Datenbank enthaltenen und
positiv auf Korrektheit überprüften Daten sowie die Erfassung von neuen Funden. Auch hier
werden weitere Nutzergruppen unterschieden, da nicht jeder neue Daten erfassen darf.
Beide Bereiche nutzen für die Visualisierung der Verbreitungspunkte GIS.
Für die Kontrolle der Zugriffsberechtigungen enthält Joomla! ein Nutzermodell.8 Dieses
wurde den Bedürfnissen des Atlas angepasst und auf die nötigen Nutzergruppen reduziert.
Geblieben sind vier Nutzerrollen, denen bestimmte Berechtigungen und Zugriffe auf das
System zuteilwerden. Abbildung 2 zeigt eine übersichtliche Darstellung der Gruppen. Sie
sind absteigend nach der Eingeschränktheit der Berechtigungen sortiert. Jede Nutzerrolle
erbt und verfügt über die Berechtigungen seines Vorgängers.
8
Vergleiche [cocoate].
6
Abbildung 2: Nutzertypen des Biodiversitätsatlas in Bezug auf ihre Rechte 9
Die ersten beiden Nutzergruppen, Guest und Registered, beschreiben den Zugriff auf das
Frontend. Hier sind die Nutzer nur auf einem niedrigen Level autorisiert. Gäste können sich
die eingetragenen Verbreitungspunkte der verschiedenen Spezies sowie die Artinformationen und zugehörige Bilder ansehen. Sie haben also nur ein einfaches Leserecht. Die
niedrigste Rolle, die erweiterten Zugriff – jedoch nur auf das Frontend – besitzt und Einträge
hinzufügen darf, ist die Rolle Registered. Ein registrierter Nutzer ist den Betreibern des
Systems bekannt, sodass sie seine Qualifikation für die Erfassung von Funden einschätzen
können. Für diese Funktion haben sie mit einem Nutzeraccount, den sie nach Nachweis von
geeignetem floristisch-faunistischem Wissen erhalten, die Berechtigung. Mit den Zugangs-
9
Überarbeitete Quelle aus [Genzel, 2011], S. 51
7
daten können sie sich über ein Formular im Frontend anmelden und anschließend Funde
melden.
Neben den dargestellten Nutzerrollen des Frontends gibt es Manager und Administratoren,
die Zugriff auf das Backend besitzen. Dort nehmen sie die gemeldeten Daten entgegen und
verifizieren sie. Diese beiden Gruppen werden über ihre technischen und fachlichen
Kenntnisse differenziert. Manager haben wie registrierte Nutzer fachliches floristischfaunistisches Wissen, durch das sie in der Lage sind, die Korrektheit der empfangenen
Zuordnungen und Verbreitungspunkte zu überprüfen und gegebenenfalls zu korrigieren. Sie
wirken als Redakteure des Systems. Erst nachdem die Daten im Backend durch die
Redaktion verifiziert wurden, werden sie für die Visualisierung im Frontend veröffentlicht. Ein
Administrator verfügt über weitergehende technische Kenntnisse und verwaltet das CMS.
Änderungen an Systemkomponenten sind alleine dieser Nutzergruppe vorbehalten.
Administratoren besitzen alle Rechte. Darum können sie ebenfalls auf die Daten in der
Datenbank zugreifen und diese ändern. Im günstigsten Fall besitzt ein Administrator daher
neben den technischen Kenntnissen auch fachliches Wissen.
2.3. Logischer Aufbau von Biodiversitätsdaten
Die Meldung über das Vorkommen einer Spezies (der Fund) setzt sich aus mehreren
logischen Einheiten zusammen, deren Kombination eine eindeutige Identifikation des
Fundes ermöglicht. Essentielle Daten sind die Nennung der Spezies, die Kennzeichnung des
Fundortes durch dessen geografische Koordinate und der Tag, an dem die Beobachtung
durchgeführt wurde. Die gezielte Datenerfassung, die einen definierten Ort und einen
Zeitpunkt besitzt, wird als Messung bezeichnet. Abbildung 3 visualisiert die logische
Verknüpfung
der
genannten
Einheiten.
Des
Weiteren
werden
deren
wichtigste
charakteristische Merkmale genannt.
Jede Einheit wird durch weitere Informationen ergänzt. Alle Einträge erhalten zur besseren
Rückverfolgung eine Referenz auf einen Bearbeiter (als Editor bezeichnet; in der Funktion
eines Urhebers und Ansprechpartners). Weiterhin können für Funde, Messungen und Orte
Kommentare abgegeben und bestimmt werden, ob diese Informationen lediglich für die
Redaktion oder allgemein im Frontend zugänglich sein sollen. Kommentare zu Spezies
stehen öffentlich zur Verfügung und können in verschiedenen Sprachen hinterlegt werden.
8
Abbildung 3: Logische Zusammensetzung eines Fundes
Des Weiteren ist für einen Fund festzulegen, ob der Verbreitungspunkt im Frontend
ausschließlich verfremdet angezeigt werden darf. Dies ist sinnvoll, falls die gefundene
Spezies unter Artenschutz steht. Zusätzlich muss unterschieden werden, ob der Fund
eigenständig gesichtet wurde („Individual“) oder aus einer Literaturquelle („Literature“)
stammt. Für die mobile Anwendung wurde zur besseren Nachvollziehbarkeit außerdem der
Wert „Mobile“ hinzugefügt. Die Herkunft der Daten wird durch die Angabe, ob der Fund durch
eine Einzelperson oder ein Katasteramt gemeldet wurde, weiter spezifiziert.10 Ist er durch
eine Einzelperson erhoben worden, wird an dieser Stelle zwischen einer „direkten Sichtung“
des Tieres und einem „indirekten Nachweis“ unterschieden. Indirekte Beobachtungen führen
aufgrund der Sichtung von z. B. Spuren, Exkrementen, Gewöllen oder abgeworfenen
Geweihen zur Identifizierung einer Spezies, ohne das Tier direkt gesehen zu haben. Der
Fund kann deswegen nur indirekt nachgewiesen werden.
Ein Ort wird neben der geografischen Koordinate durch einen eindeutigen Namen
gekennzeichnet. Ferner muss angegeben werden, in welchem Land der Ort liegt und ob
diese Koordinate eine punktgenaue Ortsangabe ist. Letzteres bedeutet, dass der Ort
geografisch genau referenziert werden soll. Beschreibt die Koordinate einen Rastermittelpunkt oder liegen keine genauen Koordinaten vor, werden die Koordinaten des Ortes
als „nicht genau“ definiert. Ein Ort kann mehreren Messungen zugeordnet werden.
10
Diese Eigenschaft wird auch als „Qualität des Fundes“ bezeichnet.
9
Die Messung wird durch die eindeutige Kombination eines Ortes und des Datums der
Messung bestimmt. Optional kann für eine Messung eine weitere geografische Koordinate
angegeben werden, insofern der Nutzer den Ort der Messung genauer spezifizieren möchte.
Innerhalb der Erfassung eines Fundes wird die Messung mit einer Spezies verknüpft. Die
Messung kann dabei wiederverwendet und mehreren Funden zugeordnet werden.
Im Gegensatz zum Ort, der Messung und dem Fund ist die Erfassung einer Spezies allein
der Administration des Atlas vorbehalten, da es relativ selten vorkommt, dass neue Arten
entdeckt werden. Spezies besitzen eine wissenschaftliche Bezeichnung, anhand derer sie
identifiziert werden. Es können außerdem Populärnamen mehrsprachig hinterlegt werden.
Eine Spezies kann wie eine Messung mehreren Funden zugeordnet werden.
2.4. Methoden der Erfassung von gesammelten
Der Weg der Daten in das System ist zeitlich gesehen lang. Datenlieferanten sind
typischerweise Behörden, die Massendaten zumeist auf Anfrage öffentlich stellen möchten
oder Einzelpersonen, die im Gegensatz zu den Behörden eher eine kleinere Anzahl an
Verbreitungspunkten von Tierarten liefern. Einzelpersonen pflegen die Daten selbstständig
über ein Formular im Frontend als registrierte Nutzer ein. Dagegen übergeben Behörden ihre
Daten an die Redaktion des Atlas, die die Daten im Frontend oder über ein ebenfalls im
Backend vorhandenes Formular eintragen. Dies stellt für kleine Datenmengen kein Problem
dar. Größere Mengen verursachen auf diesem Weg jedoch einen immensen Zeitaufwand,
der bislang durch das Schreiben von Übertragungsskripten umgangen wurde.
Die geschilderten Fälle haben gemeinsam, dass häufig sehr viel Zeit zwischen der Erhebung
der Daten und deren Erfassung im System liegt. Dies stellt ein grundsätzliches Problem dar,
da so die Aktualität des Atlas nicht aufrecht zu erhalten ist. An dieser Stelle setzt die Aufgabe
der vorliegenden Arbeit an. Da es dem System an einer schnellen Erfassung von Funden
direkt nach deren Sichtung im Freiland fehlt, soll mit dieser Bachelorarbeit ein neuer Client
konzipiert werden, der diese Aufgabe unterstützt und somit einen zeitlichen Vorteil
verschafft.
Anforderungsanalyse
10
3. Anforderungsanalyse
Dieses Kapitel behandelt die Anforderungen an die zu erstellende mobile Anwendung. Mit
der Festlegung der Anforderungen an das neue System, wird genau spezifiziert, welche
Funktionen es haben und wie es in bestimmten Fällen reagieren soll. Diese Definition bildet
die Grundlage für die folgende Konzeption und Implementierung. Es wird zunächst ein
allgemeiner Überblick über die grundlegenden Voraussetzungen für den neuen Client
gegeben. Anschließend werden die Anforderungen – aufgeteilt in funktionale und technische
– spezifiziert.
3.1. Allgemeine Übersicht und Voraussetzungen
Dem Biodiversitätsatlas fehlt bislang eine schnelle Erfassung von Funden. Unter optimalen
Bedingungen würde die schnellstmögliche Erfassung direkt nach Sichtung des Fundes im
Freiland stattfinden. Insofern soll sie über ein mobiles Gerät durchgeführt werden, welches
der Nutzer bei sich tragen und im Freien einsetzen kann. Für diese Aufgabe eignen sich
mobile Kommunikationsgeräte, wie Personal Digital Assistants (PDA), Feature Phones,
Smartphones und Tablet-PCs, die durch eigene Programme erweitert werden können. Durch
die Mobilfunkanbieter ist es möglich, über diese Geräte fast ununterbrochen auf das Internet
zuzugreifen. Smartphones haben in den letzten Jahren zunehmend an Marktanteilen
gewonnen. Prognosen verdeutlichen, dass die Zukunftschancen und die Marktentwicklung
von Smartphones sehr gut aussehen.11 Ihr Funktionsumfang umgreift den der PDAs, Feature
Phones und den von herkömmlichen Mobiltelefonen. Sie sind mittlerweile standardmäßig mit
einer hochauflösenden Kamera und GPS-Empfänger ausgestattet. Außerdem wird bei der
Konzeption von Smartphones berücksichtigt, dass sie mitunter den Witterungsbedingungen
im Freiland ausgesetzt sind und demgemäß bis zu einem gewissen Grad eine Resistenz
gegen äußere Einflüsse bieten. Parallel zu Smartphones können teilweise auch Tablet-PCs
genutzt werden, da für beide Gerätetypen häufig das gleiche oder verwandte Betriebssystem
eingesetzt wird. Aus diesen Gründen ist es eine wesentliche Anforderung, dass der neue
Client für den Einsatz auf Smartphones entwickelt wird. Abbildung 4 zeigt die dadurch
entstehende Systemstruktur.
11
In Deutschland besitzt nach einer Studie der Bitkom jeder Dritte ein Smartphone. Die Tendenz ist
dabei steigend. Siehe [Bitkom].
Anforderungsanalyse
11
Abbildung 4: Einordnung des mobilen Clients in das Gesamtsystem
Optimal wäre die direkte Eingliederung in das System inklusive der Nutzung der
vorhandenen Schnittstellen zu den Servern. Der neue Client erhält hier die benötigten
Ressourcen12 über das Internet. Anfragen werden direkt an den CMS-Server gestellt. Aus
dem Grund, dass dieser Server lediglich HTML-Seiten verschickt, ist es jedoch fraglich, ob
der mobile Client den CMS-Server auf dem gleichen Weg ansprechen kann bzw. sollte wie
der Standard-Client.
Da für die Darstellung des Biodiversitätsatlas ein großer Schwerpunkt auf den Einsatz von
GIS gelegt wurde, sollte für die visuelle Unterstützung der Erfassung von Funden diese
Technologie weiterhin verwendet werden. Aufgrund der freien Verfügbarkeit von OSMDaten, sollte ein Weg gefunden werden, diesen Dienst weiter zu nutzen. Um auf sich
verändernde Lizenzen und Angebote bezüglich von öffentlich zugänglichen Kartendaten
reagieren zu können, sollte allerdings ein Ansatz für die Austauschbarkeit der Kartendaten
berücksichtigt werden.
Die Datenverbindungen zwischen dem mobilen Client und dem CMS- sowie dem OSMServer sind strukturell (Pfeilenden und Linien) besonders gekennzeichnet. Die Bedeutung
dieser Kennzeichnung wird in Kapitel 3.3.2 erklärt. Zunächst soll jedoch festgestellt werden,
dass es eine Verbindung zwischen den Komponenten gibt, um auf die benötigten Daten
zuzugreifen und neue Funde zu melden.
12
Benötigte Ressourcen beinhalten wesentliche Daten für die Erfassung eines Fundes, welche bereits
im System eingetragen wurden und wiederverwendet werden können. Dies betrifft u. a. Spezies und
Messungen inklusive Orten, die mehrfach Funden zugeordnet werden können.
Anforderungsanalyse
12
Die geplante Anwendung soll in ihrer Funktionalität ein Erfassungstool für die Verbreitung
von Lebewesen darstellen. Der Aufwand, der für eine Erfassung betrieben wird, soll dabei
auf ein Minimum begrenzt werden. Aus diesem Grund sind nur die notwendigsten
Informationen zu einem Fund zu erheben. Die Erfassung soll mit Hilfe von GIS in ihrer
Visualisierung unterstützt werden. Zusätzlich ist es sinnvoll, Smartphone spezifische
Funktionen wie die GPS-Ortung einzusetzen. Damit Funde besser nachvollzogen werden
können, wäre die Aufnahme von einem oder mehreren Bildern von einzelnen Funden sehr
wichtig. Dies sollte durch die Nutzung der Kamerafunktion des Geräts ermöglicht werden.
Die meisten aktuell am Markt verfügbaren Smartphones werden fast ausschließlich über
Touchscreens bedient. Zudem verfügen sie nur über eine kleine Nutzungsoberfläche. Die
Bedienung der mobilen Anwendung muss deshalb speziell für diesen Kontext konzipiert
werden. Dabei ist die Anzeige und Erfassung von Daten auf die essentiellen Informationen
zu reduzieren und diese für den Nutzerdialog sinnvoll zu platzieren. Die genannte
Reduzierung der Daten und Konzipierung der Nutzerschnittstelle (engl. User Interface, Abk.
UI) sollen zudem unter Berücksichtigung einer schnellen und effizienten Eingabe der Daten
durchgeführt werden, da der Nutzer aufgrund der im Gelände herrschenden Witterungsbedingungen oder weiteren anstehenden Funden den Vorgang in kürzester Zeit durchführen
möchte.
Zusammenfassend stellen sich die allgemeinen Hauptanforderungen an das geplante
System wie folgt dar:
 Erstellung einer mobilen Anwendung, die zumindest auf einem Smartphone lauffähig ist
 Einsatz der mobilen Anwendung zur Erfassung von Daten für einen Biodiversitätsatlas
 Visualisierung der Erfassung anhand von GIS
 Nutzung von smartphonespezifischen Funktionen wie der Kamerafunktion und dem
GPS-Empfang
 Wertlegung auf einen hohen Grad an Bedienbarkeit und Effizienz der mobilen
Umsetzung
3.1.1. Nutzercharakterisierung
Da die Anwendung von einer speziellen Nutzergruppe benutzt werden soll, ist es wichtig,
den Nutzer zu charakterisieren, um in der späteren Realisierung dessen Bedürfnisse und
Erwartungen an das System beurteilen zu können sowie die Bedienung auf ihn anzupassen.
Welches Ziel möchte er mit dem Einsatz der Anwendung erreichen? Und in welchem Maße
ist er innerhalb der Durchführung der Prozesse zu unterstützen?
Anforderungsanalyse
13
Der Nutzer möchte die mobile Anwendung einsetzen, um schnell und effizient einzelne
Funde im Fachinformationssystem zu melden. Der Nutzerkreis, der dabei durch die geplante
Anwendung angesprochen wird, setzt sich zusammen aus Personen mit einem fachlichen
floristisch-faunistischen Hintergrund. Sie sind in der Lage Tier- oder Pflanzenarten im
Gelände sicher vom Stamm bis zur Art zu bestimmen und diese Meldung mit qualifizierten
biologischen Daten, bspw. Informationen zum Lebensraum, zu verknüpfen. Diese Personen
können sowohl ausgebildete Biologen als auch Studenten oder Mitglieder eines
Naturschutzverbandes sein, die sich in ihrer Freizeit mit der Katalogisierung bestimmter
Spezies befassen. In der Regel fokussieren sie sich dabei auf eine Spezies, für welche ein
fundiertes Wissen vorliegt.
Davon ausgehend, dass die Anwender im Durchschnitt geringe technische Kenntnisse
besitzen, ist es sinnvoll den einzelnen Nutzer während technischer Prozesse zu
unterstützen. Eine standardmäßige Bedienung eines PC’s sowie der vertraute Umgang mit
dem Browser werden dem Nutzerkreis der mobilen Anwendung allerdings vorausgesetzt.
Die Rolle des Nutzers entspricht den Rollen Registered bis Manager, da sie zur Erfassung
von Funden fachliche Kenntnisse besitzen müssen. Es kann, u. a. zu Testzwecken,
vorkommen, dass die Nutzer nicht entsprechend fachlich qualifiziert sind.13 Hier sollten
Betreuer zur Seite gestellt werden, die über dieses Wissen verfügen. Zusätzlich werden als
weitere Schutzmaßnahme vor inkorrekten Meldungen alle bekannt gemachten Funde durch
die Redakteure des Fachinformationssystems auf Korrektheit überprüft.
3.1.2. Anwendungsszenario
Im Folgenden wird der allgemeine Einsatz der geplanten Anwendung beschrieben. Der
Nutzer erhält die mobile Anwendung auf Anfrage bei den Anbietern des Atlas. Diese
installiert er eigenständig auf seinem Gerät. Abbildung 5 zeigt den nun startenden
Einsatzprozess der Anwendung.
Nach dem Installationsvorgang muss sich der Nutzer mit seinen vorhandenen Nutzerdaten
anmelden. Anschließend ist die Anwendung für den Einsatz bereit. Der Nutzer würde nun
gezielt nach Vorkommen suchen oder eine zufällige Beobachtung machen. Diese kann er
umgehend mit Hilfe der mobilen Anwendung erfassen und melden. Des Weiteren sollte der
Nutzer die Anwendung durch das Festlegen von Optionen, individuell konfigurieren können
(z. B. Standardwerte für die Erfassung festlegen). Nach Abschluss der gewünschten
13
Die Anwendung könnte für Projekte in Schulen eingesetzt werden, wie z. B. als Hilfsmittel für eine
praktische Exkursion eines Biologiekurses.
Anforderungsanalyse
14
Katalogisierungsprozesse loggt sich der Nutzer wieder aus. Ab dem Login kann der Vorgang
wiederholt werden.
Abbildung 5: Anwendungsprozess
Während der Erfassung des Fundes wird er eindeutig identifiziert. Der Nutzer muss eine
Spezies auswählen, den Fundort und das Datum bestimmen. Die Ermittlung des Ortes und
des Datums können durch Gerätefunktionen unterstützt werden. Der Fund kann optional
durch
Bilder
ergänzend
dokumentiert
werden.
Dieser
Prozess
ist
im
nächsten
Aktivitätsdiagramm dargestellt.
Abbildung 6: Erfassungsprozess
3.2. Funktionale Anforderung
In diesem Abschnitt werden die Dienste beschrieben, die die Anwendung leisten soll bzw.
auch die, die von vornherein ausgeschlossen werden. Die Anforderungen werden in die
einzelnen Hauptfunktionalitäten der Anwendung eingeteilt. Diese sind die Erfassung und
Verwaltung von Biodiversitätsdaten sowie deren Visualisierung mit Hilfe von GIS. Des
Anforderungsanalyse
15
Weiteren werden Anforderungen an die Nutzerauthentifizierung und das Personalisieren der
Anwendung gestellt.
3.2.1. Erfassung eines Fundes
Die Grundfunktion der Anwendung soll die Erfassung von Biodiversitätsdaten sein. Die
Anwendung soll zum Zeitpunkt der Sichtung zur Verfügung stehen, sodass der Fund ohne
Zeitverzug gemeldet wird. Demnach sollen nur einzelne Funde an das Informationssystem
gemeldet werden. Das heißt, es soll keine Sammelerfassung durchgeführt, sondern in
jeweils einem Vorgang eine Spezies mit einem Ort und einem bestimmten Zeitpunkt
verknüpft werden. Der Aufwand, der für eine einzelne Erfassung betrieben wird, muss dabei
auf ein Minimum begrenzt werden. Es sind nur die notwendigsten Informationen14 zu einem
Fund zu erheben. Diese sind:
-
der Editor
-
die Spezies
-
die Messung
∟
der Fundort
∟
∟
-
… (s. Kapitel 3.2.3)
das Datum
die Qualität des Fundes (handelt es sich um eine Literaturangabe, muss diese
zusätzlich referenziert werden)
-
die Quelle des Fundes
-
das Datum der Meldung des Fundes
-
die Zustimmung, ob der Fund mit genauen Koordinaten veröffentlicht werden darf;
andernfalls wird er nur verfremdet angezeigt
-
ein Kommentar inklusive der Entscheidung, ob dieser veröffentlicht werden darf
Funden, Messungen, Orten und Spezies muss ein Editor zugeordnet werden. Dies bedeutet
bezüglich dem neuen Anlegen von allen Einheiten, dass der Editor ermittelt werden muss
(siehe Kapitel 3.2.5). Dieser soll im Falle der mobilen Anwendung der aktuell angemeldete
Nutzer sein. Der Editor muss bei Meldung des Fundes übermittelt werden.
Um eine Spezies auswählen zu können, soll die Anwendung im Falle, dass eine Verbindung
zum Internet vorliegt, den Server kontaktieren und eine Liste aller Arten abrufen können.
Alternativ soll es möglich sein, die Daten offline zu speichern. Der Nutzer soll die Spezies
anhand der wissenschaftlichen und der populären Bezeichnung ermitteln. Da er voraus14
Die notwendigsten Informationen sind die Daten, die laut des bestehenden Datenbankmodells des
Biodiversitätsatlas einen Wert besitzen müssen und nicht null sein dürfen.
Anforderungsanalyse
16
sichtlich mit einer großen Menge an Daten konfrontiert wird, sollten die Spezies durchsucht
werden können. Das Erfassen von Daten zu einer neuen Spezies sowie deren Meldung soll
kein Bestandteil der Anwendung sein.
Auch Orte sollen online abgerufen werden und bei Bedarf offline vorliegen. Es ist ebenfalls
mit einer sehr großen Datenmenge zu rechnen. Der Nutzer sollte daher auch hier bei der
Auswahl des Ortes durch eine Suchfunktion unterstützt werden. Ist der benötigte Ort nicht
vorhanden, kann der Nutzer diesen neu erfassen. Auf die Erfassung eines Fundortes wird
ausführlicher in Kapitel 3.2.3. eingegangen. Außerdem werden an die Darstellung von
Fundorten besondere Anforderungen gestellt, die in Kapitel 3.2.4 erläutert werden. Für die
Eingrenzung der Datenmengen sollten sowohl die Spezies als auch die Orte gefiltert vom
Server abgerufen werden können.
Um eine Messung anzulegen, genügt neben dem Ort die Auswahl eines Datums. Weitere
Informationen, die für eine Messung erfasst werden könnten, wie ein Kommentar oder
zusätzliche Koordinaten, sind optional. Da die zu erfassenden Daten in der mobilen
Anwendung auf die essentiellsten Informationen zu reduzieren sind, sollen keine weiteren
Angaben zu einer Messung erhoben werden. Das Datum der Messung soll aus dem Grunde,
dass ein Fund mit der mobilen Anwendung direkt nach dessen Sichtung erfasst werden soll,
fest vorgegeben werden (mit dem aktuellen Datum).
Eine als Katasterfund definierte Meldung wird innerhalb von Massendaten an die Redaktion
des Biodiversitätsatlas übermittelt. Dies ist für die mobile Anwendung nicht relevant. Es
sollen lediglich einzelne Funde zeitnah erfasst werden. Demnach soll die Qualität eines
Fundes entweder als „direkte Sichtung“ oder „indirekter Nachweis“ gekennzeichnet werden.
Ein indirekter Fund sollte zusätzlich im Kommentar beschrieben werden. Des Weiteren wäre
ein Hinweis, dass die Spuren als Foto dokumentiert werden sollten, wichtig.
Funde, die über die mobile Anwendung gemeldet werden, sollen den Wert „Mobile“ als
Quelle erhalten. Das Datum der Meldung des Fundes soll nicht durch den Client bestimmt
werden. Das Festlegen der Quelle und des Meldedatums sind Aufgaben des Servers und
sollen nicht durch die mobile Anwendung durchgeführt werden.
Es muss festgelegt werden können, ob der Verbreitungspunkt eines Fundes veröffentlicht
werden oder nur verfremdet angezeigt werden darf. Standardmäßig sollten die Koordinaten
veröffentlicht werden dürfen. Der Nutzer soll dies verneinen können.
Ergänzend soll ein Kommentar mit weiteren Informationen, die der Anwender textuell
übermitteln möchte, angegeben werden können. Zusätzlich muss er bestimmen, ob der
Kommentar allein für die Redaktion des Atlas bestimmt ist. Standardmäßig soll es
Anforderungsanalyse
17
veröffentlicht werden dürfen. Der Nutzer soll dennoch die Möglichkeit besitzen, dies wieder
verneinen zu können.
Zur besseren Nachvollziehbarkeit wäre die Dokumentation des Fundes anhand von Bildern
sehr wichtig. Dies soll durch die Nutzung der Kamerafunktion des mobilen Gerätes
ermöglicht werden. Da diese Funktion meist in kurzer Zeit zur Verfügung stehen müsste,
sollte sie auf dem schnellstmöglichen Weg innerhalb der Anwendung erreichbar sein. Der
Nutzer soll mehrere Fotos hintereinander aufnehmen und anschließend wieder zur
Anwendung zurückkehren können. Hier sollen die Bilder einem Fund zugeordnet werden.
Die Erfassung des Fundes soll mit dem Senden an den Server abgeschlossen werden. Dies
soll durch ein durch den Nutzer ausgelöstes Ereignis ausgelöst werden. Der Fund soll
anschließend auf dem Endgerät abgespeichert werden. Dies ist vor allem wichtig, sofern
zum Zeitpunkt des Sendens keine Internetverbindung vorliegt. Bei nächster Gelegenheit soll
der Nutzer den Fund erneut senden können.
3.2.2. Verwaltung von Funden
Auf dem Gerät gespeicherte Funde sollen in einer Übersicht dargestellt werden. Sie sollen
anhand der Eigenschaften Spezies, Ort und Datum eindeutig identifiziert werden können.
Bereits gemeldete bzw. noch nicht versendete Funde sollen durch eine Kennzeichnung
unterschieden werden. Nicht versendete Funde sollen auf Anforderung durch den Nutzer
erneut abgesendet werden können. Des Weiteren sollen die Einträge gelöscht werden
können. Dies gilt sowohl für einzelne Funde als auch für die komplette Übersicht.
3.2.3. Erfassung eines Fundortes
Der Nutzer soll einen neuen Ort erfassen können. Dazu müssen folgende Informationen
erhoben werden:
-
ein Editor
-
der Name des Ortes
-
das Datum der Meldung des Ortes
-
die Koordinaten
-
die geografische Genauigkeit der Koordinaten
-
das Land, in dem der Ort liegt
-
ein Kommentar inklusive der Entscheidung, ob dieser veröffentlicht werden darf
Der angemeldete Nutzer soll dem neuen Ort als Editor zugewiesen werden.
Anforderungsanalyse
18
Der Nutzer muss den Namen des Ortes eindeutig benennen. Das Datum der Meldung des
Ortes soll nicht durch den Client bestimmt werden. Auch hier versieht der Server die
Meldung mit einem Zeitstempel.
Sehr wichtig ist die Angabe der geografischen Koordinate des neuen Ortes. Sie soll über die
GPS-Funktion des Endgerätes identifiziert werden und durch den Nutzer nicht modifiziert
werden können. Es wäre wichtig, die Koordinate per Hand festzulegen, falls kein GPSEmpfang möglich ist. Der Einsatz der GPS-Funktion sollte jedoch vorrangig behandelt
werden. Die Koordinate wird für die Weiterverarbeitung im Format des Koordinatenreferenzsystems WGS84 benötigt.
Die geografische Genauigkeit der Koordinate gibt an, ob sie den Mittelpunkt eines Rasters
beschreibt. Bspw. wäre dies für Deutschland die Rasteraufteilung nach TK25. Da die
Koordinate eines neuen Ortes über die GPS-Funktion abgerufen werden soll, kann sie allein
als punktgenaue Koordinate gemeldet werden. Dies gilt für alle Fundorte und soll
dementsprechend unabhängig von der mobilen Anwendung durch den Server bestimmt
werden.
Jeder Biodiversitätsatlas erfasst und präsentiert Daten für ein bestimmtes Gebiet. Es kann
vorkommen, dass das Gebiet nur eines oder auch mehrere Länder umfasst. Die Namen
dieser Länder sind in der Datenbank inklusive der Ländercodes gespeichert. Diese Länder
sollten dem Nutzer zur Auswahl angeboten werden. Da die Datenmenge jedoch gering ist
und sich höchstwahrscheinlich nicht verändert, sollten die Daten offline vorliegen.
Genau wie bei der Erfassung des Fundes soll ergänzend ein Kommentar mit weiteren
Informationen, die der Anwender textuell übermitteln möchte, angegeben werden können.
Und er muss bestimmen, ob der Kommentar allein für die Redaktion des Atlas bestimmt ist.
Standardmäßig sollte es veröffentlicht werden dürfen, sofern es nicht durch den Nutzer
verneint wird.
3.2.4. Visualisierung der GIS-Komponenten
Es werden besondere Anforderungen an die Unterstützung der Erfassung eines Fundortes
durch GIS gestellt, da auch in der mobilen Anwendung ein Schwerpunkt auf dieser
Technologie liegen soll. Eine GIS-Karte soll dazu als Visualisierungsmittel der vorhandenen
Orte und der durch die GPS-Funktion abgerufenen Position dienen. Die Karte sollte
möglichst großflächig sein und die zur Verfügung stehende Fläche des Smartphones
ausschöpfen. Es soll per Touchgesten gezoomt und die Ansicht verschoben werden können.
Neben der Kartenansicht sollten die Orte zusätzlich in einer Liste angezeigt werden. Die
Anforderungsanalyse
19
Auswahl eines Fundortes soll sowohl über die Karte, als auch über die Liste durchgeführt
werden können. Das Anlegen eines neuen Ortes kann unabhängig von der jeweiligen
Ansicht durchgeführt werden.
Genau wie die Reduzierung des Datenvolumens für die Spezies und Orte wäre es sinnvoll,
wenn die Karte auf das Gebiet, welches der Biodiversitätsatlas umfasst, gefiltert werden
könnte. Kartenmaterial für Gebiete, die nicht durch den Atlas abgedeckt sind, sollte nicht
heruntergeladen werden. Zusätzlich können die Zoomstufen eingegrenzt werden.
3.2.5. Nutzerauthentifizierung
Die Anwendung soll ausschließlich von autorisierten Nutzern verwendet werden. Ferner
muss für die Erfassung eines Fundes der Editor ermittelt werden. Um diese zwei
Anforderungen zu erreichen, ist eine Nutzerauthentifizierung vor Beginn des Erfassungsprozesses notwendig.
Um sich anzumelden, muss der Nutzer seinen Benutzernamen und das Passwort eingeben.
Die eingegebenen Zugangsdaten sollen an den Server gesendet werden. Dort sollen sie
geprüft werden. Der mobile Client soll anschließend eine Benachrichtigung erhalten, ob die
Authentifizierung erfolgreich war und der Nutzer dadurch autorisiert ist, das System zu
nutzen. Erhält er die Autorisierung, soll der Benutzername und das gehashte Passwort auf
dem Gerät abgespeichert werden. Bei jedem Neustart der Anwendung muss der Nutzer
jedoch das Passwort angeben, dessen Hashwert mit dem abgespeicherten Hashwert
verglichen wird. Dies soll zusätzliche Zeit und Datenvolumen sparen, da keine Verbindung
zum Server für die Überprüfung der Logindaten aufgebaut werden muss.
Im Anschluss an den Loginprozess, soll der Nutzer die Möglichkeiten haben, Funde zu
erfassen, Optionen zu ändern sowie sich abzumelden. Der Logout sollte zusätzlich
durchgeführt werden, wenn die Anwendung beendet wird oder nach einem zeitlichen Ablauf
von acht Stunden nach Login und Inaktivität. Ohne eine erfolgreiche Anmeldung soll die
Anwendung nicht verwendet werden können.
3.2.6. Optionale Einstellungen
Es wäre sinnvoll, dass der Nutzer die Anwendung personalisieren kann, indem er
Standardwerte für die Erfassung festlegt. Bspw. möchte er nicht, dass die genaue
Koordinate eines Fundes veröffentlicht wird, oder Kommentare sollen eine bestimmte
Textkette standardmäßig enthalten.
Anforderungsanalyse
20
Der Nutzer sollte bestimmen können, ob die Anwendung online oder offline auf die Daten
zugreifen soll. Diese Einstellung sollte in den Optionen festgelegt werden können. Befindet
sich die Anwendung im Offline-Betrieb, sollen Spezies und Orte nicht vom Server abgerufen
und kein Kartenmaterial heruntergeladen werden. Die Anwendung soll dabei auf die auf dem
Gerät gespeicherten Daten zurückgreifen. Die vollständige Funktionsfähigkeit ist in diesem
Fall nur gewährleistet, sofern Daten offline vorliegen. Trotz des Offline-Modus sollen jedoch
Funde versendet werden können. Ist der Online-Betrieb aktiviert, sollen die im Offline-Modus
deaktivierten Verbindungen genutzt werden.
3.3. Nichtfunktionale Anforderungen
Die nichtfunktionalen Anforderungen beschreiben die technischen Bedingungen, die an die
zu entwickelnde Anwendung gestellt werden. Im ersten Abschnitt werden dazu generelle
Aspekte beschrieben, die den Elementen einer typischen Klassifikation der nichtfunktionalen
Anforderungen zuzuordnen sind. Danach werden einzelne wichtige Aspekte angesprochen,
wie die Übertragung von Daten. Neben der Datenerfassung durch die Anwendung sollen die
Daten dem Server gemeldet werden. Dies steht deswegen ebenfalls im Mittelpunkt der
geplanten Anwendung und sollte gesondert betrachtet werden. Des Weiteren ist die
Distribution der Anwendung aufgrund dessen, dass die Verfügbarkeit des Systems
kontrolliert werden soll, ein wichtiger Prozess. Ein weiterer Schwerpunkt soll auf die
Behandlung der Mehrsprachigkeit der Anwendung gelegt werden. Zum Abschluss der
Anforderungsanalyse wird zu grundlegenden Anforderungen an die einzusetzenden
Technologien der Anwendung Stellung genommen.
3.3.1. Generelle nichtfunktionale Anforderungen
Die Anwendung soll in ihrer Bedienbarkeit der Intuitivität von aktuellen Smartphones
entsprechen. Die Menüs, Anzeigen und Buttons sollen selbsterklärend sein, damit sich auch
ein nicht technisch-versierter Anwender schnell mit der Bedienung der Anwendung zurecht
findet. Fachlich müssen dagegen nicht alle Details für den Anwender erklärt werden.
Zusätzlich wird Wert darauf gelegt, dass gerade in den Kartenansichten interaktive Elemente
nicht zu klein sind, um dem Nutzer eine angenehme und sichere Bedienung zu ermöglichen.
Da teilweise nur kurze Zeit zur Verfügung steht, um neue Daten einzutragen und
abzuschicken, sollte die Anwendung stabil funktionieren und keine großen Verzögerungen
besitzen. Ein Absturz der Anwendung sollte nicht eintreten. Die Anwendung benötigt eine
Verbindung zum Internet, da darüber die Daten versendet werden und Kontakt mit dem
Anforderungsanalyse
21
Server aufgebaut wird. Die Nutzung der internen Schnittstelle des Gerätes zum Internet
muss daher stabil sein. Dies ist jedoch eine Rahmenbedingung, die allein durch die Wahl
des Geräts und des Mobilfunkanbieters kontrolliert werden kann. Das Absenden von neuen
Funden soll bevorzugt behandelt werden.
Bezüglich des Zeitaufwandes für die Erfassung eines Fundes ist zudem gewünscht, dass der
gesamte Vorgang unter optimalen Bedingungen, d. h. bei einwandfrei funktionierendem
Gerät und Internetkonnektivität, innerhalb von fünf Minuten abgeschlossen sein soll.
Für die Nachvollziehbarkeit der Anwendung und die Ermöglichung der Wartung und
Erweiterung durch eventuelle andere Entwickler, aber auch zum Verstehen der Anwendung
durch die Betreiber und Administratoren, soll sie modular aufgebaut und der Quellcode
vollständig dokumentiert werden.
Es werden besondere Anforderungen an die Qualität der Anwendung und an den Erhalt der
Qualität der Daten des Fachinformationssystems gestellt. Zum einen sollten Nutzungsbedingungen in Zusammenarbeit mit Heiko Brunken erarbeitet werden. Diese sollten
enthalten, dass die Autorenschaft des Nutzers gewährleistet wird. Insbesondere betrifft diese
Regelung die zur Verfügung gestellten Bilder, aber auch die Meldung der Funde. Im
Gegenzug dazu sollte sich der Nutzer verpflichten, sorgfältig mit der Anwendung und der
Erfassung von Daten umzugehen. Auf diese Weise wird nicht nur die Qualität der mobilen
Anwendung sondern die des Gesamtsystems unterstützt. Zum anderen muss die mobile
Anwendung für den Zielkreis angemessen bedienbar und anwendbar sein. Am Ende dieser
Arbeit soll eine lauffähige Anwendung stehen, die den Nutzer korrekt in seiner Zielsetzung
unterstützt. Mit der Installationsdatei der mobilen Anwendung soll ein vollständig dokumentierter Quellcode, eine Installationsanleitung und ein Nutzerhandbuch geliefert werden.
3.3.2. Datenübertragung
An dieser Stelle soll noch einmal Bezug auf die Einordnung der neuen Anwendung in das
Gesamtsystem genommen werden, welche in Kapitel 3.1 beschrieben wurde. Die besondere
Kennzeichnung der Datenverbindungen von dem mobilen Client zum CMS- und dem OSMServer in Abbildung 4 basiert auf den hier vorgestellten Anforderungen.
Um die Erfassung von Funden umsetzen zu können, muss die Anwendung zum einen Daten
empfangen. Dies gilt sowohl für Daten aus der CMS-Datenbank, die von dem CMS-Server
gesendet, als auch für Tiledaten für die Visualisierung der GIS-Karten von OSM. Das
Datenvolumen sollte aus beiden Quellen auf ein Minimum reduziert werden, um so wenig
wie möglich auf eine Internetverbindung angewiesen zu sein. Die Anwendung sollte auch
Anforderungsanalyse
22
ohne Internetverbindung einsatzbereit sein. Dadurch wird zusätzlich das durch den
Mobilfunkvertrag verfügbare Datenvolumen des Nutzers nicht unnötig belastet. Aus diesen
Gründen sollte eine Lösung entwickelt werden, Daten offline vorzuhalten und auf diese
zuzugreifen.
Zum anderen müssen Daten gesendet werden. Der Versand von Daten, also die Meldung
von Funden, hat höhere Priorität als das Empfangen. Eine Internetverbindung ist für das
Senden unabdingbar.
Da die Priorität des Übertragens von Daten auf den Meldungen der neuen Funde liegen soll,
ist der Pfeil von dem mobilen Client zum CMS-Server größer. Der umgekehrte Weg, die
Lieferung von bekannten Arten, Orten, etc., soll dagegen minimal gehalten werden.
Demnach ist das Datenvolumen in diese Richtung kleiner.
Kartendaten sollen ebenfalls so wenig wie möglich aus dem Netz heruntergeladen werden.
Es ist eine Lösung zu entwickeln, wie die Daten offline gespeichert und anschließend wieder
abgerufen werden können. Optimal wäre es, wenn der mobile Client so gut wie gar nicht auf
den Download von Kartendaten über den OSM-Server angewiesen ist. Deshalb sollte die
Verbindung verschwindend gering sein. Es sollte jedoch auch nicht vernachlässigt werden,
dass das Kartenmaterial aktualisiert werden kann.
Die vom Nutzer eingetragenen Funde müssen unverändert und sicher an den Server
gesendet werden. Sollten Daten aufgrund fehlender Internetkonnektivität nicht versendet
worden sein, sind sie korrekt abzuspeichern. Eventuell sollten Daten vor der Übertragung
verschlüsselt werden. Neben den Biodiversitätsdaten ist vor allem der sichere Versand der
Zugangsdaten des Nutzers relevant. Eine weitere Option wäre der Einsatz von sicheren
Protokollen wie HTTPS.
3.3.3. Distribution und Installation des Systems
Um die Anwendung zu erhalten, muss der Nutzer die Anbieter eines Biodiversitätsatlas
kontaktieren. Sie soll ausschließlich auf Anfrage ausgeliefert werden. Der Anbieter verfügt
aus diesem Grund über die Möglichkeit, zu beurteilen, ob der Nutzer geeignet ist, die
entsprechenden Daten zu erheben und die durch den Atlas abgedeckten Lebewesen korrekt
einer Spezies zuzuordnen. Infolgedessen wird die Qualität der dargestellten Daten des
Fachinformationssystems erhöht und das Aufkommen inkorrekter Daten reduziert. Der
zweite Effekt dieses Vorgehens ist, dass der Anbieter den Nutzer im Voraus registriert und
kein zusätzlicher Registrierungsprozess erforderlich ist. Dies wird für den Biodiversitätsatlas
bislang auf diese Weise gehandhabt und soll auch in Zukunft so fortgesetzt werden. Es soll
Anforderungsanalyse
23
ein Account pro Nutzer vorhanden sein, durch den er sowohl über einen PC auf den Atlas
Zugriff hat, als auch über ein mobiles Endgerät neue Funde melden kann. Ein
Registrierungsverfahren ist darum nicht Bestandteil der Anwendung.
Die Installation sollte so einfach wie möglich gehalten werden. Im besten Fall wird der Nutzer
durch den Prozess vom System begleitet oder er erhält eine Installationsanleitung.
Die Anwendung soll für alle vorhandenen Biodiversitätsatlanten eingesetzt werden können.
Atlasspezifische Eigenschaften sollten vor der Distribution durch die Redaktion des
betroffenen Atlas konfiguriert werden. Hier ist es notwendig festzulegen, über welche
Adresse der Server angesprochen wird. Optional wäre es sinnvoll, für jeden Atlas ein
spezielles Design (Theme) zu erstellen, sodass er zusätzlich eindeutig über sein
Erscheinungsbild identifiziert werden kann. Diese wären ebenfalls bei der Konfiguration
auszuwählen.
3.3.4. Mehrsprachigkeit
Die Mehrsprachigkeit bildet aufgrund dessen, dass ein weltweiter und variabler Einsatz
unterstützt werden soll, einen wichtigen Bestandteil des Biodiversitätsatlas. Bezüglich dieser
Thematik wurden drei unterschiedliche Ansätze im Rahmen der Bachelor-Thesis von CarlHeinz Genzel15 zum Teil unter Zuhilfenahme der Joomla!-eigenen Funktionen erarbeitet. Auf
der einen Seite geht es dabei um die Mehrsprachigkeit der auf den HTML-Seiten
wiederkehrenden Elemente wie Überschriften oder Beschriftungen. Für diese Elemente
bietet Joomla! sowohl für das Frontend als auch für das Backend die Verwaltung von INIDateien an, die für die jeweilige Komponente ausgelesen werden. Die Dateien enthalten
Schlüssel-Wert-Paare, welche bei der Generierung der Seiten durch PHP aufgelöst werden.
Im Backend von Joomla! wird dafür eingestellt, welche INI-Datei für das Frontend oder
Backend verwendet werden soll. Um eine bestimmte Konsistenz und Einheitlichkeit zwischen
den Systemen zu schaffen, sollte für die mobile Anwendung eine ähnliche Lösung entwickelt
werden.
Andererseits wurde die Mehrsprachigkeit der Inhalte des Fachinformationssystems diskutiert
und
ein
entsprechender Ansatz von
Carl-Heinz Genzel modelliert, jedoch
nicht
implementiert. Zum Abschluss seiner Arbeit fasst er die Ergebnisse wie folgt zusammen:
„Mehrsprachigkeit wurde in der Form, dass alle in der Datenbank befindlichen Tabellen
in mehreren Sprachen vorliegen, noch nicht realisiert. Dies sollte allerdings in Zukunft
in Betracht gezogen werden. Aus Sicht des Autors dieser Arbeit empfiehlt es sich nicht,
15
„Web GIS Erweiterung des CMS Joomla! im Kontext der Biodiversität“; siehe [Genzel, 2011].
Anforderungsanalyse
24
eine eigene Umsetzung zu implementieren. Es ist sinnvoller die Joomla!-Erweiterung
Joom!Fish als eine der bekanntesten Erweiterungen für die Übersetzung von Inhalten
im Joomla!-CMS auf ihre Anwendbarkeit zu überprüfen. Mit Hilfe von Joom!Fish
können üblicherweise Datenbankeinträge mit einer Joom!Fish Übersetzung verknüpft
werden,
ohne
weitere
Datenbanktabellen
zu
erstellen.
Dazu
müssen
die
16
Datenbanktabellen mit Hilfe von XML erfasst werden.“
Diese stellt eine zukünftige Erweiterung des Atlas dar und kann zum jetzigen Zeitpunkt nicht
berücksichtigt werden. Da jedoch die Auswahl der Daten und die Generierung von Antworten
auf Seiten des Servers liegt, sollte die Schnittstelle zwischen Client und Server so konzipiert
werden, dass die Mehrsprachigkeit der Inhalte in Zukunft auch für den mobilen Client
umgesetzt werden kann.
Die dritte Lösung bezieht sich auf die namentliche Darstellung der Spezies. Sie werden mit
einem wissenschaftlichen Namen abgespeichert und können einen oder mehrere
Populärnamen in unterschiedlichen Sprachen besitzen. Die Populärnamen werden unter
einem Schlüssel verwaltet, der sich zusammensetzt aus dem ISO-zertifizierten Sprachcode
und dem unter dem gleichen Zertifikat stehenden Ländercode. Auf diese Weise können die
Populärnamen direkt einer Sprache zugeordnet und die Listen anhand des Sprachcodes
generiert werden. Die Schnittstelle zwischen dem neuen Client und dem Server soll so
modelliert werden, dass der Abruf der verschiedenen Listen der Populärnamen möglich ist.
3.3.5. Einzusetzende Technologien
Die mobile Anwendung sollte einen größtmöglichen Nutzerkreis ansprechen. Dies heißt,
dass die Marktanteile der einzelnen Betriebssysteme und Möglichkeiten, eventuell auch
mehrere Plattformen durch die Anwendung zu erreichen, analysiert und dementsprechend
die Anwendung umgesetzt werden sollte. Die Haupteinsatzorte der Anwendung werden
vorerst in Brasilien und Deutschland sein. Da nach Auskunft von Herrn Brunken vor allem in
Brasilien eine große Verbreitung des durch Google entwickelten mobilen Betriebssystems
Android vorliegt und auf die Kooperation im Bereich der Biodiversität zwischen den
Hochschulen in Brasilien und Deutschland besonderer Wert gelegt wird, sollte diese
Plattform bevorzugt behandelt werden. Außerdem wurde für den Atlas bislang besonderer
Wert auf den Einsatz von Open-Source bzw. Common License Software gesetzt. Dieser
Ansatz sollte möglichst weiterverfolgt werden. Um einen Überblick über die vorhandenen
Möglichkeiten und Unterstützung der einzelnen Plattformen zu erhalten, werden im nächsten
16
Zitat nach [Genzel, 2011], S. 89.
Anforderungsanalyse
25
Kapitel die aktuellen Techniken und Betriebssysteme der mobilen Programmierung näher
analysiert.
Aktuelle Techniken und Plattformen der mobilen Programmierung
26
4. Aktuelle Techniken und Plattformen der
mobilen Programmierung
Wie wird nun die mobile Anwendung aufgebaut sein und wie wird sie umgesetzt? Es ist zu
entscheiden, auf welcher Basis dies geschehen soll, bevor diese Fragen geklärt werden
können. Der Markt von Smartphones und Tablets ist sehr stark fragmentiert. Es gibt eine
Vielzahl an Betriebssystemen, deren Anwendungen in unterschiedlichen Programmiersprachen geschrieben werden, sowie Verkaufsplattformen, über die diese Programme
vertrieben werden, und viele weitere Technologien, Entwicklungsumgebungen und APIs,
anhand deren es möglich ist, mehrere Betriebssysteme gleichzeitig anzusprechen. Bevor
man also mit der Erstellung der Anwendung beginnen kann, muss validiert werden, auf
welche Art und Weise diese optimal eingesetzt werden kann und welche Technologien dafür
in Frage kommen. Das Kapitel bietet folglich einen Überblick über die aktuellen
Möglichkeiten der mobilen Programmierung.
Abbildung 7: Überblick über den Vertrieb und die Nähe zur Plattform der mobilen
Anwendungsarten
27
Da die Fragmentierung des Smartphone-Marktes sehr groß ist und die einzelnen
Komponenten, die berücksichtigt werden müssen, untereinander abhängig sind, soll der
Leser anhand der Abbildung 7 zunächst eine kurze Einführung in dieses Kapitel erhalten.
Ausgehend von den diversen Betriebssystemplattformen wie Android von Google oder iOS
von Apple, können vier Arten von mobilen Anwendungen für Smartphones oder Tablet-PCs
unterschieden werden. Diese sind: Native Anwendungen, hybride Anwendungen, Webanwendungen und mobile Widgets. Je nach Typ sind sie dabei von der Plattform, auf der sie
laufen, abhängig (native Anwendungen) bis unabhängig (Webanwendungen). Plattformabhängigkeit bedeutet in diesem Zusammenhang, dass die Anwendungen nur innerhalb der
sie unterstützenden Betriebssystemumgebungen laufen und speziell auf diese sowie die
Geräteeigenschaften und -funktionen zugeschnitten sind. Daneben gilt, je plattformunabhängiger eine Anwendung ist, desto mehr ist sie auf die Nutzung des Internets
angewiesen, welches zugleich die Basis aller proprietären Distributionsmöglichkeiten ist. Die
Programmierung der vier Anwendungsarten ist ebenfalls sehr vielfältig und wird mit
unterschiedlichen Programmiersprachen umgesetzt. Sprachen, in denen primär Anwendungen für eine Plattform entwickelt werden, werden als nativ bezeichnet. Da häufig
versucht wird, plattformunabhängig zu programmieren und somit mehr Nutzer anzusprechen,
gibt es eine große Anzahl an APIs und Entwicklungstools. Diese basieren auf aktuellen
Webtechnologien.
Die hier genannten Komponenten werden nun im Einzelnen beschrieben.
4.1. Mobile Betriebssysteme
Laut einer Umfrage des Marktforschungsunternehmens Nielsen unter ca. 1000 Smartphonebesitzern sind in Deutschland im dritten Quartal 2011 Android und Nokias Symbian mit
jeweils knapp einem Drittel die am meisten verbreiteten Betriebssysteme.17 An dritter Stelle
ist iOS zu ca. einem Viertel unter den Verbrauchern ebenfalls sehr erfolgreich vertreten.
Weitaus geringer genutzt werden dagegen BlackBerry der Firma Research in Motion (RIM),
Windows Mobile und Windows Phone von Microsoft sowie Samsungs Bada oder webOS von
HP.
Eine Studie, die durch Gartner, Inc. durchgeführt wurde, hat die weltweiten Marktanteile
anhand der tatsächlichen Verkaufszahlen im dritten Quartal 2011 analysiert. Das Ergebnis
dieser Studie zeigt, dass Android weltweit gesehen mit der Hälfte der Marktanteile weitaus
erfolgreicher ist. Symbian und iOS besitzen knapp ein Sechstel der Marktanteile und liegen
damit deutlich unter den deutschen Ergebnissen. Weltweit bedeutender ist dagegen RIM.
17
Vergleiche [Nielsen].
28
BlackBerry gehören 12% der verkauften Smartphones. Alle anderen Betriebssysteme sind
wieder gering vertreten.18 Gartner prognostiziert jedoch Windows Phone eine erfolgreiche
Zukunft. Demnach soll Microsoft im Jahr 2015 mehr Marktanteile besitzen als Apple. Diese
Prognose entstand nach der Verkündung der Kooperation zwischen Nokia und Microsoft
Anfang 2011. Nokias Smartphones werden zukünftig hauptsächlich mit Windows Phone
ausgestattet werden.19 Parallel zu dem Erfolg Microsofts wird deswegen der Einbruch von
Symbian erwartet.20
Basierend auf den vorgestellten Zahlen werden nun im Folgenden die zur Zeit wichtigsten
und erfolgreichsten mobilen Betriebssysteme vorgestellt. Wie die Statistiken verdeutlichen,
sind dies Android, Symbian und iOS. Sie bieten aktuell die besten Möglichkeiten, viele
Nutzer zu erreichen.
Android
Entwickelt wird Android durch die Open Handset Alliance™, die sich, angeführt von Google,
aus über 50 Mobilfunkanbietern, Mobiltelefon- und Chipherstellern sowie Marketing- und
Softwareunternehmen zusammensetzt. Dazu gehören u. a. die Telekom, Vodafone, die
Telefonica, Intel, Asus, HTC oder Texas Instruments. Diese Firmen haben sich zum Ziel
gesetzt, ein besseres Mobiltelefon zu entwickeln, welches weltweit Menschen in der
Erfüllung ihrer Aufgaben unterstützt.21 Aufgrund der Größe und den Marktpositionen der
Mitglieder der Allianz, ist es das am schnellsten wachsende Smartphone-Betriebssystem.22
Android wurde Ende November 2007 vorgestellt und ist bereits nach vier Jahren zum
unangefochtenen Marktführer aufgestiegen.23
Die Plattform steht unter der Apache Software Licence 2.0. Einzelne Komponenten laufen
unter anderen Lizenzen, wie der Linux Kernel, der unter der GNU GPLv2 lizenziert ist. Der
Quellcode ist dadurch öffentlich verfügbar.24 Allein, wenn man Anwendungen im Android
Market veröffentlichen möchte, fällt eine einmalige Registrierungsgebühr von $25 an.25
18
Vergleiche [Gartner-1].
Vergleiche [Nokia-5].
20
Vergleiche [Gartner-1].
21
Vergleiche [Open Handset Alliance].
22
Vergleiche [Enough Software], S.11.
23
24
Vergleiche [Android Open Source Project].
25
Vergleiche [Google].
19
29
Abbildung 8: Android Architecture26
Hinter der Bezeichnung „Android“ verbirgt sich nicht nur das marktführende Betriebssystem,
sondern auch eine Sammlung von Standardanwendungen (wie z. B. ein Emailprogramm, die
SMS-Funktion oder der Browser) sowie die virtuelle Maschine Dalvik, welche für mobile
Endgeräte optimiert ist. Das Android SDK beschreibt ein umfassendes Anwendungsframework für die Entwicklung weiterer Anwendungen. Entwickler finden hier Ressourcen für
bspw. die Kommunikation mit anderen Programmen, den Zugriff auf Dateien oder auch
Views und vorgefertigte Widgets für die Gestaltung der eigenen Anwendung. Neben der
Android Runtime gibt es in der Middleware der Architektur Bibliotheken für die Darstellung
von Grafiken in 2D oder 3D sowie Vektorgrafiken oder Datenbanken mittels SQLite, die in C
bzw. C++ geschrieben sind. Die letzte Schicht bildet der Linux Kernel, über den auf die
Geräteressourcen zugegriffen werden kann. Die Anwendungen werden in Java entwickelt.
Neben dieser Programmiersprache, die nativ unterstützt wird, können außerdem Programme
mit dem Android NDK in C und C++ programmiert werden.27
Die vollständige Einarbeitung in die Entwicklung mit Android beträgt laut der Developer
Economics 2011-Studie ca. sechs Monate.28 Ein Vergleich mit anderen Plattformen sowie
26
Quelle: [Android Developers-1].
Vergleiche [Android Developers-1].
28
Vergleiche [Vision Mobile]. Für diese Studie wurden weltweit Entwickler zu der Entwicklung und der
Distribution von mobilen Anwendungen befragt.
27
30
dem mobilen Web (mobile Websites und Webanwendungen, siehe Kapitel 4.2.2) zeigt, dass
Android am schnellsten zu erlernen ist.
Abbildung 9: Dauer der Einarbeitung in die verschiedenen Plattformen 29
Android wird auf Smartphones, Tablets, Mediaplayern und Entertainmentsystemen für
Automobile eingesetzt.30 Außerdem sind diverse Netbooks mit diesem Betriebssystem
ausgestattet. Für Smartphones und Tablets gab es bislang unterschiedliche Versionen. Am
gängigsten sind die für Smartphone konzipierten Versionen Froyo (Android 2.2) und
Gingerbread (Android 2.3.3 bis 2.3.7). Anfang des Jahres 2011 kam die rein für Tablets
entwickelte Version Honeycomb (Android 3.0) auf den Markt, gefolgt von Ice Cream
Sandwich (Android 4.0) im Oktober desselben Jahres.31 Letztere bietet eine API für beide
Geräteklassen.32
29
Quelle: [Vision Mobile].
31
32
30
31
Abbildung 10: Marktverteilung der Android-Versionen (Stand: 01. Dezember 2011)33
Symbian OS
Symbian OS ist eines der Betriebssysteme, die auf Nokia-Smartphones – früher auch unter
Samsung und anderen Mobiltelefonherstellern – eingesetzt werden. Seine Ursprünge lassen
sich auf das PDA-Betriebssystem EPOC der Firma Psion zurückführen, welches seit 1996
entwickelt wurde. Da sich der Markt veränderte, schloss sich Psion zwei Jahre später mit
den damals führenden Mobiltelefonherstellern Nokia, Ericsson, Motorola und Panasonic zu
dem Gemeinschaftsunternehmen Symbian zusammen, welche die Kernelemente EPOCs
übernahm und kurz nach der Jahrtausendwende die ersten Smartphones mit Symbian OS
6.034 veröffentlichte.35 Das Konsortium löste sich jedoch 2008 auf und übernahm die Aufgabe
der Lizenzierung des Betriebssystems unter dem Namen Symbian Foundation.36 Seitdem
führt Nokia die Entwicklung Symbians eigenständig fort, verkündete jedoch im Februar 2011
fortan den größten Teil ihrer Smartphones mit Windows Phone auszustatten.37
Von 2003 bis 2005 fanden grundlegende Überarbeitungen für Übertragbarkeit, Flexibilität,
Performance und Sicherheit statt. Danach folgten weitere Versionen, in denen die
Unterstützung neuester Techniken, wie Wifi, Near Field Communication (NFC) oder SQLite,
eingeführt wurde. Die erste Version (eigentlich Symbian OS 9.4) nach der Gründung der
Symbian Foundation 2008 erhielt die Bezeichnung „Symbian^1“ mit einer neuen
33
34
Das letzte Release von EPOC hatte die Versionsnummer 5.0. Aus diesem Grund erhielt die erste
Version von Symbian die Nummer 6.0. Vergleiche [Tanenbaum, 2009], S. 1068.
35
Vergleiche [Tanenbaum, 2009], S. 1067f.
36
Siehe [Symbian Foundation].
37
32
Nummerierung. Eine weitere Umbenennung erfolgte nach der Verkündung der Kooperation
mit Windows. Der Versionssprung von Symbian^3 auf Symbian^4 wurde zurückgezogen und
die Erweiterung als Symbian Anna auf Basis von Symbian^3 eingeführt. 2011 folgte die
letzte Aktualisierung mit Symbian Belle.
„We are Open!“ 38, so lautet die Überschrift eines Blogbeitrages auf der Symbian- Website
von Nokia. Auch wenn es aufgrund dieses Slogans den Anschein hat, so ist Symbian keine
Open Source-Software, sondern steht unter der Nokia Symbian Lizenz.39 Dieser Lizenz nach
hat man erst nach einer Registrierung Zugriff auf den Quellcode des Betriebssystems. Nokia
möchte außerdem den Entwicklerkreis, der am System arbeitet, begrenzt halten und
bestätigt dadurch nur Registrierungsanfragen von bereits bekannten Mitarbeitern.40
Anwendungen werden nativ in C++ programmiert.41 Die Einarbeitung in die Programmierung
für Symbian mit dieser Sprache dauert im Vergleich mit anderen Plattformen länger (siehe
Abbildung 9, S.32). Nokia empfiehlt deshalb auch die Entwicklung mit Qt.42 Dies ist ein
Framework zur Erstellung von plattformunabhängigen Anwendungen und UIs, welches sich
vor Kurzem von Nokia losgelöst hat und fortan für die Open Source-Entwicklung frei zur
Verfügung steht.43 Das letzte Release des Qt SDKs ermächtigt den Entwickler, Anwendungen für Symbian sowie die weitaus weniger genutzten Plattformen Maemo und MeeGo,
die ebenfalls von Nokia entwickelt werden, zu erstellen.44
iOS
Apple gab mit der Einführung des ersten iPhones Anfang 2007 den Anstoß für den Erfolg
von Smartphones und löste „ein unvergleichliches Wettrennen der mobilen Plattformen
aus“.45 Ein weiterer Triumph gelang Apple im Juli 2008 mit der Einführung des App Store.
Mittlerweile stellt er die größte Verkaufsplattform mobiler Anwendungen mit über 500.000
Anwendungen dar.46
Das Betriebssystem iOS läuft sowohl auf dem Apple-eigenen Smartphone iPhone als auch
auf dem Tablet-PC iPad und dem Mediaplayer iPod.47 In der ersten Version von iOS konnten
keine Anwendungen von Drittanbietern installiert werden. Dies wurde parallel zur Eröffnung
des App Store 2008 in der zweiten Version hinzugefügt. Jährlich folgten weitere
38
Zitat nach [Nokia-2].
40
41
Vergleiche [Nokia Developer-1].
42
Vergleiche [Nokia Developer-2].
43
Vergleiche [Qt Project].
44
45
Zitat nach [Spiering, 2011], S. 11.
46
47
Vergleiche [Apple].
39
33
Systemupdates, die u. a. neue Standardanwendungen, die Unterstützung neuer Hardwarefeatures und die Anbindung an neue App Store-Dienste lieferten.48 Die Updates wurden
dabei stetig mit der Vorstellung neuer iPhone-Modelle begleitet, sodass fortlaufend ältere
Modelle vom Markt genommen und durch die neuen ausgetauscht werden konnten. Dies
begünstigt, dass die Fragmentierung innerhalb der Plattform nicht so groß ist und gleichzeitig
für Smartphones und Tablet-PCs entwickelt werden kann.49
Anwendungen werden für iOS mit Objective-C programmiert.50 Für die Entwicklung wird die
Entwicklungsumgebung Xcode durch Apple frei zur Verfügung gestellt.51 Um Zugriff auf die
Entwicklungsressourcen (API-Bibliothek, Codebeispiele, Videotutorials, etc.) zu bekommen,
muss man sich als Entwickler registrieren und einen Mac-Rechner besitzen.52, 53, 54 Möchte
man während der Entwicklung Anwendungen auf einem Apple-Gerät testen oder
Anwendungen im App Store verkaufen, hat man Apple als Einzelperson jährlich $99 zu
zahlen.55, 56 Firmen zahlen $299.57
Das iOS-System basiert auf der Anwendungsumgebung Cocoa, welche auch für MacRechner eingesetzt wird. Allerdings wurde der Umfang der Anwendungsumgebung für iOS
reduziert, da bestimmte Features wie der Zugriff auf die Kommandozeile oder QuickTime
nicht benötigt werden. Dafür wurde der Anwendungsschicht jedoch eine spezielle Schicht für
das UI hinzugefügt.58, 59
Abbildung 11: Architektur von iOS60
48
Vergleiche [Wikipedia].
50
Vergleiche [iOS Developer Library-1].
51
Vergleiche [Apple Developer-1].
52
53
54
55
56
57
58
59
60
Quelle: [iOS Developer Library-2].
49
34
Die Einarbeitungszeit in die Programmierung für iOS ist im Vergleich zu den anderen
Plattformen durchschnittlich (siehe Abbildung 9, S.32). Es müssen bei der Entwicklung
jedoch strenge Programmier- und UI-Richtlinien beachtet werden, in die sich ein Entwickler
zusätzlich einzuarbeiten hat.61 Die Anwendungen werden vor der Freistellung im App Store
zusätzlich stark reglementiert und die Einhaltung aller Richtlinien überprüft. 62
4.2. Strukturen der mobilen Programmierung
Am Anfang der Entwicklung von Anwendungen für mobile Geräte steht man vor der
Entscheidung, wie die Anwendung aussehen soll und auf welchem Wege die Nutzer erreicht
bzw. in ihrer Arbeit unterstützt werden sollen. Es gibt verschiedene Arten von Anwendungen,
die auf unterschiedliche Art und Weise Funktionen zur Verfügung stellen. Bei der Wahl einer
dieser Arten ist es wichtig zu validieren, was für den Nutzer am geeignetsten ist und wie er
am besten in seiner Arbeit unterstützt wird. Dieses Unterkapitel bietet einen Überblick über
die möglichen Arten einer mobilen Anwendung und zeigt deren Vor- und Nachteile auf.
4.2.1. Native Anwendungen
Native Anwendungen sind Programme, die auf ein mobiles Gerät geladen und dort installiert
werden. Sie werden somit als Software, lauffähig auf einem dedizierten Betriebssystem, in
dem Gerät integriert. Dies ermöglicht einen direkten Zugriff auf Systemfunktionen wie das
Gyroskop, die GPS-Ortung oder die Kamera. Daneben können Rechenoperationen schneller
durchgeführt werden.63
Die Betriebssysteme der meisten Wettbewerber auf dem Smartphone-Markt ermöglichen es,
native Applikationen zu installieren. 64 Dazu steht für jede mobile Plattform ein eigenes SDK
zur Verfügung, das Entwickler in die Lage versetzt, Anwendungen in der nativen
Programmiersprache des Betriebssystems zu programmieren. Es ist schwierig und komplex,
mehrere Plattformen auf diesem Weg gleichzeitig zu unterstützen, da die Transformation von
einer Programmiersprache in eine andere sehr aufwändig ist. 65
61
63
64
Vergleiche [Enough Software], S. 89.
65
62
35
Native Anwendungen können durch GIS APIs ergänzt werden. Speziell für OSM ist es für
fast jede Plattform möglich, Kartendaten einzubinden. Die OSM-APIs werden für die OpenSource-Verwendung entwickelt.66
Die Distribution der nativen Anwendungen findet fast ausschließlich über die App-Stores
statt. Als einzige Plattform erlaubt es Android, Anwendungen u. a. über einen Server oder EMail zu installieren.67 Die Distribution über den App-Store ermöglicht jedoch eine kontrollierte
und sichere Verteilung der Anwendungen. So können auf diesem Wege auch leichter
kommerzielle Dienste verkauft werden, die mit Hilfe der Stores abgerechnet werden. Die
Veröffentlichung einer Anwendung ist jedoch teilweise auch mit Kosten verbunden und die
Betreiber der App-Stores erhalten bei kostenpflichtigen Anwendungen eine Provision. Des
Weiteren sind die Barrieren für die Aufnahme einer Anwendung in einen Store mitunter sehr
hoch und das Verfahren aufwändig. Genauso müssen Genehmigungsprozesse auch bei
Aktualisierungen erneut durchlaufen werden.68
4.2.2. Webanwendungen
Als Alternative zu den nativen Anwendungen gibt es Webanwendungen als plattformunabhängigsten Ansatz. Der Faktor, den alle Smartphones gemeinsam haben, ist das
Internet, was sich hier zunutze gemacht wird. Über den Browser ist jedes Gerät imstande,
Webseiten auf Basis von gängigen Webtechnologien anzuzeigen.69 Anstatt des Begriffes
„Webanwendung“ (bzw. dem englischen Begriff „Web-App“) wird in der Literatur und im
Internet häufig auch die Formulierung „mobile Website“ verwendet. Es soll jedoch darauf
hingewiesen werden, dass die Gleichsetzung dieser beiden Begriffe in der Diskussion steht.
Es gibt Stimmen, die der Meinung sind, dass diese beiden Begriffe getrennt werden
müssten:
„Web Apps grenzen sich von einer mobilen Website durch höhere Komplexität sowie
die Möglichkeiten der Interaktion ab. Dennoch kann jede Web App auch eine für die
mobile Nutzung optimierte Webseite sein. Die Grenzen sind dabei oft fließend.”70
Andere stellen fest, dass keine deutliche Trennung existiert. 71 An dieser Stelle sollte nur kurz
auf die Diskussion hingewiesen werden. Im Folgenden wird unabhängig davon der Begriff
66
Vergleiche [OpenStreetMap].
68
69
70
Zitat nach [Linnhoff-Popien, 2012], S. 149.
71
Vergleiche [AppsLab].
67
36
Webanwendung für eine auf der HTML-Technologie basierende Anwendung, die über den
Browser zugänglich ist, verwendet.
Ein großer Vorteil von Webanwendungen ist die einfache Distribution und Erreichbarkeit.
Webanwendungen waren, bevor App-Stores existierten, sehr populär und mitunter fast die
einzige Möglichkeit, Dienste auf dem mobilen Endgerät durchzuführen. Dadurch, dass native
Anwendungen über App-Stores schnell auf das Gerät geladen werden können, und man so
direkt auf sie zugreifen kann, rückten Webanwendungen für einige Zeit in den Hintergrund.
Mit der Entwicklung von HTML 5 und CSS 3 gewinnen sie jedoch wieder zunehmend an
Bedeutung, da sie weiterhin als plattformunabhängigste Anwendungsart die größte Anzahl
an Nutzern erreichen.72 Mit der Web Storage API ist es möglich, Daten als Schlüssel-WertPaare oder in einer Datenbank im Browser des Clients zu speichern. Dies kann für die Laufzeit einer Session, aber auch dauerhaft durchgeführt werden. Daneben können Webanwendungen durch die Offline Application Caching API73 auch ohne Internetverbindung
zugänglich gemacht werden74 oder mit Hilfe der Geolocation API75 direkten Zugriff auf die
Ortungsfunktion des Geräts zu nehmen.
Des Weiteren steht für Entwickler und Firmen im Vordergrund, dass Webanwendungen nicht
über die App-Stores, sondern allein über das Internet bezogen werden. Es gibt infolgedessen keinen aufwändigen Genehmigungsprozess, um die Anwendung in einem App-Store
zu veröffentlichen. Damit geht einher, dass Aktualisierungen den Nutzer weitaus schneller
erreichen als native Anwendungen.76
Webanwendungen sind jedoch insofern beschränkt, als dass sie von den Leistungen und
Funktionen der Browser abhängig sind. Bietet ein Browser den Zugriff auf Hardwarekomponenten an, so kann die Webanwendung diese Funktion nutzen. Dies ist momentan
allerdings nicht mit allen Browser möglich, da sie sich an dieser Stelle noch in der
Entwicklung befinden.77 Standardisierungs- und Entwicklungsprozesse sind jedoch von
Seiten des W3C und der Entwickler im Gange.78 Für eine vollständige Einarbeitung in die
Entwicklung von mobilen Webanwendungen bzw. Websites müssen durchschnittlich neun
Monate eingeplant werden.79
Es gibt einige Frameworks, die Aussehen und Verhalten einer Webanwendung mittels CSS
und Javascript an das native UI anpassen sowie die Speicherung von Daten offline
72
Siehe [W3C-1].
74
Vergleiche [Linnhoff-Popien, 2012], S. 153.
75
Siehe [W3C-2].
76
77
78
79
Vergleiche [Vision Mobile].
73
37
unterstützen. Der Zugriff auf Hardwarekomponenten ist dagegen nicht möglich. 80 jQuery
Mobile ist eines dieser Tools, welches im Gegensatz zu den anderen Lösungen sehr viele
Plattformen unterstützt.81 Es ist ein Open Source-Framework zur Entwicklung mobiler Webanwendungen, welche sich fast wie native Anwendungen verhalten und ein einheitliche UI
besitzen. Dafür wurde eine umfangreiche Komponentenbibliothek für die Anpassung an
verschiedene Endgeräte entwickelt. Die Anpassung geschieht durch die Generierung der
Komponenten durch Progressive Enhancement. Dies ist eine Technologie, die beim Laden
das Dokument analysiert und mit entsprechenden Funktionen (je nach Möglichkeiten des
Gerätes) erweitert.82
Eine weitere Alternative zur Erstellung einer Webanwendung wäre im Hinblick dessen, dass
das bisherige System des Biodiversitätsatlas mit Joomla! betrieben wird, die Umsetzung
mittels Mobile Joomla!. Diese Erweiterung des CMS erzeugt für mobile Endgeräte
angepasste Webseiten der eigenen Website und wird im Backend als Plugin installiert.
Mobile Geräte werden automatisch erkannt und entsprechend eine optimierte Seite
angezeigt. Dabei können spezielle Einstellungen für bestimmte Geräte (wie das iPhone)
getroffen und daraufhin die Anzeige der Seite an die Plattform angepasst werden.83
4.2.3. Hybride Anwendungen
Eine Mischform zwischen Web- und nativen Anwendungen sind hybride Anwendungen.
Anhand dieser Art ist es möglich, Webanwendungen in App-Stores zu stellen. Um dies zu
realisieren erzeugt man ein natives Programm, welches ein WebView-Element enthält, das
die Webanwendung anzeigt. Die native Anwendung funktioniert hier als Wrapper. Ihre
einzigen Aufgaben sind die Darstellung der Webseiten und die Bereitstellung von
Hardwarekomponenten. Die Funktionalität der hybriden Anwendung liegt damit hauptsächlich beim Server.84, 85
4.2.4. Mobile Widgets
Neben den zuvor genannten Arten von Anwendungen gibt es mobile Widgets. Sie basieren
auf Markup- und Skriptingsprachen, also XML, HTML, CSS und JavaScript. Zurzeit wird
noch häufig ein Player für Widgets benötigt, da die Plattformen nicht nativ auf sie eingerichtet
80
Vergleiche [Enough Software], S. 96f.
82
Vergleiche [mobile Developer-1], S. 28ff.
83
Vergleiche [Mobile Joomla!].
84
85
Vergleiche [Rodger, 2012], S. 5.
81
38
sind. Es findet jedoch ein Standardisierungsprozess durch das W3C statt, um mobile
Widgets standardmäßig zu etablieren.86 Mobile Widgets sehen für den Nutzer aus wie native
Anwendungen. Sie sind jedoch aufgrund ihrer Programmierung eine Sonderform von
Webanwendungen, da im Gegensatz dazu rohe Daten und keine HTML-Seiten übergeben
werden. Die Distribution dieses Anwendungstyps kann über einen Store, aber auch über
einen Link auf einer Webseite durchgeführt werden.87
4.2.5. Plattformunabhängige Entwicklungstools
Es gibt drei grundlegende Vorgehen, bei denen versucht wird, mit einem Projekt mehrere
Plattformen
zu
erreichen.
Diese
werden
innerhalb
von
plattformunabhängigen
Entwicklungstools eingesetzt. Zum einen ist dies die bereits erwähnte Entwicklung von
hybriden Anwendungen mittels eines WebViews innerhalb der nativen Anwendung. Zum
anderen gibt es die Methode der Interpretation. Hier wird für jede Plattform eine Engine
mitgeliefert, die den erstellten Code in eine der Plattform bekannte Sprache interpretiert. Die
dritte Möglichkeit ist die Cross-Kompilierung, bei der die Anwendung für eine Plattform
programmiert und anschließend in die nativen Sprachen der anderen Plattformen übersetzt
wird.88
Das größte Hindernis einer plattformunabhängigen Entwicklung, die in allen drei
Vorgehensweisen beachtet werden muss, ist die Anpassung der UI. Die einer Plattform
bekannten Nutzungsmethoden wie Touchgesten oder das Design der Anwendung können
durch die Verwendung von plattformübergreifenden APIs so verändert bzw. anders
dargestellt werden, dass sie für den Nutzer nicht selbsterklärend sind. Dies führt zu Fehlern
innerhalb der Bedienung der Anwendung, was jedoch für den Nutzer so aussieht, dass die
Anwendung nicht funktioniert. Das kann anschließend dazu führen, dass die Anwendung
nicht mehr verwendet wird. Die Anpassung an die UIs der verschiedenen Plattformen
beinhaltet jedoch einen immensen Aufwand. Weitere Herausforderungen stellen u. a. die
Multitaskingfähigkeit der Betriebssysteme, der Batterieverbrauch und Push Services dar.89
86
Vergleiche [W3C-3].
Vergleiche [Enough Software], S. 8, 78ff.
88
89
Vergleiche [Enough Software], S. 92ff.
87
39
4.3. Unterschiede in der Programmierung von
Smartphone- und Tablet-PC-Anwendungen
Die vorgestellten Betriebssysteme gehen unterschiedlich mit der Unterstützung von
Smartphones und Tablet-PCs um. Symbian wird allein auf Smartphones eingesetzt. 90 Die
Programmierung für andere Geräteklassen ist damit kein Diskussionsgegenstand.
Dagegen bietet Android mit Honeycomb ein eigenes Betriebssystem für Tablet-PCs.
Außerdem sind auf dieser Plattform laufende Programme generell aufwärts kompatibel und
können auf höheren API-Versionen eingesetzt werden. Dadurch können Anwendungen mit
der Version 2.x auch unter Honeycomb laufen. Neuere Komponenten der APIs (z. B.
Funktionen oder UI-Element) werden in diesem Fall jedoch nicht unterstützt, da keine
Abwärtskompatibilität vorliegt.
91
Es ist jedoch möglich, die API-Version zur Laufzeit abzu-
fragen und dementsprechend Anpassungen vorzunehmen.92
iOS ist im Gegensatz zu Android sowohl für das iPhone als auch für das iPad konzipiert.
Jede iPhone-Anwendung läuft ebenfalls auf Apples Tablet-PC. iPad-Anwendungen, die die
größere Nutzungsoberfläche ausnutzen und mehr Informationen darstellen, können jedoch
umgekehrt nicht auf iPhones ausgeführt werden.93
Die Konzeption von Anwendungen für unterschiedliche Displaygrößen und Auflösungen
bilden für Apple und Android einen Schwerpunkt in der Entwicklung für Smartphones und
Tablet-PCs. Zusätzlich muss bei Android noch der erweiterte Funktionsumfang der TabletAPIs im Vergleich zu den Smartphone-APIs beachtet werden.
90
Vergleiche [Symbian Blog].
92
Vergleiche [mobile Developer-2], S. 56ff.
93
Vergleiche [Goldstein, 2011], S. 9ff.
91
Realisierungskonzept
40
5. Realisierungskonzept
Dieses Kapitel stellt ein Konzept vor, welches beschreibt, wie die in der Anforderungsanalyse
beschriebene Anwendung realisiert wird. Zuerst werden dafür auf Basis der Ergebnisse des
vorigen Kapitels sinnvolle Technologien ausgewählt und das System aus technologischer
Sicht konzipiert. Weiterhin werden der Aufbau der Nutzerschnittstelle sowie dort
einzuhaltende Richtlinien beschrieben. Darauf aufbauend wird anschließend die Anwendung
funktional modelliert. Dieser Abschnitt widmet sich dabei den Vorgängen, die essentiell für
die Umsetzung der Funktionen, die die Anwendung leisten soll, sind.
Für den ersten Prototypen wurden die Anforderungen nach Relevanz sortiert. Zweitrangige
Anforderungen sind nicht (!) Inhalt des Realisierungskonzeptes. Zu ihnen wird jedoch zum
Abschluss dieses Kapitels kurz Stellung genommen.
5.1. Systemaufbau
In diesem Unterkapitel wird der Aufbau der Anwendung aus technologischer Sicht
beschrieben. Dieser beinhaltet die Festlegung der Zielplattform der Anwendung sowie die
Art, wie sie entwickelt werden soll. Beides wird auf Basis der im vorigen Kapitel
durchgeführten Analyse festgelegt. Des Weiteren wird erläutert, wie die Architektur des
Gesamtsystems sinnvoll erweitert und darauf aufbauend die Kommunikation zum Server
stattfinden wird. Es werden außerdem weitere Komponenten vorgestellt, die das System
ergänzen und nachträglich zum System hinzugefügt werden müssen. Dies betrifft die
Erweiterung um eine API zum Einsatz von GIS.
5.1.1. Zielplattform
Die im vorigen Kapitel durchgeführten Analysen der Betriebssysteme zeigen, dass die
Entwicklung für Android aktuell die beste Wahl darstellt. Zum einen wird kein App Store
benötigt, wodurch die Distribution der Anwendung eigenständig gesteuert werden kann. Um
jedoch trotzdem eine Vielzahl an Nutzern zu erreichen, ist es zum anderen von Vorteil, dass
die Plattform weit verbreitet ist. Potentielle Nutzer werden daher mit größerer Wahrscheinlichkeit ein Android-Smartphone besitzen und die Anwendung sofort einsetzen können. Dies
gilt sowohl z. B. für Deutschland als auch für Brasilien. Die Kooperation zwischen der
Hochschule Bremen und den Universitäten in Pernambuco und Recife im Bereich der
Biodiversitätsforschung wird somit berücksichtigt. Zudem wird durch den Einsatz von Android
weiterhin mit Open Source gearbeitet.
41
5.1.2. Zielstruktur
Für die Umsetzung der Anwendung bieten sich sowohl die native Programmierung als auch
die Erstellung einer Web- oder hybriden Anwendung an. Mobile Widgets sind noch nicht in
dem Maße in Android standardisiert, als dass sie ebenfalls in Frage kommen würden. Sie
könnten mit Titanium oder PhoneGap für die Plattform umgesetzt werden. 94 Allerdings bieten
die drei anderen Möglichkeiten geeignetere Alternativen, dadurch dass sie von Haus aus mit
Android eingesetzt werden können.
Auch wenn mittlerweile Webanwendungen schon sehr viel leisten können, ist es sinnvoll die
erste Version der mobilen Anwendung rein nativ zu programmieren. Neben der schnelleren
Einarbeitungszeit in Android im Vergleich zum mobilen Web, hat dies den Vorteil, dass die
benötigten Hardwarefeatures sicher benutzt werden können. Die Entwicklung einer hybriden
App würde die Einarbeitung in beide Technologien bedeuten. Der Prototyp der mobilen
Anwendung zur Erfassung von Biodiversitätsdaten wird daher nativ entwickelt.
Bei der anschließenden Wahl der zu nutzenden Android API ist zu bedenken, für welche
Geräteklasse man programmieren und welche Leistungen man anbieten möchte. Zusätzlich
sollte die Verbreitung der Versionen berücksichtigt werden. Da die mobile Anwendung zur
Erfassung von Biodiversitätsdaten für Smartphones konzipiert wird, sollte man zurzeit
entweder Android 2.2 oder 2.3 nutzen. Android-Programme sind generell aufwärts
kompatibel
und
können
auf
höheren
API-Versionen
eingesetzt
werden.
Eine
Abwärtskompatibilität liegt nicht vor. Infolgedessen wird Version 2.2 (API 8) verwendet.
Diese Version sollte durch die Aufwärtskompatibilität ebenfalls unter Honeycomb auf TabletPCs laufen.
5.1.3. Entwicklungsumgebung
Android bietet eine vollständige Integration in die Open Source-Entwicklungsumgebung
Eclipse. Dafür wird neben der Installation des benötigten Android SDK ein Plugin für Eclipse
installiert. Dieses wird als Android Development Tools (ADT) bezeichnet. Damit kann in
Eclipse ein Android-Projekt angelegt, das UI erstellt, Anwendungen debuggt und die Projekte
signiert werden.95 Die Anwendung wird daher mit Eclipse implementiert.
94
95
42
5.1.4. Client-Server Architektur
Der neue mobile Client muss in die bestehende Architektur eingegliedert werden. Aus
Sicherheitsgründen sollte er dabei nicht direkten Zugriff auf den Datenbankserver besitzen.
Demnach muss der Client mit einem zusätzlichen Server kommunizieren. Der CMS-Server
könnte als Kommunikationsstelle mit der mobilen Anwendung eingesetzt werden. Dies würde
bedeuten, dass der Client HTML-Seiten, die mit Javascript verknüpft sind, abrufen würde.
Innerhalb dieser Seiten würden sich die Daten befinden, die vom restlichen Code getrennt
werden müssten. Dieser ist überflüssig und stellt einen Overhead dar. An dieser Stelle sollte
deutlich werden, dass dieser Ansatz wenig effizient ist, da zusätzliches Datenvolumen
verursacht wird, das den Mobilfunkvertrag des Nutzers unnötig belastet. Außerdem benötigt
die Filterung der Daten aus den HTML-Seiten heraus Zeit.
Es entsteht daher eine neue Gesamtarchitektur (siehe Abbildung 12), in die neben dem
mobilen Client auch ein weiterer Server hinzugefügt wird. Der mobile Client ist sowohl für die
Logik, als auch für die Datenhaltung und die Präsentation zuständig. Die Aufteilung dieser
Bereiche auf einzelne Komponenten der Architektur ist daher nicht mehr vollständig möglich
und wird ferner nicht weiter verwendet.
Abbildung 12: Neue Gesamtarchitektur
Der Webserver dient dem Client als Kommunikationspartner, der Daten aus der Datenbank
des Biodiversitätsatlas abruft und ihm diese schickt. Umgekehrt nimmt er neue Funde
43
entgegen und speichert sie in der Datenbank. Um dies zu realisieren bedarf es eines
Kommunikationskanals, über den schnell und kompakt Daten versendet werden können.
In Zusammenhang mit Android existieren dafür sehr viele Möglichkeiten, die umgesetzt
werden könnten. Standardmäßig bietet die Plattform im Java SDK die Kommunikation über
eine einfache HTTP- bzw. HTTPS-Verbindung sowie über Sockets bzw. SSL Sockets an. Mit
diesen lassen sich sowohl Server als auch Clients auf dem mobilen Gerät erstellen. Weitere
Alternativen für die Programmierung der Client-Server-Kommunikation wären der Einsatz
von XML- oder JSON-basierten Webservices mittels SOAP, REST oder Servlets, JSONRPC oder WebSockets. Eine Recherche zum Einsatz der unterschiedlichen Technologien
innerhalb von Android zeigte, dass jede genannte Möglichkeit häufig eingesetzt wird.
Achtung sollte jedoch bei der Verwendung von Beans und Java RMI geboten sein: Nicht alle
Pakete, die zum Java SDK gehören, sind auch in der Java SDK-Variante in Android
vorhanden; die Pakete java.rmi und java.beans gehören z. B. nicht dazu.96
Ein ausführlicher Vergleich der genannten Technologien wäre eine wichtige Aufgabe, die bei
der Implementierung der neuen Architektur eine Rolle spielt. Da in dieser Arbeit der
Schwerpunkt vornehmlich auf der Clientanwendung liegt, wird jedoch vorerst eine schnell
umzusetzende Technologie gewählt, die bereits im Funktionsumfang von Android enthalten
ist – nämlich Sockets. Für den Einsatz von Sockets spricht zusätzlich, dass die zu
übertragenden Daten als Objekte gesendet werden können. Die Zusammensetzung von
Funden, Spezies, Messungen und Fundorten können so in Java-Klassen abgebildet sowie
Daten über öffentliche Zugriffmethoden auf diese Klassen direkt gespeichert und abgerufen
werden. Da die Daten in der mobilen Anwendung weiterverwendet werden müssen, bietet
dieser Ansatz folgende Möglichkeit: Die Umsetzung über Sockets beinhaltet das Senden und
Empfangen von Java-Objekten. Bspw. wird ein Fundort so auf eine Java-Klasse abgebildet,
dass dieser, nachdem der Server ihn an den Client gesendet hat, direkt weiterverarbeitet
wird. Die Modellierung der Java-Objekte ist somit fester Bestandteil des Clients.
Abbildung 13: Direkte Client-Server-Kommunikation über Sockets
Sollte die Socket-Kommunikation mit einer anderen Technologie (bspw. REST) ausgetauscht
werden, müsste clientseitig allein die Komponente der Verbindung zum Server ausgetauscht
werden. Die Nutzung der erstellten Java-Klassen zur Abbildung der Fundorte bleibt
96
Vergleiche [Becker, 2009], S. 327f.
44
bestehen. Die Schnittstellen innerhalb des Clients werden dafür modular implementiert, dass
allein ein Wrapper benötigt wird, der zum einen die Kommunikationsstelle zum Server
enthält. Zum anderen bearbeitet er die Daten, die z. B. als XML-Objekt vorliegen und
überführt sie in die jeweiligen Java-Klassen. Mit diesen kann der Client anschließend
weiterarbeiten. Auf diese Weise ist die Verbindung vom Client zum Server austauschbar.
Abbildung 14: Alternative Client-Server-Kommunikation unter Nutzung eines Wrappers
5.1.5. Einsatz von GIS
Ein GIS bildet einen Schwerpunkt innerhalb der mobilen Anwendung. Es ist jedoch keine
Bibliothek
zur
Erzeugung
von
GIS-Karten
im
Android
SDK
enthalten.
In
der
Anforderungsanalyse wurde festgelegt, dass vorzugsweise Karten von OSM verwendet
werden sollen, da diese als Open Source verfügbar sind und bereits im Biodiversitätsatlas
genutzt werden. Alternativen dazu gibt es (wie z. B. Google Maps97). Bei der Auswahl einer
geeigneten GIS-API wurde aufgrund der Anforderungen nach einem Weg gesucht, OSM
einzubinden. Dies wird durch die Open Source-Bibliothek osmdroid98 umgesetzt. Diese JavaBibliothek steht unter der GNU Lesser GPL (LGPL).
Karten werden über ein MapView-Widget99 in die Anwendung eingebunden. Das Kartenelement ist ein Container für die Darstellung der Tiledaten. Für das Widget wurden bereits
die Zoomfunktion und das Verschieben durch Touchgesten implementiert. Es kann mit
weiteren Layern und Markern erweitert werden.100
Des Weiteren bietet die Bibliothek einen TileProvider, der für das Empfangen, Speichern und
Abrufen der Tiledaten eingesetzt wird. Zum einen lädt der TileProvider die Daten bei einer
vorliegenden Internetverbindung herunter und zeigt sie an. Zum anderen legt er gleichzeitig
einen Tile-Cache an, durch den es möglich ist, offline auf die bereits angesehenen Karten in
den jeweiligen abgerufenen Zoomstufen zuzugreifen. Daneben hat man die Möglichkeit, die
Anwendung mit einem Archiv, in dem ausgesuchte Tiles vorhanden sind, auszustatten. 101
97
Siehe [Google code].
Siehe [Google Project Hosting-1].
99
Der Aufbau der Nutzerschnittstelle wird in Kapitel 5.2 beschrieben.
100
Siehe [Google Project Hosting-2].
101
Vergleiche [Google Project Hosting-3].
98
45
Zur Erstellung solcher Archive gibt es Tools, wie z. B. den Mobile Atlas Creator102. Dort wird
festgelegt, welcher Kartenausschnitt archiviert werden soll und es werden zusätzlich die
Zoomlevel beschränkt. Jeder Biodiversitätsatlas enthält Informationen zu der abgedeckten
Fläche, mit denen ein solches Archiv vor Auslieferung an den Nutzer erstellt werden kann.
Aufgrund der Lizenzierung und den Anforderungen wird das Android SDK um die osmdroidBibliothek zur Umsetzung der mobilen Anwendung mit GIS erweitert. Durch das MapViewWidget ist ein modularer Austausch von Kartendaten gegeben.
5.2. Nutzerschnittstelle
Im Folgenden wird gezeigt, wie ein einheitliches Layout mit den wichtigsten DesignKonzepten umgesetzt werden kann und eine Struktur in die Nutzerschnittstelle gebracht
wird. Außerdem wird ein Navigationspfad für die mobile Anwendung vorgestellt, der zeigt,
welche Bildschirmseiten der Nutzer wann zu sehen bekommt und wie er in der Anwendung
navigieren kann. Vorher wird beschrieben, wie das UI in Android aufgebaut wird.
Das UI wird aus hierarchisch angeordneten Views gebildet.103 Es stehen dafür standardmäßig Views zur Verfügung, die in drei Kategorien aufgeteilt werden. Zum einen gibt es
Layouts. Sie sind von der Klasse ViewGroup abgeleitet und sorgen für die Anordnung der
anderen Views. Zum anderen gibt es Views, die als Widgets bezeichnet werden. Diese sind
nicht zu verwechseln mit Mobile Widgets (Kapitel 4.2.4). Es sind visuelle und auch interaktive
Elemente auf dem Bildschirm, mit denen der Nutzer interagieren kann, wie z. B. Buttons,
Checkboxen, Textfelder oder der zuvor beschriebene MapView. Als letztes gibt es noch
Zeichenflächen, welche rechteckige Bereiche darstellen, in die z. B. Bilder eingefügt werden
können und in denen gezeichnet werden kann.104
Ein Layout kann auf zwei Wegen erzeugt werden. Entweder per Code in einer Activity 105
oder mit einer XML-Layout-Datei, welche im Ressourcenordner res/layout gespeichert wird.
Activities sind eine der wichtigsten Komponenten in Android, die die Anzeige des UI erst
ermöglichen und diese mit Funktionen hinterlegen. Sie repräsentieren generell eine
Bildschirmseite und bestehen aus einem oder mehreren Views. Sie besitzen einen speziellen
Lebenszyklus, der durch das System gesteuert wird (siehe Abbildung 15: Lebenszyklus einer
102
Siehe [MOBAC].
Siehe [Android Developers-7].
104
Vergleiche [Louis, 2011], S.78.
105
103
46
Activity). Es gibt spezielle Activities, die ein bestimmtes Layout erstellen, wie z. B. eine
Listenansicht.106
Abbildung 15: Lebenszyklus einer Activity107
Activities sind lose aneinander gekoppelt. Sie kommunizieren untereinander allein über
Intents. Über diese ist es möglich Daten zu schicken, die durch ein Callback in der
ausgehenden Activity wieder abgerufen werden. Dazu muss der aufzurufenden Activity
bekannt gegeben werden, dass von ihr ein Rückgabewert erwartet wird. Der ermittelte Wert
wird in einem Intent gespeichert, der an die erste Activity zurückgegeben wird.
106
107
Vergleiche [Louis, 2011], S. 76f.
47
5.2.1. Einsatz von UI Patterns
Obwohl von Android keinerlei Vorgaben zur Gestaltung des Designs gemacht werden, haben
sich mittlerweile einige Konzepte zur Gestaltung von UIs bewährt. Diese werden seit der
Veröffentlichung von Ice Cream Sandwich von Android empfohlen.108 Im Folgenden werden
zwei Konzepte zur Gestaltung des UIs vorgestellt, die in der mobilen Anwendung umgesetzt
werden.
Abbildung 16: Dashboard (UI Patterns)109
Das erste Konzept ist der Einsatz eines Dashboards. Dies ist die zentrale Bildschirmseite der
Anwendung. Von hier aus können alle Aktionen gestartet werden. Dafür werden Buttons
angeboten, die auf die weiteren Seiten führen. Abbildung 16 zeigt den Aufbau eines solchen
Dashboards.
Mit Hilfe einer Action Bar wird zusätzlich ein einheitliches Erscheinungsbild der Anwendung
realisiert. Hier werden Buttons platziert, über die der Nutzer in der Anwendung navigieren
und wichtige Funktionen ausführen kann. Die Action Bar wird als wichtigstes Element einer
Anwendung angesehen.110 Daher wird sie in der mobilen Anwendung eingesetzt.
108
Vergleiche [Android Design-1].
Quelle: [Android UI Patterns].
110
Vergleiche [Android Design-2].
109
48
Abbildung 17: Action Bar (UI Patterns)111
5.2.2. Navigationspfad
Zur Strukturierung der Anwendung in Bezug auf die dargestellten Bildschirmseiten zeigt
Abbildung 18: Nutzerpfad der mobilen Anwendung den Nutzerpfad der mobilen Anwendung.
Die in der Anforderungsanalyse beschriebenen Funktionen wurden dafür Activities zugeteilt.
die Anwendung startet mit einer Anmeldung, bei der sich der Nutzer authentifizieren muss.
Hat er dies erfolgreich getan, wird er zum Dashboard der Anwendung – dem HomeBildschirm – geführt. Hier hat er die Möglichkeit, die Kameraanwendung zu starten,
Einstellungen vorzunehmen, einen neuen Fund zu erfassen und bereits fertig gestellte
Funde zu verwalten. Wenn ein neuer Fund erfasst wird, kann man zu weiteren Seiten
gelangen, die jeweils einen Rückgabewert mit Hilfe von Intents liefern. Es wird ein Bild aus
der Bildergalerie, eine Spezies aus einer Liste sowie ein Fundort aus einer GIS-Karte oder
Liste ausgesucht. Für letzteren hat man zusätzlich die Möglichkeit, einen neuen Fund
anzulegen. Dies geschieht ebenfalls durch eine neue Activity, der die empfangene GPSKoordinate übergeben wird. Als Ergebnis wird ein neuer Fundort zurückgeliefert, der dann
über die Fundort-Activity weitergeleitet wird.
111
Quelle: [Android UI Patterns].
49
Abbildung 18: Nutzerpfad der mobilen Anwendung
Der Zurück-Button, mit dem alle Android-Geräte ausgestattet sind, dient dem Nutzer dazu,
zu der vorher gestarteten Activity zurückzugehen. Für jede Anwendung wird dafür durch
Android ein Task angelegt. Dieser beinhaltet einen Stack, in dem Activities in der
Reihenfolge, in der sie gestartet wurden, eingeordnet werden. Wenn eine Activity beendet
wird, wird sie aus dem Stack entfernt. Hier spielt der oben erwähnte Lebenslauf einer Activity
eine wichtige Rolle. Die Activity wird (falls Speicherplatz benötigt wird) entweder durch das
System oder durch die Anwendung selber, was in der Programmierung festgelegt wird,
gelöscht.112 In Bezug auf die Anwendung heißt dies, dass bestimmt werden kann, zu welcher
Activity aus der Reihe der Bildschirmseiten, die vorher aufgerufen wurden, das Programm
zurückkehren soll, wenn der Zurück-Button geklickt wird.
112
50
Sobald ein neuer Fund eingetragen wird, wäre es nicht sinnvoll, wieder zu den vorhandenen
Fundorten zurückzukehren, sondern direkt zu der Seite des Fundes. Die Activity des
Fundortes wird daher, sofern der Nutzer den Erfassungsvorgang eines neuen Ortes nicht
abbricht, zu der Erfassung des Fundes weitergeleitet. Bei allen anderen Activities wird der
Nutzer zur letzten Activity zurückgeleitet, wenn der Zurück-Button betätigt wird.
5.3. Funktionaler Aufbau
Im Folgenden wird ein Konzept beschrieben, wie die in der Anforderungsanalyse vorgestellten und benötigten Informationen erhoben und verarbeitet werden.
5.3.1. Datenerfassung
Die wesentliche Funktion, die durch die mobile Anwendung realisiert werden soll, ist die
Erfassung eines Fundes inklusive die eines neuen Fundortes. Die in der Anforderungsanalyse festgelegten Daten, die für einen Fund ermittelt werden müssen, werden
übersichtlich für den Nutzer innerhalb einer Bildschirmseite dargestellt. Sie können in drei
Gruppen eingeteilt werden, die verdeutlichen, auf welche Weise die Daten eingegeben bzw.
erzeugt werden. Diese werden folgend erläutert.
5.3.1.1. Separater Vorgang
Die Erfassung der Daten der ersten Gruppe stellt einen zusätzlichen Vorgang dar, der in
weiteren Bildschirmseiten (also Activities) durchgeführt wird, und den Aufbau einer
Verbindung zum Server beinhaltet. Dies ist zum einen die Ermittlung des Editors, welcher
dem Fund bzw. einem neuen Fundort als Bearbeiter und Urheber zugeordnet wird. Der
Editor ist der zurzeit am System angemeldete und für die Erfassung von Funden autorisierte
Nutzer der Anwendung. Die Nutzerauthentifizierung wird in Kapitel 5.3.3 näher erläutert.
Zum anderen muss der Nutzer dem Fund eine Spezies zuweisen. Dazu wird eine Liste der
vorhandenen Spezies benötigt. Diese erhält der Client, indem er den Server kontaktiert und
eine Liste aller vorhandenen Spezies abruft. Jede Spezies enthält dabei die eindeutige
Identifikationsnummer (anhand derer sie dem Fund zugeordnet wird), die wissenschaftliche
Bezeichnung sowie die Populärnamen. Letztere liegen dem Biodiversitätsatlas in mehreren
Sprachen vor. Spezies werden sowohl mit dem wissenschaftlichen als auch mit dem
Populärnamen angezeigt, sofern einer vorliegt. Die Darstellung der Populärnamen wird
anhand der in Android vorliegenden Konzepte zur Mehrsprachigkeit umgesetzt. Deren
51
Funktionsweise und die Darstellung der Bezeichnung einer Spezies werden in Kapitel
5.3.45.3.4 beschrieben. Der Vorgang wird mit der Auswahl abgeschlossen.
Eine Suchfunktion auf Basis der vorhandenen textuellen Bezeichnungen einer Spezies
unterstützt den Nutzer bei der Auswahl der Spezies aus der vorhandenen Liste. Für die
Suche enthält Android ein Framework.113 Um den Suchvorgang zu starten, wird entweder der
Standardsuchbutton auf dem Gerät oder ein in der Anwendung vorhandener Button
verwendet. Letztere Lösung wird von Android empfohlen, da u. U. der Standardsuchbutton
auf dem Gerät nicht vorhanden ist.
Neben dem Editor und der Spezies wird ebenfalls für die Ermittlung des Fundortes ein
separater Vorgang gestartet. Eigentlich gehört der Ort zu einer Messung, die ihn mit dem
Datum verknüpft. Aufgrund dessen, dass keine weiteren Informationen zu einer Messung
erhoben und die für den Nutzer dargestellten Informationen auf ein Minimum beschränkt
werden, wird die Messung für den Nutzer nicht dargestellt. Die strukturelle Modellierung
eines Fundes dargestellt in Java-Klassen wird jedoch diese Zwischenstufe beinhalten, damit
die Daten dem Datenbankmodel der Biodiversitätsatlas-Datenbank angeglichen sind. So
kann der Server diese leichter verarbeiten.
Die Liste der Fundorte wird genauso wie die Liste der Spezies vom Server abgerufen. Jeder
Fund enthält die eindeutige Identifikationsnummer, einen Namen und eine Koordinate. Die
Funde werden sowohl innerhalb der Liste als auch unter Einsatz der durch osmdroid
erzeugten Karte dargestellt. Innerhalb der Karte werden sie anhand ihres Namens und mit
einem Marker angezeigt. Ein Ort wird entweder über einen Listeneintrag oder über einen
Marker ausgewählt. Die Liste der Orte ist ebenfalls anhand der Namen durchsuchbar. Im
Falle der Suche innerhalb der Karte wird für die gefundenen Einträge, die zum Suchstring
passen, zuerst eine Liste der Namen der Fundorte angezeigt. Wählt der Nutzer anschließend
einen der Einträge aus, wird der gefundene Marker in der Karte angezeigt.
Neben den vorhandenen Fundorten, wird in der Karte der aktuelle Standort angezeigt, der
mit Hilfe des GPS-Dienstes des Geräts ermittelt wird. Die Ermittlung dieser Koordinate wird
unter 5.3.1.3 beschrieben. Wenn eine Koordinate vorliegt, kann ein neuer Fund eingetragen
werden. Diesem neuen Fund wird die Koordinate fest zugeordnet. Sie kann nicht verändert
werden. Die Erfassung der Daten zu einem Fund ist in Kapitel 5.3.1.2 erläutert.
Weiterhin werden Bilder einem Fund zugeordnet. Über den Home-Bildschirm kann der
Nutzer dafür zuerst Bilder aufnehmen. Android bietet eine Kameraanwendung, die in diesem
Fall aufgerufen wird. Dies geschieht (wie auch der Aufruf der Activities innerhalb der
Anwendung) über Intents. Eine eigene Kameraanwendung wird nicht erstellt, sondern die
113
52
vorhandenen Mittel, die über das Betriebssystem angeboten werden, genutzt. Da mehrere
Bilder zugeordnet werden, die dementsprechend Platz brauchen, wird die Zuordnung der
Bilder zu einem Fund in einen separaten Vorgang ausgelagert. Hier werden die durch die
Kameraanwendung aufgenommenen Bilder ausgewählt.
5.3.1.2. Nutzereingaben mittels Widgets
Die zweite Gruppe beinhaltet direkte Nutzereingaben innerhalb einer Bildschirmseite, für
deren Darstellung keine Verbindung zum Server aufgebaut werden muss und die mit Hilfe
von Widgets durchgeführt werden.
Der Nutzer bestimmt die Qualität des Fundes. Dazu wird ihm ein Spinner visualisiert, welcher
ein aus einer Liste ausgewähltes Textobjekt anzeigt. Die Werte, die sich in dieser Liste
befinden, werden nicht vom Server abgerufen, da davon ausgegangen wird, dass sie sich
nicht verändern. Nichtsdestotrotz wird ein Mechanismus benötigt, der dem Fund die richtige
ID der Qualität zuordnet. Die direkte Sichtung hat in der Datenbank des Biodiversitätsatlas
die ID „1“ und der indirekte Nachweis die ID „3“. Diese müssen je nach Auswahl eines
Elementes durch den Spinner gesetzt werden, damit die Qualität des Fundes korrekt in die
Datenbank eingetragen wird.
Die Verfremdung des Fundes wird durch eine Checkbox realisiert. Standardmäßig wird der
Ort veröffentlicht. Sollte der Nutzer damit nicht einverstanden sein, ändert er den Zustand
der Checkbox.
Es wird ebenfalls eine Checkbox für die Veröffentlichung des Kommentares zu einem Fund
verwendet. Sie ist so eingestellt, dass der Kommentar veröffentlicht wird, was der Nutzer
jedoch wieder ändern kann. Der Kommentar wird in einem Textfeld eingegeben.
Bis auf die Koordinate und den Editor werden die Informationen zu einem Fundort ebenfalls
durch Widgets erfasst. Diese bestehen aus dem Namen des Ortes sowie dem Kommentar,
welche beide in ein Textfeld eingetragen werden. Auch hier wird zusätzlich eine Checkbox
für die Veröffentlichung des Kommentares verwendet. Weiterhin kann der Nutzer ein
entsprechendes Land durch einen Spinner wählen. Die Liste der durch den Atlas abgedeckten Länder ist in der Anwendung gespeichert (siehe dazu Kapitel 5.3.5).
Alle Texteingaben durch einen Nutzer müssen aus Sicherheitsgründen überprüft werden, da
sie in die Datenbank des Biodiversitätsatlas eingefügt werden. Demnach wird jede
Nutzereingabe nach SQL-Befehlen durchsucht, um die Gefahr vor einer SQL-Injection zu
vermeiden.
53
5.3.1.3. Ermittlung durch das System
Das aktuelle Datum wird durch das System ermittelt und kann nicht durch den Nutzer
verändert werden. Dies hat den Grund, dass die Anwendung direkt nach Sichtung eingesetzt
wird. Die Erfassung findet daher zum gleichen Zeitpunkt statt und erhält dementsprechend
ein festes Datum.
Ebenfalls durch das System ermittelt wird bei der Erfassung eines Fundes die aktuelle GPSKoordinate des Smartphones. Der Abruf der Koordinate erfolgt ebenfalls über ein
Framework, welches Bestandteil des Android SDK ist.114 Die Koordinate kann sowohl über
den GPS-Sensor als auch über die umliegenden Wifi-Netze ermittelt werden, welche als
LocationProvider bezeichnet werden. Zum Abruf dieser Provider dient als zentraler Dienst
der LocationManager. Um ein schnellstmögliches Ergebnis zu erhalten, werden beide
genannten Provider eingesetzt und die Suche nach der aktuellen Position beendet, wenn
einer der Provider ein Ergebnis liefert.
Da über die mobile Anwendung nicht die Möglichkeit besteht, eine zusätzliche Koordinate für
eine Messung einzutragen, wäre es sinnvoll, für jeden Fund die ermittelte GPS-Koordinate
an den Server zu schicken. Auf diese Weise besteht eine weitere Möglichkeit, einen Fund
noch zu dokumentieren.
5.3.2. Schnittstelle zum Server
Der Client startet die Kommunikation, indem er eine Anfrage an den Server stellt. Dies wird
in folgenden Szenarien durchgeführt:
1. Verifikation von Zugangsdaten zur Anmeldung eines Nutzers
2. Abruf einer Liste der vorhandenen Spezies
3. Abruf einer Liste der vorhandenen Orte
4. Senden eines Fundes
5. Senden von Bildern
Zentrales Augenmerk wird in diesem Abschnitt auf die letzten beiden Fälle gelegt. Die
Kommunikation mit dem Server für die Verifikation der Zugangsdaten wird in Kapitel 5.3.3.
behandelt, da sie eng mit dem Prozess der Nutzerauthentifizierung verbunden ist. Zum Abruf
der Listen für Spezies und Orte wurden die wesentlichen Vorgänge bereits im vorherigen
Abschnitt behandelt, da sie nur wenige Schritte behandeln und auf die Anfrage allein eine
Antwort vom Server zurückgesendet wird. Damit sind die Vorgänge abgeschlossen.
114
Siehe http://developer.android.com/guide/topics/location/index.html.
54
Komplexere Vorgänge, für die ein bestimmtes Protokoll durchgeführt werden müssen, sind
dagegen das Senden eines Fundes und das Senden von Bildern.
Um den Fund zu versenden, steht dem Nutzer ein Button zur Verfügung, welcher folgenden
Vorgang startet, sofern alle Daten eingetragen wurden:
1. Die eingegebenen Daten werden in einem Objekt gespeichert.
2. Dem Server wird Bescheid gegeben, dass ein neuer Fund gesendet werden soll.
3. Im Anschluss daran wird direkt das Objekt gesendet.
4. Die Anwendung erhält als Antwort eine Zahl zurück, die anzeigt, ob der Fund
verarbeitet werden konnte.
Falls die Kombination zwischen der Spezies und der Messung (Ort und Datum) bereits
vorliegt, kann der Fund nicht in der Datenbank gespeichert werden. Dies liegt daran, dass
die Kombination ein eindeutiger Index innerhalb des Datenbankmodells ist. Aufgrund dessen
ist es sinnvoll, dem Nutzer mitzuteilen, ob ein Fund bereits gemeldet wurde. Der Nutzer weiß
dadurch, dass die Spezies, die er an Tag X entdeckt hat, bereits durch jemand anderen
gesichtet und gemeldet wurde. Erhält er lediglich die Meldung, dass der Fund gesendet
worden ist, wüsste er nicht, dass dieser Fund verworfen wurde und jemand anders als Editor
des Fundes eingetragen ist. Um darauf folgende Urheberrechtsprobleme zu verhindern,
erwartet die Anwendung nach dem Senden eines Fundes eine Antwort des Servers, die die
beschriebene Information enthält.
Code
-1
Statusbeschreibung
Der Fund konnte durch den Server nicht verarbeitet und angelegt werden,
da er bereits existiert.
0
Der Fund wurde bislang nicht gesendet bzw. es lag keine Netzwerkverbindung vor, sodass der Fund nicht gesendet werden konnte. Dies gilt
ebenso, wenn die Netzwerkverbindung während der Übertragung abbricht.
>0
Der Fund wurde erfolgreich angelegt. Der Code entspricht der Identifikationsnummer des Fundes in der Datenbank.
Tabelle 1: Status eines Fundes
Es werden mehrere Bilder einem Fund zugeordnet. Sie werden allerdings unabhängig von
dem Fund versendet, da sie in der Modellierung mit Sockets als Dateien verschickt werden.
Bei dem Fund handelt es sich dagegen um ein Objekt. Die Dateien werden nacheinander an
den Server gesendet. Dieser muss dafür vorab mitgeteilt bekommen, dass Bilder gesendet
55
werden, zu welchem Fund sie gehören, wie groß jedes einzelne Bild ist und welchen Titel es
hat. Der zweite Punkt bedingt, dass der Fund bereits erfolgreich gemeldet wurde.
Es ist keine Antwort des Servers zum erfolgreichen Empfangen und Speichern notwendig.
Allein die Verbindung zum Server muss durch die Anwendung kontrolliert werden. Sollten
Bilder nicht versendet werden können, besteht nicht die Möglichkeit, die Bilder erneut zu
schicken. An dieser Stelle ist das Bild direkt an die Redaktion des Biodiversitätsatlas mit
einer Referenz auf den Fund zu senden.
Da der Verbindungsaufbau und die Datenübertragung einige Zeit in Anspruch nehmen
können, wird empfohlen, diese Aufgaben in Threads auszulagern. Ansonsten friert das UI für
die Ausführung der Kommunikation ein. Dadurch ist die Bedienung aus Sicht des Nutzers
nicht flüssig.115 Für die Durchführung und Entgegennahme der Daten bieten sich des
weiteren Services an. Sie sind eine wichtige Komponente, die unabhängig von Activities
gestartet wird und im Hintergrund läuft. Services besitzen ihren eigenen Lebenszyklus.
Dadurch kann zwischen Activities gewechselt werden, ohne dass der Service gestoppt wird.
Auf diese Weise ist der Service für alle Komponenten der Anwendung verfügbar.116
5.3.3. Nutzerauthentifizierung
Der Nutzer der mobilen Anwendung verfügt über Zugangsdaten, die in der Tabelle
„jos_users“ in der Datenbank des Biodiversitätsatlas abgespeichert sind. Mit diesen Daten
muss er sich zum Start der mobilen Anwendung anmelden, um sie nutzen zu können. Ohne
eine erfolgreiche Anmeldung kann der Nutzer keine Funktionen verwenden. Die Anwendung
ist, solange dies nicht geschehen ist, mit einem Login-Screen gesperrt.
Der Nutzer wird anhand seines Nutzernamens und Passwortes authentifiziert und erhält
anschließend die Autorisierung für die Erfassung von Funden. Für die Authentifizierung
werden der Nutzername und das zugehörige Passwort benötigt. Diese Daten gibt der Nutzer
in ein Formular im Login-Screen ein. Für die erste Anmeldung muss eine Verbindung zum
Server aufgebaut werden, um die Nutzerdaten zu verifizieren. Da sehr sensible Daten
geschickt werden, muss aus Gründen des Datenschutzes ein sicheres Protokoll verwendet
werden.
Da der erste Prototyp auf Sockets aufsetzen soll, wäre eine sicherere Alternative SSL
Sockets, die standardmäßig von Android angeboten wird. SSL Sockets erweitern mit Hilfe
von SSL oder TLS das Netzwerkprotokoll gewöhnlicher Sockets um eine zusätzliche Schicht,
115
116
56
die Sicherungsmaßnahmen enthält. Diese Maßnahmen umfassen die Überwachung, damit
Daten während der Übertragung nicht verändert werden, die Authentifizierung von Client und
Server sowie das verschlüsselte Senden der Daten. Man könnte nun den gesamten
Datenaustausch mit SSL Sockets realisieren. Zum einen muss dabei jedoch bedacht
werden, dass die Daten eines Fundes nicht derart sensibel sind wie die Zugangsdaten des
Nutzers. Zum anderen stellen sie eine weitaus größere Menge an Daten dar (inklusive dem
Abruf von Spezies und Funden). Des Weiteren wäre der Overhead, der durch die
Authentifizierung
der
Kommunikationspartner
in
der
Summe
aller
zu
startenden
Verbindungen anfallen würde, sehr groß. Aus diesen Gründen sollte der Server aus zwei
Sockets bestehen, die jeweils an einem Port auf eingehende Verbindungen warten.
Ist die Verbindung zum Server aufgebaut und hat er die Daten erhalten, müssen sie validiert
werden, um zu entscheiden, ob der Nutzer autorisiert wird. An dieser Stelle wird ein
Verfahren implementiert, welches dem Authorisierungsprozess in Joomla! gleicht. Joomla!
speichert Nutzerdaten in der Tabelle „jos_users“. Passwörter werden nicht im Klartext,
sondern als MD5-Prüfsumme hinterlegt. Für das Prüfsummenverfahren wird eine per Zufall
generierte 32-stellige Hexadezimalzahl117 als Salt zur Erweiterung des Passwortes
verwendet. Der bei dem Hashverfahren entstehende MD5-Hash ist ebenfalls eine 32-stellige
Hexadezimalzahl. Das Passwort lässt sich praktisch nicht wieder in Klartext umwandeln, da
die Umwandlung aufgrund der großen Länge des Hashes und der Kombination des
Passwortes mit dem Salt unter Einsatz aktueller Prozessoren zu viel Zeit benötigen würde.
Der Prüfsummenwert wird zusammen mit dem Salt in folgender Struktur als String
abgespeichert:
{ Prüfsumme }
:
{ Salt }
Abbildung 19: Struktur eines gespeicherten Passwortes in Joomla!
Um ein eingegebenes Passwort mit dem vorhandenen zu vergleichen, wird der gespeicherte
Passwortstring anhand des Doppelpunktes gesplittet. Das eingegebene Passwort im Klartext
wird mit dem Salt in die MD5-Prüfsummenfunktion gegeben und das Ergebnis mit der
gespeicherten Prüfsumme verglichen. Stimmen die beiden Prüfsummen überein, ist das
Passwort korrekt. In diesem Fall schickt der Server die dazu passende EditorID an den
Client zurück. Ist das Passwort falsch oder existiert gar der Nutzername nicht, wird eine 0
zurückgegeben.
Für die Zuordnung eines Editors zu einem Fund übermittelt man entweder den Usernamen
oder die ID. Beide Attribute sind eindeutig. Es ist jedoch sicherer, die ID zu übermitteln, da
117
Der Hash ist 128 Bit lang und wird als Hexadezimalzahl notiert.
57
man sie nicht für den Login benutzen kann. Ein Nutzername könnte abgefangen und
anschließend für eine Bruteforce-Attacke verwendet werden. Aus diesem Grund wird am
Ende des Logins die EditorID übertragen.
Wenn die Anmeldung erfolgreich war, wird das Passwort ebenfalls mit einem per Zufall
generierten Salt gehasht und mit der gleichen Struktur wie in Joomla! in der lokalen
Datenbank gespeichert. Zusätzlich werden die empfangene EditorID, die fortan für die
Meldung von Funden und Orten verwendet wird, und der Nutzername gespeichert. Weitere
Loginversuche mit dem Nutzernamen werden zuerst offline validiert. Sollte das Ergebnis der
Validierung hier nicht korrekt sein (z. B. falls der Nutzer sein Passwort geändert hat), muss
zusätzlich der Server kontaktiert werden. Gibt der Server die Antwort zurück, dass die
Zugangsdaten korrekt sind, wird das gespeicherte Passwort in der Android-Datenbank mit
dem neuen eingegebenen Passwort überschrieben.
Ist der Nutzer angemeldet, erhält er auf dem Homescreen der Anwendung die Möglichkeit,
sich wieder abzumelden. Um den Ablauf der Anmeldung zu realisieren wird mit der
erfolgreichen Anmeldung ein Timer gesetzt, der den Nutzer automatisch nach 8 Stunden
abmeldet. Es ist jedoch sinnvoll, diesen Timer bei einer Aktivität des Nutzers neu zu starten,
damit er nicht während eines Erfassungsprozesses unterbrochen wird.
5.3.4. Mehrsprachigkeit
Android-Anwendungen können sich der im System eingestellten Sprache anpassen.
Grundsätzlich werden alle konstanten Ressourcen wie Bilder, Layouts oder Strings in einem
jeweiligen Ordner unterhalb des Ordners res eines Android-Projektes verwaltet. Strings sind
dabei innerhalb einer XML-Datei standardmäßig in res/values gespeichert (siehe Abbildung
20). Dies ist der Standardsatz an Strings, der benutzt wird, sofern sich keine andere
Ressource finden lässt, die besser zu den lokalen Einstellungen des Geräts passt. Die
Strings sind dort als Schlüssel-Wert-Paare definiert.
58
Abbildung 20: Speicherung von Ressourcen (Beispiel 1)
Möchte man mehr als eine Sprache unterstützen, kreiert man einen zweiten Ordner, der den
gleichen Namen besitzt, jedoch um den Ländercode der Sprache ergänzt wird. Außerdem
müssen sich die übersetzten Strings in diesem Ordner befinden. Abbildung 21 zeigt bspw.
den Ordner values-de für deutschsprachige Ressourcen. Ist auf dem Android-Gerät Deutsch
als zu nutzende Sprache eingestellt, so werden die Strings aus res/values-de/strings.xml
verwendet. Ist der benötigte Stringwert nicht in dieser Datei enthalten (da der SchlüsselWert-Eintrag fehlt), wird der Standardsatz unter res/values/strings.xml genutzt.
Abbildung 21: Speicherung von Ressourcen (Beispiel 2)
Auf diese Weise wird die Mehrsprachigkeit von festgelegten Strings geregelt, die nicht mehr
geändert werden. Wenn jedoch Daten, die erst empfangen werden müssen (wie die
Populärnamen der Spezies) in einer bestimmten Sprache angezeigt werden sollen, können
59
die Systemeinstellungen zur Laufzeit über den Kontext der Anwendung abgerufen werden.
Dieser liefert den zweistelligen Sprachcode gemäß ISO 639-1 der eingestellten Sprache.118,
119
Die Mehrsprachigkeit der mobilen Anwendung kann über diese zwei Wege vollständig
gewährleistet werden. Konstante Zeichenketten werden innerhalb von XML-Dateien in den
durch den Biodiversitätsatlas abgedeckten Sprachen definiert. Standardmäßig wird Englisch
eingesetzt. Weitere Sprachdateien werden in entsprechenden Ordnern hinterlegt.
Die Darstellung der Populärnamen von Spezies in einer bestimmten Sprache wird über eine
Abfrage zur Laufzeit der Anwendung bestimmt. Die Populärnamen einer Spezies sind in der
Datenbank des Biodiversitätsatlas inklusive ihrem Sprachcode, der ebenfalls ISO 639-1
entspricht, abgespeichert.120
Um eine Spezies auszuwählen, wird eine Liste der vorhandenen Spezies inklusive deren
Populärnamen benötigt. Bezüglich der Populärnamen hat man die Möglichkeit, den
Ländercode mitzuschicken. Dann würde man die Namen allein in der angegebenen Sprache
erhalten; oder man erhält die gesamte Liste der Populärnamen und die Auswahl der Sprache
wird durch die mobile Anwendung durchgeführt. Die zweite Lösung stellt den Vorteil dar,
dass, wenn Spezies gespeichert werden, alle Populärnamen lokal vorhanden sind. Dadurch
kann die Mehrsprachigkeit, falls dem Smartphone kein Zugang zum Internet vorliegt,
weiterhin gewährleistet werden. Außerdem entstehen keine Probleme, wenn der Nutzer die
Sprache in den lokalen Einstellungen des Geräts ändert. Daher werden alle Populärnamen
vom Server abgerufen und die Auswahl der Sprache durch die Anwendung durchgeführt. Ist
der Populärname nicht in der eingestellten Sprache vorhanden, wird (wie auch bei den
Sprachdateien) die englische Bezeichnung angezeigt. Sofern auch diese nicht zur Verfügung
steht, wird kein Populärname dargestellt.
5.3.5. Datenspeicherung
Es gibt verschiedene Möglichkeiten, Daten unter Android persistent zu speichern. Welche
dabei die passende ist, hängt davon ab, in welcher Form man die Daten speichern möchte,
ob sie auch für andere Anwendungen zugänglich sein sollen und wie viel Platz die Daten
einnehmen.
118
119
120
Vergleiche [Genzel, 2011], S. 48.
60
Methode
Beschreibung
Shared Preferences
Speichern von persistenten Schlüssel-Wert-Paaren primitiver Datentypen, die innerhalb einer Anwendung verfügbar sind.
Interner Speicher
Speichern von Dateien im Gerätespeicher. Standardmäßig werden
sie privat gespeichert und gelöscht, wenn der Nutzer die Anwendung deinstalliert. Alternativ können Daten kurzzeitig im Cache
abgelegt werden.
Externer Speicher
Speichern von Dateien im öffentlichen Speicher des Gerätes oder
einem austauschbaren Speicher (wie SD-Karten). Die Dateien
können durch andere Anwendungen genutzt werden.
SQLite Datenbank
Android unterstützt von Haus aus die Open Source-Datenbank
SQLite. Allein die Anwendung kann auf sie zugreifen.
Online Speicherung
Daten über eine Netzwerkverbindung an einen Server senden und
dort abrufen.
Tabelle 2: Methoden zur Speicherung von Daten in Android 121
In sechs Fällen ist in der mobilen Anwendung eine Speicherung von Daten notwendig. Vier
verwenden die Datenbank, weil sie komplexere Daten beinhalten und nur für die Anwendung
zugänglich sein sollen.
Ein Fund wird mit Abschluss des Erfassungsvorgangs eines Ortes inklusive aller seiner
Informationen, wie dem Fundort, der Spezies und Referenzen zu den Bildern gespeichert.
Da bei einem Fehler die durch den Server gesendete Identifikationsnummer nicht eindeutig
ist (entweder 0 oder -1), kann diese nicht als Primärschlüssel verwendet werden.
Spezies und Fundorte können unabhängig von der Meldung eines Fundes in der Datenbank
als Favoriten gespeichert werden. Dazu steht dem Nutzer eine Funktion innerhalb der
jeweiligen Activities zur Verfügung, durch die er vorhandene Spezies und Orte in der
Datenbank speichern kann. Auf diese Weise kann er auch offline auf sie zugreifen.
Für die Erfassung von Fundorten müssen die Länder vorliegen. Diese befinden sich bereits
zum Zeitpunkt der Auslieferung der Anwendung innerhalb der Datenbank. Um sie mit einem
Ort zu verknüpfen, werden der Identifikationscode und der Name des Landes gespeichert.
121
61
Die Erfassung von Nutzerinformationen wurde bereits in Kapitel 5.3.3 beschrieben. Diese
müssen ebenfalls in der Datenbank hinterlegt werden, damit sie dem abgespeicherten Fund
zugeordnet werden können. Dies unterstützt die Verwendung der Anwendungen auf einem
Smartphone mit mehreren Accounts, auch wenn dieses Szenario eher unwahrscheinlich ist.
Die Datenbank wird mit Hilfe des SQLite-Frameworks erstellt.122 Dabei wird über eine zu
implementierende Unterklasse der Klasse SQLiteOpenHelper die Datenbank erstellt. Der
Datenbankzugriff wird über einen ContentProvider durchgeführt. ContentProvider bilden
neben Activities einen weiteren wichtigen Baustein in der Android-Architektur. Wie der Name
bereits verdeutlicht, werden über ContentProvider Daten abgefragt. Durch sie wird ein
Mechanismus ermöglicht, der die Daten vor fremdem Zugriff schützt.
Nutzerspezifische Einstellungen werden über Shared Preferences gespeichert und allen
Komponenten der Anwendung zugänglich gemacht. Dieses Thema wird im nächsten Kapitel
ausführlicher beschrieben.
Zu guter Letzt werden Bilder durch die Kameraanwendung im externen Speicher
gespeichert. Von dort können sie durch die mobile Anwendung des Biodiversitätsatlas
wieder abgerufen und einem Ort zugeordnet werden.
5.3.6. Verwaltung der Daten
Die in der Datenbank gespeicherten Funde werden in einer separaten Acitivity angezeigt,
sodass der Nutzer seine Meldungen nachvollziehen kann. Außerdem dient dieser Bereich
dazu, dass noch nicht versandte Funde geschickt werden können. Einzelne Funde können
außerdem gelöscht werden. Die darin enthaltenen Spezies und Orte werden jedoch nicht
entfernt, sodass sie offline vorhanden sind und gegebenenfalls erneut eingesetzt werden
können.
5.3.7. Benutzerspezifische Konfiguration
Um ein Optionsmenü in einer Anwendung zu realisieren, bietet Android ein Framework an,
welches durch eine spezielle Activity, die PreferenceActivity, und das Speichern von
SharedPreferences ein Optionsmenü kreiert. 123 Innerhalb des Menüs setzt der Nutzer
Standardwerte zur Erfassung von Funden und Fundorten. Für Funde macht es Sinn
benutzerdefinierte Standardwerte für die Verfremdung einer Koordinate, der Veröffentlichung
122
123
62
eines Kommentares sowie das Kommentar selbst festgelegt werden. Für die Fundorte
bedeutet das Setzen von Standardwerten ebenso den Kommentar und die Entscheidung, ob
dieser veröffentlicht werden darf sowie das Land, welches für jeden Fund voreingestellt
werden soll. Durch einen Button hat der Nutzer die Möglichkeit, die eingetragenen Werte auf
ihre Standardeinstellungen zurückzusetzen.
5.4. Grenzen und Einschränkungen
Innerhalb dieses Kapitels wurde das Konzept des wesentlichen Kerns der Anwendung
vorgestellt. Diese bildet die Basis für die Realisierung des ersten Prototypen. Zweitrangige
Anforderungen, die vorerst nicht relevant sind, wurden nicht in das Konzept eingeschlossen.
Sie sind jedoch für spätere Weiterentwicklungen nicht zu vernachlässigen.
Dies betrifft zum einen die manuelle Aktualisierung von Kartendaten. Die Bibliothek osmdroid
bietet in dem Zusammenhang eine automatisierte Aktualisierung des Tile-Caches. Eine
durch den Nutzer gestartete Aktualisierung der Tiledaten mit der Eingrenzung des durch den
Atlas abgedeckten Gebietes in verschiedenen Zoomstufen, bildet eine sinnvolle Erweiterung
der mobilen Anwendung.
Zum anderen wird die Filterung von Orten und Spezies nicht berücksichtigt. Dieses
Verfahren benötigt eine komplexere Kommunikation zwischen dem Client und dem Server.
Zusätzlich werden eventuell auch weitere Bildschirmseiten benötigt, z. B. für die Eingrenzung
der Spezies, die der Nutzer durchführen muss.
Die Anzeige und Bestätigung von Nutzungsbedingungen wurden vorerst nicht in das
Konzept eingebunden. Für die öffentliche Verteilung der Anwendung ist es jedoch sehr
wichtig, dass die Nutzer diesen Bedingungen zustimmen müssen.
Die mobile Anwendung soll für mehrere Biodiversitätsatlanten eingesetzt werden. Das
Konzept berücksichtigt keine Konfiguration der Anwendung, da dies eine weitere
Entwicklung des Systems darstellt.
Realisierung
63
6. Realisierung
In diesem Kapitel wird der realisierte Prototyp vorgestellt. Der Fokus der Entwicklung wurde
auf den inneren Kern der mobilen Anwendung gelegt. Dies sind die Erfassung von Funden
inklusive der Aufnahme von Bildern sowie die Erfassung eines neuen Fundortes und dessen
Visualisierung mittels GIS. Dem Prototyp liegt sowohl ein vollständiger englischer als auch
ein deutscher Sprachsatz vor. In der folgenden Präsentation der realisierten Lösung werden
die deutschen Bezeichnungen verwendet. Es soll jedoch darauf verwiesen werden, dass
dazu jeweils englische Äquivalente existieren.
Neben dem Prototyp der mobilen Anwendung wurde ein Server entwickelt, um die
Anwendung zu testen. Der Server fügt Daten in die Datenbank ein oder liest sie aus,
generiert anschließend Objekte, die an Client gesendet werden und nimmt seine Anfragen
entgegen.
6.1. Aufbau des Android-Projektes
Die umgesetzte Lösung enthält die in Abbildung 22 dargestellte Projektstruktur. Das Projekt
beinhaltet neben dem im Verzeichnis src erstellten Quellcode weitere wichtige Androidspezifische Ordner. Im Verzeichnis gen befindet sich die automatisch generierte Java-Klasse
hsb.mobile.android.R. Über diese Datei wird aus dem Quellcode heraus auf alle Ressourcen
zugegriffen, die sich im Ordner res befinden.
Realisierung
64
Abbildung 22: Struktur des Android-Projektes
Neben dem Android SDK und der osmdroid API, muss die Bibliothek Simple Logging Facade
for Java (SLF4J) dem Projekt hinzugefügt werden. Die SLF4J API wird durch osmdroid für
Log-Ausgaben genutzt.
Eine wichtige Datei ist das Android Manifest. Dieses beinhaltet wesentliche Informationen
über die Anwendung, die dem System vor der Ausführung des Programms mitgeteilt werden.
Über den XML-Tag <uses-sdk android:minSdkVersion="8" /> wird angegeben, dass
mindestens das Android SDK 2.2 verwendet werden soll. Ältere Versionen werden daher
nicht unterstützt. Für neue Android-Version heißt dies jedoch, dass sie die Anwendung
ebenfalls installieren können. Des Weiteren müssen die Berechtigungen für den
Internetzugriff, den Zugriff auf die Positionsabfrage sowie auf den externen Speicher
eingetragen werden, welche die Anwendung zur Ausführung der Funktionen benötigt. Dies
wird über <uses-permission>-Tag ausgeführt. Außerdem wird mittels <uses-feature
android:name="android.hardware.camera" android:required="false" /> festgelegt, dass die
Anwendung eine Kamera nutzt, diese jedoch u. U. nicht notwendig ist. Diese Informationen
Realisierung
65
werden vor der Installation dem Nutzer angezeigt. Daraufhin kann dieser entscheiden, ob er
die Anwendung installieren und ihr die geforderten Berechtigungen damit übergibt.
Als nächstes werden in der Manifest-Datei innerhalb des <application>-Tags alle Activities,
Services und ContentProvider aufgelistet, die zu der Anwendung gehören. Erst wenn sie dort
deklariert wurden, sind sie für das System auffindbar. Weiterhin muss eine Activity als
Startpunkt der Anwendung festgelegt werden. Dies ist für die hier realisierte Anwendung das
Dashboard, welches mit einem Intent-Filter dem System angezeigt wird. Durch Intent-Filter
wird mitgeteilt, dass eine Komponente eine bestimmte Aktion (wie in diesem Fall
android.intent.action.MAIN) ausführen kann. Dazu kann zusätzlich eine Kategorie bestimmt
werden,
in
die
ein
Intent
ebenfalls
eingeteilt
werden
kann
(wie
hier
android.intent.category.LAUNCHER). Activities, die nur innerhalb der Anwendung aufgerufen
werden sollen, benötigen keine Intent-Filter.
<activity
android:label="@string/app_name"
android:name=".biodiv.HomeDashboard"
android:launchMode="singleInstance" >
<intent-filter >
<action android:name="android.intent.action.MAIN" />
<category
android:name="android.intent.category.LAUNCHER" />
</intent-filter>
</activity>
Abbildung 23: Deklarierung der Main-Activity HomeDashboard
6.2. Erfassung eines Fundes
Zur Erfassung eines Fundes wurde die RecordNewActivity erstellt, über die die benötigten
Informationen, wie in Kapitel 5.3.1 beschrieben, erfasst und in der diese dargestellt werden
(siehe Abbildung 24). Die Activity wird über den Button „Neuer Fund“ aufgerufen.
Realisierung
66
Abbildung 24: RecordNewActivity
Der Fund wurde in mehrere Java-Klassen abgebildet (siehe Abbildung 24). Innerhalb dieser
Klassen werden die für die Erfassung eines Fundes benötigten Informationen gespeichert.
Bei der Modellierung wurde an dieser Stelle die logische Einheit der Messung (Klasse
Measurement) mit berücksichtigt. Sie bildet hier die Verknüpfung zwischen einem Datum und
dem Fundort. Eine weitere Besonderheit ist das Interface RecordQuality. Dieses definiert die
Werte für eine direkte Sichtung und einen indirekten Nachweis. Die Klasse Record
implementiert dieses Interface und überschreibt die Methoden zum Setzen des jeweiligen
Wertes.
Die Klassen liegen sowohl dem Client als auch dem Server vor. Dadurch ist es möglich, dass
der Client dem Server diese Objekte direkt zuschickt. Es wird dazu innerhalb der ServiceKlasse RecordHandler ein statisches Record-Objekt initiiert und verwaltet. Der Service wird
durch den ersten Aufruf der RecordNewActivity gestartet. Jede Information, die der Nutzer
innerhalb der RecordNewActivity zu einem Fund ermittelt, wird in diesem Objekt gespeichert.
Realisierung
67
Es wurde ein Service für diese Aufgabe gewählt, da durch den getrennten Lebenslauf des
Services zur Activity der Fund über die Anwendung hinweg als instanziiertes Objekt
bestehen bleibt. Erst nachdem der Nutzer den Fund abgeschickt hat, wird der Service
gestoppt und das Record-Objekt ist nicht mehr vorhanden.
Abbildung 25: Strukturierung eines Fundes mittels Java-Klassen
6.3. Auswahl einer Spezies
Eine Spezies wird über die SpeciesListActivity ausgewählt. Diese visualisiert eine scrollbare
Liste, aus der Elemente ausgewählt werden können. Über die Service-Klasse ClientHandler
des Pakets hsb.mobile.android.services wird die Kommunikation mit dem Server gesteuert.
Der ClientHandler liefert für die Auswahl einer Spezies nach Anfrage an den Server ein
Species-Array (siehe Abbildung 25, Klasse Species) zurück. Mittels eines Adapters werden
die Namen der Spezies in die Liste eingefügt. Daraus kann anschließend eine Spezies zu
einem Fund daraus ausgewählt werden. Die Listenansicht für Fundorte wird ebenfalls auf
diese Weise umgesetzt.
Realisierung
68
Abbildung 26: SpeciesLIstActivity
Ferner wird der Nutzer in der Listenansicht durch eine Suchfunktion unterstützt. Diese filtert
momentan die Anfänge der wissenschaftlichen Namen. Eine sinnvolle Ergänzung wäre die
Suche nach Übereinstimmungen auch innerhalb der Wörter.
6.4. Einbindung von OSM
Für die Visualisierung der Auswahl eines Fundortes mittels der GIS-Karte wurde die durch
osmdroid gelieferte MapView-Widget durch die Klasse OSMBaseMap aus dem Paket
hsb.mobile.android.maps überschrieben. Diese Klasse fügt einen Layer der OSM-Karte
hinzu, in der die durch die Activity hsb.mobile.android.biodiv.location.LocationMapActivity
ermittelte GPS-Koordinate angezeigt wird. Durch einen Klick auf diesen Marker wird ein
Dialog zur Erfassung eines neuen Fundortes gestartet. Die Koordinate wird dabei über den
Intent, mit dem die neue Activity aufgerufen wird, übergeben. Der Nutzer kann an dieser
Stelle den neuen Fundort eintragen.
Um neben der aktuellen Koordinate auch die vorhandenen Fundorte inklusive ihrer Namen
anzuzeigen, wird die Klasse OSMLocationMap verwendet. Diese erbt von der Klasse
OSMBaseMap und wird als Widget in die Layout-Datei der Activity eingebunden. Über sie
wird ein weiterer Layer eingebunden, der die Marker und die dazugehörigen Namen anzeigt.
Durch einen Klick auf einen dieser Marker wird der ausgewählte Ort dem Fund hinzugefügt.
Realisierung
69
Abbildung 27: LocationMapActivity
6.5. Ermittlung der GPS-Koordinate
Die GPS-Koordinate wird über den LocationManager abgerufen. Dieser wird mit dem Befehl
getSystemService(Context.LOCATION_SERVICE) aufgerufen. Da die Positionsermittlung
über Wifi schneller ist, als die über GPS, wird als erstes nach einer Koordinate über diese
Dienst gesucht. Ist es nicht vorhanden, wird versucht, eine Koordinate über den GPS-Sensor
zu empfangen. Dabei wird zuerst der LocationManager aufgefordert, nach neuen
Koordinaten über GPS zu suchen. Solange dieser sucht, wird nachgesehen, ob die zuletzt
abgerufene Position noch vorhanden ist. Ist sie es, erscheint ein neuer Marker auf der Karte.
Sobald über den LocationManager eine neue Koordinate gefunden wurde, wird die Position
des Markers geändert.
Realisierung
70
public void initGPSCall() {
this.locationManager.requestLocationUpdates(GPS, 0, 0, this);
android.location.Location lastKnownLocation =
this.locationManager.getLastKnownLocation(GPS);
if (lastKnownLocation != null) {
showCurrentPositionOnMap(lastKnownLocation);
}
...
}
Abbildung 28: Initialisierung der Ermittlung der aktuellen Position über GPS
6.6. Meldung von Bildern
Für die Aufnahme von Bildern steht ein Button auf dem Dashboard der Anwendung zur
Verfügung, der die externe Kameraanwendung aufruft. Dies geschieht mittels eines
impliziten Intents, welcher dem System anhand des Namens der Aktion mitteilt, welche
Komponente aufgerufen werden soll. Implizite Intents werden für den Aufruf von
Anwendungen außerhalb der eigenen Anwendung eingesetzt. Neben einer gewünschten
Aktion können sie ebenfalls eine Anwendung anhand einer Kategorie oder bestimmten
Daten (durch Uri und MIME-Typ) starten. Das System sucht daraufhin nach passenden
Intent-Filtern, die die Aktion, die Kategorie oder die Daten filtern. Dadurch geben sie dem
System zu verstehen, dass sie geeignet sind, die geforderte Aufgabe zu erfüllen. Die IntentFilter werden im Manifest der jeweiligen Anwendung für Activities, Services und Broadcast
Receiver definiert.
Intent intent = new Intent(MediaStore.ACTION_IMAGE_CAPTURE);
startActivity(intent);
Abbildung 29: Aufruf der Kamerafunktion
Um
die
Kameraanwendung
aufzurufen,
wird
MediaStore.INTENT_ACTION_STILL_IMAGE_CAMERA
dem
Intent
übergeben.
Mit
die
Aktion
dem
Befehl
startActivity(intent) wird der Intent an das System gesendet. Alternativ hätte die
Aktion
MediaStore.ACTION_IMAGE_CAPTURE
verwendet
werden
können.
Die
Kameraanwendung würde dann jedoch lediglich ein Bild aufnehmen. Speichert man das Bild
würde die Kameraanwendung beendet werden und der Dateipfad des Bildes an die
Anwendung, die die Kameraanwendung aufgerufen hat, zurückgeschickt werden. Der Intent
müsste
in
diesem
Fall
mit
der
Methode
startActivityForResult(intent,
REQUEST_CODE) abgeschickt werden. Ein Beispiel dafür zeigt der Aufruf der Bildergalerie
für die Auswahl eines Bildes, um es dem Fund zuzuordnen.
Realisierung
71
Mittels der Konstanten Intent.ACTION_GET_CONTENT wird eine Activity aufgerufen, in der
der Nutzer eine Datei auswählen kann. Damit ausschließlich Bilder angezeigt werden, wird
zusätzlich der MIME-Typ angegeben. Der Aufruf der Aktion verursacht auch, dass der Nutzer
aus der Activity, über die ein Bild ausgewählt werden kann, die Kamerafunktion aufrufen
kann, um neue Bilder zu erstellen.
Intent intent = new Intent(Intent.ACTION_GET_CONTENT);
intent.setType("image/*");
startActivityForResult(intent, REQUEST_CODE_IMAGE);
Abbildung 30: Aufruf der Bildergalerie
Wählt der Nutzer ein Bild aus, wird ein Intent erstellt, dem die Uri des Bildes übergeben wird.
Der Intent wird an die RecordNewActivity zurückgesendet, die die Uri in der CallbackMethode onActivityResult() ausliest. Es wird daraufhin eine neue Datei angelegt, welche
zentral im RecordHandler gespeichert wird. Anschließend wird das Layout erneut geladen,
sodass das neue Bild angezeigt wird.
if (requestCode == REQUEST_CODE_IMAGE && resultCode == RESULT_OK) {
Uri selectedImageUri = data.getData();
String selectedImagePath = getPath(selectedImageUri);
File file = new File(selectedImagePath);
mService.addImage(file);
createLayout();
}
Abbildung 31: Auswertung des Intents (Bildergalerie)
Das Füllen des GridViews, in dem die Bilder angeordnet werden, geschieht über einen
Adapter, der für jede Datei in der ArrayList des RecordService ein ImageView-Widget
instanziiert und diesem den Pfad der gespeicherten Datei zuweist. Nachdem dies
durchgeführt wurde, kann der Nutzer das Bild in der Activity sehen (siehe Abbildung 3232).
Einmal zugeordnete Bilder können durch langes Tippen auf das Bild wieder entfernt werden.
Realisierung
72
Abbildung 32: Zuordnung von Bildern zu einem Fund
Bilder werden, wie im Konzept beschrieben, unabhängig vom Fund versendet, da sie
nacheinander als Datei gesendet werden. Das Senden geschieht ebenfalls über den
ClientHandler. Für jedes Bild wird dafür die Verbindung zum Server aufgebaut und diesem
zuerst ein String geschickt, anhand dessen er sich auf den Empfang des Bildes vorbereiten
kann (siehe Abbildung 33). Dem festen String „sendImage“ wird direkt die vorher
empfangene RecordID angehängt. Anschließend folgen jeweils nach einem Doppelpunkt der
Dateiname sowie die Dateigröße. Konnte ein Bild erfolgreich übertragen werden, wird durch
den ClientHandler eine „1“ zurückgeliegert, andernfalls eine „0“. Der Nutzer bekommt eine
Meldung angezeigt, in der ihm mitgeteilt wird, wie viele Bilder gesendet werden konnten.
„sendImage“
newRecordID
:
Dateiname
:
Dateigröße
Abbildung 33: Struktur des Anforderungsstrings zum Senden von Bildern
Realisierung
73
6.7. Datenbank
Für die Speicherung von Funden, Spezies, Orten und den Nutzerinformationen wurde ein
Datenbankmodell erstellt (siehe Abbildung 34). Dieses ist eine kleinere Version des
Datenbankmodells des Biodiversitätsatlas, welches nur die Informationen abdeckt, die
innerhalb der Anwendung verwendet werden und gespeichert werden sollen. SQLite kann
nur mit einfachen Datentypen wird INTEGER oder TEXT umgehen. Daher wurden die
Datentypen dementsprechend vereinfacht.
Abbildung 34: Datenbankmodell
Die Datenbank wird mit Hilfe der Klasse hsb.mobile.android.biodiv.db.BiodivDatabase
angelegt. Diese ist von der Klasse SQLiteOpenHelper abgeleitet und muss dadurch eine
onCreate-Methode, in der die Tabellen der Datenbank bei Instanziierung der Klasse angelegt
werden, sowie eine onUpgrade-Methode implementieren, die aufgerufen wird, sobald sich
die Versionsnummer der Datenbank ändert. Wird eine neue Version der Anwendung
ausgeliefert, deren Versionsnummer der Datenbank mit der der noch installierten
Realisierung
74
übereinstimmt, wird die Datenbank nicht überschrieben. Die dort gespeicherten Daten sind
danach immer noch vorhanden. Für den Falls, dass es eine neue Datenbankversion gibt,
wird die alte samt Daten gelöscht, sofern kein Mechanismus in der onUpgrade-Methode
vorliegt, der die Daten überträgt. Dieser Mechanismus liegt der Anwendung bislang nicht vor.
Außerdem konnte eine vollständige Umsetzung des in Abbildung 34 vorgestellten
Datenbankmodells bislang aus zeitlichen Gründen nicht durchgeführt werden.
Bereits gespeichert werden die Funde in der Tabelle bio_record. Für den Zugriff auf die
Datenbank wurde die Klasse hsb.mobile.android.biodiv.db.BiodivDBProvider erstellt. Dieser
ist ein ContentProvider, dem über in der Klasse definierte Uris mitgeteilt wird, auf welche
Tabellen der Datenbank zugegriffen werden soll und ob Daten eingefügt oder abgerufen
werden. Bspw. zeigt Abbildung 35 das Einfügen eines neuen Fund-Eintrages in die
Datenbank. Mit dem letzten Aufruf wird die insert-Methode des Providers aufgerufen. Um
Aufträge entgegennehmen zu können, muss der BiodivDBProvider dafür im Android Manifest
deklariert werden.
ContentValues recordData = new ContentValues();
// RecordID
recordData.put(
BiodivDatabase.COL_RECORDID,
newRecord.id);
...
getContentResolver().insert(
BiodivDBProvider.CONTENT_URI_RECORD,
recordData);
Abbildung 35: Einfügen eines Datensatzes in die Datenbank
In der Klasse RecordLIstActivity ist bereits eine Methode vorhanden, die gespeicherte
Datensätze wieder abruft. Dazu müssen zuerst die zu ermittelnden Spalten definiert werden.
Über die Konstante BiodivDatabase.COL_RECORD_COMBINE wird eine aus den Feldern
recordid, speciesid, locationid und measurementdate generierte Spalte abgerufen.124 Mittels
der Funktion managedQuery() werden die Spaltennamen dann an den ContentProvider
geschickt, welche die abgerufenen Daten in einem Cursor-Objekt zurückliefert.
124
Die Felder speciesid und locationid werden in dieser Version als Textattribute erzeugt, sodass dort
die Namen von Spezies und Ort abgespeichert werden. Diese sollten später in den Tabellen
bio_species und bio_location hinterlegt werden.
Realisierung
75
String[] projection = {
BiodivDatabase.ID, BiodivDatabase.COL_RECORD_COMBINE
};
...
Cursor records = this.managedQuery(
BiodivDBProvider.CONTENT_URI_RECORD,
projection, null, null, null);
Abbildung 36: Abrufen von Datenbankeinträgen
Zusammenfassung und Ausblick
76
7. Zusammenfassung und Ausblick
Im Rahmen dieser Bachelorarbeit wurde ein erster Prototyp als native Anwendung für
Android entwickelt, der die grundlegende Funktion – die Erfassung eines Fundes inklusive
Bildern und unter Einsatz von GIS – ermöglicht und bereits für Arbeiten im Freiland
eingesetzt werden kann. Dafür wurden in einem ersten Vorgang die Anforderungen an das
System analysiert. Eine Recherche verhalf weiterhin dabei, die aktuellen technologischen
Möglichkeiten zu validieren und in Kombination mit den Anforderungen ein umfassendes
Konzept zur Realisierung des Systems zu erstellen. Neben der zentralen Funktion, Daten für
einen Biodiversitätsatlas direkt nach der Sichtung zu erheben und an einen Server zu
schicken, was vollständig umgesetzt wurde, wurden weitere Funktionen (wie die Verwaltung
von Funden oder zum Einsatz der Anwendung im Offlinebetrieb) ebenfalls umgesetzt. Im
zeitlichen Rahmen war die Realisierung weiterer Anforderungen wie der Nutzerauthentifizierung, die Darstellung von Populärnamen von Spezies und weiterführende Maßnahmen
zur lokalen Datenspeicherung nicht möglich. Bei ihnen handelt es sich jedoch um wichtige
Funktionen, die für den Produktivbetrieb der Anwendung benötigt werden. Anhand des
Realisierungskonzeptes existiert dafür ein Vorgehen, welches weiterhin zur Umsetzung der
mobilen Anwendung verwendet werden kann und sich in die bislang erstellte Lösung
eingliedert.
Daneben
sind
einige
Möglichkeiten
zur
Weiterentwicklung
des
Biodiversitätsatlas
entstanden. Darin eingeschlossen ist vor allem die Implementierung eines Servers, der
Anfragen des neuen Clients bearbeitet. Der erstellte Testserver bietet dafür bereits erste
Grundlagen. Wie jedoch auch angesprochen wurde, sollte die Kommunikation zwischen dem
Client und dem Server eingehend geprüft und entsprechende Technologien validiert werden.
Ein modularer Austausch wurde dafür bereits umgesetzt. Der neue Server sollte als Plugin
für die bestehende Joomla!-Komponente entwickelt werden. Dadurch steht es jeder
Redaktion eines Biodiversitätsatlas frei, den mobilen Client als zusätzliche Möglichkeit für die
Erfassung von Funden anzubieten. Außerdem wird ein Konfigurationstool für die mobile
Anwendung benötigt, wodurch sie individuell für die bestehenden Biodiversitätsatlanten
eingesetzt werden kann.
Ferner ist die Dokumentation von Funden mit Bildern bislang nicht für den Biodiversitätsatlas
vorgesehen. Diese Möglichkeit besteht lediglich für die Dokumentation von Spezies. Anhand
dieses Beispiels sollte jedoch eine zusätzliche Bilderverwaltung für Funde entwickelt werden.
Dasselbe gilt für die Erfassung einer Koordinate zu einem Fund. Die Speicherung einer
solchen ist bislang nicht im Datenmodell enthalten. Änderungen an der Datenbank erfordern
77
außerdem, dass die bestehende Joomla!-Komponente des Biodiversitätsatlas erweitert
werden sollte. Dies ist insbesondere für das Backend sinnvoll, um neue Funde zu validieren.
Anhang A
Anhang A
Datenträger
1. Bachelor-Thesis – Digitale Fassung der vorliegenden Arbeit
2. Biodiversity Atlas (Ordner) – Quellcode der mobilen Anwendung
3. SocketServer – Quellcode des SocketServers
78
Literaturverzeichnis
79
[Android
Design-1]
Android
Design:
Welcome.
http://developer.android.com/design/index.html,
zuletzt
Online:
aufgerufen
am
30.01.2012.
[Android
Design-2]
Android
Design:
Action
Bar.
Online:
http://developer.android.com/design/patterns/actionbar.html, zuletzt aufgerufen
am 30.01.2012.
[Android
Developers-1]
Android
Developers:
What
is
Android?.
http://developer.android.com/guide/basics/what-is-android.html,
Online:
27.01.2012,
zuletzt aufgerufen am 29.01.2012.
[Android
Developers-2]
Android
Developers:
Build.VERSION_CODES.
Online:
http://developer.android.com/reference/android/os/Build.VERSION_CODES.ht
ml, 27.01.2012, zuletzt aufgerufen am 29.01.2012.
[Android
Developers-3]
Android
Developers:
Platform
Versions.
Online:
http://developer.android.com/resources/dashboard/platform-versions.html,
[Android
Developers-4]
Android
Developers:
Publishing
Overview.
Online:
http://developer.android.com/guide/publishing/publishing_overview.html, zuletzt
aufgerufen am 30.01.2012.
[Android
Developers-5]
Android
Developers:
Android
API
Levels.
Online:
http://developer.android.com/guide/appendix/api-levels.html, zuletzt aufgerufen
am 30.01.2012.
[Android
Developers-6]
Android
Developers:
Installing
http://developer.android.com/sdk/installing.html,
the
zuletzt
SDK.
Online:
aufgerufen
am
30.01.2012.
[Android
Developers-7]
Android
Developers:
Activities.
Online:
http://developer.android.com/guide/topics/ui/index.html, zuletzt aufgerufen am
30.01.2012.
[Android
Developers-8]
80
Android
Developers:
User
Interface.
Online:
http://developer.android.com/guide/topics/fundamentals/activities.html,
zuletzt
[Android Developers-9] Android Developers: Activities - Tasks and Back Stack. Online:
http://developer.android.com/guide/topics/fundamentals/tasks-and-backstack.html, zuletzt aufgerufen am 30.01.2012.
[Android
Developers-10]
Android
Developers:
Search.
Online:
http://developer.android.com/guide/topics/search/index.html, zuletzt aufgerufen
am 30.01.2012.
[Android Developers-11] Android Developers: Designing for Responsiveness. Online:
http://developer.android.com/guide/practices/design/responsiveness.html,
[Android
Developers-12]
Android
Developers:
Services.
Online:
http://developer.android.com/guide/topics/fundamentals/services.html,
zuletzt
[Android
Developers-13]
Android
Developers:
Localization.
Online:
http://developer.android.com/guide/topics/resources/localization.html,
zuletzt
[Android
Developers-14]
Android
Developers:
Locale.
Online:
http://developer.android.com/reference/java/util/Locale.html, zuletzt aufgerufen
am 30.01.2012.
[Android
Developers-15]
Android
Developers:
Data
Storage.
Online:
http://developer.android.com/guide/topics/data/data-storage.html,
zuletzt
[Android
Developers-16]
Android
Developers:
Preference
Activity.
Online:
http://developer.android.com/reference/android/preference/PreferenceActivity.h
tml, zuletzt aufgerufen am 30.01.2012.
[Android Open Source Project] Android Open Source Project: Licenses. Online:
http://source.android.com/source/licenses.html,
29.01.2012.
zuletzt
aufgerufen
am
81
[Android UI Patterns] Android UI Design Patterns: What Android Apps Should Look like?.
Online:
http://www.androiduipatterns.com/2011/12/how-should-android-apps-
look-like_16.html, zuletzt aufgerufen am 30.01.2012.
[Apple]
Apple:
iOS
5,
Die
neuen
Features
in
iOS
5.
Online:
http://www.apple.com/de/ios/features.html, zuletzt aufgerufen am 29.01.2012.
[Apple
Developer-1]
Apple
Developer:
Download
Xcode
4.
Online:
http://developer.apple.com/xcode/index.php, zuletzt aufgerufen am 29.01.2012.
[Apple Developer-2] Apple Developer: Register as an Apple Developer. Online:
http://developer.apple.com/programs/register/,
zuletzt
aufgerufen
am
29.01.2012.
[Apple
Developer-3]
Apple
Developer:
iOS
Dev
Center.
Online:
http://developer.apple.com/support/ios/ios-dev-center.html, zuletzt aufgerufen
am 29.01.2012.
[Apple Developer-4] Apple Developer: Develop on your Mac, iOS Developer Program.
Online:
http://developer.apple.com/programs/ios/develop.html,
zuletzt
[Apple Developer-5] Apple Developer: Test on your iPad, iPhone, and iPod touch, iOS
Developer Program. Online: http://developer.apple.com/programs/ios/test.html,
[Apple Developer-6] Apple Developer: Program Enrollment, iOS Developer Program.
Online:
http://developer.apple.com/support/ios/enrollment.html,
zuletzt
[Apple Developer-7] Apple Developer: App Store Review Guidelines and Mac App Store
Review
Guidelines.
Online:
http://developer.apple.com/appstore/guidelines.html, zuletzt aufgerufen am
30.01.2012.
[AppsLab]
The
AppsLab:
Website
vs.
Web
http://theappslab.com/2010/11/12/website-vs-web-app/,
App?.
Online:
12.11.2012,
zuletzt
[Becker, 2009] Arno Becker, Marcus Pant: Android – Grundlagen und Programmierung.
dpunkt.verlag GmbH, 1. Auflage Heidelberg 2009.
[Bitkom]
82
Bitkom:
Bitkom
zum
Handymarkt.
http://www.bitkom.org/files/documents/BITKOM_Presseinfo_Handy_und_Smartphone-Markt_15_08_2011.pdf, 15.08.2011, zuletzt aufgerufen am
29.01.2012.
[cocoate] cocoate.com, Hagen von Graf: Benutzer. Online: http://cocoate.com/de/joomla15/menue-site/benutzer, 18.12.2007, zuletzt aufgerufen am 30.01.2012.
[Enough Software] Enough Software GmbH + Co. KG: Mobile Developer’s Guide to the
Galaxy. Enough Software GmbH + Co. KG, 9. Auflage Bremen 2011.
[Gartner-1] Gartner, Inc.: Gartner Says Sales of Mobile Devices Grew 5.6 Percent in Third
Quarter of 2011; Smartphone
Sales
Increased
42 Percent. Online:
http://www.gartner.com/it/page.jsp?id=1848514, 15.11.2011, zuletzt aufgerufen
am 29.01.2012.
[Gartner-2] Gartner, Inc.: Gartner Says Android to Command Nearly Half of Worldwide
Smartphone
Operating
System
Market
by
Year-End
2012.
Online:
http://www.gartner.com/it/page.jsp?id=1622614, 07.04.2011, zuletzt aufgerufen
am 29.01.2012.
[Genzel, 2011] Carl-Heinz Genzel: Web GIS Erweiterung des CMS Joomla! im Kontext
der Biodiversität. Bremen 2011.
[GFI] Gesellschaft für Ichthyologie e. V.: Digitaler Fischartenatlas von Deutschland und
Österreich. Online: http://www.fischartenatlas.de/cms/, 24.01.2012, zuletzt
[Goldstein, 2011] Neil Goldstein, Tony Bove: iPadTM Application Development For
Dummies©, Wiley Publishing, Inc., 2. Ausgabe Indiana, Indianapolis 2011.
[Google] Google: Android Market for Developer, Developer Registration. Online:
http://support.google.com/androidmarket/developer/bin/answer.py?hl=en&ans
wer=11346, zuletzt aufgerufen am 29.01.2012.
[Google code] Google code: Google Projects for Android - Maps External Library. Online:
http://code.google.com/intl/de-DE/android/add-ons/google-apis/mapsoverview.html, zuletzt aufgerufen am 30.01.2012.
83
[Google Project Hosting-1] Google Project Hosting: osmdroid - OpenStreetMap-Tools for
Android. Online: http://code.google.com/p/osmdroid/, zuletzt aufgerufen am
30.01.2012.
[Google Project Hosting-2] Google Project Hosting: osmdroid - How to include osmdroid
source
in
your
application.
http://code.google.com/p/osmdroid/wiki/HowToUse,
Online:
10.01.2011,
zuletzt
[Google
Project
Hosting-3]
Google
Project
Hosting:
osmdroid
-
ModularTileProviderArchitecture.
Online:
code.google.com/p/osmdroid/wiki/ModularTileProviderArchitecture,
zuletzt
[iOS
Developer
Library-1]
iOS
Developer
Library:
Introduction.
Online:
http://developer.apple.com/library/ios/#documentation/Cocoa/Conceptual/Obje
ctiveC/Introduction/introObjectiveC.html#//apple_ref/doc/uid/TP30001163,
12.10.2011, zuletzt aufgerufen am 29.01.2012.
[iOS
Developer
Library-2]
iOS
Developer
Library:
What
Is
Cocoa?.
Online:
http://developer.apple.com/library/ios/#documentation/Cocoa/Conceptual/Coco
aFundamentals/WhatIsCocoa/WhatIsCocoa.html,
13.12.2010,
zuletzt
[iOS
Developer
Library-3]
iOS
Developer
Library:
Getting
Started.,
Online:
http://developer.apple.com/library/ios/navigation/#section=Resource%20Types
&topic=Getting%20Started, zuletzt aufgerufen am 30.01.2012.
[Linnhoff-Popien, 2012] Claudia Linnhoff-Popien (Hrsg.), Stephan Verclas: Smart Mobile
Apps – Mit Business-Apps ins Zeitalter mobiler Geschäftsprozesse. SpringerVerlag, Berlin Heidelberg 2012.
[Louis, 2011] Dirk Louis, Peter Müller: Jetzt lerne ich Android – Der schnelle Einstieg in
die Programmierung und Entwicklungsumgebung. Markt+Technik, München
2011.
[MOBAC]
Mobile
Atlas
Creator
(MOBAC):
Mobile
Atlas
Creator.
Online:
http://mobac.sourceforge.net/, zuletzt aufgerufen am 30.01.2012.
[mobile Developer-1] mobile Developer, Oliver Brüning: jQuery Mobile, Teil 1: Einführung
und Konzepte, jQuery macht mobil. Ausgabe 11/1011, S. 28-31.
84
[mobile Developer-2] mobile Developer, Rene Scholze: Vom Smartphone aufs Tablet.
Ausgabe 11/1011, S. 56-61.
[Mobile
Joomla!]
Mobile
Joomla!:
Take
a
tour.
Online:
http://www.mobilejoomla.com/tour.html, zuletzt aufgerufen am 30.01.2012.
[Nielsen] Nielsen: Nielsen präsentiert erste Ergebnisse aus aktuellem Smartphone
Insights
Report
für
Deutschland.
Online:
http://www.nielsen.com/de/de/insights/presseseite/2011/nielsen-praesentierterste-ergebnisse-aus-aktuellem-smartphone-i.html, für das dritte Quartal 2011,
Abruf: 29.01.2012.
[Nokia-1]
Nokia:
Nokia
Qt
SDK.
Online:
http://doc.qt.nokia.com/nokia-qtsdk-
1.0.1/index.html, 2010, zuletzt aufgerufen am 29.01.2012.
[Nokia-2] Nokia: We are Open!. Online: http://symbian.nokia.com/blog/2011/03/31/we-areopen/, 11.04.2011, zuletzt aufgerufen am 29.01.2012.
[Nokia-3] Nokia: Terms and Conditions. Online: http://symbian.nokia.com/terms/, 2011,
[Nokia-4]
Nokia:
Not
Open
Source,
just
Open
for
Business.
Online:
http://symbian.nokia.com/blog/2011/04/04/not-open-source-just-open-forbusiness/, 15.04.2011, zuletzt aufgerufen am 29.01.2012.
[Nokia-5] Nokia: Nokia and Microsoft announce plans for a broad strategic partnership to
build
a
new
global
ecosystem.
Online:
http://press.nokia.com/2011/02/11/nokia-and-microsoft-announce-plans-for-abroad-strategic-partnership-to-build-a-new-global-ecosystem/,
11.02.2011,
[Nokia
Developer-1]
Nokia
Developer:
Symbian
C++.
Online:
http://www.developer.nokia.com/Develop/Featured_Technologies/Symbian_C+
+/, zuletzt aufgerufen am 29.01.2012.
[Nokia
Developer-2]
Nokia
Developer:
http://www.developer.nokia.com/Develop/Qt/,
29.01.2012.
zuletzt
Qt.
aufgerufen
Online:
am
85
[Open Handset Alliance] Open Handset Alliance: What would it take to build a better
mobile phone?. Online: http://www.openhandsetalliance.com, 18.07.2011,
[OpenStreetMap]
OpenStreetMap
Wiki:
Software/Mobile.
Online:
http://wiki.openstreetmap.org/wiki/Software/Mobilephones, 16.11.2011, , zuletzt
.[Qt Project] Qt Project: Contribution Agreement Version 1.1. Online: http://qt.project.org/legal/QtContributionLicenseAgreement.pdf, zuletzt aufgerufen am
29.01.2012.
[Rodger, 2012] Richard Rodger: Beginning Mobile Application Development in the Cloud.
John Wiley & Sons, Inc., Indianapolis, Indiana 2012.
[Spiering, 2011] Markus Spiering, Sven Haiges: HTML5-Apps für iPhone und Android.
Franzis Verlag GmbH, Poing 2011.
[Symbian Blog] Symbian Blog: Can Symbian Operating System be used in Tablets?.
Online:
http://www.symbianblogs.com/symbian-blog/114-can-symbian-
operating-system-be-used-in-tablets.html, zuletzt aufgerufen am 30.01.2012.
[Symbian Foundation] Symbian Foundation: Symbian Foundation has transitioned to a
licensing body. Online: http://licensing.symbian.org/, zuletzt aufgerufen am
29.01.2012.
[Tanenbaum, 2009] Andrew S. Tanenbaum: Moderne Betriebssysteme. Pearson Studium,
3. Auflage München 2009.
[Vision
Mobile]
Vision
Mobile:
Developer
Economics
2011.
Online:
http://www.visionmobile.com/devecon.php, zuletzt aufgerufen am 29.01.2012.
[W3C-1] W3C: Offline Web Applications. Online: http://www.w3.org/TR/offline-webapps/,
30.05.2008, zuletzt aufgerufen am 30.01.2012.
[W3C-2] W3C: Geolocation API Specification. Online: http://www.w3.org/TR/geolocationAPI/, 07.09.2010, zuletzt aufgerufen am 30.01.2012.
[W3C-3]
W3C:
Widget
Packaging
and
XML
Configuration.
Online:
http://www.w3.org/TR/widgets/, 27.09.2011, zuletzt aufgerufen am 30.01.2012.
[Wikipedia]
86
Wikipedia:
iOS
version
history.
Online:
http://en.wikipedia.org/wiki/IOS_version_history, 29.01.2012, zuletzt aufgerufen
am 29.01.2012.
Erklärung
Erklärung
Hiermit versichere ich, dass ich die vorliegende Arbeit selbstständig und ohne Benutzung
anderer als der angegebenen Quellen angefertigt habe. Alle von mir wörtlich oder
sinngemäß übernommenen Zitate wurden als solche gekennzeichnet. Die Arbeit hat in
gleicher oder ähnlicher Form noch keiner anderen Prüfungsbehörde vorgelegen.
Ort, Datum
Unterschrift

- Fischfauna

Transcrição

Documentos relacionados

Version: Android 2.0.2

Midi-Datei aus Youtube Beschreibung in Notenschreib

WGSoft.de - Automotive Diagnostic Software (OBD, OBD

WGSoft.de - Automotive Diagnostic Software (OBD, OBD

Lehrerinfo

Januar 2016

April_2016 - Josefbauernfeindsblog

Hello Android - DHBW Stuttgart

Steck das Smartphone in die Reistüte! - CIPS

Interconnecting Android