Kurzfassung

Diese Arbeit umfasst die Evaluierung verschiedener Plattformen für die Anwendungsentwicklung auf mobilen Endgeräten. Als Beispiel für ein mögliches zu realisierendes Entwicklungsprojekt werden konkrete Szenarien eines vernetzten, positionsbezogenen Systems für ein Universitätsgelände (im weiteren Teil als Ambient Campus System bezeichnet) beschrieben und verglichen. Die einzelnen Plattformen werden beschrieben, allgemein verglichen und zusätzlich dahin gehend evaluiert, wie gut sie geeignet sind um auf ihnen Anwendungen für ein solches System zu entwickeln. Es kommt zudem darauf an die geeigneten Kriterien für diesen Vergleich zu erarbeiten. Weiterhin spielt der Aspekt der Portierbarkeit eine wesentliche Rolle. Es wird analysiert, welche Probleme entstehen, wenn man eine Anwendung, die auf einer bestimmten Plattform entwickelt wurde, auf eine andere Plattform portiert bzw. welche Architektur eine Anwendung generell besitzen sollte.

Die zu evaluierenden Plattformen sind Java ME, Googles Android, das .NET Compact Frame-work und die webbasierte Implementierung via Websprachen (wie bspw. HTML, PHP etc.). Nach einer Motivation für die Thematik folgt eine einführende Beschreibung eines möglichen Ambient Campus Systems.

In Kapitel 2 werden die Anforderungen an die zu entwickelnde Anwendung herausgearbeitet. Hier kommt es auf die Wahl der Architektur an, da die gewählte Architektur bestimmte Anforderungen komplett, gar nicht oder nur eingeschränkt unterstützt. Die möglichen Architekturen und Anforderungen werden beschrieben und die Architekturen zusätzlich miteinander verglichen. Sie werden am Ende dahin gehend ausgewertet, welche am besten für die Entwicklung eines Ambient Campus Systems geeignet wäre.

Es folgt die Einführung in die ausgewählten Entwicklungsplattformen, um dem Leser einen ersten Überblick über jede Plattform zu geben.

Kapitel 4 beinhaltet die Herausarbeitung der Kriterien für den anschließenden Vergleich der Plattformen. Danach erfolgt in Kapitel 5 der Vergleich anhand dieser Kriterien mit einem Fazit der Evaluierung und der Empfehlung einer Plattform für die Entwicklung eines Ambient Campus Systems.

Die beiden Kapitel 6 und 7 der Arbeit beinhalten den Versuch bestehende Anwendungen von einer Plattform auf eine andere zu portieren. Dies bietet die Möglichkeit, die im vorangegangenen Kapitel 5 herausgearbeiteten Probleme bei einer Portierung an realen Beispielen zu verdeutlichen. Kapitel 6 enthält den Versuch, eine Java Desktop Anwendung nach Java ME, .NET und in eine webbasierte Umgebung zu portieren. In Kapitel 7 wird dann versucht, eine bereits in Java ME geschriebene Anwendung nach Android, .NET und als webbasierte Implementierung zu portieren. Es folgt abschließend zu diesem Kapitel ein Fazit, bei welcher Plattform man real eine Portierung in Betracht ziehen könnte bzw. bei welcher Plattform eine Portierung verglichen zum Aufwand keinen Sinn ergäbe.

Die Arbeit endet mit einem kapitelübergreifenden Fazit, das alle Ergebnisse zusammenfassend darstellt.

Schlagwörter: Ambient Campus, Ubiquitous Campus, mobile Anwendungsentwicklung, Java ME, J2ME, Google Android, .NET Compact Framework, .NET CF, webbasierte Implementierung, Plattformen-Vergleich, Portierbarkeit.

3

Evaluierung  von Plattformen und Frameworks für die mobile Anwendungsentwicklung  

Inhaltsverzeichnis

Kurzfassung   3

Inhaltsverzeichnis   4

Abbildungsverzeichnis   8

Tabellenverzeichnis   9

Abk  ürzungsverzeichnis  10

1  Einführung  11

1.1  Motivation  11

1.2  Szenario eines Ambient Campus Systems  11

2  Architekturen und Anforderungen mobiler Anwendungen am Beispiel eines  

Ambient  Campus Systems  13

2.1  Beschreibung typischer Anforderungen  13

2.1.1  Point of Service  13

2.1.2  Datenaktualität  13

2.1.3  Softwareverteilung  14

2.1.4  Gestaltung der Benutzeroberfläche  14

2.1.5  Sicherheit  15

2.2  Beschreibung und Vergleich möglicher Architekturen  15

2.2.1  Webbasierte Always-Online-Architektur  16

2.2.2  Rich-Client Always-Online-Architektur  17

2.2.3  Rich-Client Hybrid-Architektur  17

2.2.4  Fat-Client Offline-Architektur  19

2.3  Erfüllung der Anforderungen durch die einzelnen Architekturen  20

2.4  Empfehlung einer Architektur für die Entwicklung mobiler Anwendungen im  

Rahmen  eines Ambient Campus Systems  21

2.4.1  Das Ortungssystem  21

2.4.2  Das Nachrichtensystem  22

3  Beschreibung ausgewählter Plattformen und Frameworks  23

3.1  Java ME  23

3.2  Android  25

3.3  NET Compact Framework  26

3.4  Webbasierte Implementierung  28

4  Herausarbeitung der Vergleichskriterien  30

4.1  Unterstützung von Betriebssystemen  30

4.2  Einarbeitungsaufwand durch Sprachunterstützung und Standardisierung  30

4

Inhaltsverzeichnis

4.3  Portierbarkeit zu anderen Plattformen.  31

4.4  Sicherheit und mögliche Schwachstellen  31

4.5  Performanz und Freigabe von Speicherplatz  32

4.6  Nutzung nativer Methoden und Hardwareunterstützung  32

4.7  Unterstützung von Schnittstellen  33

4.8  Entwicklungsumgebungen  33

4.8.1  Installation und Bedienbarkeit  34

4.8.2  Möglichkeiten zur Gestaltung der Benutzeroberfläche (GUI Designer)  34

4.8.3  Emulatoren-Unterstützung  34

4.8.4  Hilfsfunktionalitäten bei Fehlersuche und Eingabe  34

4.8.5  Dokumentation.  34

4.9  Dokumentation, Entwickler Community und Support  35

4.10  Kosten und Lizenzen  35

5  Evaluierung der Plattformen und Frameworks anhand ausgewählter  

Kriterien   36

5.1  Unterstützung von Betriebssystemen  36

5.1.1  Java ME  36

5.1.2  Android  37

5.1.3  NET Compact Framework  37

5.1.4  Webbasierte Implementierung  38

5.2  Einarbeitungsaufwand durch Sprachunterstützung und Standardisierung  41

5.2.1  Java ME  41

5.2.2  Android  41

5.2.3  NET Compact Framework  42

5.2.4  Webbasierte Implementierung  42

5.3  Portierbarkeit zu anderen Plattformen.  43

5.3.1  Portierung von Plattform zu Plattform  43

5.3.2  Portierung von Desktopanwendung zu mobiler Anwendung  44

5.4  Sicherheit und mögliche Schwachstellen  46

5.4.1  Java ME  46

5.4.2  Android  47

5.4.3  NET Compact Framework  48

5.4.4  Webbasierte Implementierung  49

5.5  Performanz und Freigabe von Speicherplatz  50

5.5.1  Java ME  50

5.5.2  Android  50

5.5.3  NET Compact Framework  50

5.5.4  Webbasierte Implementierung  51

5

Evaluierung  von Plattformen und Frameworks für die mobile Anwendungsentwicklung  

5.6  Nutzung nativer Methoden und Hardwareunterstützung.  51

5.6.1  Java ME.  51

5.6.2  Android  52

5.6.3  NET Compact Framework  52

5.6.4  Webbasierte Implementierung  52

5.7  Unterstützung von Schnittstellen  53

5.7.1  Java ME.  53

5.7.2  Android  53

5.7.3  NET Compact Framework  54

5.7.4  Webbasierte Implementierung  55

5.8  Entwicklungsumgebungen  55

5.8.1  Die Wahl der Entwicklungsumgebungen  55

5.8.2  Installation und Bedienbarkeit  56

5.8.3  Möglichkeiten zur Gestaltung der Benutzeroberfläche (GUI Designer)  59

5.8.4  Emulatoren-Unterstützung  60

5.8.5  Hilfsfunktionalitäten bei Fehlersuche und Eingabe  61

5.8.6  Dokumentation  62

5.9  Dokumentation, Entwickler Community und Support  63

5.9.1  Java ME.  63

5.9.2  Android  63

5.9.3  NET Compact Framework  64

5.9.4  Webbasierte Implementierung  64

5.10  Kosten und Lizenzen  64

5.10.1  Java ME.  65

5.10.2  Android  65

5.10.3  NET Compact Framework  65

5.10.4  Webbasierte Implementierung  66

5.11  Fazit des Vergleichs und Empfehlung einer Plattform für die Entwicklung eines  

Ambient  Campus Systems  66

6  Portierung einer Java Desktop-Anwendung auf mobile Plattformen  69

6.1  Das Zeichenprogramm als Java Applikation für Java ME  69

6.2  Das Zeichenprogramm als Java Applikation für das NET Compact Framework  74

6.3  Das Zeichenprogramm als Java Applet für die webbasierte Implementierung  74

7  Vergleich der Portierbarkeit anhand einer bestehenden Beispielanwendung in  

Java  ME  75

7.1  Beschreibung des mobilen Nachrichtensystems.  75

7.2  Portierung des mobilen Nachrichtensystems nach Android  75

7.3  Portierung des mobilen Nachrichtensystems nach NET Compact Framework  77

6

Inhaltsverzeichnis

7.4  Portierung des mobilen Nachrichtensystems in eine webbasierte Implementierung  79

7.5  Fazit  80

8  Kapitelübergreifendes Fazit mit Empfehlungen für die  

Anwendungsentwicklung   81

Glossar   82

Literaturverzeichnis   83

7

Evaluierung  von Plattformen und Frameworks für die mobile Anwendungsentwicklung  

Abbildungsverzeichnis   

Abbildung  1: Webbasierte Always-Online-Architektur GK07 , S.4  

Abbildung  2: Rich-Client Always-Online Architektur GK07 , S.5  

Abbildung  3: Rich-Client Hybrid-Architektur GK07 , S.6  

Abbildung  4: Fat-Client Offline-Architektur GK07 , S.7  

Abbildung  5: Anforderungsabdeckung der einzelnen Architekturen GK07 , S.9  

Abbildung  6: Java ME im Überblick angelehnt an Ted06  

Abbildung  7: Anwendungsbereiche von CDC und CLDC angelehnt an Tan07  

Abbildung  8: Android Überblick angelehnt an Goo08d  

Abbildung  9: NET Compact Framework Architektur angelehnt an Mic08c  

Abbildung  10: Webbasierte Implementierung Überblick angelehnt an Misd  

Abbildung  11: Der NetFront Browser  

Abbildung  12: Das Zeichenprogramm  

Abbildung  13: Das unvollständige Zeichenprogramm im CDC Emulator  

Abbildung  14: JFileChooser Dialog in der ursprünglichen Java Applikation  

Abbildung  15: Einfacher Eingabedialog auf dem mobilen Endgerät  

Abbildung  16: JColorChooser in der ursprünglichen Java Applikation  

Abbildung  17: Einfacher Optionsdialog auf dem mobilen Endgerät  

Abbildung  18: Das Zeichenprogramm im CDC Emulator  

Abbildung  19: J2ME HelloWorld  

Abbildung  20: Android HelloWorld  

Abbildung  21: Visual Studio Konvertierungsbericht  

Abbildung  22: MicroEmulator Demo  

8

Tabellenverzeichnis   

Tabellenverzeichnis   

Tabelle 1:  Betriebssystemmatrix des NET Compact Frameworks angelehnt an Rob05  38

Tabelle 2:  Vergleichsmatrix aller Plattformen  67

Tabelle 3:  Zusammengefasste Vergleichsmatrix  67

9

Evaluierung von Plattformen und Frameworks für die mobile Anwendungsentwicklung

Abkürzungsverzeichnis

ADO Active Data Objects API Application Programming Interface BSI Bundesamt für Sicherheit in der Informationstechnik CDC Connected Device Configuration CLDC Connected Limited Device Configuration CSS Cascading Style Sheets EMCA European Computer Manufacturers Association GUI Graphical User Interface HTML Hypertext Markup Language HTTP Hypertext Transfer Protocol ISO International Organization for Standardization J2EE Java Enterprise Edition J2ME Java Micro Edition J2SE Java Standard Edition Java ME Java Micro Edition JDBC Java Database Connectivity JSR Java Specification Request JVM Java Virtual Machine MIDP Mobile Information Device Profile SMTP Simple Mail Transfer Protocol SOAP Simple Object Access Protocol W3C World Wide Web Consortium WLAN Wireless Local Area Network WTP Web Tools Platform WYSIWYG What you see is what you get XML Extensible Markup Language

10

1 Einführung

1.1 Motivation

In der heutigen Zeit gehören mobile Endgeräte wie bspw. Handys und Laptops zum alltäglichen Erscheinungsbild unserer Kultur dazu. Der hohe Verbreitungsgrad und auch die stete und rasche Weiterentwicklung tragen dazu bei, dass immer mehr neue Anwendungen für diese Geräte entwickelt werden.

Um solche Anwendungen entwickeln zu können muss sich der Entwickler zunächst für eine Entwicklungsplattform entscheiden. Die Wahl der richtigen Plattform hängt von diversen Kriterien ab, die in dieser Arbeit im Detail erarbeitet werden und deren Gewichtung von der jeweiligen Anwendung abhängt, die entwickelt werden soll.

In diesem Fall wird am Ende des allgemeinen Vergleichs eine spezielle Empfehlung für Anwendungen eines Ambient Campus System gegeben, welches im folgenden Kapitel eingehender erläutert wird.

Diese Arbeit soll somit eine Hilfe dabei sein die richtige Plattform für eine mobile Anwendung zu finden und die Anwendungsentwicklung so zielgerichtet wie möglich zu gestalten.

1.2 Szenario eines Ambient Campus Systems

Mobile Endgeräte wie Handys, PDAs oder Laptops sind besonders bei jüngeren Menschen im Schüler- und Studentenalter beliebt. Vor allem bei den Handys kann man sagen, dass es kaum mehr einen Schüler ab der 5.-7. Klasse gibt, der kein solches besitzt. Belegen lässt sich dies anhand der KidsVerbraucherAnalyse 2007 [HB07], nach deren Angaben 2,1 Millionen Kinder (37%) ein Handy besitzen von denen der Großteil (62%) zwischen 10-13 Jahren alt sind. Die beliebtesten Anwendungen in diesem Alter sind laut [HB07] Spiele, da 57% der Kinder ihr Handy dafür nutzen.

PDAs und Laptops sind dagegen erst bei älteren Jugendlichen und besonders bei Studenten beliebt und verbreitet, da sie eine größere Anzahl an Informationsmöglichkeiten bieten. So wird es dem Studenten möglich, direkt in der Universität digital seine Hausaufgaben zu erledigen oder sich während einer Vorlesung im Internet weiterführende Informationen zu beschaffen. Laut [Mis07d] wurden im November 2007 vom Studenten-Vorteilsclub Allmaxx.de. 1.026 Studierende befragt, wovon über 70% einen Laptop besitzen und 40% ausschließlich einen Laptop ohne zusätzlichen Desktop PC.

Dieser Beliebtheitsgrad für mobile Endgeräte und ihre Anwendungen führte zu der Idee, den Campus einer Universität so zu vernetzen, dass den Studenten über die mobilen Endgeräte Möglichkeiten der Interaktion und weiterführenden Informationsgewinnung geboten werden. Es gibt eine Vielzahl von möglichen Anwendungen, die für solch ein System, in Betracht kämen. Im Folgenden werden zwei dieser Anwendungen vorgestellt.

Bei der ersten Anwendung handelt es sich um ein Nachrichtensystem. Dies ermöglicht es dem Studenten an einem bestimmten Ort auf dem Universitätsgelände eine Nachricht für jemanden zu hinterlassen, der die Nachricht dann angezeigt bekommt, sobald er sich an diesem Ort befindet. Das Ganze ist also vergleichbar mit einem elektronischen Schwarzen Brett, dessen Nachrichten allerdings nur von berechtigten Personen gelesen werden können. Die zweite Anwendung ist ein Ortungssystem, das es dem Client, also dem mobilen Endgerät, ermöglicht, seine eigene Position zu ermitteln. Diese Funktionalität bildet dabei die Grundlage für mögliche weitere Services. So könnte es in Zukunft den Studenten möglich sein ortsbezoge-

11

Evaluierung von Plattformen und Frameworks für die mobile Anwendungsentwicklung

ne Informationen zu ihrem jeweils aktuellen Standort zu erhalten (bspw. wo befindet sich das Büro eines Professors etc.). Weiterhin wäre es denkbar ein Netzwerk unter Personen aufzubauen in dem jeder seinen eigenen Standort anderen Leuten freigeben kann und man somit weiß wo sich seine Kommilitonen gerade befinden oder auch in welchem Raum sich gerade Leute aufhalten (und dieser somit belegt ist).

Im weiteren Verlauf der Arbeit werden diese zwei Anwendungen, wenn es um die Bewertung von Anforderungen und Vergleichskriterien geht, als Basis für ein Ambient Camus System herangezogen.

12

Architekturen und Anforderungen mobiler Anwendungen am Beispiel eines Ambient Campus Systems

2

Dieses Kapitel beinhaltet die Herausarbeitung der Anforderungen an eine zu entwickelnde mobile Anwendung. Neben den Anforderungen kommt es zudem auf die Wahl der Architektur an, da diese bestimmte Anforderungen unterstützt oder nicht bzw. nur eingeschränkt unterstützt. Die möglichen Architekturen und Anforderungen werden nachfolgend beschrieben und die Architekturen zusätzlich miteinander verglichen und am Ende dahin gehend ausgewertet, welche am besten geeignet wäre für die Entwicklung eines Ambient Campus Systems. Schließlich wird eine Empfehlung einer Architektur für eine mobile Anwendung im Rahmen eines Ambient Campus Systems abgegeben.

2.1 Beschreibung typischer Anforderungen

Es folgt eine Beschreibung typischer Anforderungen an mobile Anwendungen. Es werden im Einzelnen die Punkte Point of Service, Datenaktualität, Softwareverteilung, Gestaltung der Benutzeroberfläche und Sicherheit diskutiert.

2.1.1 Point of Service

Der Point of Service beschreibt den Ort, an dem eine Anwendung hauptsächlich genutzt wird. Man kann hier unterscheiden ob eine Anwendung stets an festgelegten Orten, wie bspw. einem bestimmten Raum, oder unterwegs, also an wechselnden Plätzen, genutzt wird [GK07]. Im Fall eines Ambient Campus Systems ist sowohl die Nutzung einer Anwendung an wechselnden Orten als auch die Nutzung nur in einem bestimmten Raum denkbar. So macht bspw. ein Ortungssystem nur dann Sinn, wenn man vom gesamten Campus aus eine Übersicht über die Positionen anderer Teilnehmer bekommt. Ein Nachrichtendienst wäre allerdings auch dahin gehend denkbar, dass an einem bestimmten Punkt eine Nachricht hinterlassen werden kann, die auch nur an diesem Punkt empfangen werden kann.

Des Weiteren ist es, aufgrund der Verfügbarkeit von Funknetzwerken, interessant zu wissen ob die Anwendung in städtischer oder in ländlicher Umgebung genutzt wird bzw. kann auch in städtischer Umgebung die Verfügbarkeit variieren [GK07].

Bei einem Ambient Campus System kann von einer städtischen Umgebung ausgegangen werden, da Universitäten im Allgemeinen in einer Stadt angesiedelt sind. Und auch wenn dies nicht immer zutrifft kann auf einem Universitäts-Campus generell von einer guten WLAN Verfügbarkeit ausgegangen werden. Hier müsste allerdings im Einzelfall die Verfügbarkeit vor Ort getestet werden.

2.1.2 Datenaktualität

Bei der Datenaktualität geht es um die Frage, wie aktuell die Daten sein sollen, die dem Benutzer über die Anwendung zur Verfügung gestellt werden. Man kann unterscheiden in die Forderung nach:

• Echtzeitdaten,

• nicht ganz so aktuellen Daten (bspw. Daten vom Vortag)

• und nach Daten deren Aktualität nicht kritisch ist [GK07].

Betrachtet man das Ambiet Campus Szenario so wird deutlich, dass hier sowohl bei einem Ortungssystem, als auch bei einem Nachrichtensystem Echtzeitdaten bzw. möglichst aktuellste

13

Evaluierung von Plattformen und Frameworks für die mobile Anwendungsentwicklung

Daten benötigt werden. Dies lässt sich zum einen daraus schließen, dass ein Ortungssystem die aktuelle Position einer Person liefern soll und nicht die Position von vor einem Tag. Zum anderen sollte es auch bei einem Nachrichtensystem möglich sein Nachrichten abzurufen, die vor kurzer Zeit hinterlegt wurden.

2.1.3 Softwareverteilung

Die Anforderung Softwareverteilung beinhaltet die Frage danach, wie neue Versionen der Anwendungen an die Nutzer bereits bestehender Versionen verteilt werden. Hierbei muss bedacht werden ob die Anwendung überhaupt auf den Endgeräten der Nutzer installiert ist, oder ob die Benutzer, bspw. mit Hilfe eines Browsers, lediglich auf eine Anwendung, die zentral auf einem Server liegt, zugreifen. Liegt die Anwendung auf einem Server und alle Nutzer greifen somit auf dieselbe Anwendung zu, so muss auch nur dort ein Update eingespielt werden.

Hat jeder Nutzer eine Version der Anwendung auf seinem mobilen Endgerät installiert, bieten sich zwei Möglichkeiten des Updates: Eine offline und eine online Verteilung. Bei einer online Verteilung lädt der Nutzer aktiv die neuste Version direkt über das Internet herunter. Eine offline Verteilung bedeutet hingegen, dass Datenträger, die die neuste Version enthalten, erstellt und verteilt werden müssen. Dieses Szenario ist unweigerlich mit höheren Kosten verbunden [GK07].

Für Anwendungen eines Ambient Campus Systems ist sowohl die Variante einer zentralen Server-Anwendung als auch die Variante einer direkt auf den Endgeräten installierten Anwendung denkbar. Eine zentrale Server-Anwendung bietet hierbei den Vorteil, dass alle Nutzer mit derselben Version arbeiten und somit die Kompatibilität gewährleistet werden kann. Für die zweite Variante ist aufgrund der einzusparenden Kosten und der ohnehin verfügbaren Internetverbindung die Möglichkeit einer online Verteilung sinnvoll.

2.1.4 Gestaltung der Benutzeroberfläche

Eine weitere Anforderung liegt in der Gestaltung der Benutzeroberfläche der jeweiligen Anwendung. Hauptkriterium ist hier die einfache Bedienbarkeit der Benutzerschnittstellen interaktiver Systeme (Webseiten oder Software). Die DIN EN ISO 9241 gibt in Teil 110 eine Übersicht über die Grundsätze, die bei der Gestaltung von Schnittstellen (zwischen dem Benutzer und dem System) eine wichtige Rolle spielen [Sch06]. Zu den Grundsätzen zählen Punkte wie:

• Aufgabenangemessenheit

• Selbstbeschreibungsfähigkeit

• Erwartungskonformität

• Fehlertoleranz

• Individualisierbarkeit

• und Lernförderlichkeit [Sch06].

Die Aufgabenangemessenheit sagt aus, dass das System durch seine Funktionalität und seine Oberfläche dem Nutzer helfen soll seine Arbeitsaufgabe in angemessenem Rahmen durchzuführen. Zudem sollen unnötige Interaktionen vermieden bzw. minimal gehalten werden [Sch06]. Ein Beispiel hierfür ist ein Button auf einer Webseite zum Einloggen eines Nutzers. Auf diesem Button sollte ein erklärender Text, der die Aktion klar verdeutlicht (wie z.B. „Login“), platziert werden. Zudem sollte der Button gut sichtbar und schnell erreichbar sein und bei einem Betätigen die erwartete Funktion (den Login) ausführen.

14

Architekturen und Anforderungen mobiler Anwendungen am Beispiel eines Ambient Campus Systems

Bei der Selbstbeschreibungsfähigkeit geht es darum, das die Anwendung Hilfen und Rückmeldungen bietet, die dem Benutzer die Verständlichkeit erleichtern [Sch06]. Als Beispiel ist hier eine Systemmeldung anzuführen, die dem Benutzer klar und einfach verdeutlicht, welchen Vorgang das System gerade ausführt. Es wird also bspw. keine Sanduhr angezeigt sondern ein Dialog, dass einen Erläuterungstext über die aktuelle Systemaktivität enthält. Die Erwartungskonformität zielt auf die Konsistenz der Oberfläche und ihre Anpassung an das Benutzermodell ab [Sch06]. Der Benutzer hat also eine ganz bestimmte Erwartung an z.B. die Benennung eines Buttons aufgrund dessen, was er beabsichtigt zu tun und aufgrund von Erfahrungen, die er bereits mit anderen Produkten gemacht hat. Ein Button zum Speichern ist oft mit dem Abbild einer Diskette dargestellt. Bietet das Programm nun allerdings einen Speicher-Button mit einem ganz anderen Abbild (bspw. einer Blume), so erwartet der Benutzer dies nicht, sucht den Button und ist ggf. verwirrt, wenn er herausfindet, dass dies der Speicher-Button ist [Gei05].

Die Fehlertoleranz beschreibt, dass es wichtig ist, das auftretende Fehler nicht die Benutzung der Anwendung und somit das Ziel des Nutzers verhindern [Sch06]. Hier gilt, sollte ein Nutzer bspw. ein Feld falsch ausgefüllt haben, darf das Programm nicht abstürzen, sondern sollte einen Hinweis geben, welches Feld falsch ist und wie es richtig gefüllt werden muss [Zip07]. Die Oberfläche, beschrieben durch den Punkt Individualisierbarkeit, soll auf einzelne Benutzer oder Benutzergruppen und ihren Arbeitskontext abgestimmt sein. So sind Variationen der Darstellung pro Person möglich [Sch06]. Ein Beispiel hierfür ist eine Webseite, bei der jeder Nutzer individuell einstellen kann, welche Seite er nach seinem Login angezeigt bekommen möchte [Zip07].

Die Lernförderlichkeit drückt aus, dass es dem Benutzer in minimaler Zeit möglich sein soll die Benutzung der Anwendung zu erlernen. [Sch06] Dies kann bspw. eine geführte Tour zur Nutzung einer komplizierten Webseite sein, bei der der Nutzer vorab lernt, wie er später die Seite zu bedienen hat um die gewünschte Funktionalität ausführen zu können [Zip07].

2.1.5 Sicherheit

Da Anwendungen, die auf mobilen Geräten zum Einsatz kommen, oft vertrauliche, personenbezogene Daten verarbeiten, ist es wichtig, dass diese Daten ausreichend gut geschützt werden. Dies kann durch ein geeignetes, möglichst gut steuerbares und zentral organisiertes Sicherheitsmanagement erreicht werden [GK07].

In der Nachrichtenanwendung des Ambient Campus würde sich das bspw. darin äußern, dass Nachrichten nur von den Personen gelesen werden dürfen, für die die Nachricht auch hinterlassen wurde. Hier müsste bei der Implementierung der Anwendung ein geeignetes kryptografisches Verfahren zum Einsatz kommen.

2.2 Beschreibung und Vergleich möglicher Architekturen

Im Folgenden werden mögliche Architekturen für mobile Anwendungen erläutert und mitei-nander verglichen. Es lassen sich hautsächlich vier verschiedene Architekturen heraus kristallisieren. Zum einen zwei Varianten der Always-Online-Architektur, deren Kommunikation mit einem zentralen Server nur online statt findet. Zum anderen gibt es die hybride Architektur, die die Vorteile von online und offline vereint und es dem Nutzer somit ermöglicht die Anwendung auch offline zu nutzen, falls gerade kein Netz verfügbar sein sollte, und zu einem späteren Zeitpunkt online zu synchronisieren. Die letzte hier betrachtete Architektur ist eine offline Architektur, bei der eine gelegentliche Synchronisation mit einem Server durchgeführt wird.

15

Evaluierung von Plattformen und Frameworks für die mobile Anwendungsentwicklung

Eine Architektur, die komplett offline agiert, und somit nicht über ein Netzwerk kommuniziert, wird hier nicht näher betrachtet, da eine mobile Anwendung ihren Sinn fast immer in der Vernetzung hat und somit auch die für den Nutzer interessanten Features aus dieser Vernetzung entstehen. Bei der Beschreibung der einzelnen Architekturen wurde der Aufsatz „Anforderungen in mobilen Geschäftsprozessen und ihre Auswirkungen auf die Architektur mobiler Systeme“ von Volker Gruhn und André Köhler [GK07] als Hauptquelle herangezogen. Der Zusammenhang zwischen den jeweiligen Architekturen mit den Anwendungen eines Ambient Campus Systems wurde selbst hergestellt.

2.2.1 Webbasierte Always-Online-Architektur

Bei der webbasierten Always-Online-Architektur ist der Client die ganze Zeit online und kommuniziert über ein mobiles Netzwerk. Abbildung 1 stellt die Präsentations-, Anwendungs- und Datenschicht der Architektur dar. Sie zeigt, dass die Präsentationsschicht bei der webbasierten Always-Online-Architektur lediglich aus einer Browserkomponente, die auf dem Client läuft, besteht. Der Server beinhaltet hingegen die komplette Anwendungs- und Datenschicht.

Die Tatsache, dass auf dem Client nur ein Browser installiert sein muss bietet eine Reihe an Vorteilen. Zum einen ist es so möglich viele verschiedene Client-Systeme zu unterstützen, da bestimmte Eigenschaften des Clients, wie bspw. das Betriebssystem, nur eine Rolle für die Unterstützung der einzelnen Browservarianten spielt, nicht aber für die Funktionen des Programms.

Dies wäre auch für ein Ambient Campus System in sofern ein Vorteil, als dass die Vielfalt mobiler Endgeräte, gerade bei einem Informatik-orientierten Studium in dem von einer größeren Nutzung solcher Technik ausgegangen werden kann, als sehr groß eingestuft werden kann. Weiterhin muss sich der Client nicht um Updates oder Synchronisationen kümmern, da die Anwendung inklusive der benötigten Daten komplett auf dem Server liegt. Das heißt, dass alle Clients, die auf die Anwendung zugreifen, immer an denselben Echtzeitdaten arbeiten und somit auch die aktuellsten Präsentations- und Geschäftslogiken nutzen.

Hier bietet sich der Vorteil niedrigerer Kosten und Aufwände bei der Softwareverteilung (siehe hierzu Kapitel 2.1.3). Dies erspart, in einem Universitätsumfeld, den Studenten zum einen Zeit-aufwand und zum anderen, je nach dem internen Abrechnungsmodell, eventuelle Kosten. Ein Nachteil dieser Architektur ist die Tatsache, dass immer eine Verbindung zu einem Netzwerk zur Verfügung stehen muss, da der Client sonst nicht auf die Anwendung zugreifen kann. Daher sollte im Vorfeld genau überprüft werden, wie die Verbindungsqualität am Point of Service (siehe Kapitel 2.1.1 Point of Service) ist.

Im Allgemeinen kann wohl eher davon ausgegangen werden, dass es am Point of Service Schwankungen in der Qualität der Verbindung gibt. Hier müsste geprüft werden ob die Verbindung etwas, stark oder komplett beeinträchtigt ist und demnach eine Entscheidung gefällt werden.

16

Architekturen und Anforderungen mobiler Anwendungen am Beispiel eines Ambient Campus Systems

Ein anderer Nachteil besteht in der vergleichsweise geringen Bandbreite eines mobilen Netzes, die dazu führt, dass Daten langsamer übertragen werden können als bspw. über eine LAN Verbindung. Das bedeutet, dass für Nutzer, die an eine Verbindungsgeschwindigkeit über LAN gewohnt sind, die Performanz des Clients nicht ausreichend erscheinen kann. Weiterhin muss bedacht werden, dass der Server unter Umständen eine Vielzahl von Client-Anfragen parallel behandeln muss. Dies bedeutet wiederum, dass der Server entsprechend per-formant und verfügbar sein muss.

2.2.2 Rich-Client Always-Online-Architektur

Die Rich-Client Always-Online-Architektur bietet gegenüber der webbasierten Always-Online-Architektur (siehe Kapitel 2.2.1) den Vorteil, dass die Präsentationslogik auf den Client gelagert werden kann. Durch das somit reduzierte Volumen an zu übertragenden Daten entstehen Kosten- und Performancevorteile.

Der Client enthält, wie in Abbildung 2 zu erkennen, die komplette Präsentationsschicht (bestehend aus GUI und Teilen der Präsentationslogik). Weiterhin sind auch Komponenten wie Update und Session-Handling aus der Anwendungsschicht auf dem Client realisiert, die allerdings auf dem Server jeweils noch ein Gegenstück haben. Auf dem Server liegen sowohl die der Anwendungsschicht angehörende Geschäftslogik, wie auch die komplette Datenschicht.

Die Vorteile dieser Architektur liegen darin, dass ein Client für die mögliche Oberflächengestaltung genutzt wird und in dem reduzierten Datenvolumen. Weiterhin können auch bei dieser Architektur, analog zur webbasierten Always-Online-Architektur, die Clients auf einer zentralen Datenbank arbeiten. Sie arbeiten somit immer mit den neusten Daten sowie der aktuellsten Geschäfts- und Präsentationslogik. Zudem ist es durch Einsatz von Rich-Clients in Kombination mit der Komponente für das Session Handling auch möglich, kürzere Zeiten, in denen keine Onlineverbindung besteht, zu überbrücken.

Nachteile dieser Architektur sind auch hier wieder ein zwingend benötigtes mobiles Netz um die Funktionsfähigkeit des Clients zu sichern, die begrenzte Bandbreite für die Übertragung und die Performance des Clients sowie die des Servers. Des Weiteren muss bedacht werden, dass zusätzliche Komponenten für Session- und Update-Handling eingebunden werden müssen.

2.2.3 Rich-Client Hybrid-Architektur

Die Rich-Client Hybrid-Architektur behebt das Problem eines zwingend benötigten mobilen Netzwerks zur Anwendungsnutzung. Generell ist die Architektur zwar weiterhin auf die online

17

Evaluierung von Plattformen und Frameworks für die mobile Anwendungsentwicklung

Nutzung des Clients ausgerichtet, der Nutzer kann jedoch bei einem möglichen Verbindungsabbruch weiterhin offline mit der Anwendung arbeiten.

In Abbildung 3 wird deutlich, dass es zusätzlich zu der Präsentationsschicht, die (durch eine GUI und die Präsentationslogik) komplett auf dem Client realisiert ist, auf dem Client noch weitere Komponenten der Anwendungs- und Datenschicht gibt. Die auf dem Client vorhandenen Komponenten der Anwendungsschicht für Geschäftslogik, Session- und Update-Handling sowie die Synchronisation brauchen auf dem Server jeweils ein Gegenstück. Die Datenschicht des Servers besteht nicht nur aus einer Datenbank, wie die Datenschicht des Clients, sondern beinhaltet zusätzlich auch noch Vorlagen für Geschäfts- und Präsentationslogik.

Diese Realisierungsstruktur ermöglicht es grundsätzlich immer online zu arbeiten. Hierbei werden, wie in der Rich-Client Always-Online Architektur (siehe Kapitel 2.2.2), die Geschäftslogik und die Datenbanken des Servers genutzt. Sollte die Verbindung allerdings einmal abbrechen, kann die Anwendung weiter arbeiten und die eigenen Komponenten auf Client Seite nutzen, da die aktuell benötigten Daten vom Server auf den Client geladen werden. Sobald die Verbindung zum Netzwerk wieder möglich ist, wird eine Synchronisation zwischen den Client- und Serverdaten durchgeführt und die Anwendung kann wieder online arbeiten.

Neben dem Vorteil der möglichen offline Arbeit ist auch hier die Reduzierung des Datenvolumens durch die Nutzung eines Rich-Clients zur Gestaltung der Benutzerschnittstelle erwähnenswert. Des Weiteren gelten auch bei dieser Architektur wieder die bereits im Vorigen herausgearbeiteten Vorteile wie die zentrale Datenhaltung und der Zugriff auf zentrale Geschäfts-und Präsentationslogik.

Der hauptsächliche Nachteil dieser Architektur ergibt sich gleichzeitig aus ihrem größten Vorteil. Es muss eine Komponente zur Synchronisation entwickelt werden. Diese muss die Konflikte lösen, die ggf. entstehen wenn die Daten des Clients, die während der offline Phase geändert

18