Programmierung einer mobilen Applikation zur ... · schriftliche Quellen verzichtet werden,...

Programmierung einer mobilen Applikation

zur archäologischen Befunddokumentation

Bachelorarbeit

zur Erlangung des akademischen GradesBachelor of Arts (B. A.)

Humboldt-Universität zu Berlin

Mathematisch-Naturwissenschaftliche Fakultät II

Institut für Informatik

eingereicht von: Antje Hemlinggeboren am: 23.05.1986in: Berlin

Gutachter(innen): Prof. J. C. FreytagDr. Axel Gering

eingereicht am: 04.01.2013

Inhaltsverzeichnis

1 Einleitung 1

1.1 Aufgabenstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2 Aufbau der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Archäologische Grundlagen 4

2.1 Gegenstand der Archäologie . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.2 Archäologische Ausgrabungen . . . . . . . . . . . . . . . . . . . . . . . . . . 52.3 Anforderungen an die Anwendung . . . . . . . . . . . . . . . . . . . . . . . 8

2.3.1 Mobilität . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.3.2 Datensicherheit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.3.3 Funktionsaufteilung . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3 Informationstechnische Grundlagen 9

3.1 Mobile Endgeräte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.2 Mobile Plattformen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.2.1 Apple iPhone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.2.2 Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.2.3 Windows Phone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.2.4 Weitere Plattformen . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.3 Plattformunabhängigkeit und Portabilität . . . . . . . . . . . . . . . . . . . 14

4 Methoden zur Entwicklung mobiler Applikationen 16

4.1 Apps und ihr Anwendungsbereich . . . . . . . . . . . . . . . . . . . . . . . . 164.2 Native Apps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4.2.1 Entwicklung für Apples iPhone . . . . . . . . . . . . . . . . . . . . . 184.2.2 Entwicklung für Android Geräte . . . . . . . . . . . . . . . . . . . . 184.2.3 Entwicklung für Windows Phones . . . . . . . . . . . . . . . . . . . . 194.2.4 Vor- und Nachteile von nativen Apps . . . . . . . . . . . . . . . . . . 19

4.3 Web Apps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204.3.1 HTML 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204.3.2 JavaScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224.3.3 CSS3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224.3.4 JQuery Mobile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

i

ii INHALTSVERZEICHNIS

4.3.5 Sencha Touch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244.3.6 Vor- und Nachteile von Web-Apps . . . . . . . . . . . . . . . . . . . 24

4.4 Hybride Apps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244.4.1 Cross-Compiler Frameworks . . . . . . . . . . . . . . . . . . . . . . . 254.4.2 Wrapper Frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . . 254.4.3 Vor- und Nachteile von hybriden Apps . . . . . . . . . . . . . . . . . 25

4.5 Vergleich der Methoden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264.5.1 Plattformabdeckung . . . . . . . . . . . . . . . . . . . . . . . . . . . 274.5.2 Portabilitätsaufwand . . . . . . . . . . . . . . . . . . . . . . . . . . . 284.5.3 Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.6 Auswahl einer Technologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

5 Datenspeicherung 32

5.1 Web Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325.2 Web-SQL Datenbanken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335.3 IndexedDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345.4 Auswahl einer Speichermethode . . . . . . . . . . . . . . . . . . . . . . . . . 35

6 Systementwurf 37

6.1 Zielrichtung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376.2 Funktionalitäten für beide Nutzergruppen . . . . . . . . . . . . . . . . . . . 386.3 Funktionalitäten für den Grabungsleiter . . . . . . . . . . . . . . . . . . . . 38

6.3.1 Mitarbeiter verwalten . . . . . . . . . . . . . . . . . . . . . . . . . . 416.3.2 Grabungen verwalten . . . . . . . . . . . . . . . . . . . . . . . . . . . 436.3.3 Befunde verwalten . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

6.4 Funktionalitäten für den Grabungsassistenten . . . . . . . . . . . . . . . . . 486.5 Datenhaltung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

7 Implementierung 52

7.1 JQuery Touch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 527.2 PhoneGap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

8 Zusammenfassung 56

8.1 Diskussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 568.1.1 Mobilität . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 578.1.2 Datensicherheit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 578.1.3 Plattformunabhängigkeit . . . . . . . . . . . . . . . . . . . . . . . . . 578.1.4 Portabilität und Performance . . . . . . . . . . . . . . . . . . . . . . 578.1.5 Auswertung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

8.2 Fazit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 588.3 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

8.3.1 Datenspeicherung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 598.3.2 Kommunikation zwischen Smartphones . . . . . . . . . . . . . . . . . 598.3.3 Auswertung der Befunde . . . . . . . . . . . . . . . . . . . . . . . . . 59

INHALTSVERZEICHNIS iii

8.3.4 Vereinfachung der App-Entwicklung . . . . . . . . . . . . . . . . . . 60

A Ergänzende Abbildungen 61

A.1 Beispielhafte Verwendung der Anwendung . . . . . . . . . . . . . . . . . . . 61A.2 Beispiel Befundblatt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

Abbildungsverzeichnis

2.1 Beispielhafter Ablauf einer archäologischen Ausgrabung . . . . . . . . . . . 7

3.1 Prognose zu Marktanteilen mobiler Plattformen 2012 und 2016 . . . . . . . 113.2 Absatz von iPhones bis zum 3. Quartal 2012 . . . . . . . . . . . . . . . . . . 12

4.1 Verteilung von Arten unterschiedlicher Apps . . . . . . . . . . . . . . . . . . 174.2 Entstehung einer nativen App mit PhoneGap . . . . . . . . . . . . . . . . . 26

5.1 Browsersupport für die Speicher APIs . . . . . . . . . . . . . . . . . . . . . 35

6.1 Loginbildschirm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396.2 Auswahl zwischen GL und GA . . . . . . . . . . . . . . . . . . . . . . . . . 406.3 EPK für einen Anmeldevorgang . . . . . . . . . . . . . . . . . . . . . . . . . 416.4 Hauptmenü für den Grabungsleiter . . . . . . . . . . . . . . . . . . . . . . . 426.5 Menü zum Verwalten der Mitarbeiter . . . . . . . . . . . . . . . . . . . . . . 436.6 Menü um einen neuen Mitarbeiter anzulegen . . . . . . . . . . . . . . . . . . 446.7 Menü zum Anlegen einer neuen Ausgrabung . . . . . . . . . . . . . . . . . . 456.8 Menü zum Wählen einer Grabung und anschlieÿenden Bearbeitung der Be-

funde . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466.9 Use-Case Diagramm der Anwendungsfälle der GLs . . . . . . . . . . . . . . 476.10 Use-Case Diagramm der Anwendungsfälle der GA . . . . . . . . . . . . . . . 496.11 ER-Modell für die Datenbank . . . . . . . . . . . . . . . . . . . . . . . . . . 50

7.1 Login-Seite ohne und mit eingebundenem JQuery mobile . . . . . . . . . . . 54

A.1 Beispielhafte Verwendung der Anwendung als GA . . . . . . . . . . . . . . . 62A.2 Befundblatt basierend auf den Vorgaben des Landesdenkmalamtes Bayern . 63

iv

Tabellenverzeichnis

4.1 Programmiersprachen und Entwicklungsumgebungen der verschiedenen Platt-formen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.2 Plattformunterstützung von jQuery Mobile . . . . . . . . . . . . . . . . . . 234.3 Plattformabdeckung der unterschiedlichen Technologien . . . . . . . . . . . 284.4 Portabilität der mit unterschiedlichen Technologien entwickelten Anwendun-

gen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304.5 Performance der mit unterschiedlichen Technologien entwickelten Anwen-

dungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

6.1 Anwendungsfälle Mitarbeiter verwalten . . . . . . . . . . . . . . . . . . . . . 416.2 Anwendungsfälle Ausgrabungen verwalten . . . . . . . . . . . . . . . . . . . 446.3 Anwendungsfälle Befunde verwalten . . . . . . . . . . . . . . . . . . . . . . 476.4 Anwendungsfälle für den GA . . . . . . . . . . . . . . . . . . . . . . . . . . 48

8.1 Anwendungsfälle Befunde verwalten . . . . . . . . . . . . . . . . . . . . . . 58

v

vi TABELLENVERZEICHNIS

Kapitel 1

Einleitung

Ein wichtiger Bestandteil archäologischer Arbeit ist die Feldforschung. Hier sollen im Rah-men von Ausgrabungen wichtige Fragestellungen zu unserer Geschichte beantwortet wer-den. So geben z.B. Funde aus Nekropolen einen Überblick über die soziale Struktur derBevölkerung, Funde aus Heiligtümern geben Aufschluss über die Glaubensvorstellungenantiker Kulturen [HB02].

Eine wichtige Voraussetzung für Aussagen dieser Art ist jedoch die sorgfältige Aus-grabung und vor allem Dokumentation der Funde und ihres Fundkontextes. Diese Doku-mentation wird jedoch oft vernachlässigt. Grund hierfür ist unter anderem der enormeArbeitsaufwand, der mit ihr verbunden ist. Alle Funde sowie ihre Fundzusammenhängemüssen in Papierform möglichst genau und unmittelbar aufgenommen werden, da sie imweiteren Verlauf der Ausgrabung zerstört werden könnten. Wichtige Zusammenhänge wür-den so verloren gehen. Dies bedeutet meist eine Menge Schreibarbeit, die den �ieÿendenArbeitsablauf unterbricht und somit erschwert.

Im heutigen Informationszeitalter stellt sich nun die Frage nach der Vereinfachung desSchrittes der Dokumentation mittels moderner Techniken. Hierfür bieten sich nun mehrereMöglichkeiten, eine grundlegende Idee ist die Entwicklung eines Programmes, mit dem sichdie Dokumentation schneller und unkomplizierter realisieren lässt, als es bei einer schrift-lichen Dokumentation möglich ist. Da die Dokumentation aber, wie bereits beschrieben,unmittelbar nach Tätigung eines Befundes geschehen muss, scheint diese Aufgabe aufgrundder fehlenden Mobilität von Personal Computern (PC) und der Gröÿe von Notebooks nurschwer realisierbar. Abhilfe scha�en hier mobile Endgeräte, insbesondere die modernenSmartphones, die neue Generation von Computern [AGL10].

Mit der Vorstellung des ersten Apple iPhones im Jahr 2007 erhielt der Smartphone-Markt neuen Aufschwung [Imm12]. Der Absatz dieser kleinen Computer verpackt in einemMobiltelefon stieg rapide an, im Jahr 2012 haben sie das klassische Handy weitestgehendabgelöst [BI12]. Die neuen Smartphones bieten eine Vielzahl von Möglichkeiten der Ver-wendung. Zusätzlich kann jeder, der über die notwendigen Programmierkenntnisse verfügt,Anwendungen, sogenannte Apps, für sie entwickeln. Da sie auÿerdem sehr handlich sind

1

2 KAPITEL 1. EINLEITUNG

und aufgrund der neuen innovativen Bedienmöglichkeiten schnelles Arbeiten erleichtern,bieten sie sich für die Aufgabe der archäologischen Funddokumentation geradezu an.

Allerdings erfolgt die Entwicklung von Applikationen für mobile Endgeräte nicht oh-ne Probleme. Auf dem Markt existiert eine Vielzahl von Anbietern für Smartphones. DasFehlen von Standards hat hier zu einer Vielzahl von Betriebssystemen sowie nutzbarenEntwicklertools für die einzelnen Geräte geführt. Das macht es App-Entwicklern beinaheunmöglich, ihre Applikation für mehr als nur ein spezi�sches Endgerät zu programmie-ren. Um die Applikation dennoch auf möglichst vielen mobilen Endgeräten zugänglich zumachen, gibt es verschiedene Herangehensweisen, die jedoch relativ neu und daher kaumdokumentiert sind. Aus diesem Grund ist eine genauere Untersuchung in diesem Bereichnötig.

1.1 Aufgabenstellung

Das Ziel dieser Arbeit besteht in der Entwicklung einer Anwendung für mobile Endgerätezur archäologischen Funddokumentation. Die Anwendung soll es Archäologen auf Ausgra-bungen erleichtern, die Fundkontexte mit ihren Funden zu dokumentieren. Hierbei sollendie verschiedenen Methoden der mobilen Anwendungsentwicklung miteinander verglichenwerden. Dabei wird insbesondere auf die Methoden einzugehen sein, die eine Programmie-rung für möglichst viele mobile Betriebssysteme ermöglichen. Anschlieÿend wird die fürarchäologische Bedürfnisse passende Methode auszuwählen und umzusetzen sein.

Zu diesem Zweck müssen die Anforderungen an eine solche Anwendung aus archäolo-gischer Sicht de�niert und anschlieÿend in technische Anforderungen übertragen werden.Um die Methoden der mobilen Anwendungsentwicklung vergleichen zu können, müssen ver-schiedene Kenngröÿen gefunden werden. Unter dem Gesichtspunkt dieser Kenngröÿen sinddie möglichen Methoden auszuwerten, um eine geeignete Vorgehensweise zu wählen. Die-se soll anschlieÿend in einen Prototyp der Anwendung umgesetzt werden. Zusätzlich wirddie entstandene Anwendung hinsichtlich der gegebenen archäologischen Anforderungen zuanalysieren sein.

1.2 Aufbau der Arbeit

Die Arbeit gliedert sich in acht Kapitel. Das erste Kapitel beschäftigt sich mit der Moti-vation und der Aufgabenstellung der Arbeit sowie ihrem Aufbau.

Im zweiten Kapitel der Arbeit werden die archäologischen Anforderungen an die An-wendung de�niert. Zu diesem Zweck werden zuerst wichtige archäologische Begri�e erläu-tert. Die ermittelten archäologischen Anforderungen sollen in den folgenden Kapiteln intechnische Anforderungen an die Anwendung übertragen werden.

Kapitel drei und vier beschäftigen sich mit mobilen Endgeräten und mobilen Anwen-dungen. In diesen Kapiteln werden diese Begri�e de�niert und vorhandene Methoden zur

1.2. AUFBAU DER ARBEIT 3

Entwicklung von mobilen Anwendungen erläutert und analysiert. Für die Analyse notwen-dige Kennzahlen werden in Kapitel drei eingeführt.

Im fünften Kapitel wird auf die verschiedenen Möglichkeiten zur Datenspeicherung aufmobilen Endgeräten eingegangen und die für die Anforderungen passende ausgewählt.

Der beispielhafte Ablauf einer Entwicklung mittels der in den Kapiteln vier und fünfausgewählten Technik wird in Kapitel sechs und sieben aufgezeigt. Hierbei wird Kapitelsechs zuerst eine Übersicht über die genauen Anforderungen an die Applikation gebensowie einen skizzenhafter Entwurf der Anwendung vorstellen. Anschlieÿend wird in Kapitelsieben ausführlich die Umsetzung der Anforderungen mit dem ausgewählten Werkzeugdokumentiert. Als Ergebnis dieses Kapitels soll ein Prototyp der Anwendung entstehen.

Kapitel acht bietet neben einer Analyse des Prototyps sowie einem abschlieÿendenFazit auÿerdem einen Ausblick auf weiterführende Entwicklungsmöglichkeiten im Bereichder informationstechnischen Unterstützung der archäologischen Feldforschung sowie derEntwicklung mobiler Applikationen im Allgemeinen.

Kapitel 2

Archäologische Grundlagen

Vorbereitend auf die Entwicklung der Anwendung sollen in diesem Kapitel zuerst de-ren wichtigste archäologische Grundlagen aufgezeigt werden. Anschlieÿend werden hierausgrundlegende Anforderungen an die Anwendung erarbeitet.

2.1 Gegenstand der Archäologie

De�nition 2.1 Der Begri� Archäologie wird zusammengesetzt aus den griechischen Wör-tern archaios �alt� und lógos �Lehre� und wird daher gewöhnlich als Altertumskunde über-setzt.

Als historische Wissenschaft hat sich die Archäologie die möglichst weitgehende Er-forschung einer älteren Kultur zum Ziel gemacht. Daraus ergibt sich eine Vielzahl vonBereichen, die sich mit unterschiedlichen Zeit- und Kulturperioden der altertümlichen Ge-schichte befassen. Beispiele hierfür sind unter anderem die vorderasiatische, die ägyptischeund die klassische Archäologie, die sich mit der griechisch-römischen Antike beschäftigt[19996]. Ein weiterer eigenständiger Bereich ist die Vor- und Frühgeschichte oder auch prä-historische Archäologie, die sich mit den Hinterlassenschaften von Kulturen befasst, dievor unserer Geschichtsschreibung wirkten.

Eine wichtige Gemeinsamkeit der einzelnen Teilbereiche ist die Auswertung von Denk-mälern, Bodenfunden und Schriftquellen, um Aussagen über vergangene Kulturen machenzu können [19996]. Bei der Vor- und Frühgeschichte muss allerdings beinahe gänzlich aufschriftliche Quellen verzichtet werden, Aussagen können lediglich aufgrund von materi-ellen Funden gemacht werden. Insbesondere in diesem Bereich steht also die praktischeForschung (Feldforschung) in Form von Ausgrabungen im Vordergrund.

Diese praktische Forschung, die der Archäologie auch den Beinamen �Wissenschaft desSpatens� verleiht, steht bei der vorliegenden Arbeit besonders im Blickpunkt [Egg59]. Ausdiesem Grund sollen archäologische Ausgrabungen im Folgenden genauer betrachtet wer-den.

4

2.2. ARCHÄOLOGISCHE AUSGRABUNGEN 5

2.2 Archäologische Ausgrabungen

De�nition 2.2 Eine Ausgrabung ist die Freilegung und Untersuchung paläontologischerund Archäologischer Fundstellen [geo07].

Solche Fundstellen können unter anderem Siedlungen, Kultstätten, Gräber oder Höhlensein. Da diese durch die Ausgrabungen zerstört werden, ist eine umfangreiche Dokumen-tation unerlässlich. Dazu gehört die Vermessung, Zeichnung, Fotogra�e, Probenentnahmeund ausführliche Beschreibung der Fundstellen.

Die bei einer Ausgrabung gefundenen Artefakte werden als Funde bezeichnet. Hierunterfällt jedes Artefakt, welches von der Stelle bewegt werden kann, beispielsweise Keramik,Schmuck, Münzen oder ähnliches. Diese werden meist nach Beendigung der Ausgrabungin einem Labor mit verschiedenen Methoden untersucht und dokumentiert. Für die Zu-ordnung der Funde sind die Kontexte, in denen sie gefunden werden, besonders wichtig.Diese sogenannten Befunde werden bei der Bergung der Funde oder der Suche nach darun-ter liegenden Funden zerstört und müssen daher vor Ort ausführlich dokumentiert werden[HB02].

Der Ablauf einer Ausgrabung ist zwar in den Grundzügen vorgegeben, wird jedochvon unterschiedlichen Faktoren beein�usst. Einer dieser Faktoren ist beispielsweise derGrund der Grabung. Hier können drei Arten unterschieden werden: die Lehrgrabung, dieForschungsgrabung und die baubegleitende Ausgrabung, wobei die verschiedenen Formendurchaus gleichzeitig bei einer Ausgrabung auftreten können. Der gröÿte Unterschied zwi-schen den Typen ist die zur Verfügung stehende Zeit.

Während des Studiums der Archäologie werden den Studierenden vor allem theore-tische Kenntnisse vermittelt. Daher werden für die Studenten zur Einführung von Aus-grabungstechniken die Lehrgrabungen veranstaltet. Diese gehen meist über einen kurzenfestgelegten Zeitraum und dienen in erster Linie der Schulung, dazu gehört auch die grund-legende Vermittlung von Dokumentationskenntnissen. Ein Beispiel hierfür ist die jährlichstatt�ndende Lehrgrabung der internationalen archäologischen Sommerakademie Xanten[Rhe12]. Hier erforschen seit 2008 jedes Jahr 30 Teilnehmer eine dicht bebaute römischeSiedlung. Die Ausgrabung dauert in der Regel vier Wochen und soll den Studierenden denGrabungsalltag näher bringen.

Forschungsgrabungen beschäftigen sich über einen langen Zeitraum mit einer Fundstelleund untersuchen diese ausführlich. Eingeschlossen ist hier eine ausführliche Dokumenta-tion, die nach Beendigung oder bereits während der Ausgrabung publiziert werden soll.So dauerten die Ausgrabungen der Terme piccole und der spätantiken Exedra in Ostiain Italien unter der Leitung von Dr. Axel Gehring vier Jahre. In dieser Zeit konnte eineausführliche Dokumentation erstellt werden, auf deren Grundlage viele neue Erkenntnissegewonnen wurden [LL11].

Bei baubegleitenden Ausgrabungen werden Archäologen zu Bauarbeiten hinzugezogen,um die eventuelle Zerstörung von Hinterlassenschaften zu verhindern. Sie überwachen die

6 KAPITEL 2. ARCHÄOLOGISCHE GRUNDLAGEN

Arbeiten auf der Baustelle und dokumentieren, ob und was gefunden wird. Der Zeitfak-tor spielt dabei eine besonders wichtige Rolle, da die Bauarbeiten zügig voran schreitenmüssen. So bleibt meist nur wenig Zeit für die archäologischen Arbeiten. Die baubeglei-tende Ausgrabung ist nur in einigen Bundesländern P�icht, Vorreiter auf diesem Gebietist das Bundesland Bayern. Hier existieren genaue Vorschriften für die Dokumentation vonBefunden, die bei einer solchen Ausgrabung getätigt werden. Ein auf Grundlage dieserVorschriften erstelltes Befundblatt, soll in dieser Arbeit als Vorlage für die Anwendungdienen. Die folgende Abbildung (2.1) stellt den grundlegenden beispielhaften Ablauf einerAusgrabung vor.

Bevor die Ausgrabung beginnen kann, muss sie zuerst ausgeschrieben werden. Verschie-dene Grabungs�rmen bewerben sich für die Ausgrabung. Entscheidend für die Vergabe sindsowohl die fachliche Eignung als auch die preislichen Vorstellungen der Grabungs�rma.Nach der Vergabe muss sich das Grabungsteam zunächst umfassend über die Thematikinformieren. Vor Ort beginnt die Ausgrabung mit einer ersten Begehung des Geländes,hier lassen sich meist schon einzelne wichtige Fundstellen identi�zieren und abgrenzen. Zudiesem Zweck wird der auszugrabende Bereich in Rasterquadrate unterteilt, um sie bei derspäteren Dokumentation leichter zuordnen zu können.

Für die anschlieÿende Grabung lassen sich zwei grundlegende Techniken de�nieren.Zum einen sind das die Techniken, welche die vertikale Dimension hervorheben. Diese sindfür eine stratigraphische Analyse, also eine Analyse der unterschiedlichen Bodenschichten,besonders wichtig. Sie helfen, die chronologische Abfolge der innerhalb dieser Schichtengetätigten Funde zu erleichtern. Die zweite Kategorie sind Methoden, die vor allem diehorizontale Dimension eines Befundes untersuchen. Hier wird der Befund groÿ�ächig freigelegt, um die räumliche Beziehung zwischen Funden innerhalb des Kontextes sowie Be-ziehungen zwischen einzelnen Kontexten aufzuzeigen [RB09].

In der Regel wird eine Kombination aus beiden Strategien angewendet, so werden dieBefunde erst groÿ�ächig frei gelegt, identi�ziert und vom Grabungsleiter mit einer Befund-nummer versehen. Anschlieÿend wird ein Pro�l des Fundes durch eine vertikale Ausgrabungerstellt. Dieses Pro�l muss anschlieÿend wiederum ausführlich schriftlich dokumentiert wer-den. Hierfür wird für jeden Befund ein sogenanntes Befundblatt ausgefüllt. Anhang A ent-hält zwei beispielhafte Befundblätter, eines von den Ausgrabungen im antiken Ostia undeines basierend auf den Vorschriften des Landesdenkmalamtes in Bayern.

Nach der schriftlichen erfolgt noch eine zeichnerische sowie fotogra�sche Dokumenta-tion. Anschlieÿend müssen die Befunde und Funde genau vermessen werden. Ist die Do-kumentation abgeschlossen, kommt es zur Bergung der Funde. Zusätzlich kann es unterUmständen noch zur Entnahme einiger Bodenproben zur Analyse mithilfe verschiedenerwissenschaftlicher Methoden im Labor kommen. Nach Abschluss der Ausgrabung folgt dieErstellung eines ausführlichen Grabungsberichtes. In diesem erfolgt auch eine Untersu-chung der Dokumentation und der entnommenen Funde und Proben, um die Fundstelle zuanalysieren und Aussagen zu Chronologie, Zweck und ähnlichem der Fundstelle machen zukönnen.

2.2. ARCHÄOLOGISCHE AUSGRABUNGEN 7

Abbildung 2.1: Beispielhafter Ablauf einer archäologischen AusgrabungQuelle: Eigene Abbildung

8 KAPITEL 2. ARCHÄOLOGISCHE GRUNDLAGEN

2.3 Anforderungen an die Anwendung

Aus den archäologischen Grundlagen lassen sich wesentliche Anforderungen an die Anwen-dung herleiten.

2.3.1 Mobilität

Da die Dokumentation der Befunde zeitnah erfolgen soll, muss die Anwendung direkt vorOrt nutzbar sein. Die Fundstellen können unter Umständen sehr groÿ�ächig sein, wasdazu führt, dass die Befunde eventuell sehr weit auseinander liegen. Um einen Befund zudokumentieren, ist der ständige Blickkontakt zu ihm unerlässlich. Daraus resultiert, dassdie Anwendung eine groÿe Mobilität gewährleisten muss.

2.3.2 Datensicherheit

Es ist unumgänglich, dass die Befunde im Laufe einer Ausgrabung zerstört werden. Darausresultiert, dass im Falle des Verlustes der Dokumentation die gesammelten Informationenunwiderru�ich verloren gehen können. Deshalb ist es zwingend notwendig, dass die An-wendung eine sichere Speicherung der Daten gewährleistet.

2.3.3 Funktionsaufteilung

Auf einer Ausgrabung arbeiten meist mehrere Personen, die für unterschiedliche Aufga-ben eingeteilt sind. So ist der Grabungsleiter (GL) für die Einteilung der Fundstelle inQuadranten, sowie das Identi�zieren und Nummerieren von Befunden zuständig. Die Do-kumentation der freigelegten und gesäuberten Befunde wird wiederum von Archäologenund Grabungsassistenten (im folgender unter der Bezeichnung GA zusammen gefasst) vor-genommen. Daraus ergibt sich, dass die Anwendung die Erstellung von verschiedenen Be-nutzergruppen mit unterschiedlichen Zugri�en und Funktionen zur Verfügung stellen muss.Auÿerdem kann es vorkommen, dass mehrere GA's zeitgleich unterschiedliche Befunde do-kumentieren. Die Anwendung muss demnach auf unterschiedlichen Geräten zur Verfügungstehen. Eine Kommunikation unter den Geräten wird ebenfalls nötig sein, um alle Mitar-beiter ständig auf dem aktuellsten Stand zu halten. Auÿerdem soll sie dem Grabungsleiterdie Möglichkeit geben, Befunde einzelnen Grabungsassistenten zuzuweisen.

In diesem Kapitel wurden die grundlegenden Anforderungen an die Anwendung ausarchäologischer Sicht heraus gearbeitet. Diese sollen im Folgenden nun in technische An-forderungen überführt werden.

Kapitel 3

Informationstechnische Grundlagen

Aus den beschriebenen archäologischen Grundlagen ergeben sich bereits wichtige Anfor-derungen an die Anwendung. Dazu gehört unter anderem die notwendige Mobilität. Umsie zu gewährleisten ist es nötig, eine mobile Applikation, also eine Anwendung, die aufeinem mobilen Endgerät genutzt werden kann, zu erstellen. Zunächst muss daher spezi�-ziert werden, was allgemein und in dieser Arbeit speziell unter einem mobilen Endgerät zuverstehen ist.

3.1 Mobile Endgeräte

Eine einheitliche und präzise De�nition eines mobilen Endgerätes �ndet sich in der Li-teratur nicht. So de�niert [Pou04] von der Universität München als Kriterium für dieEinordnung von Geräten in die Kategorie mobiles Endgerät lediglich die Möglichkeit desmobilen Einsatzes eines technischen Produktes. Er zählt hierzu Mobiltelefone, Smartpho-nes, Personal Digital Assistants (PDAs), aber auch Tablets. Die Enzyklopädie der Online-Computerzeitschrift pcmag.de fügt dem noch die ungenaue Formulierung: �any other por-table, electronic product� hinzu [pcm12a]. Im Allgemeinen ist ein mobiles Endgerät alsojedes elektronische Gerät, das für einen mobilen Einsatz konzipiert wurde. Diese Arbeit be-schränkt sich jedoch nur auf mobile Endgeräte zur Kommunikation, speziell Smartphonesund Tablets. Was darunter zu verstehen ist, wird im Folgenden spezi�ziert.

Eine einheitliche De�nition für Smartphones lässt sich ebenfalls nur schwer �nden, wasunter anderem mit der schnellen Weiterentwicklung des Marktes und den daraus resultie-renden ständig neuen Merkmalen der Geräte zusammen hängt. Im [Gre03] beispielsweisede�nierte sich ein Smartphone noch als ein �Mobiltelefon, in das ein Organizer integriertist�. Seither wurden bestehenden Smartphones immer neue Funktionalitäten hinzugefügt,auf deren Basis immer wieder neue De�nitionen für Smartphones gebildet wurden. Zu die-sen Funktionen gehören beispielsweise eine integrierte Kamera sowie die Möglichkeit, dasmobile Internet zu nutzen [AGL10].

Inzwischen besitzen Smartphones noch weitere de�nierende Merkmale. Die ausschlag-gebendste ist hier wohl das Vorhandensein eines eigenen mobilen Betriebssystems. Dar-

9

10 KAPITEL 3. INFORMATIONSTECHNISCHE GRUNDLAGEN

über hinaus gibt es viele unterschiedliche Funktionen, die von den meisten Smartphonesangeboten werden. Dazu gehören unter anderem die Bedienung mit mehreren Fingern,die Verwaltung von Emails oder die Fähigkeit dieser Geräte, Videos abzuspielen. Zusätz-lich bietet ein Smartphone umfangreiche Möglichkeiten der Personalisierung, indem eineVielzahl von Applikationen mit unterschiedlichen Funktionen, sogenannte Apps, installiertwerden können. Aus diesem Grund werden Smartphones bereits als eine neue Generationvon mobilen Computern bezeichnet, die zu einer Vielzahl von unterschiedlichen Zweckeneingesetzt werden können [AGL10].

Tablets sind ebenfalls mobile Computer, jedoch gröÿer als Smartphones. Sie sind voll-kommen in einen Touchscreen eingebettet und werden mit dem Finger oder seltener miteinem Stift bedient [pcm12b]. Bereits in [Gre03] stehen Tablets als mobile Computer mitdem Format eines Schreibblocks, deren Oberseite aus einem berührungsemp�ndlichen Bild-schirm besteht. Hier wurden die Marktchancen dieser Geräte allerdings wenig positiv ein-geschätzt. Der Aufschwung der Tablets kam erst mit der Version der Firma Apple Inc.,dem iPad. Seither sind viele weitere Anbieter, die sich auch für die meisten Smartphonesverantwortlich zeigen, mit einem oder mehreren eigenen Geräten in den Markt eingestiegen.

In Kapitel zwei wurde heraus gearbeitet, dass die Anwendung auf mehreren Geräten zurVerfügung stehen muss. Im Laufe der letzten Jahre sind viele unterschiedliche Firmen in denSmartphone-Markt eingestiegen. Daraus resultiert eine groÿe Anzahl an unterschiedlichenmobilen Plattformen, die sich auch auf den Tablets �nden lassen.

De�nition 3.1 Eine Plattform ist eine Hardware- bzw. Softwarearchitektur, auf der einelektronisches Gerät basiert [Gre03].

Es gibt unterschiedliche Arten von Plattformen abhängig von den gewählten Unter-scheidungsmerkmalen. Dazu gehören beispielsweise Computersysteme, Betriebssysteme,übergreifende Anwendungsprogramme oder Portale im Internet [Gre03]. In dieser Arbeitwerden insbesondere die Betriebssysteme als Plattform betrachtet, da die gängigen Smart-phones hier starke Di�erenzen aufweisen.

Sind diese Betriebssysteme für mobile Endgeräte konzipiert, werden sie als mobile Platt-form bezeichnet. Die starke Fragmentierung des Smartphone-Marktes hat eine groÿe An-zahl von mobilen Plattformen hervorgebracht. Diese sollen im Folgenden kurz vorgestelltwerden.

3.2 Mobile Plattformen

Wie die nachfolgende Abbildung 3.1 zeigt, haben sich Apples iPhone sowie die verschiede-nen Android-Geräte unter den mobilen Plattformen am stärksten durchgesetzt. Sie werdendeshalb detailliert betrachtet.

Aufgrund ihrer Aktualität und des innovativen Designs sollen auch Smartphones mitdem neuen Windows-Betriebssystem Windows Phone 7 einer näheren Untersuchung un-terzogen werden. Die übrigen Anbieter werden abschlieÿend kurz vorgestellt.

3.2. MOBILE PLATTFORMEN 11

Abbildung 3.1: Prognose zu Marktanteilen mobiler Plattformen 2012 und 2016Quelle: [Sta12c]

3.2.1 Apple iPhone

Das erste iPhone der Firma Apple Inc. wurde im Jahr 2007 auf der Macworld Conference& Expo in San Francisco vorgestellt und erö�nete damit die Ära der Smartphones [Fli09].Seitdem hat Apple mehrere Millionen iPhones verkauft, im laufenden Jahr 2012 sind esbereits an die 100 Millionen Stück (Abb. 3.2). Ein Grund für die stets hohen Verkaufs-zahlen ist der Tatsache geschuldet, dass Apple seitdem jedes Jahr eine neue Version desiPhones, zuletzt das iPhone 5, die sechste Generation des Smartphones, auf den Marktbringt [Sta12a].

Für den Vertrieb der entwickelten Anwendungen ist der hauseigene AppStore zuständig[Inc]. Bevor eine Anwendung hier angeboten werden kann, wird sie von Apple hinsichtlichgegebener Richtlinien untersucht. Diese Richtlinien beziehen sich besonders auf Design derOber�äche sowie verwendete Technologien zur Entwicklung der Anwendung. Werden dieRichtlinien nicht erfüllt, wird die Anwendung abgelehnt und kann aufgrund mangelnderAlternativen nur schwer vermarktet werden [Imm12].

3.2.2 Android

Eine weitere groÿe Plattform ist das Android Betriebssystem von Google, welches o�ziellam 22. Oktober 2008 mit dem T-Mobile G in den USA auf den Markt kam. Dieses ersteGerät besaÿ noch keines der Merkmale, die ein Smartphone heutzutage auszeichnet, weder


Abbildung 3.2: Absatz von iPhones bis zum 3. Quartal 2012Quelle: [Sta12a]

eine Bildschirmtastatur, noch ein Multitouch-Display, zusätzliche Apps waren ebenfallsnicht erhältlich. In den folgenden drei Jahren brachte Google acht neue Versionen aufden Markt. Das Windows-Betriebssystem für Computer scha�t es im Vergleich auf zehnVersionen in 25 Jahren [Zie11].

Im Unterschied zu Apples iOS ist das Android Betriebssystem nicht nur auf ein Gerätbeschränkt. Es ist auf vielen Geräten unterschiedlicher Hersteller zu �nden, was unteranderem ein Grund für die im Gegensatz zu iOS schneller steigenden Absatzzahlen seinkann. Forscher prognostizieren Verkaufszahlen im Milliarden-Bereich für Android bereitsfür das Jahr 2013, für Apple sehen sie diese Grenze erst im Jahr 2015 erreicht [Gur12].

Auch Android hat einen eigenen Markt zum Verbreiten der Anwendungen, ähnlich demApp Store von iPhone, bietet darüber hinaus aber noch die Möglichkeit, Anwendungen aufeigenen Websites oder in unabhängigen Marktplätzen anzubieten [And]. Die Vermark-tung der Anwendungen ist im Wesentlichen kostenlos, bei Verkauf über den Market-Placewird eine einmalige Gebühr von 25 US-Dollar fällig. Bei den einzuhaltenden Richtlinienlässt Google den Entwicklern mehr Freiheiten als Apple. Lediglich einige inhaltliche undtechnische Vorgaben werden überprüft, die Gestaltung wird jedoch dem Programmiererüberlassen.

3.2. MOBILE PLATTFORMEN 13

3.2.3 Windows Phone

Das erste mobile Betriebssystem von Windows erschien bereits im Jahr 2000 für PocketPC und hieÿ Windows Mobile. Die letzte Version 6.5 kam im Jahr 2009 auf den Markt.Die Marktanteile für das mobile Betriebssystem lagen zu diesem Zeitpunkt bereits weitabgeschlagen, eine Besserung war nicht in Sicht [Imm12].

Aus diesem Grund entschied sich Microsoft zu einem Neuanfang und brachte im Okto-ber 2012 mit Windows Phone 7 ein völlig neu konzipiertes Betriebssystem auf den Markt.Die Prognosen hinsichtlich der Verkaufszahlen für diese überarbeitete Versionen sind op-timistischer als seinerzeit für Windows Mobile, das deutsche Marktforschungsinstitut IDCsieht Windows Phone bis 2015 sogar als Platz zwei direkt hinter Android [Cor12].

Wie die beiden bereits beschriebenen Plattformen besitzt auch Windows einen speziellfür den Vertrieb von Anwendungen eingerichteten Store, den Marketplace [Phoa]. Wie beiApple wird für die Verö�entlichung von Anwendungen eine Gebühr von 99 US Dollar imJahr fällig. Zusätzlich ist das Limit an verö�entlichbaren kostenlosen Anwendungen auf100 beschränkt, bei kostenp�ichtigen Programmen gibt es diese Grenze nicht [Imm12].

Auch Microsoft prüft den Inhalt und die Technik einer Anwendungen vor deren Ver-ö�entlichung genau. Zusätzlich hat Microsoft noch die Vorgabe eingeführt, dass Anwen-dungen einem besonderen Zweck dienen müssen. Allein die Darstellung einer Website aufeinem mobilen Gerät, wie das bei vielen Apple Anwendungen der Fall ist, entspricht diesenRichtlinien daher nicht [Imm12].

3.2.4 Weitere Plattformen

Neben den vorgestellten Plattformen existieren noch weitere, drei Beispiele werden hierkurz vorgestellt. [Jas11] enthält einen umfassenderen Überblick über die meisten gängigenmobilen Betriebssysteme.

Das Betriebssystem Symbian, inzwischen unter dem Namen Nokia Belle verzeichnet,wurde in enger Zusammenarbeit mit der Firma Nokia entwickelt. Da diese sich nun aufMicrosofts Betriebssystem Windows Phone konzentrieren will, wird die Entwicklung vonSymbian langfristig nicht �nanzierbar sein [Tel]. Aber schon vorher hatte das Betriebssys-tem unter starken Einbuÿen zu leiden.

Blackberrys werden mit einem Betriebssystem genannt Blackberry OS der Firma Re-search in Motion (RIM) ausgeliefert. Herausragend in diesem System ist der Email Dienst,aktuelle Multimedia-Features sind auch vorhanden. Die Bedienung des Blackberrys erfolgtvorwiegend über eine Tastatur und ein Trackpad, nur wenige Touchelemente sind derzeitenthalten.

Das Betriebssystem bada der Firma Samsung beschränkt sich nur auf einige wenigeGeräte, da es lediglich mit der hauseigenen Wave-Reihe der Smartphones ausgeliefert wird.Der Vorteil der Geräte ist der günstige Preis. Aufgrund der Einschränkung auf eine einzelneSmartphone-Reihe existieren aber kaum Anwendungen für diese Plattform.


3.3 Plattformunabhängigkeit und Portabilität

Diese Vielfalt an Betriebssystemen macht den Ansatz der plattformunabhängigen Program-mierung von Applikationen für mobile Endgeräte zu einer aktuellen und vielversprechendenMöglichkeit. Da die Forschung auf diesem Gebiet jedoch nicht weit vorangeschritten ist,ist die Erstellung einer solchen Anwendung eine herausfordernde Aufgabe.

De�nition 3.2 Die Plattformunabhängigkeit ist die Eigenschaft einer Software auf ver-schiedenen Computersystemen bzw. unter verschiedenen Betriebssystemen betrieben werdenzu können [Gre03].

Die plattformunabhängige Programmierung ist nicht erst seit dem Durchbruch von mo-bilen Endgeräten ein beliebtes Thema. So führte das Vorhandensein von unterschiedlichenPlattformen auf PCs, insbesondere die Betriebssysteme der Firmen Apple und Microsoft,im Jahr 1990 zur Entwicklung der Programmiersprache Java [Dor06]. Java zeichnet sichdadurch aus, dass die erstellten Programme zum Laufen lediglich die Java Virtual Machine(JVM) benötigt. Solange die JVM auf einem Gerät installiert werden kann, können auchalle in Java entwickelten Programme genutzt werden, unabhängig von der verwendetenPlattform.

Die Fragmentierung des mobilen Marktes führt nun ebenfalls zu Bemühungen auf demGebiet der Plattformunabhängigkeit. Hier wurden in den letzten Jahren unterschiedlicheFortschritte gemacht, die im nächsten Kapitel genau betrachtet werden. Die verschiedenenMethoden zur Anwendungsentwicklung für Smartphones sollen anschlieÿend in Bezug aufihre Plattformunabhängigkeit bewertet werden. Zu diesem Zweck werden hier verschiedeneKenngröÿen eingeführt.

Ein wichtiger Punkt, der untersucht werden muss, ist die Plattformunterstützung bzw.die darauf aufbauenden Plattformabdeckung. Der Begri� Plattformabdeckung beschreibtdie Anzahl der unterschiedlichen Plattformen, auf denen eine Anwendung genutzt werdenkann, gemessen an den vorhandenen Plattformen [Wei12]. In dieser Arbeit beschränkt sichdie Untersuchung der Plattformabdeckung auf die zuvor vorgestellten Plattformen undwird in Prozent angegeben.

Ein weiterer wichtiger Begri� im Zusammenhang ist die Portabilität.

De�nition 3.3 Die Portabilität ist ein Maÿ für die Leichtigkeit der Übertragung einesSoftwareproduktes auf eine neue rechentechnische Umgebung ohne wesentliche Qualitäts-minderung [Rot87].

Die Portabilität (P) errechnet sich dabei aus dem Aufwand zur Übertragung des Pro-grammes (Ü) zusammen mit dem Aufwand zu Anpassung der Anwendung (A) im Vergleichzu dem Aufwand, der für eine Neuentwicklung des Programmes (N) nötig wäre. Für diePortabilität folgt daraus:

P = 1 - (Ü + A) / N.

3.3. PLATTFORMUNABHÄNGIGKEIT UND PORTABILITÄT 15

Hierbei handelt es sich jedoch nur um Schätzgröÿen, die vor Ausführung der Übertra-gung errechnet werden können. Nach [Rothardt 1988] kann die Portabilität auf drei Ebe-nen beein�usst werden. Die erste Ebene sind Hardwaredi�erenzen. Diese Ebene wird in dervorliegenden Arbeit jedoch vernachlässigt. Ausgegangen wird von einem Minimalsystem,auf dem eine Central Processing Unit (PCU), ausreichend Speicher und eine Kamera fürdie Fotoaufnahmen vorhanden sind und sich nicht grundlegend unterscheiden. Die zweiteEbene ist die Umgebungsabhängigkeit des Softwareproduktes, die ebenfalls vernachlässigtwerden kann, da die Anwendung für sich allein steht und keine weitere Software nutzt. Dieletzte Ebene, die Systemsoftwaredi�erenzen ist die wichtige Ebene für die geplante Anwen-dung, insbesondere die unterschiedlichen Betriebssysteme. Diese bedingen unterschiedlicheVorgaben für die Entwicklungsumgebung, die Programmiersprache sowie das Design derAnwendung.

Sowohl die Plattformabdeckung als auch die Portabilität auf Betriebssystemebene sol-len im folgenden Kapitel bei der Auswahl der genutzten Methode zur Entwicklung derAnwendung berücksichtigt werden. Zu diesem Zweck sind die zur Verfügung stehendenMethoden im nächsten Kapitel genau zu beschrieben und zu untersuchen.

Kapitel 4

Methoden zur Entwicklung mobiler

Applikationen

Kapitel drei hat gezeigt, dass die Entwicklung einer mobilen Anwendung zur Umsetzungder archäologischen Anforderungen notwendig ist. In diesem Kapitel sind darauf aufbauenddie aktuellen Methoden zur Entwicklung einer solchen Anwendung genauer zu untersuchen.

4.1 Apps und ihr Anwendungsbereich

Der am häu�gsten genutzte Begri� für diese mobilen Anwendungen �App� ist die Abkür-zung für �application� im Allgemeinen. Er wurde vor allem durch Apples Werbeslogan �the-re is an App for that� bekannt und seither als Bezeichnung für Smartphone-Anwendungenallgemein anerkannt.

Im Unterschied zu Anwendungen für Desktop-Computer sind mobile Apps meist aufeine simple Funktion beschränkt und für diese optimiert. Hierbei haben sich verschiedeneAnwendungsbereiche für Apps besonders durchgesetzt, die am häu�gsten genutzten sindin Abbildung 4.1 dargestellt. Wie die Abbildung zeigt, sind die beliebtesten Apps gröÿten-teils im Entertainment-Bereich anzusiedeln, dazu gehören Spiele und Musik Apps. SocialMedia Apps, wie die App-Varianten der sozialen Plattformen �Facebook� oder �Google+�,werden am häu�gsten genutzt [Sta12b]. Apps mit dem Thema Archäologie hingegen sindkaum vorhanden. Gibt man in Apples App-Store �Archäologie� als Suchwort ein, �ndetman gerade einmal 12 Apps. Vertreten sind hier Apps zu archäologischen Nachrichten wie�ArchaeoNews� oder �Karfunkel-Zeitschrift�, sowie Museums-Apps wie �Mainlimes Mobil�oder �iMuseums�. Eine Applikation, die den Archäologen ihre tägliche Arbeit erleichtert -wie die hier geplante App zur Ausgrabungsdokumentation - ist keine vorhanden, obwohlsie, wie bereits erwähnt, mehr als hilfreich sein kann. Aus diesem Grund ist die Entwicklungeiner solchen App angezeigt.

Vor der Entwicklung von Apps sind zunächst konzeptionelle Fragen zu klären. So mussentschieden werden, ob eine App nur für eine bestimmte Plattform verfügbar sein oder von

16

4.1. APPS UND IHR ANWENDUNGSBEREICH 17

Abbildung 4.1: Verteilung von Arten unterschiedlicher AppsQuelle: [Sta12b]

18 KAPITEL 4. METHODEN ZUR ENTWICKLUNG MOBILER APPLIKATIONEN

möglichst vielen dieser Plattformen unterstützt werden soll. Ausgehend von dieser Frage-stellung ergeben sich drei grundlegende Typen von Apps, die nativen Apps, die Web-Apps,sowie die hybriden Apps. In diesem Kapitel sollen diese drei Arten ausführlich vorgestelltwerden.

4.2 Native Apps

De�nition 4.1 Eine native App ist eine App, die für ein bestimmtes mobiles Betriebssys-tem mittels der für dieses System vorgesehenen Entwicklertools programmiert wurde undnur auf diesem System verfügbar ist.

Aus De�nition 4.1 geht hervor, dass jede native App mit der für die Plattform spezi�-schen Entwicklungsumgebung programmiert wird. Diese Umgebungen werden im folgendenfür die in Kapitel zwei genau beschriebenen Plattformen Apple, Android und Windows be-schrieben.

4.2.1 Entwicklung für Apples iPhone

Das Betriebssystem für das iPhone heiÿt seit Juni 2009 iOS (vormals iPhone OS) undbasiert auf dem Betriebssystem Mac OS X [Paa11]. Im Laufe der Jahre sind verschiedeneGeräte für dieses Betriebssystem erschienen. Neben den verschiedenen Generationen vonSmartphones nutzen auch die erschienenen Versionen des MP3-Players von Apple, demiPod Touch, sowie des Tablets iPad dieses Betriebssystems.

Die Entwicklung von Anwendungen für das iPhone kann nur mit dem ebenfalls vonder Firma Apple hergestellten Computer, dem Mac, erfolgen. Die Verwendung andererSysteme, beispielsweise eines Computers mit einem Windows-Betriebssystem ist ausge-schlossen. Eine weitere Voraussetzung ist die Registrierung bei Apple als Entwickler. Umdie selbst entwickelten Anwendungen auf dem Gerät testen zu können, ist zusätzlich einkostenp�ichtiges Entwicklerkonto nötig [Imm12].

Die eigentliche Programmierung erfolgt nach der Registrierung in der Entwicklungsum-gebung Xcode mittels der ebenfalls nur für iPhone Anwendungen Verwendung �ndendenProgrammiersprache Objective-C. Wichtig bei der Entwicklung ist auÿerdem, die Richtli-nien von Apple einzuhalten, da es sonst zu Schwierigkeiten mit der Verö�entlichung derAnwendung kommen kann [Imm12].

4.2.2 Entwicklung für Android Geräte

Die Entwicklung von Android Anwendungen erfolgt in der Programmiersprache Java.Hieraus ergibt sich schon ein wesentlicher Vorteil von Android gegenüber dem iPhone, daJava im Gegensatz zu Objective-C nicht ausschlieÿlich für ein Betriebssystem konzipiert ist.Im Gegenteil, Java kann als der Wegbereiter zum plattformunabhängigen Programmierengesehen werden und ist auÿerdem eine seit vielen Jahren anerkannte Programmiersprache,mit der viele Entwickler bereits vertraut sind [Imm12].

4.2. NATIVE APPS 19

Auch für das Betriebssystem, mit dem programmiert wird, gibt es im Gegensatz zumiPhone keine Einschränkungen, es muss lediglich ein kompatibles Android SDK installiertsein. Hierbei handelt es sich um ein Plug-In für Eclipse, welches damit auch das Standard-Framework für die Entwicklung von Android Anwendungen ist. Zum Testen auf dem Gerätsind keine weiteren Anmeldungen nötig, zusätzlich ist die Portierung auf das Smartphonekostenlos, ein weiterer Vorteil gegenüber dem iPhone [Imm12].

4.2.3 Entwicklung für Windows Phones

Die Entwicklung von Anwendungen für das Betriebssystem Windows Phone 7 erfolgt wahl-weise in den Programmiersprachen C# oder Visual Basic. Beides sind bereits bekannteProgrammiersprachen, welche nicht ausschlieÿlich für die Entwicklung von mobilen Appli-kationen genutzt werden können. Als Umgebung für die Entwicklung bietet Microsoft hierVisual Studio, allerdings erst ab Version 2010. Frühere Versionen unterstützen lediglich dieEntwicklung für Windows Mobile [GHN11].

Tabelle 4.1 gibt noch einmal einen Überblick über die verschiedenen Entwicklungs-umgebungen und Programmiersprachen. Zur Vollständigkeit sind hier auch BlackBerry,Symbian und bada enthalten.

Plattform Programmiersprache EntwicklungsumgebungAndroid Java (C, C++) EclipseiOS Objective-C XcodeWindows Phone C Visual Studio 10Blackberry Java JDESymbian C++ EclipseBada C++ Bada SDK

Tabelle 4.1: Programmiersprachen und Entwicklungsumgebungen der verschiedenen Platt-formen

Die Programmierung von nativen Apps birgt sowohl Vor- als auch Nachteile. Diesesollen im folgenden Abschnitt beschrieben werden.

4.2.4 Vor- und Nachteile von nativen Apps

Native Apps haben den Vorteil, alle Funktionen des Gerätes, für das sie konzipiert wur-den, nutzen zu können. Dazu gehören die eingebaute Hardware, wie die Kamera oder dieBeschleunigungssensoren, aber auch die mitgelieferte Software, wie das Telefonbuch. DerNachteil ist allerdings, dass die App nur für dieses eine System verfügbar ist. Soll sie aufeinem weiteren System laufen, muss sie neu programmiert werden. Da jede Plattform auchihre eigene Programmiersprache verwendet, lassen sich bereits entwickelte Teile nicht por-tieren.

Dank der zur Verfügung stehenden Frameworks, welche die Entwicklung stark verein-fachen, passen die Apps sich optisch nahtlos in ihr System ein. Dies erleichtert auch die


Vermarktung sehr, da man weniger auf die optischen Richtlinien achten muss und so weni-ger Fehler unterlaufen. Die Apps können auÿerdem direkt im hauseigenen Store angebotenwerden und �nden so leicht zum Endnutzer. Entsprechen sie allerdings nicht den Vorgaben,kann es leicht zu einer Ablehnung im entsprechenden Store kommen (zumindest bei Appleund Microsoft). Dies kann dazu führen, dass die App nicht vermarktet werden kann, da esan Alternativen mangelt.

4.3 Web Apps

De�nition 4.2 Web-Applikationen oder kurz Web-Apps, sind Anwendungen, welche mitgängigen Web-Technologien entwickelt werden und ausschlieÿlich in einem Browser ablau-fen [Sch11].

Für die Entwicklung von Web-Apps werden also lediglich Web-Technologien benötigt.Die häu�gsten eingesetzten Mittel sind hierbei HTML5, CSS3, sowie JavaScript. Diesesollen im Folgenden genau vorgestellt werden. Eine weitere Technologie ist Flash, eineTechnik der Firma Adobe mit der sich die Darstellung von Videos, Musik und multimedia-len Interaktionen in Webseiten einbetten lassen. Da diese Technologie sich aufgrund einigerKontroversen mit Apple nicht durchsetzen konnte, wird in dieser Arbeit nicht explizit dar-auf eingegangen [Job10].

4.3.1 HTML 5

Bevor die Entstehung von HTML5 beschrieben werden kann, müssen zunächst die beidenwichtigsten Institutionen in diesem Zusammenhang eingeführt werden.

Das World Wide Web Consortium (W3C) ist ein Gremium, das von Tim Berners-Leegeleitet wird und dessen Ziel es ist, Standards für die Webentwicklung zu entwerfen unddurchzusetzen. Das Gremium besteht dabei aus verschiedenen Mitgliedern der gröÿtenFirmen zur Web-Entwicklung wie Apple, Adobe, Microsoft und Google [Cas09].

Die Web Hypertext Application Technology Working Group (WHATWG) ist eineGruppe von Opera-Entwicklern sowie einigen Entwicklern der Firma Mozilla unter der Lei-tung von Ian Hickson, die maÿgeblich für die Entwicklung des neuen HTML5-Standardsverantwortlich sind [LS11].

Die Hypertext Markup Language (HTML) ist eine so genannte Auszeichnungssprache.Sie dient der Strukturierung von Texten und bietet gleichzeitig die Möglichkeit, Gra�kenund multimediale Inhalte mittels Referenzen einzubinden. Entwickelt wurde die Sprachevon Tim Berners-Lee im Zuge des Internet-Booms, ihre erste Version erschien 1990 [MG10].Seitdem wurde HTML kontinuierlich weiterentwickelt, wobei bis zur Entstehung des mo-dernen HTML5-Standards noch einige Hürden zu meistern waren.

1998 beschloss das W3C, die Weiterentwicklung von HTML nicht mehr zu unterstützen,sondern vielmehr auf Extensible Markup Language (XML) zu bauen. Die daraus resultie-rende Spezi�kation, XHTML, konnte sich ohne die Unterstützung der Browserhersteller

4.3. WEB APPS 21

nicht durchsetzen. So kam es dazu, dass die WHATWG begann, an einer neuen Spezi�ka-tion zu arbeiteten, aus der schlieÿlich der neue HTML5-Standard hervor ging.

Der neue Standard wurde im Jahr 2004 dem W3C vorgestellt, dieser lehnte ihn jedochab. So musste die Weiterentwicklung von HTML5 zunächst auÿerhalb des W3C von stattengehen. Allerdings musste auch das W3C bald darauf eingestehen, dass die Entwicklung vonXHTML gescheitert war. So kam es im März 2007 zur Gründung einer neuen HTML Wor-king Group innerhalb des W3C, der sich auch die Mitglieder der WHATWG anschlossen[FÖ11].

HTML5 bringt einige Neuerungen gegenüber HTML4, dazu gehören unter anderem:

- Darstellung von Video, Audio, dynamischen 2D- und 3D-Gra�ken ohne Browser-Plug-Ins

- neue strukturierende Elemente

- Neue interaktive Formularelemente

- Geolocation

- Web Storage

Besonders interessant für die Programmierung von mobilen Anwendungen sind dieletzten beiden Elemente, da sie Web-Apps den nativen Apps immer weiter annähern. DankGeolocation ist es nun möglich, den eigenen Standort zu ermitteln und in Anwendungenzu nutzen, eine Möglichkeit die bisher den nativen Applikationen vorbehalten war. Grundhierfür ist die fehlende Unterstützung der Hardware-Schnittstellen der mobilen Gerätedurch Web-Applikationen. Mit Geolocation lässt sich nun Bewegungssensoren simulierenund somit die Position des Anwenders bestimmen. Web Storage hingegen bietet nun vieleverschiedene Möglichkeiten der Datenspeicherung auf dem mobilen Gerät (Client). Diesesollen im Folgenden in einem eigenen Kapitel genauer untersucht werden.

Ein Vorteil dieser Client-seitigen Speicherung ist auÿerdem, dass die Anwendung o�ine-fähig wird, also ohne eine Internetverbindung lau�ähig ist. Auch dies lieÿ sich bisher mitWeb-Apps nicht realisieren, da immer eine Verbindung zum Web-Server nötig war, um ak-tuelle Seiteninhalte zu laden. Mit der Datenspeicherung auf dem mobilen Endgerät ist einesolche Verbindung nun entbehrlich. Hierfür wird eine sogenannte Manifest-Datei angelegt.Hierbei handelt es sich um eine einfache Textdatei, in der alle Ressourcen enthalten sind,die lokal auf dem Gerät gespeichert werden sollen. Alle in der Manifest-Datei referenzier-ten Daten werden, sobald sie das erste Mal geladen werden, lokal gespeichert und könnenso auch im O�ine-Betrieb aufgerufen werden. So wird es Web-Apps möglich, auch ohneInternetverbindung lau�ähig zu sein.

HTML5 bietet also schon viele Möglichkeiten, damit die Web-Apps den nativen Appsnoch ähnlicher werden. Dabei stellt HTML allerdings nur die grundlegenden Seitenele-mente. Für weiterführende Funktionen wird die Scriptsprache JavaScript benötigt, die imfolgenden Abschnitt genau erläutert wird.


4.3.2 JavaScript

Bevor die Entstehung von JavaScript behandelt werden kann, muss zunächst der Begri��Scriptsprache� de�niert werden

De�nition 4.3 Eine Scriptsprache ist eine einfach strukturierte und leicht zu erlernen-de Programmiersprache, die es erlaubt innerhalb einer Anwendung Prozeduren (i.d.R zurVerbindung mit einem Netz und zur Steuerung darin) zu schreiben [Gre03].

JavaScript ist eine solche Scriptsprache, die Ende 1995 mit dem Internetbrowser Nets-cape Navigator 2 unter dem Codenamen LiveScript erschien. Im Laufe der Jahre erhieltauch der Internet Explorer die Fähigkeit, JavaScript zu interpretieren und auszuführen, al-lerdings unter dem Namen JScript. Zu diesem Zeitpunkt begann der sogenannte �Browser-Krieg� der beiden Browser-Hersteller um die Unterstützung von immer neuen und besserenVersionen von JavaScript.

Ein wichtiger Schritt war hier die Standardisierung durch die European ComputerManufacturers Association (ECMA). Der Standard wurde vor allem vom Netscape Navi-gator unterstützt, Microsoft setzte hier eher auf die W3C. Auch diese beschäftigte sichmit einer Standardisierung von JavaScript. Daraus resultierte das sogenannte DocumentObject Model (DOM) [Wen10]. Hierbei handelt es sich jedoch nicht um einen JavaScript-Standard, sondern vielmehr einen Standard für das dynamische Verwalten einer Webseitedurch Scriptsprachen [W3Cb].

Inzwischen wird JavaScript von den meisten Browsern unterstützt und ist daher platt-formübergreifend. Bei der Entwicklung von Web-Apps ist die Scriptsprache ein wichtigerBestandteil. Das durch JavaScript ermöglichte dynamische Nachladen von Inhalten, ohnedass die komplette Webseite neu geladen werden muss (Asynchronus JavaScript and XML- AJAX), bringt die Anwendung einer nativen Anwendung näher. Um die Web-App einernativen App noch ähnlicher zu gestalten, wird zusätzlich zu HTML5 und JavaScript nochCSS3 benötigt, worauf im folgenden Abschnitt genauer eingegangen wird.

4.3.3 CSS3

Eine Beschreibung für Cascading Style Sheets (CSS) lässt sich ebenfalls bei der W3C�nden. Hier steht:

CSS is the language for describing the presentation of Web pages, includingcolors, layout, and fonts [W3Ca].

CSS ist also maÿgeblich für das Design einer Website zuständig und nimmt damit einewichtige Rolle in der Entwicklung von Web-Apps ein. Um eine Internetanwendung einernativen Anwendung anzugleichen, ist es von Vorteil, wenn die Web-App äuÿerlich nichtvon der nativen Variante zu unterscheiden ist. Hierfür kann das Design der Web-App mitHilfe von CSS angepasst werden.

4.3. WEB APPS 23

Um den Schritt der Gestaltung einer Web-App zu vereinfachen, existieren unterschied-liche Frameworks.

De�nition 4.4 Im Software-Engineering ist ein Framework ein modernes Rahmenwerk,das dem Programmierer den Entwicklungsrahmen für seine Anwendungsprogrammierungzur Verfügung stellt und damit die Software-Architektur der Anwendungsprogramme be-stimmt. [Gre03]

Dient das Framework der Erstellung einer Internetanwendung spricht man von einemWeb-App-Framework. Diese nutzen die genannten Web-Technologien HTML5, JavaScriptund CSS3. Sie bieten zahlreiche UserInterface (UI) Komponenten und Hilfsfunktionen zurErstellung von Web-Apps, die von nativen Apps kaum unterschieden werden können. Zweiverbreitete Frameworks sind JQuery Mobile und Sencha Touch, die in den folgenden Ab-schnitten näher betrachtet werden.

4.3.4 JQuery Mobile

Bei mobilen Web-Apps muss zwar nur eine Codebasis gep�egt werden, dennoch besitzendie verschiedenen Plattformen Eigenheiten, die bei der Entwicklung berücksichtigt werdenmüssen. Um diese Arbeit zu erleichtern kann das Web-App-Framework JQuery Mobilegenutzt werden. Die jQuery Mobile Foundation de�niert das Framework selbst wie folgt:

A uni�ed, HTML5-based user interface system for all popular mobile deviceplatforms, built on the rock-solid jQuery and jQuery UI foundation [mob].

Das JavaScript-basierte Framework bietet eine einfache Möglichkeit, Web-Apps aufBasis von HTML5 zu erstellen, die auf möglichst vielen Plattformen nutzbar sind. DieUnterstützung von jQuery Mobile für die in Kapitel 3 vorgestellten Plattformen zeigt dieTabelle 4.2. Unterstützungsgrad A bedeutet, dass sämtliche Funktionen unterstützt wer-den, bei Unterstützungsgrad B fehlt die Unterstützung von AJAX. Eine genaue Übersichtüber die unterstützten Plattformen ist auf [mob] zu �nden.

Plattform UnterstützungsgradiOS AAndroid AWindows Phone ABlackBerry ASymbian BBada A

Tabelle 4.2: Plattformunterstützung von jQuery Mobile


4.3.5 Sencha Touch

Sencha Touch ist ebenfalls ein Framework basierend auf Java Script zur Erstellung vonWeb-Applikationen, unterstützt derzeit aber nur Android und iOS [Sen]. Es besitzt einenwesentlich gröÿeren Funktionsumfang im Gegensatz zu jQuery Mobile. Das Frameworkist so aufgebaut, dass praktisch kein HTML und CSS geschrieben wird, sondern nur inJavaScript programmiert wird. Die fertigen HTML-Seiten werden dann von Sencha Touchgeneriert. In der neuesten Version 2.1 unterstützt das Framework auch neue Hardware-APIund Funktionen zur Erstellung von Anwendungen, die wie native Apps auf dem mobilenGerät installiert werden können. Diese sogenannten hybriden Apps werden später nochgenauer betrachtet.

Nachdem nun einige Technologien für die Erstellung von Web-Apps eingeführt wurden,können deren Vor- und Nachteile analysiert werden.

4.3.6 Vor- und Nachteile von Web-Apps

Die Vorteile von Web-Apps liegen in den Entwicklungskosten. Da hier nur mit gebühren-freien Internettechnologien entwickelt wird, beschränken sich die Kosten auf ein Minimum.Hinzu kommt, dass die Technologien bereits vielen Entwicklern bekannt sind und nichterst neu erlernt werden müssen. Die einzige Voraussetzung ist ein Smartphone mit einemBrowser, der HTML5 unterstützt. Da dies aber inzwischen bei vielen Browsern der Fall ist,geben Web-Apps kaum Einschränkungen in der Wahl der Plattform. Zusätzlich existierenFrameworks, welche die Entwicklung erleichtern und viele Möglichkeiten bieten, Web-Appseiner nativen App anzunähern.

Als Nachteil gegenüber einer nativen App ist die fehlende Unterstützung der Hard-und Softwarefunktionen der mobilen Geräte zu sehen. Auÿerdem sind die Web-Apps nurim Internet verfügbar. Sie können weder über einen nativen App-Markt erworben, nochauf dem Gerät installiert werden. HTML5 macht eine O�ine-Nutzung zwar möglich, dieseFunktion ist den meisten Nutzern jedoch nicht bekannt.

Die Entwicklung von Web-Apps ist demnach ein guter Ansatz, besitzt allerdings nocheinige Nachteile. Um sie auszugleichen, wurde ein dritter Ansatz für die Programmierungentwickelt. Hierbei handelt es sich um sogenannte hybride Apps, welche im folgenden Ab-schnitt betrachtet werden.

4.4 Hybride Apps

Hybride Apps sind Anwendungen, die ähnlich den Web-Apps mit Internettechnologienentwickelt wurden, jedoch wie native Apps auf einem Gerät installiert werden können.Damit können die Nachteile von Web-Apps ausgeglichen werden. Eine Nutzung der Hard-und Software eines mobilen Endgerätes wird so ermöglicht. Auÿerdem können die Appsüber native Marktplätze angeboten werden.

4.4. HYBRIDE APPS 25

Für die Entwicklung von hybriden Apps wird ein Framework benötigt, welches ver-schiedene Funktionen bereit stellt. Hierbei lassen sich zwei Arten von Frameworks anhandder genutzten Technik unterscheiden, die Cross-Compiler Frameworks und die WrapperFrameworks. Beide werden im folgenden Abschnitt kurz vorgestellt.

4.4.1 Cross-Compiler Frameworks

Cross-Compiler Frameworks zeichnen sich dadurch aus, dass die Anwendungen in einerWeb-Sprache wie Ruby oder JavaScript entwickelt und anschlieÿend für verschiedene Platt-formen kompiliert werden. Die daraus resultierende Anwendung kann über die nativenMarktplätze verteilt und als native App genutzt werden. Beispiele für solche Frameworkssind Titanium [App] und Rhodes [Sol]. Titanium bietet auÿerdem auch die Möglichkeit, dieApps als Web-Apps zu kompilieren und über das Internet anzubieten. Unterstützt werdenauch hier die Plattformen Android und iOS. Rhodes hingegen bietet die Möglichkeit derWeb-App Programmierung nicht, unterstützt jedoch weit mehr Plattformen.

4.4.2 Wrapper Frameworks

Ein Wrapper Framework kann zur Erweiterung einer Web-App eingesetzt werden. Das be-kannteste Beispiel ist hier das Framework PhoneGap [Phob]. Hierbei handelt es sich um einPlug-In für die native Entwicklungsumgebung eines mobilen Endgerätes. Um PhoneGapzu nutzen, muss zunächst eine Web-App entwickelt werden. PhoneGap bietet anschlie-ÿend die Schnittstelle, um die App in die native Entwicklungsumgebung einzubinden. Diesgeschieht mittels des sogenannten Web Views, eines Browsers, der in einer nativen Appverpackt wird und die Web-App anzeigt. Anschlieÿend kann die Anwendung als native Appvon der Entwicklungsumgebung kompiliert und über native Marktplätze verteilt werden.Dieser Vorgang wird in Abb. 4.2 noch einmal verdeutlicht. Zusätzlich bietet PhoneGapdie Möglichkeit über JavaScript Programmierschnittstellen (APIs) die Hard- und Softwareder mobilen Geräte zu nutzen. PhoneGap wird stetig weiter entwickelt und unterstütztinzwischen eine Vielzahl von Plattformen.

Hybride Apps sind also eine weitere Methode zur Programmierung von mobilen An-wendungen. Der folgende Abschnitt beschreibt die Vor- und Nachteile dieser Methoden.

4.4.3 Vor- und Nachteile von hybriden Apps

Hybride Apps bieten die Vorteile der beiden vorher vorgestellten Methoden. Sie sindwie Web-Apps auf mehreren Plattformen verfügbar, bieten Zugang zu den nativen App-Märkten und gleichzeitig Zugri� auf die Hard- und Softwarekomponenten der mobilenEndgeräte. Allerdings muss beachtet werden, dass nicht jedes Framework alle Plattformenunterstützt. Auÿerdem können nicht immer alle Features eines Smartphones auf jeder ange-botenen Plattform genutzt werden. Es ist notwendig, sich vor Beginn der Programmierungumfassend zu informieren, ob die gewünschte Plattform und Funktion unterstützt wird.


Abbildung 4.2: Entstehung einer nativen App mit PhoneGapQuelle: [Phob]

Allerdings liegen viele der Frameworks noch in einer ersten Version vor und werden per-manent weiter entwickelt, so dass sich die Verfügbarkeit von Plattformen und Funktionenjederzeit ändern kann.

Der Nachteil einer hybriden App gegenüber einer nativen App kann in der Performanceder Anwendung gesucht werden. Apps auf Basis von Webtechnologien bieten nicht immerdie Performance, die eine in der nativen Programmiersprache entwickelte Anwendung zurVerfügung stellt. Grund hierfür ist, dass die nativen Werkzeuge und Technologien speziellauf das mobile Endgerät angepasst sind und somit dessen Hardware und Funktionen bessernutzen können.

4.5 Vergleich der Methoden

Dieses Kapitel hat bisher die drei gängigsten Methoden zur Programmierung von mobilenAnwendungen aufgezeigt. In diesem Abschnitt sollen die unterschiedlichen Herangehens-weisen unter verschiedenen Gesichtspunkten miteinander verglichen werden. Abschlieÿendsoll die Methode, die für die geplante App am besten geeignet erscheint, bestimmt werden.

Wie in Kapitel drei beschrieben, ist eine wichtige Voraussetzung für die Anwendung,dass sie auf möglichst vielen Plattformen verfügbar sein sollte. Dabei wurden die bei-den Kenngröÿen Plattformabdeckung und Portabilität heraus gearbeitet. Daher werden

4.5. VERGLEICH DER METHODEN 27

zunähst die drei Methoden hinsichtlich dieser beiden Kriterien miteinander verglichen. Ei-nige andere Arbeiten haben diesen Vergleich bereits gezogen, [Jas11] beispielsweise hatfestgestellt, dass native Apps eine Plattform, hybride und Web-Apps hingegen die meistengängigen Plattformen unterstützen.

Diese Di�erenzierung ist jedoch relativ unpräzise, da auch innerhalb der einzelnen dreiBereiche genauere Betrachtungen nötig sind. Web-Apps beispielsweise funktionieren dankHTML5 zwar auf den meisten Geräten, nicht jeder Browser hat jedoch jeden HTML5-Standard implementiert, zumal sich HTML5 selbst noch in der Entwicklung be�ndet. Dazukommt, dass auch bei Web-Apps das Bestreben existiert, die App dem nativen Designdes Gerätes anzupassen. Zu diesem Zweck existieren zwar Frameworks, welche die Arbeiterleichtern, diese unterstützen jedoch nicht immer alle verfügbaren Plattformen. Ähnlichverhält es sich bei den Frameworks für hybride Apps. PhoneGap beispielsweise unterstütztbereits die meisten Plattformen, Titanium hingegen nur iOS und Adroid. Aus diesemGrund sollen hier die verschiedenen vorgestellten Technologien einzeln verglichen werdenund nicht auf die drei Bereiche native, Web- und hybride App reduziert werden.

4.5.1 Plattformabdeckung

Die Plattformabdeckung nativer Apps beschränkt sich lediglich auf ein Plattform. Da derCode in einer eigenen nativen Entwicklungsumgebung und einer speziellen Programmier-sprache entwickelt werden muss, kann er auf keinem anderen mobilen Gerät als dem, fürdas er entwickelt wurde, genutzt werden. Deshalb beträgt die Plattformabdeckung bei na-tiven Apps unabhängig von der zur Entwicklung genutzten Plattform immer 1/6 = 16Prozent.

Bei Web-Apps muss zwischen den unterschiedlichen Frameworks di�erenziert werden.Hier wurden Sencha Touch und jQuery Mobile als Beispiele gewählt. Anwendungen, diemittels jQuery Mobile geschrieben wurden, funktionieren auf allen der vorgestellten Platt-formen. Einzige Ausnahme ist die Nutzung von AJAX unter Symbian, aus diesem Grundbekommt jQuery Mobile für Symbian nur die Hälfte der Punkte. Daraus ergibt sich einePlattformabdeckung von 5,5/6 = 96 Prozent. Sencha Touch hingegen unterstützt lediglichAndroid und iOS, daraus resultiert eine Plattformabdeckung von 2/6 = 33 Prozent.

Für die Entwicklung von hybriden Apps gibt es ebenfalls verschiedene Frameworks, dieeinzeln betrachtet werden müssen. Titanium unterstützt ledigliche Android und iOS, erhältdamit ebenfalls eine Plattformabdeckung von 2/6 = 33 Prozent, Rhodes hingegen iOS,Android, Windows Phone und Blackberry und erzielt damit eine Plattformabdeckung von4/6 = 67 Prozent. Das Wrapper Framework PhoneGap unterstützt jede der vorgestelltenPlattformen und erreicht damit die maximale Plattformabdeckung von 100 Prozent.

Tabelle 4.3 gibt noch einmal einen Überblick zur Plattformabdeckung der unterschiedli-chen Technologien. Es lässt sich erkennen, dass lediglich PhoneGap die volle Unterstützungfür alle Plattformen bietet und daher zur Entwicklung einer Anwendung, die auf möglichstvielen Geräten verfügbar sein soll, favorisiert werden sollte.


Technologie Plattformabdeckung in Prozentnativ 16sencha touch 33Titanium 33Rhodes 67jQuery Mobile 92PhoneGap 100

Tabelle 4.3: Plattformabdeckung der unterschiedlichen Technologien

Von vielen Technologien werden zwar unterschiedliche Plattformen unterstützt, es stelltsich jedoch die Frage nach dem nötigen Aufwand, um den geschriebenen Code auf allenunterstützten Plattformen lau�ähig zu machen.

4.5.2 Portabilitätsaufwand

Der Portabilitätsaufwand ist lediglich eine Schätzgröÿe abhängig von der konkreten Ursprungs-und Zielumgebung [Rot87]. Auf Betriebssystemebene sind dabei die Entwicklungsumge-bung, die Programmiersprache und das Design ausschlaggebend (vgl. Kapitel 3.3 zur Por-tabilität). In dieser Arbeit wird der Anpassungsaufwand in die folgenden Kennzi�ern un-terteilt:

- Einarbeitungsaufwand in eine neue Programmiersprache

- Einarbeitungsaufwand in eine neue Entwicklungsumgebung

- Überarbeitungsaufwand für das Design

Eine 1 wird vergeben, wenn ein gröÿerer Aufwand nötig ist und eine 0 bei keinem odernur geringem Aufwand. Der Übertragungsaufwand ist entweder 1, bei Anwendungen dieneu kompiliert und auf ein mobiles Gerät transportiert werden müssen oder 0, falls diesnicht nötig ist. Eine Neuentwicklung entspricht einem maximalen Aufwand und beträgtsomit 4. Wendet man die in Kapitel 3.3 beschriebene Formel an, ergibt sich eine Portabilitätvon 0 bis 1, wobei 0 eine gute Portierbarkeit des Programmes darstellt, bei 1 hingegen lässtsich die Anwendung nicht portieren. Nachfolgend wird die Portabilität für alle Arten vonApps geprüft.

Da native Apps lediglich ihre eigene Plattform abdecken, ist der Aufwand eine An-wendung auf eine andere Plattform zu portieren im Allgemeinen bei allen nativen Anwen-dungen der gleiche. Die einzige Möglichkeit die Anwendung auf einer anderen Plattformverfügbar zu machen ist demnach, sie völlig neu zu programmieren. Daraus ergibt sich eineminimale Portabilität von 0.

Reine Web-Anwendungen, die lediglich HTML5, Javascript und CSS3 nutzen und überdas Internet angeboten werden, können auf jeder Plattform mit Browser gleichermaÿen

4.5. VERGLEICH DER METHODEN 29

genutzt werden. Sie müssen nur einmal entwickelt werden und können dann wie eine Web-site auf jedem mobilen Endgerät aufgerufen werden. Da man bei einer Website auch nichterwartet, dass sie im Design an das Gerät angepasst ist, sind auch hier keine Änderungennötig. Es entsteht also kein Aufwand bei der Portierung auf ein anderes Gerät und damiteine maximale Portabilität.

Anders sieht es aus, wenn ein Framework benutzt wird. Bei Sencha Touch wird die An-wendung in JavaScript geschrieben, das Framework generiert daraus anschlieÿend HTMLund CSS. Diese Web-Apps kann man zwar auf jedem Gerät anbieten, das Design wirdvom Framework allerdings für Android und iOS angepasst. Will man das Design für einanderes Gerät anbieten, muss der HTML5- und CSS-Code manuell überarbeitet werden.Daraus ergibt sich für die Designanpassung ein Aufwand von 1. Entwicklungsumgebungund Programmiersprache bleiben jedoch gleich. Die Portabilität für diese Anwendungenliegt bei 0,75, was einer sehr hohen Portabilität entspricht.

Bei hybriden Apps gibt es unterschiedliche Frameworks, die unterschiedliche Betriebs-systeme unterstützen. Bei den Cross-Compiler Frameworks Rhodes und Titanium kannder Code für verschiedene Plattformen kompiliert werden, allerdings nicht für alle. Hiermuss also unterschieden werden, ob nur die unterstützten Plattformen genutzt werdensollen oder alle. Im ersten Fall muss der Code nur einmal geschrieben und dann nur un-terschiedliche kompiliert werden, die Portabilität liegt demnach bei 0,75, da lediglich derÜbertragungsaufwand 1 beträgt. Will man alle Plattformen einsetzen, muss man für dienicht unterstützten zwangsweise eine neue Anwendung schreiben. Daraus ergibt sich wie-derum eine minimale Portabilität von 0.

Beim Wrapper-Framework PhoneGap ist die Anwendung anders als bei den Cross-Compiler Frameworks. Hier wird der Code in HTML geschrieben und mit Javascript werdenweitere Funktionen, um native Hard- und Software zu nutzen, hinzugefügt. Zur Übertra-gung der Anwendung auf ein mobiles Endgerät wird die native Entwicklungsumgebungmit einem Plug-In erweitert. Eine Einarbeitungszeit für die nativen Entwicklungsumge-bungen muss demnach berechnet werden. Die native Programmiersprache zu erlernen istjedoch nicht zwingend notwendig. Zur Übertragung muss für jede Plattform eine hybrideApp kompiliert werden. Zusätzlich müssen Designänderungen für jede Plattform manuellvorgenommen werden, da von einer hybriden App ein natives Aussehen erwartet wird. DiePortabilität liegt demnach bei 0,25, ist daher verhältnismäÿig gering.

Tabelle 4.4 gibt noch einmal einen Überblick über die Portabilität der einzelnen Ent-wicklungsmöglichkeiten für Apps.

4.5.3 Performance

Neben der Plattformabdeckung und der Portabilität muss auch die Performance der un-terschiedlichen Technologien berücksichtigt werden.

[Pat11] hat einen Performance Vergleich zwischen reinen Web-Anwendungen, nativenAnwendungen und Anwendungen, die mit Hilfe des Web-Frameworks PhoneGap erstellt


Technologie Portabilitätnativ 1PhoneGap 0,25Titanium 0,75/0Rhodes 0,75/0jQuery Mobile 0,75sencha touch 0,75

Tabelle 4.4: Portabilität der mit unterschiedlichen Technologien entwickelten Anwendungen

wurden, gezogen. Hierfür hat er verschiedene Programme mit allen drei Möglichkeiten er-stellt und auf einem mobilen Gerät mit Android Betriebssystem laufen lassen. Dabei solltenfolgende Dinge getestet werden: die Performance bei der Ausführung einfacher Algorith-men (in diesem Fall dem Fibonacci Algorithmus), die Performance bei der Ausführung vonGra�koperationen (hier dem Zeichnen von einfachen Kreisen) und die Performance bei derAusführung von Datenbankabfragen, insbesondere der Speicherung von Daten. Zusätzlichhat er auch ein Augenmerk auf die Möglichkeit des Zugri�s auf die spezi�schen Hardwa-refeatures der mobilen Geräte gelegt, was für die hier geplante Anwendung ebenfalls zuberücksichtigen ist, da die Nutzung der Kamera zu den Anforderungen an die App gehört.

[Pat11] hat bei jedem Test dem Gerät eine Wertung zwischen 1 und 3 bekommen, 1als beste Bewertung und 3 als Schlechteste. Bei diesen Tests hat sich ergeben, dass dieeinzige Performance-Schwäche von PhoneGap in der Darstellung von Gra�ken liegt. DieWerte lagen bei allen drei Varianten allerdings sehr nah beieinander. Tabelle 4.5 zeigt dieErgebnisse zusammen gefasst. Aufgrund der Aktualität der Arbeit ist diese als Grundlagefür den Performancevergleich ausreichend.

Technologie Algorithmus Gra�k Datenbank Hardwarezugri�nativ 3 1 1 JaPhoneGap 1 2 1 JaHTML5 2 2 1 Nein

Tabelle 4.5: Performance der mit unterschiedlichen Technologien entwickelten Anwendun-gen

4.6 Auswahl einer Technologie

Nachdem die unterschiedlichen Technologien miteinander verglichen wurden, kann die be-vorzugte für die geplante App ausgewählt werden. Besonders wichtig ist hierbei die Ge-währleistung eine maximale Plattformabdeckung. Unter diesem Gesichtspunkt scheint dieEntwicklung einer hybriden App mit Hilfe des Wrapper Frameworks PhoneGap die geeig-netste Methode. Eine reine Web-App zu entwickeln ist aufgrund der mangelnden Kame-raunterstützung nicht möglich. Bei nativen Apps ist der Aufwand, der für eine maximalePlattformabdeckung vorgenommen werden muss zu groÿ.

4.6. AUSWAHL EINER TECHNOLOGIE 31

Da bei der Anwendung keine Graphiken verarbeitet werden, sondern vielmehr die Da-tenspeicherung ein sehr wichtiger Punkt ist, scheint im Hinblick auf die Performance Pho-neGap ebenfalls eine gute Wahl zu sein. Die Kameraunterstützung wird zusätzlich gewähr-leistet. Lediglich im Hinblick auf die Portabilität ist PhoneGap als eher schwah einzustufen.Um diesen Schwachpunkt zu umgehen, soll der HTML5 und CSS3 Code mit Hilfe einesWeb-App-Frameworks entwickelt werden. So entfällt für PhoneGap die Design-Anpassung.Die JavaScript Funktionalitäten zur Datenspeicherung und zur Nutzung der Kamera wer-den mit PhoneGap anschlieÿend hinzugefügt. Die Anwendung soll im Rahmen dieser Arbeitnur für Android und Windows Phone kompiliert werden, um die Plattformunabhängigkeitvon PhoneGap in diese Richtung zu testen.

Neben der Auswahl der Technologie zur Entwicklung der Anwendung ist die Auswahleiner Speichermethode wichtig. Das folgende Kapitel stellt die für HTML5-Anwendungengeläu�gsten Methoden zur Speicherung der Daten vor und tri�t eine Auswahl der geeig-netsten Methode.

Kapitel 5

Datenspeicherung

Für die Anwendung ist es nötig, dass die im Rahmen einer Ausgrabung aufgenommenenBefunddaten gespeichert werden können. Für diese Speicherung lassen sich in der Doku-mentation des W3C einige Ansätze �nden, die im Folgenden beschrieben werden. Da imvorherigen Kapitel die Entwicklung einer hybriden App mittels Web-Technologien gewähltwurde, müssen die Möglichkeiten dieser Technologien hinsichtlich der Speicherung von Da-ten berücksichtigt werden.

Mit HTML5 werden einige interessante Neuerungen hinsichtlich der Client-seitigenSpeicherung von Daten eingeführt. Diese lassen sich in zwei unterschiedliche Systeme eintei-len, das Web Storage und die Erstellung von Web SQL Datenbanken [Hog11]. Eine weitereArt der Datenspeicherung auf dem Client wurde von Mozilla mit der sogenannten IndexedDatabase API eingeführt [Hog11]. Auf diese drei Speichermethoden wird im Folgendeneingegangen. Anschlieÿend wird die für die Anwendung passende Methode ermittelt.

5.1 Web Storage

Die Web-Storage API wurde aus HTML5 ausgegliedert, fällt aber trotzdem in das Umfeldvon HTML5 und wird daher vom W3C als Neuerung von HTML5 spezi�ziert [FÖ11]. DieBeschreibung der API lautet in der Spezi�kation wie folgt:

This speci�cation de�nes an API for persistent data storage of key-valuepair data in Web clients [W3Ce].

Es handelt sich also um eine API mit der einfache Schlüssel-Wert Paare dauerhaft beimClient gespeichert werden sollen. Hierbei werden vom W3C zwei verschiedene Speicherty-pen angeboten, sessionStorage und localStorage. Unabhängig vom Speichertyp ist für WebStorage eine maximale Datenmenge von 5 MB zulässig. Diese kann beliebig erweitert wer-den, benötigt dazu jedoch die Zustimmung des Nutzers [LS11]. Browser, welche die APIunterstützen, sind Google Chrome, Firefox, Opera, Safari, mobile Safari und alle Browser,die für Geräte mit dem Betriebssystem Android verfügbar sind. [Hog11].

32

5.2. WEB-SQL DATENBANKEN 33

Das �Storage-Interface� stellt verschiedene Methoden zur Verfügung, um eine Listevon Schlüssel-Wert-Paaren abhängig von der Domäne zu erstellen. Laut Spezi�kation sindsowohl die Schlüssel als auch die Werte Strings von beliebiger Länge, einschlieÿlich desleeren Strings. Das Speichern von komplexen Datentypen, wie beispielsweise Arrays, er-fordert daher eine Umwandlung des Datentyps in einen String [FÖ11]. Die Unterschiedezwischen sessionStorage und localStorage liegen in der Haltbarkeit sowie der Verfügbarkeitder gespeicherten Daten.

Listen von Schlüssel-Wert-Paaren, die mit dem Attribut sessionStorage gespeichert wer-den, stehen nur dem Browserfenster zur Verfügung, in dem sie gespeichert werden. Dasbedeutet, dass die Daten verloren gehen, sobald das Fenster geschlossen wird. Wird einneues Fenster von der gleichen Domäne aufgerufen, kann nicht auf die Daten zugegri�enwerden [LS11].

Werden die Daten hingegen mit dem Attribut localStorage gespeichert, sind sie abhän-gig von der Domäne. Sie können in allen Fenstern, die von dieser Domäne geö�net werdenabgerufen werden. Darüber hinaus bleiben die Daten auch nach Sitzungsende erhalten. Siewerden so lange gespeichert, bis sie vom Nutzer gelöscht werden [LS11].

Mit WebStorage lassen sich Daten in Form von Schlüssel-Wert-Paaren speichern, dieBeschränkung des Datentyps auf Strings macht das Speichern von komplexen Datentypenjedoch sehr aufwendig. Aus diesem Grund wurde zusätzlich die Möglichkeit gescha�en,eine Web-SQL-Datenbank auf dem Client anzulegen und zu verwalten. Diese Web-SQLDatabase API wird im nächsten Abschnitt beschrieben.

5.2 Web-SQL Datenbanken

Eine weitere Möglichkeit Daten auf dem Client zu speichern, die HTML5 bietet, sind diesogenannten Web SQL Datenbanken [LS11]. Auch hierfür existiert eine Spezi�kation desW3C, in der die Speichermethode beschrieben wird:

This speci�cation de�nes an API for storing data in databases that can bequeried using a variant of SQL [W3Cd].

In der Spezi�kation wird die API genauer beschrieben, zusammengefasst handelt essich um eine Möglichkeit, Daten mittels der Structured Query Language (SQL) innerhalbeiner lokalen relationalen Datenbank zu speichern.

De�nition 5.1 Eine Datenbank (Datenbank-Managementsystem) ist ein System zur Spei-cherung und Verwaltung groÿer Datenmengen [Gre03].

Jede Datenbank besitzt dabei eine Datenbasis, die auf verschiedene Weisen organisiertsein kann:

- in Form von Tabellen bestehend aus Datensätzen und Feldern

34 KAPITEL 5. DATENSPEICHERUNG

- hierarchisch in einer Art Baumstruktur

- in vernetzter Form

- oder als Objekte.

Bei einer relationalen Datenbank werden die Daten in Tabellen gespeichert, welchedurch Relationen miteinander verbunden werden. Das Modell dient vor allem der e�zientenSpeicherung der Daten, insbesondere der Vermeidung von Redundanzen [Gre03].

Die Web-SQL Datenbank API nutzt solch ein relationales Datenbanksystem. Die Ma-nipulation der Daten erfolgt dabei mit SQL-Befehlen. Diese werden hierbei in einem Stringverpackt und mittels JavaScript ausgeführt [Pil11].

Auch hier gibt HTML5 keine Speichergröÿe für die Datenbank vor, Einschränkungenwerden lediglich durch den Browser getätigt. Bei Überschreitung der maximalen Speicher-gröÿe des Browser wird der Nutzer ebenfalls um Zustimmung gefragt [LS11].

Der groÿe Nachteil an der Web SQL Datenbank API liegt darin, dass sie vom W3Caufgegeben wurde und derzeit nicht weiter entwickelt wird. Eine Weiterentwicklung innaher Zukunft ist ebenfalls nicht vorgesehen, wie auf der Seite des W3C angegeben wird[W3Cd]. Trotzdem wurde die API von vielen Browserentwicklern bereits implementiert,insbesondere den auf WebKit basierenden mobilen Browsern [Krö11]. Aus diesem Grund istdamit zu rechnen, dass sie auch in zukünftigen Versionen der Browser noch implementiertsein wird, wie lange sich die API noch verwendet werden kann, lässt sich nicht abschätzen.

Um dennoch die Möglichkeit einer strukturierten Datenspeicherung zu gewährleisten,die über ein simples Key-Value-Verfahren hinaus geht, wurde vom W3C auf Initiativevon Mozilla eine neue API entworfen, die sogenannte IndexedDB API, die im folgendenAbschnitt behandelt werden soll.

5.3 IndexedDB

Nachdem die Arbeit an der Web-SQL Datenbank API eingestellt wurde, legte Mozilla demW3C den Entwurf einer neuen Datenbank API für HTML5, der sogenannten IndexedDBAPI, vor. Diese be�ndet sich derzeit in der Entwicklung und ist bisher in nur wenigenBrowsern implementiert, wie Abb. 5.1 zeigt.

Da auf diesem Gebiet aufgrund der wenig fortgeschrittenen Unterstützung kaum Lite-ratur existiert, soll die API an dieser Stelle nur kurz erläutert werden. Die Spezi�kationder API vom W3C lautet wie folgt:

This document de�nes APIs for a database of records holding simple values andhierarchical objects. Each record consists of a key and some value. Moreover,the database maintains indexes over records it stores. An application developer

5.4. AUSWAHL EINER SPEICHERMETHODE 35

Abbildung 5.1: Browsersupport für die Speicher APIs[dev11]

directly uses an API to locate records either by their key or by using an index.A query language can be layered on this API. An indexed database can beimplemented using a persistent B-tree data structure [W3Cc].

IndexedDB speichert Daten im Gegensatz zur Web-SQL Datenbank nicht in starrenTabellen, sondern verwendet hierfür Objekte in einem Key-Value-Speicher. Zusätzlich wer-den verschiedene Funktionen geboten, um auf die Inhalte dieser Objekte zuzugreifen, wiebeispielsweise Cursor und Indizes [Krö11]. Änderungen am Objektspeicher werden überTransaktionen abgewickelt [Pil11].

5.4 Auswahl einer Speichermethode

Aus den beschriebenen drei Möglichkeiten zur Datenspeicherung in HTML5, soll nun diefür die Anwendung passende ausgewählt werden.

Da die IndexedDB API noch kaum implementiert ist, scheidet sie als Speichermög-lichkeit aus. Für die Anwendung ist es auÿerdem nötig, dass zwischen den Daten Bezie-hungen hergestellt werden können. So sollen einer Ausgrabung Mitarbeiter zugeteilt wer-den, wobei ein Mitarbeiter auf mehr als einer Grabung gleichzeitig arbeiten kann. Solchem-n-Beziehungen lassen sich mit einfachen Schlüssel-Wert-Paaren nur sehr umständlich

36 KAPITEL 5. DATENSPEICHERUNG

darstellen. Die Web-SQL Datenbank API bietet diese Funktionalität und ist daher, trotzfehlender Weiterentwicklung, die passende Methode. Hinsichtlich der Entwicklung weg vonWeb SQL hin zu IndexedDB muss die Datenspeicherung, sobald die Implementierung derIndexedDB weiter vorangeschritten ist, überarbeitet werden.

Nachdem nun die Methoden zur Entwicklung der App und der Speicherung der Datenausgewählt und die wichtigsten Anforderungen beschrieben wurden, befassen sich die bei-den folgenden Kapitel mit der Programmierung der Anwendung. Kapitel sechs fasst nocheinmal die gewählten Methoden zusammen und skizziert den Entwurf der Anwendung.Kapitel sieben beschreibt die wichtigsten Merkmale der Implementierung der Anwendungsowie dabei entstehende Probleme.

Kapitel 6

Systementwurf

Bevor mit der Entwicklung der Anwendung begonnen werden kann, soll sie in diesem Ka-pitel zunächst entworfen werden. Die Implementation wird anschlieÿend in Kapitel siebenbeschrieben. Zunächst werden die Zielrichtung der App als Grundlage für den Entwurf for-muliert sowie die ermittelten zu nutzenden Methoden und Technologien zusammengefasst.

6.1 Zielrichtung

In Kapitel 2.2 wurde der beispielhafte Ablauf einer Ausgrabung beschrieben. Aufbauenddarauf wird die Zielrichtung der Anwendung beschrieben. Die App soll die Dokumentationder Befunde erleichtern. Der erste Schritt der Dokumentation ist dabei die Vergabe einerBefundnummer, nachdem der entsprechende Befund identi�ziert wurde. Diese Befundnum-mernvergabe soll durch die Anwendung automatisiert werden und als Funktionalität demGrabungsleiter zur Verfügung stehen.

Die anschlieÿende Dokumentation des Befundes gliedert sich in verschiedene Schritte.Dazu gehören die schriftliche, die zeichnerische sowie die fotogra�sche Dokumentation unddie Entnahme von Proben. Diese einzelnen Schritte sollen durch die App für den Gra-bungsassistenten automatisiert werden. Hierzu müssen Funktionalitäten zur Vergabe vonProbennummern, zur Aufnahme von Fotogra�en und zur Eingabe von wichtigen Infor-mationen vorhanden sein. Zusätzlich müssen die innerhalb des Befundes getätigten Fundeverzeichnet werden können. Hierfür ist ebenfalls eine Funktionalität zur Vergabe von Fund-nummern unverzichtbar. Die so gesammelten Daten sollen anschlieÿend gesichert werden.Daraus resultierend soll von der App demnach nach erfolgreichem Abschluss einer Ausgra-bung eine vollständige Dokumentation der Befunde zur Verfügung gestellt werden.

Für die Umsetzung der Zielsetzung stehen verschiedene Technologien und Techniken zurVerfügung. In den letzten Kapiteln wurden diese analysiert und die für die Umsetzung derAnforderungen geeignetsten ausgewählt. Dabei hat sich ergeben, dass eine Hybrid-App mitHilfe von HTML5, CSS3 und JavaScript entwickelt werden soll. Der HTML5 Code wirdmit Hilfe des Web-App Frameworks JQuery Mobile entwickelt. Mit Hilfe des WrapperFrameworks PhoneGap werden JavaScript Funktionalitäten hinzugefügt. Die Anwendung

37

38 KAPITEL 6. SYSTEMENTWURF

kann dank PhoneGap anschlieÿend für mehrere unterschiedliche Plattformen kompiliertwerden. Die Datenhaltung erfolgt dabei in einer Web-SQL Datenbank.

Es hat sich ergeben, dass für die beiden Benutzergruppen Grabungsleiter (GL) und Gra-bungsassistent (GA) unterschiedliche Funktionen bereitgestellt werden müssen. Daher istdas Kapitel unterteilt in vier Unterabschnitte. Zuerst werden Funktionalitäten beschrie-ben, die beide Nutzergruppen benötigen. Im zweiten und dritten Abschnitt werden dieunterschiedlichen Teilanwendungen für die Grabungsleiter und die Grabungsassistentenentworfen. Im letzten Abschnitt wird die der Anwendung zu Grunde liegende Datenbankmodelliert.

6.2 Funktionalitäten für beide Nutzergruppen

Nachdem die Anwendung gestartet wurde, muss sich jeder Benutzer zunächst anmelden,unabhängig davon, ob er als GL oder GA arbeiten will. Zu diesem Zweck wird jedem Benut-zer ein Nutzername sowie ein Passwort zugewiesen, welche er bei der Anmeldung angebenmuss (Abb. 6.1). Wird die Anwendung erstmalig gestartet, muss sich ein Grabungsleitermit einem default-Passwort anmelden. Dieses kann anschlieÿend geändert werden. Der GLkann nun neue Nutzer hinzufügen und damit auch die Anmeldung als GA ermöglichen. Fürdie Anmeldung hat der Nutzer allerdings nur drei Versuche. Wird das Passwort mehrmalsfalsch eingegeben, wird die Anwendung beendet und gesperrt. Anschlieÿend kann sie nurvon einem GL entsperrt werden.

Nach einer erfolgreichen Anmeldung muss der Anwender zunächst auswählen, ob er dieAnwendung als Grabungsleiter oder als Grabungsassitent nutzen will (Abb. 6.2).

Zu diesem Zweck muss zunächst eine Auswahlmöglichkeit zur Verfügung gestellt wer-den. Hierbei soll das Programm die Möglichkeit, sich als Grabungsleiter anzumelden, nurden Nutzern zur Verfügung stellen, die in der Datenbank als Grabungsleiter eingetragensind. Die Auswahlmöglichkeit sich als GA anzumelden soll allen Benutzern zur Verfügungstehen. Die beschriebenen Vorgänge werden in Abb. 6.3 noch einmal skizziert.

6.3 Funktionalitäten für den Grabungsleiter

Ein Grabungsleiter soll die Anwendung insbesondere zur Verwaltung der Mitarbeiter, derAusgrabungen sowie der Befunde nutzen. Daraus ergeben sich drei Grundfunktionalitäten,die von der Anwendung zur Verfügung gestellt werden müssen (Abb. 6.4).

Hierbei muss jedoch wiederum unterschieden werden zwischen einem übergreifendenGrabungsleiter und einem Leiter für bestimmte Grabungen. Die Verwaltung der Befundesoll sowohl für den übergreifenden Grabungsleiter als auch für den Leiter der Grabung,der die Befunde zugeordnet werden, möglich sein. Alle anderen Funktionen stehen nurdem übergreifenden Grabungsleiter zur Verfügung. Zur Synchronisation der Daten mitden Grabungsassistenten hat der Grabungsleiter auÿerdem die Möglichkeit, die Daten in

6.3. FUNKTIONALITÄTEN FÜR DEN GRABUNGSLEITER 39

Abbildung 6.1: LoginbildschirmQuelle: eigene Abbildung


Abbildung 6.2: Auswahl zwischen GL und GAQuelle: eigene Abbildung


Abbildung 6.3: EPK für einen AnmeldevorgangQuelle: eigene Abbildung

einer Datei auf dem jeweiligen Gerät zu speichern. Diese kann anschlieÿend von den Gra-bungsassistenten empfangen werden.

6.3.1 Mitarbeiter verwalten

Der Grabungsleiter soll die Möglichkeit erhalten, die Mitarbeiterdaten zu p�egen. Dazugehören die folgenden Anwendungsfälle (Akteur ist in allen Anwendungsfällen der über-greifende Grabungsleiter):

Nummer Name Beschreibung001 Mitarbeiter

erstellenEs wird ein neuer Mitarbeiter mit Name, Nut-zername und Passwort angelegt. Zusätzlich wirdfestgehalten, ob es sich um einen übergreifendenGrabungsleiter handelt.

002 Mitarbeiterbearbeiten

Name, Nutzername und Passwort bestehenderMitarbeiter können geändert werden.

003 Mitarbeiterlöschen

Bestehende Mitarbeiter können gelöscht werden,es sei denn, sie sind als übergreifender Grabungs-leiter eingetragen.

Tabelle 6.1: Anwendungsfälle Mitarbeiter verwalten

Die Ober�äche soll dabei aus einer Liste aller Mitarbeiter bestehen. Um die Daten einesMitarbeiters zu bearbeiten, muss er lediglich in der Liste ausgewählt werden. Schalt�ächenzum Löschen und Bearbeiten der Mitarbeiter müssen ebenfalls vorhanden sein (Abb. 6.5).


Abbildung 6.4: Hauptmenü für den GrabungsleiterQuelle: eigene Abbildung


Für neu angelegte Mitarbeiter werden ein Nutzername, ein Passwort sowie ein Vermerk,ob der Nutzer Administratorrechte erhalten soll, angegeben (Abb. 6.6).

Abbildung 6.5: Menü zum Verwalten der MitarbeiterQuelle: eigene Abbildung

6.3.2 Grabungen verwalten

Eine weitere Funktionalität, die nur vom übergreifenden Grabungsleiter genutzt werdenkann, ist die Verwaltung der Ausgrabungen. Dabei müssen folgende Anwendungsfälle ab-gedeckt werden:

Das Menü soll dabei analog dem Menü zum Verwalten der Mitarbeiter aufgebaut sein.Beim Anlegen einer Ausgrabung soll neben der ID, einer Bezeichnung sowie dem Zeitraumder Ausgrabung zusätzlich eine Liste der teilnehmenden Mitarbeiter angelegt werden kön-nen (Abb. 6.7).


Abbildung 6.6: Menü um einen neuen Mitarbeiter anzulegenQuelle: eigene Abbildung

Nummer Name Beschreibung004 Ausgrabung

erstellenEine neue Ausgrabung kann erstellt werden. Dazugehört ein Kürzel für die Grabung, eine Bezeich-nung, sowie ein Start- und ein Enddatum.

005 Ausgrabungbearbeiten

Daten einer Ausgrabung können bearbeitet wer-den.

006 Ausgrabunglöschen

Eine bestehende Ausgrabung kann gelöscht wer-den

007 Mitarbeiterzuweisen

Ein Mitarbeiter kann einer bestehenden Grabungentweder als GA oder GL zugewiesen werden.

Tabelle 6.2: Anwendungsfälle Ausgrabungen verwalten


Abbildung 6.7: Menü zum Anlegen einer neuen Ausgrabung


6.3.3 Befunde verwalten

Bevor Befunde bearbeitet werden, muss im Hauptmenü zunächst die zuvor angelegte Aus-grabung ausgewählt werden (Abb. 6.8).

Abbildung 6.8: Menü zum Wählen einer Grabung und anschlieÿenden Bearbeitung derBefunde

Quelle: eigene Abbildung

Die Funktionalitäten zur Verwaltung der Befunde können sowohl vom übergreifendenGrabungsleiter als auch vom der entsprechenden Ausgrabung zugewiesenen Grabungsleitergenutzt werden. Folgende Anwendungsfälle ergeben sich dabei (Tabelle 6.3)

Das Menü soll äquivalent zu den Menüs �Mitarbeiter bearbeiten� und �Ausgrabungbearbeiten� aufgebaut sein. Beim Anlegen eines neuen Befundes wird automatisch eineNummer für diesen Befund ermittelt. Anschlieÿend können eine kurze Beschreibung zum


Nummer Name Beschreibung008 Befund er-

stellenBefunde für eine bestimmte Ausgrabung, die vor-her ausgewählt wird, können mit einer Befund-nummer angelegt werden. Auÿerdem kann ihnenein GA als Bearbeiter zugeordnet werden.

009 Befund be-arbeiten

Ein bestehender Befund kann bearbeitet werden

010 Befund lö-schen

Ein bestehender Befund kann gelöscht werden

Tabelle 6.3: Anwendungsfälle Befunde verwalten

Befund sowie der Bearbeiter eingegeben werden.

Die Verknüpfung der Anwendungsfälle wird im Use-Case Diagramm in Abb. 6.9 auf-gezeigt. Eine Funktionalität zum Bearbeiten der Befunde ist für die Grabungsleiter nichtvorgesehen, da diese nur von Grabungsassistenten bearbeitet werden. Die dafür nötigenAnwendungsfälle werden im folgenden Abschnitt beschrieben.

Abbildung 6.9: Use-Case Diagramm der Anwendungsfälle der GLsQuelle: eigene Abbildung


6.4 Funktionalitäten für den Grabungsassistenten

Die Verwaltungsfunktionen werden nur vom Grabungsleiter ausgeführt, daher stehen demGrabungsassistenten lediglich Funktionen zur Bearbeitung der Befunde zu Verfügung. Hier-für ist es nötig, dass die Endgeräte der Grabungsassistenten eine Verbindung zum Endgerätdes Grabungsleiters aufbauen können, um Daten auszutauschen. So kann ein Grabungsas-sistent die für ihn zu bearbeitenden Befunde ermitteln, dokumentieren und anschlieÿendan das Endgerät des Grabungsleiters zurück geben. Daraus resultieren die folgenden An-wendungsfälle für Grabungsassistenten:

Nummer Name Beschreibung011 Verbindung

zum GLaufbauen

Eine Verbindung zwischen den Endgeräten desGAs und des GLs wird aufgebaut.

012 Befunde er-mitteln

Vom GA zu bearbeitende Befunde müssen ermit-telt werden (Setzt 011 voraus). Speichert die lee-ren Befunde in einer lokalen Datenbank.

013 Befund be-arbeiten

Einen leeren Befund auswählen und die nötigenDaten eingeben. Anschlieÿend wird der Befundlokal gespeichert

014 Foto hinzu-fügen

Ö�net die native Kameraanwendung und ermög-licht das Aufnehmen eines Fotos, welches anschlie-ÿend an den Befund angehängt wird.

015 Bodenprobehinzufügen

Eine Bodenprobennummer generieren und an denBefund anhängen.

016 Fund hinzu-fügen

Eine Fundnummer generieren und an den Befundanhängen.

017 Daten anGL senden

Fertiggestellte Befunde sollen an den GL gesendetwerden (setzt 011 voraus)

Tabelle 6.4: Anwendungsfälle für den GA

In den Anwendungsfällen von 013 - 015 sollen die angefügten Bodenproben, Fotos undFunde auch entfernt werden können. Die Verknüpfung der Anwendungsfälle wird im Use-Case Diagramm in Abb. 6.10 aufgezeigt. Eine beispielhafte Verwendung der Anwendung istin Abb. A.1 im Anhang A dargestellt. Die Beschreibung der Anwendungsfälle hat gezeigt,dass für beide Anwendungsbereiche eine Datenbank zur Datenhaltung Voraussetzung ist.Diese soll im folgenden Abschnitt beschrieben werden.

6.5 Datenhaltung

In Kapitel fünf wurde zur Datenhaltung die Erstellung einer Web-SQL Datenbank imBrowser ausgewählt. Hierbei muss wiederum zwischen den Funktionalitäten für Grabungs-leiter und Grabungsassistenten unterschieden werden. Da die Grabungsassistenten jedoch

6.5. DATENHALTUNG 49

Abbildung 6.10: Use-Case Diagramm der Anwendungsfälle der GAQuelle: eigene Abbildung


eine Teildatenbank der Grabungsleiter nutzen, wird hier nur die Datenbank der Grabungs-leiter beschrieben. Tabellen, die ebenfalls beim Grabungsassistenten zur Verfügung stehenmüssen, werden als solche gekennzeichnet.

Abbildung 6.11: ER-Modell für die DatenbankQuelle: eigene Abbildung

Für die Anwendung müssen verschiedenen Daten in einer Datenbank gespeichert wer-den. Abb. 6.11 zeigt ein ER-Modell für die Datenbank. Als Ausgangsbasis für die Da-tenbank existieren zwei Entitäten mit grundlegenden Daten, eine für die Benutzer derAnwendung und eine für die Ausgrabungen.

Jeder Benutzer erhält eine eindeutige Identi�kationsnummer, die ID. Zusätzlich wirdder Benutzername sowie das Passwort für jeden Benutzer gespeichert. Das Feld Admin-rechte weist einen Benutzer als übergreifenden Grabungsleiter aus und gibt ihm damitdie Rechte, die Daten aus den Entitäten Benutzer und Ausgrabung, sowie der EntitätVerwaltung, zu bearbeiten.

6.5. DATENHALTUNG 51

Für eine Ausgrabung wird ebenfalls eine eindeutige Identi�kationsnummer gespeichert.Zusätzlich erhält jede Ausgrabung eine Bezeichnung, den Ausgrabungsort sowie Beginn-und Enddatum.

Basierend auf diesen Tabellen enthalten die Entitäten Verwaltung, Befund und Zusam-menhang weiterführende Informationen. Die Entität Verwaltung enthält alle Zuweisungenzwischen Benutzern und Ausgrabungen. Dabei kann ein Benutzer an keiner oder belie-big vielen Ausgrabungen beteiligt sein, auf einer Ausgrabung muss aber mindestens einBenutzer arbeiten. Zusätzlich wird noch die Zeitspanne, in der ein Benutzer auf einer Gra-bung arbeitet, gespeichert, sowie seine Rolle bei der Ausgrabung (Grabungsassistent oderGrabungsleiter).

Die Entität Befund enthält alle Befunde, die auf einer Ausgrabung frei gelegt werden.Hierbei ist ein Befund eindeutig einer Ausgrabung zugeordnet, es können aber mehrereBefunde auf einer Ausgrabung auftreten. Ein Befund hat auÿerdem genau einen Benutzer,von dem er bearbeitet wird. Ein Benutzer kann aber gleichzeitig an mehreren Befundenarbeiten. Zu jedem Befund müssen verschiedene Informationen gespeichert werden, dazugehören eine Bezeichnung, die Maÿe des Befundes (Länge, Breite, Tiefe), sowie seine Da-tierung. Im Feld Ansprache können weitere Informationen, die für diesen Befund wichtigsind, gespeichert werden.

Im Allgemeinen stehen die verschiedenen Befunde in Verbindung zueinander, dies wirdin der Entität Zusammenhang festgehalten. Dabei kann ein Befund mit mehreren anderenBefunden im Zusammenhang stehen. Zusätzlich wird die Art der Verbindung festgehalten,möglich wären hier �liegt über�, �liegt unter�, �schneidet�, �liegt neben� oder �liegt in�.

Der Entität Befunde untergeordnet sind diejenigen Entitäten, welche Daten enthalten,die einen Befund ergänzen. Dazu gehören Funde, Bodenproben oder Fotos. Jede dieserEntitäten besitzt eine Identi�kationsnummer, einen Verweis auf den Befund, zu dem siegehört, sowie eine Bezeichnung. Dabei kann ein Befund keine bis beliebig viele dieser zu-sätzlichen Informationen besitzen.

Kapitel 7

Implementierung

Nachdem die Anwendung im letzten Kapitel entworfen wurde, stellt diese Kapitel diewichtigsten Besonderheiten in der Implementierung vor. Dazu gehören die Erstellung vonHTML-Seiten mittels JQuery Touch, die Verwendung von PhoneGap zur Kompilierung derAnwendung für eine bestimmte Plattform sowie die wichtigsten JavaScript Funktionen.

7.1 JQuery Touch

Zur Entwicklung einer hybriden App muss zunächst ein Grundgerüst bestehend aus unter-schiedlichen Webseiten mittels HTML erstellt werden. Dieses lässt sich anschlieÿend mitCSS an das Design des jeweiligen Smartphones anpassen.

Das Framework JQuery Mobile bietet hierfür verschiedene Ressourcen, die das Erstel-len der Webseiten erleichtern sollen. Um diese Ressourcen, bestehend aus verschiedenenJavaScript und CSS-Dateien, zu nutzen gibt es zwei verschiedene Möglichkeiten. Sie könnenentweder von der JQuery Mobile Homepage herunter geladen und lokal gespeichert, oderdirekt, über Verweise auf die Homepage, eingebunden werden. Die erste Methode erlaubtdie O�ine-Nutzung der Dateien, verbraucht allerdings mehr Speicherplatz auf dem Gerät,da sie bei jeder Installation der Anwendung mit herunter geladen und auf dem Smartphonedirekt gespeichert werden müssen. Die Dateien können anschlieÿend entsprechend Abb. ..in die HTML-Datei eingebunden werden.

<l i n k r e l="s t y l e s h e e t " h r e f="http :// code . jquery . com/mobile / 1 . 2 . 0 / jquery . mobile −1 . 2 . 0 .min . c s s " /><s c r i p t s r c="http :// code . jquery . com/ jquery −1 . 8 . 2 .min . j s "></s c r i p t ><s c r i p t s r c="http :// code . jquery . com/mobile / 1 . 2 . 0 /jquery . mobile −1 . 2 . 0 .min . j s "></s c r i p t >

Nach dem Einbinden der Dateien erfolgt die Gestaltung der einzelnen Seiten. In HTML5können mehrere Seiten innerhalb eines HTML5 Dokumentes erstellt werden. Für jede benö-tigte Seite wird ein <div>-Tag mit dem Attribut �data-role=page� und einer ID angelegt.Über diese ID lassen sich die unterschiedlichen Seiten später ansprechen und verlinken. Die

52

7.2. PHONEGAP 53

Struktur innerhalb einer Seite kann mit den neuen HTML5-Elementen �header�, �content�und �footer� realisiert werden. Der folgende Codeausschnitt zeigt den beispielhaften Auf-bau einer in HTML5 geschriebenen Seite. Das Design der einzelnen Elemente wird dabeidurch JQuery Mobile anhand der vergebenen Attribute festgelegt.

<div data−r o l e="page" id="index">

<div data−r o l e="header " data−po s i t i o n="f i x ed"><h1>Login</h1>

</div><div data−r o l e="content">

<p><l ab e l f o r="nutzername">Nutzername</labe l ><input type="text " name="nutzername"id="nutzername" value="" /><l ab e l f o r="passwort">Passwort</labe l ><input type="password" name="passwort "id="passwort " value="" /><a hr e f="" id="go" data−r o l e="button"onc l i c k="l o g i n ()">Login</a>

</p></div><div data−r o l e="f o o t e r " data−po s i t i o n="f i x ed">

<h1>Navigation</h1></div>

</div>

Eine Besonderheit von JQuery Mobile sind die Buttons. Diese werden hier als Linksmit dem Attribut �data-role=button� eingebunden und können später mittels JavaScriptmit Funktionalitäten belegt werden. Abb. zeigt einen Vergleich der Seite mit und ohneJQuery mobile. Nachdem das Grundgerüst mittels HTML erstellt wurde, kann PhoneGapgenutzt werden, um die Anwendung in eine native App einzubetten.

7.2 PhoneGap

Um PhoneGap zu nutzen muss zunächst die native Entwicklungsumgebung installiert wer-den. Anschlieÿend kann das PlugIn von der Homepage herunter geladen und in die Ent-wicklungsumgebung integriert werden. Eine genaue Beschreibung für die Einbindung indie verschiedenen Tools ist auf [Phob] zu �nden.

Das PlugIn besteht dabei aus verschiedenen Komponenten, die eine Webanwendunginnerhalb einer nativen App in der sogenannten WebView darstellen. Hierfür können diezuvor erstellten HTML Dateien in den zugehörigen Ordner kopiert und durch weitere

54 KAPITEL 7. IMPLEMENTIERUNG

Abbildung 7.1: Login-Seite ohne und mit eingebundenem JQuery mobileQuelle: eigene Abbildung

Funktionen ergänzt werden. Insbesondere JavaScript Funktionen zum Nutzen der nativenHard- und Software lassen sich hier einbinden.

In der Anwendung zur Befunddokumentation müssen den Befunden mehrere Fotoshinzugefügt werden. Hierfür ist es nötig, dass die native Kamera angesprochen wird. DerBefehl für das ansprechen der Kamera lautet dabei wie folgt:

nav igator . camera . g e tP i c tu r e ( onSuccess , onFai l , { qua l i t y : 50 ,dest inat ionType : Camera . Dest inat ionType .FILE_URI } ) ;

Die Funktion camera.getPicture ö�net die native Kameraanwendung und lässt denNutzer ein Foto schieÿen. Anschlieÿend wird die Anwendung geschlossen und die Speicher-adresse des aufgenommenen Bildes an die Funktion obSuccess übergeben. PhoneGap bietetauf diese Weise Zugri� auf die meisten nativen Hard- und Softwareelemente.

Zur Speicherung der eingegebenen Daten ist das Anlegen einer Datenbank nötig. Dieswird in HTML5 ebenfalls mit Hilfe von JavaScript bewerkstelligt. Der erste Schritt hierbeiist das Ö�nen der Datenbank. Dies geschicht mit Hilfe des folgendes Codes:

var db = openDatabase ( ' befunddatenbank ' , ' 1 . 0 ' ,' Datenbank zur Befunddokumentation ' , 2 * 1024 * 1024) ;

Der Befehl ö�net eine bereits bestehende oder erstellt eine neue Datenbank, abhängigdavon, ob die angegebene Datenbank bereits existiert. Die Datenbank erhält dabei einen

7.2. PHONEGAP 55

Namen, eine Versionsnummer, einen beschreibenden Text sowie die vorgesehene Gröÿe derDatenbank.

Zummanipulieren der Daten können SQL-Befehle innerhalb einer �transaction�-Funktionausgeführt werden. Hit Hilfe von �executeSql� werden beliebige Transaktionen auf der Da-tenbank ausgeführt. Die so geö�nete Datenbank wird auf dem Gerät gespeichert und kannvom Programm beliebig verwendet werden. Der folgende Code zeigt beispielhaft das ein-fügen eines neuen Benutzers in die Datenbank:

db . t r an sa c t i on ( func t i on ( tx ) {tx . executeSq l ( ' INSERT INTO t_nutzer ( id , name , passwort , admin )VALUES ( ? , ? , ? , ? ) ' , [ id , name , passwort , admin ] ;

} ) ;

Die �?� sind dabei Platzhalter für die Angaben, die der Nutzer im Formular gemacht hat.Diese müssen vorher ausgelesen und in den entsprechenden Variablen hinterlegt werden.

Nach der Erstellung der WebApp mit HTML und JQuery Mobileund dem anschlie-ÿenden Hinzufügen der JavaScript-Funktionen kann der Prototyp der Anwendung in dernativen Entwicklungsumgebung als natvie App kompiliert und anschlieÿend auf dem Gerätgetestet werden. Die fertige Anwendung kann als native App über die jeweiligen AppStoresangeboten und auf dem entsprechenden Gerät installiert werden.

Kapitel 8

Zusammenfassung

Die vorliegende Arbeit hat sich mit der Entwicklung einer Anwendung zur archäologi-schen Funddokumentation auseinander gesetzt. Zu diesem Zweck wurden zunächst diewichtigsten archäologischen Grundlagen beschrieben. Das Thema archäologische Ausgra-bung wurde hier besonders ausführlich betrachtet, um darauf aufbauende Anforderungenan die geplante Anwendung zu beschreiben. Zu diesen Anforderungen zählen die Mobili-tät der Applikation sowie die verteilte Nutzung auf unterschiedlichen Plattformen. Darausresultierend wurde die Entwicklung einer plattformübergreifenden App für Smartphonesbeschlossen.

Bevor die App entwickelt werden konnte, mussten zunächst einige Grundlagen zur Pro-grammierung von Apps eingeführt werden. Dazu gehörten die aktuellen unterschiedlichenSmartphone Betriebssysteme sowie Methoden zur plattformübergreifenden Entwicklungvon Applikationen für diese. Die gefundenen Arten von Apps (nativ, Web App oder Hy-brid App) wurden anschlieÿend im Hinblick auf die Portabilität, die Performance sowie diePlattformabdeckung miteinander verglichen. Als Ergebnis wurde die Entwicklung einerHybrid-App als die beste Umsetzung der geplanten Anwendung ermittelt.

Nach einem kurzen Überblick über Speicher- und Kommunikationsmöglichkeiten sol-cher Apps wurde schlieÿlich ein Prototyp der geplanten Anwendung entworfen und im-plementiert. Dieser Prototyp wird im folgenden Abschnitt hinsichtlich der archäologischenund informationstechnischen Anforderungen diskutiert. Im abschlieÿenden Fazit werdendie gewonnenen Erfahrungen in der plattformübergreifende App-Entwicklung dargestellt.Ein abschlieÿender Ausblick zeigt mögliche Verbesserungen und Weiterentwicklungen derAnwendung auf.

8.1 Diskussion

Anforderungen aus archäologischer Sicht, die in Kapitel zwei heraus gearbeitet wurden, sinddie Mobilität, die Datensicherheit sowie die Aufteilung der Funktionen auf verschiedeneBenutzergruppen.

56

8.1. DISKUSSION 57

8.1.1 Mobilität

Die Mobilität der Anwendung, um die Befunddokumentation direkt vor Ort vornehmenzu können, wird mit der gescha�enen App gewährleistet. Die Anwendung wird mit Hilfeeines Smartphones ausgeführt, die Bearbeitung der Befunde ist dabei unabhängig vomGrabungsleitergerät und dem Internet möglich. Dadurch wird eine hohe Mobilität auf derGrabungs�äche gewährleistet. Durch eine Benutzerauthenti�zierung ist es zudem möglich,unterschiedliche Funktionalitäten für Grabungsleiter und Grabungsassistenten anzubieten.

8.1.2 Datensicherheit

Die Speicherung der Daten erfolgt bisher mit der Web-SQL Datenbank API auf jedemGerät direkt. So lange es nur ein Grabungsleitergerät gibt, entstehen hier keine Probleme,bei mehreren Geräten stellt die Synchronisation ein Problem dar, da das Versenden derkompletten Daten bisher nicht möglich ist. Lediglich die zur Befundbearbeitung wichtigenDaten werden bisher versendet. In diese Richtung wären demnach ebenfalls weitere An-passungen vorzunehmen. Hinzu kommt, dass die Daten derzeit nur auf den Smartphonesvorhanden sind. Es ist nicht möglich, eine Sicherung beispielsweise auf einem Webserveranzulegen. Um die Datensicherheit zu gewährleisten, bedarf es in diesem Bereich einerErweiterung der Anwendung.

8.1.3 Plattformunabhängigkeit

Die wichtigste Anforderung aus informationstechnischer Sicht, die in Kapitel 3.3 ermit-telt wurde, ist die Plattformunabhängigkeit der Anwendung. Durch die Entwicklung mitHTML5 und JavaScript kann die Anwendung weitestgehend auf allen Plattformen ange-boten werden. Bisher wurde sie allerdings nur mit dem Android- und dem Windows PhoneBetriebssystem getestet. Optisch entspricht die Anwendung allerdings nicht dem nativenMetro-Design des Windows Phone, so dass hier einige Anpassungen nötig wären. Auch fürdie Verwendung auf einem iPhone oder anderen mobilen Betriebssystemen wären mehrereAnpassungen sowohl im Design als auch in den JavaScript Funktionen nötig.

8.1.4 Portabilität und Performance

Aufgrund der genutzten Mittel (HTML5, JavaScript, PhoneGap, JQuery Mobile) lässtsich die Anwendung leicht auf weitere mobile Betriebssysteme portieren. Hier sind lediglicheinige Anpassungen in den JavaScript Dateien nötig, die dank PhoneGap gut zu handhabensind. Über die Performance der Anwendung lässt sich keine Aussage machen, da hier dieVergleichsmöglichkeit zu einer mit anderen Mitteln erstellten (zum Beispiel einer nativen)Anwendung fehlt.

8.1.5 Auswertung

Die Anwendung erfüllt demnach weitestgehend die Anforderungen aus archäologischerSicht. Dennoch besitzt das Programm an vielen Stellen Verbesserungs- und Anpassungs-

58 KAPITEL 8. ZUSAMMENFASSUNG

möglichkeiten. Insbesondere der Punkt der Datensicherheit wurde bisher vernachlässigtund bedarf einer dringenden Überarbeitung.

Aus informationstechnischer Sicht ist ebenfalls weitere zusätzliche Arbeit nötig. So istdas Programm bisher lediglich auf zwei mobilen Betriebssystemen einsatzfähig. Bei einergeplanten maximalen Plattformabdeckung entspricht dies lediglich rund 33 Prozent. DieErweiterung der Anwendung zur Nutzung insbesondere unter iOS ist demnach zwingendnotwendig.

Die folgende Tabelle 8.1 enthält einen zusammenfassenden Überblick über die Erfüllungder gestellten Anforderungen durch die Anwendung. Dabei sind Werte von 0 bis 3 möglich,wobei 0 für nicht erfüllt und 4 für komplett erfüllt steht.

Anforderung ErfüllungsgradMobilität 3Datensicherheit 1Funktionsaufteilung 3Plattformabdeckung 1Portabilität 2Performance keine Angabe

Tabelle 8.1: Anwendungsfälle Befunde verwalten

8.2 Fazit

Im Laufe der Fertigstellung dieser Arbeit konnte ich einen umfassenden Überblick über denStand der plattformübergreifenden App-Entwicklung gewinnen. Wie in Kapitel 3 beschrie-ben existieren bereits viele Ansätze, die es dem Entwickler erleichtern sollen, ein Programmauf möglichst vielen Plattformen anzubieten. Diese Ansätze haben verschiedene Technolo-gien wie beispielsweise JQuery Mobile oder PhoneGap hervor gebracht, die sich allerdingsnoch im Entwicklungsstadium be�nden und daher kaum die wichtigsten Plattformen ab-decken. Will man eine Anwendung wirklich auf jeder Plattform verfügbar machen, müssenmehrere dieser Technologien und Techniken miteinander kombiniert werden.

Es stellt sich jedoch die Frage, ob es nötig ist, wirklich jede Plattform abzudecken. Ka-pitel drei hat gezeigt, dass nur wenige Plattformen sich tatsächlich durchsetzen konnten.Demnach ist es ausreichend, sich zunächst auf die wichtigsten Plattformen zu konzen-trieren. Hierbei ist die Entwicklung mit PhoneGap eine gute Wahl, da die wichtigstenPlattformen derzeit komplett unterstützt werden. Ob der Begri� �plattformübergreifend�jedoch angemessen ist, erscheint fragwürdig. In Kapitel vier wurde gezeigt, dass die Porta-bilität lediglich bei reinen Web-Anwendungen ausreichend hoch ist, um wirklich von einerplattformübergreifenden Anwendungsentwicklung zu sprechen. Eine Weiterentwicklung der

8.3. AUSBLICK 59

Technologien in diesem Bereich zur Unterstützung nativer Hard- und Software wäre daherwünschenswert.

Allgemein ist zu sagen, dass die Entwicklung von Apps eine zukunftsträchtige Alter-native zur Entwicklung von Desktopanwendungen ist. Dies zeigt vor allem der rasanteAnstieg der Verkaufs- und Nutzerzahlen besonders der groÿen Anbieter von Smartpho-nes. Die Entwicklung plattformübergreifender Technologien ist dabei besonders wichtig,da eine Anpassung der Smartphones hin zu einer einheitlichen Entwicklungsgrundlage un-wahrscheinlich ist.

8.3 Ausblick

Nach der Diskussion und einem abschlieÿenden Fazit sollen im letzten Abschnitt des Ka-pitels mögliche künftige Erweiterungen und Verbesserungen für die Anwendung vorgestelltwerden.

8.3.1 Datenspeicherung

Eine wichtige Aufgabe ist dabei die Speicherung der Daten innerhalb des Programmes.Bei der Entwicklung der App wurde die Web-SQL Datenbank API zur Speicherung derDaten genutzt. Diese wird jedoch vom W3C nicht mehr weiter entwickelt. Sie wurde vonder IndexedDB API ersetzt. Diese ist jedoch in den meisten Browsern bisher nicht imple-mentiert und be�ndet sich selbst noch im Entwicklungsstatus. Auf langfristige Sicht mussdie Speichermethode der Anwendung daher angepasst werden, da die Unterstützung derWeb-SQL Datenbank API durch zukünftige Browser nicht gesichert ist.

8.3.2 Kommunikation zwischen Smartphones

Auch die Möglichkeiten der Kommunikation zwischen Smartphones, insbesondere verschie-denen Plattformen sind bisher kaum entwickelt. Der Austausch zwischen Grabungsleiterund Grabungsassistenten ist daher bisher nur über das Speichern der Daten in eine Dateimöglich. Diese muss von den einzelnen GAs beim Gerät des Grabungsleiters erfragt werden.Zu diesem Zweck war es nötig einen Web-Server auf dem Smartphone des GLs aufzuset-zen, was jedoch viele Ressourcen des Gerätes verbraucht. Hier wäre eine Möglichkeit desdirekten Austauschs zwischen den Geräten im Programm eine wichtige Weiterentwicklungder Anwendung.

8.3.3 Auswertung der Befunde

Der entwickelte Prototyp ist für eine erste Erfassung der Befunde zwar geeignet, eine Ana-lyse der Dokumentation um wissenschaftliche Aussagen über die Befunde zu machen ist je-doch nicht möglich. Zu diesem Zweck ist die Entwicklung einer gröÿeren und umfassenderenAnwendung nötig, die mit einer Smartphone-App nicht realisierbar ist. Den Smartphonesfehlt die nötige Rechenleistung, um eine detaillierte Darstellung der Befunde zu Analy-sezwecken zu ermöglichen. Dazu gehören beispielsweise eine stratigra�sche Analyse und

60 KAPITEL 8. ZUSAMMENFASSUNG

Darstellung mittels GIS-basierten Anwendungen oder eine dreidimensionale Darstellungder Funde und ihrer Kontexte.

Um dies zu ermöglichen ist die Entwicklung einer Desktop-Anwendung zur Analyse dermit Hilfe der App dokumentierten Befunde denkbar. Hierfür müssen die Möglichkeiten desDatenaustauschs zwischen Smartphone und PC untersucht werden. Dies könnte Themaeiner weiterführenden Arbeit sein.

8.3.4 Vereinfachung der App-Entwicklung

Auch die genutzten Methoden zur plattformübergreifenden Programmierung der App be-�nden sich bisher noch in der Entwicklung. Dazu gehört beispielsweise PhoneGap, aberauch die Web-App Frameworks werden stetig weiter entwickelt. HTML5 ist ebenfalls nochkein fertiger Standard und bietet in Zukunft eventuell weitere Möglichkeiten für eine bes-sere App-Entwicklung.

Anhang A

Ergänzende Abbildungen

A.1 Beispielhafte Verwendung der Anwendung

Abbildung A.1 zeigt die beispielhafte Verwendung der Anwendung aus Sicht eines Gra-bungsassistenten. Die Anwendung wird hier zuerst gestartet. Anschlieÿend muss eine Ver-bindung zum Gerät des Grabungsleiters erstellt werden. Bei erfolgreichem Verbindungsauf-bau kann der GA alle für ihn o�enen Befunde auf sein Smartphone laden und anschlieÿendbearbeiten. Dazu gehört das Eingeben aller nötigen Daten sowie das eventuelle Hinzufü-gen von Fotos, Funden und Bodenproben. Nach Fertigstellung der Bearbeitung können dieDaten nach nochmaligem Verbindungsaufbau an den Grabungsleiter gesendet werden.

A.2 Beispiel Befundblatt

Abb. A.2 zeigt beispielhaft ein Befundblatt. Dieses beruht auf den Vorgaben des Bayeri-schen Landesamtes für Denkmalp�ege.

61

62 ANHANG A. ERGÄNZENDE ABBILDUNGEN

Abbildung A.1: Beispielhafte Verwendung der Anwendung als GAQuelle: eigene Abbildung

A.2. BEISPIEL BEFUNDBLATT 63

Abbildung A.2: Befundblatt basierend auf den Vorgaben des Landesdenkmalamtes BayernQuelle: eigene Abbildung

Literaturverzeichnis

[19996] Brockhaus � Die Enzyklopädie: in 24 Bänden. AQ-BEC. Number Bd. 2. F. A.Brockhaus, 1996.

[AGL10] S. Allen, V. Graupera, and L. Lundrigan. Pro Smartphone Cross-Platform De-velopment: iPhone, Blackberry, Windows Mobile and Android Development andDistribution. Apresspod Series. Apress, 2010.

[And] Androidpit. Androitpit app market. Website: https://www.androidpit.de/de/android-market.

[App] Appcelerator. Appcelerator titanium. Website: http://www.appcelerator.com/.

[BI12] Telekommunikation und neue Medien e.V. Bundesverband Informations-wirtschaft. Presseinformation, hochwertige smartphones werden standard.Website: http://www.bitkom.org/files/documents/BITKOM-Presseinfo_

Smartphone-Absatz_21_08_2012.pdf, August 2012.

[Cas09] Elizabeth Castro. HTML, XHTML & CSS : der Meisterkurs. Markt + Technik-Verlag, 2009.

[Cor12] International Data Corporation. Idc worldwide quarterly mobile phone tracker.Website: http://www.idc.com/getdoc.jsp?containerId=prUS22762811, Juni2012.

[dev11] BlackCharly's developments. Html5 browser storage-state of the art.Website: http://blog.elendev.com/development/html5-javascript/

html5-browser-storage-state-of-the-art/, Dezember 2011.

[Dor06] Rolf Dornberger. Software-engineering und optimierungsanwendungen in derthermodynamik: Objektorientierte programmierung mit java. Vorlesung, April2006.

[Egg59] H.J. Eggers. Einführung in die Vorgeschichte. Ergebnisse und Probleme moder-ner Wissenschaft. R. Piper and Company, 1959.

[Fli09] Brian Fling. Mobile Design and Development: Practical concepts and techniquesfor creating mobile sites and web apps. Oreilly Series. O'Reilly Media, 2009.

64

LITERATURVERZEICHNIS 65

[FÖ11] Klaus Förster and Bernd Öggl. HTML 5 : Leitfaden für Webentwickler. Addison-Wesley, 2011.

[geo07] GEO Themenlexikon 21 Archäologie: Hochkulturen, Grabungsstätten, Funde: BD21. Bibliographisches Institut, Mannheim, 2007.

[GHN11] Patrick Getzmann, Simon Hackfort, and Peter Nowak. Entwickeln für WindowsPhone 7: Architektur, Frameworks, APIs. Microsoft Press, 2011.

[Gre03] Walter (Red. Leitung) Greulich. Der Brockhaus Computer und Informationstech-nologie : Hardware, Software, Multimedia, Internet, Telekommunikation. Brock-haus Mannheim, 2003.

[Gur12] Android Guru. 1,1 milliarden android-geräte ende 2013. Website: http:

//www.android-guru.de/content/1331-1-1-milliarden-android-ger%C3%

A4te-ende-2013.html, September 2012.

[HB02] T. Hölscher and B. Borg. Klassische Archäologie: Grundwissen. Wiss. Buchges.,2002.

[Hog11] Brian P. Hogan. HTML5 & CSS3: Webentwicklung mit den Standards von mor-gen. The pragmatic programmers. O'Reilly Vlg. GmbH & Company, 2011.

[Imm12] Christian Immler. Der App-Entwickler-Crashkurs für Android, iOS und Win-dows Phone. Franzis Verlag GmbH, 2012.

[Inc] Apple Inc. App store. Website: http://www.apple.com/de/osx/apps/

app-store.html.

[Jas11] Michael Jaser. Evaluation, bewertung und implementierung verschiedener cross-platform development ansätze für mobile internet devices auf basis von web-technologien. Bachelorthesis, März 2011.

[Job10] Steve Jobs. Thought on �ash. Website: http://www.apple.com/hotnews/

thoughts-on-flash/, April 2010.

[Krö11] Peter Kröner. HTML5: Webseiten innovativ und zukunftssicher. Professionalreference. Open Source Press, 2011.

[LL11] Axel Gering Luke Lavan. Kent�berlin ostia excavations. Website: http:

//lateantiqueostia.wordpress.com/, November 2011.

[LS11] Bruce Lawson and Remy Sharp. HTML5. Addison-Wesley, 2011.

[MG10] Stefan Münz and Clemens Gull. HTML5�Handbuch. Franzis Verlag, 2010.

[mob] JQuery mobile. Jquery mobile. Website: http://jquerymobile.com/.

[Paa11] Timo Paananem. Smartphone cross�platform frameworks: A case study. Ba-chelorthesis, April 2011.

66 LITERATURVERZEICHNIS

[Pat11] Yashodhar Rajnikant Patel. Comparing performance of applications written insmartphone development environmentes. Masterthesis, 2011.

[pcm12a] Online Computer-Magazin pcmag.com. encyclopedia: mobile device. Web-site: http://www.pcmag.com/encyclopedia_term/0%2C1237%2Ct%3Dmobile+

device&i%3D61074%2C00.asp, Dezember 2012.

[pcm12b] Online Computer-Magazin pcmag.com. encyclopedia: tablet. Website:http://www.pcmag.com/encyclopedia_term/0,1237,t=tablet+computer&i=

52520,00.asp, Dezember 2012.

[Phoa] Windows Phone. Windows phone marketplace. Website http://www.

windowsphone.com/de-de/store.

[Phob] PhoneGap. Easily create apps using the web technologies you know and love:Html, css and javascript. Website: http://phonegap.com/.

[Pil11] Mark Pilgrim. Durchstarten mit HTML 5. O'Reilly, 2011.

[Pou04] Key Pousttchi. Mobile commerce � einführung in ein neues forschungsgebiet derwitschaftsinformatik. Vorlesung, 2004.

[RB09] C. Renfrew and P.G. Bahn. Basiswissen Archäologie: Theorien, Methoden, Pra-xis. Philipp von Zabern Verlag, GmbH, 2009.

[Rhe12] Landesverband Rheinland. Internationale archäologische sommerakademiexanten. Website: http://www.apx.lvr.de/ihrbesuch/betriebsausfluege/

studierende.htm, Dezember 2012.

[Rot87] Günther Rothhardt. Praxis der Softwareentwicklung. Hüthig, 1987.

[Sch11] Steve Schneider. Web�apps als zukunft der mobilen anwendungsentwicklung.11./12. Forschungskolloquium am Frauenhofer IFF 2011, pages 39�42, 2011.

[Sen] Sencha. Sencha touch. Website: http://www.sencha.com/products/touch.

[Sol] Motorola Solutions. Rhodes. Website: http://www.motorola.com/Business/US-EN/RhoMobile+Suite/Rhodes.

[Sta12a] Statista. Absatz von apple iphones weltweit vom 3. geschäftsquartal2007 bis zum 4. geschäftsquartal 2012 (in millionen stück). Websi-te: http://de.statista.com/statistik/daten/studie/12743/umfrage/

absatz-von-apple-iphones-seit-dem-jahr-2007-nach-quartalen/, 2012.

[Sta12b] Statista. Art der meistgenutzten apps in 2011. Website: http:

//de.statista.com/statistik/daten/studie/224133/umfrage/

art-der-meistgenutzten-apps-in-deutschland/, 2012.

LITERATURVERZEICHNIS 67

[Sta12c] Statista. Prognose zu den marktanteilen der betriebssysteme am ab-satz von smartphones weltweit in den jahren 2012 und 2016. Website:http://de.statista.com/statistik/daten/studie/182363/umfrage/

prognostizierte-marktanteile-bei-smartphone-betriebssystemen/,2012.

[Tel] Teltarif.de. Symbian, blackberry os, bada & meego: Daskönnen die mobilen os. Website: http://www.teltarif.de/

smartphone-handy-betriebssysteme-vergleich/news/45810.html.

[W3Ca] W3C. Cascading style sheets. Website: http://www.w3.org/Style/CSS/.

[W3Cb] W3C. W3c standard: Dom. Website: http://www.w3.org/DOM/.

[W3Cc] W3C. W3c standard: indexeddb. Website: http://www.w3.org/TR/IndexedDB/.

[W3Cd] W3C. W3c standard: Websql. Website: http://www.w3.org/TR/webdatabase/.

[W3Ce] W3C. W3c standard webstorage. Website: http://www.w3.org/TR/

webstorage/.

[Wei12] Martin Weissbach. Untersuchung plattformübergreifender entwicklungsansätzefür den zugri� auf ein innovatives informationssystem mit smartphones. Ba-chelorthesis, Juli 2012.

[Wen10] Christian Wenz. JavaScript und AJAX � Das umfassende Handbuch. GalileoPress, 2010.

[Zie11] Chris Ziegler. Android: A visual history. Website: http://www.theverge.com/2011/12/7/2585779/android-history, Dezember 2011.

68 LITERATURVERZEICHNIS

Selbständigkeitserklärung

Ich erkläre hiermit, dass ich die vorliegende Arbeit selbständig verfasst und nur unterVerwendung der angegebenen Quellen und Hilfsmittel angefertigt habe. Weiterhin erkläreich, eine Bachelorarbeit in diesem Studiengebiet erstmalig einzureichen.

Berlin, den 28. Dezember 2012 . . . . . . . . . . . . . . . . . . . . . . . . . .

Statement of authorship

I declare that I completed this thesis on my own and that information which has beendirectly or indirectly taken from other sources has been noted as such. Neither this nor asimilar work has been presented to an examination committee.

Berlin, 28th December 2012 . . . . . . . . . . . . . . . . . . . . . . . . . .

Programmierung einer mobilen Applikation zur ... · schriftliche Quellen verzichtet werden,...

Documents

Transcript of Programmierung einer mobilen Applikation zur ... · schriftliche Quellen verzichtet werden,...