Evaluierung von Plattformen und Frameworks für die mobile Anwendungsentwicklung

Inhaltsverzeichnis

Kurzfassung

Abbildungsverzeichnis

Tabellenverzeichnis

Abkürzungsverzeichnis

1 Einführung
1.1 Motivation
1.2 Szenario eines Ambient Campus Systems

2 Architekturen und Anforderungen mobiler Anwendungen am Beispiel eines Ambient Campus System
2.1 Beschreibung typischer Anforderungen
2.1.1 Point of Service
2.1.2 Datenaktualität
2.1.3 Softwareverteilung
2.1.4 Gestaltung der Benutzeroberfläche
2.1.5 Sicherheit
2.2 Beschreibung und Vergleich möglicher Architekturen
2.2.1 Webbasierte Always-Online-Architektur
2.2.2 Rich-Client Always-Online-Architektur
2.2.3 Rich-Client Hybrid-Architektur
2.2.4 Fat-Client Offline-Architektur
2.3 Erfüllung der Anforderungen durch die einzelnen Architekturen
2.4 Empfehlung einer Architektur für die Entwicklung mobiler Anwendungen im Rahmen eines Ambient Campus Systems
2.4.1 Das Ortungssystem
2.4.2 Das Nachrichtensystem

3 Beschreibung ausgewählter Plattformen und Frameworks
3.1 Java ME
3.2 Android
3.3 .NET Compact Framework
3.4 Webbasierte Implementierung

4 Herausarbeitung der Vergleichskriterien
4.1 Unterstützung von Betriebssystemen
4.2 Einarbeitungsaufwand durch Sprachunterstützung und Standardisierung
4.3 Portierbarkeit zu anderen Plattformen
4.4 Sicherheit und mögliche Schwachstellen
4.5 Performanz und Freigabe von Speicherplatz
4.6 Nutzung nativer Methoden und Hardwareunterstützung
4.7 Unterstützung von Schnittstellen
4.8 Entwicklungsumgebungen
4.8.1 Installation und Bedienbarkeit
4.8.2 Möglichkeiten zur Gestaltung der Benutzeroberfläche (GUI Designer)
4.8.3 Emulatoren-Unterstützung
4.8.4 Hilfsfunktionalitäten bei Fehlersuche und Eingabe
4.8.5 Dokumentation
4.9 Dokumentation, Entwickler Community und Support
4.10 Kosten und Lizenzen

5 Evaluierung der Plattformen und Frameworks anhand ausgewählter Kriterien
5.1 Unterstützung von Betriebssystemen
5.1.1 Java ME
5.1.2 Android
5.1.3 .NET Compact Framework
5.1.4 Webbasierte Implementierung
5.2 Einarbeitungsaufwand durch Sprachunterstützung und Standardisierung
5.2.1 Java ME
5.2.2 Android
5.2.3 .NET Compact Framework
5.2.4 Webbasierte Implementierung
5.3 Portierbarkeit zu anderen Plattformen
5.3.1 Portierung von Plattform zu Plattform
5.3.2 Portierung von Desktopanwendung zu mobiler Anwendung
5.4 Sicherheit und mögliche Schwachstellen
5.4.1 Java ME
5.4.2 Android
5.4.3 .NET Compact Framework
5.4.4 Webbasierte Implementierung
5.5 Performanz und Freigabe von Speicherplatz
5.5.1 Java ME
5.5.2 Android
5.5.3 .NET Compact Framework
5.5.4 Webbasierte Implementierung
5.6 Nutzung nativer Methoden und Hardwareunterstützung
5.6.1 Java ME
5.6.2 Android
5.6.3 .NET Compact Framework
5.6.4 Webbasierte Implementierung
5.7 Unterstützung von Schnittstellen
5.7.1 Java ME
5.7.2 Android
5.7.3 .NET Compact Framework
5.7.4 Webbasierte Implementierung
5.8 Entwicklungsumgebungen
5.8.1 Die Wahl der Entwicklungsumgebungen
5.8.2 Installation und Bedienbarkeit
5.8.3 Möglichkeiten zur Gestaltung der Benutzeroberfläche (GUI Designer)
5.8.4 Emulatoren-Unterstützung
5.8.5 Hilfsfunktionalitäten bei Fehlersuche und Eingabe
5.8.6 Dokumentation
5.9 Dokumentation, Entwickler Community und Support
5.9.1 Java ME
5.9.2 Android
5.9.3 .NET Compact Framework
5.9.4 Webbasierte Implementierung
5.10 Kosten und Lizenzen
5.10.1 Java ME
5.10.2 Android
5.10.3 .NET Compact Framework
5.10.4 Webbasierte Implementierung
5.11 Fazit des Vergleichs und Empfehlung einer Plattform für die Entwicklung eines Ambient Campus Systems

6 Portierung einer Java Desktop-Anwendung auf mobile Plattformen
6.1 Das Zeichenprogramm als Java Applikation für Java ME
6.2 Das Zeichenprogramm als Java Applikation für das .NET Compact Framework
6.3 Das Zeichenprogramm als Java Applet für die webbasierte Implementierung

7 Vergleich der Portierbarkeit anhand einer bestehenden Beispielanwendung inJava ME
7.1 Beschreibung des mobilen Nachrichtensystems
7.2 Portierung des mobilen Nachrichtensystems nach Android
7.3 Portierung des mobilen Nachrichtensystems nach .NET Compact Framework
7.4 Portierung des mobilen Nachrichtensystems in eine webbasierte Implementierung
7.5 Fazit

8 Kapitelübergreifendes Fazit mit Empfehlungen für die Anwendungsentwicklung

Glossar

Literaturverzeichnis

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 Framework 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

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

Tabellenverzeichnis

Tabelle 1: Betriebssystemmatrix des .NET Compact Frameworks [angelehnt an [Rob05]

Tabelle 2: Vergleichsmatrix aller Plattformen

Tabelle 3: Zusammengefasste Vergleichsmatrix

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

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ülerund 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 ortsbezogene 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.

2 Architekturen und Anforderungen mobiler Anwendungen am Beispiel eines Ambient Campus Systems

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

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.

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 miteinander 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.

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-, Anwendungsund 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 Anwendungsund Datenschicht.

Abbildung in dieser Leseprobe nicht enthalten

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

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äsentationsund 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 Zeitaufwand 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.

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 performant 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.

Abbildung in dieser Leseprobe nicht enthalten

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

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äftsund 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 Sessionund 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 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 Anwendungsund Datenschicht gibt. Die auf dem Client vorhandenen Komponenten der Anwendungsschicht für Geschäftslogik, Sessionund 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äftsund Präsentationslogik.

Abbildung in dieser Leseprobe nicht enthalten

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

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 Clientund 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äftsund 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 wurden, mit denen des Servers synchronisiert werden, sobald wieder eine Verbindung möglich ist. Weitere Nachteile sind auch bei dieser Architektur wieder die geringe Bandbreite, die Netzabdeckung und die Clientund Server-Performance. Zudem kommt hinzu, dass bei dieser Architektur der Client deutlich komplexer ist als bei den beiden vorangegangenen Architekturen, was somit zu einem höheren Administrationsaufwand führt.

2.2.4 Fat-Client Offline-Architektur

Die Fat-Client Offline-Architektur ist, wie man anhand von Abbildung 4 erkennen kann, ähnlich aufgebaut wie die zuvor erläuterte Rich-Client Hybrid-Architektur. Der wesentliche Unterschied besteht allerdings darin, dass bei der Fat-Client Offline-Architektur die komplette Anwendung auf dem Client liegt und keine online Nutzung der Anwendung vorgesehen ist. Das heißt, dass der Nutzer die Anwendung offline betreibt und nur an bestimmten Standpunkten in der Umgebung eine Synchronisation der auf dem Client geänderten Daten mit denen des Servers vornimmt. Da sich bei diesem Szenario sowohl die Präsentationsals auch die Geschäftslogik komplett und exklusiv auf dem Client befinden, müssen auch eventuelle Updates über den Synchronisationsprozess an den festgelegten Synchronisations-Standorten durchgeführt werden.

Abbildung in dieser Leseprobe nicht enthalten

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

Der große Vorteil bei dieser Architektur ist somit die Tatsache, dass keine Netzwerkverbindung benötigt wird. Dies ermöglicht eine Nutzung der Anwendung in fast jeder Umgebung und schließt gleichzeitig Performanceprobleme und Kosten für eine Datenübertragung aus. Weiterhin kann auch bei dieser Architektur die Benutzeroberfläche komplett frei gestaltet werden.

Die Nachteile bestehen zum einen in der Notwendigkeit der kontinuierlichen Entwicklung und Verbreitung der Komponenten für das Updatehandling und die Synchronisation und zum anderen darin, dass jeder Anwender selbst dafür verantwortlich ist, wann und ob er ein Update oder eine Synchronisation vornimmt. Somit kann keine festgelegte Aktualität von Daten und Komponenten gewährleistet werden.

2.3 Erfüllung der Anforderungen durch die einzelnen Architekturen

Im folgenden Kapitel werden die im vorigen Kapitel herausgearbeiteten Architekturen dahin gehend verglichen, welche Anforderungen aus Kapitel 2.1 sie in wie weit erfüllen bzw. nicht erfüllen.

Abbildung 5 verdeutlicht noch einmal zusammengefasst die Vorund Nachteile der Architekturen in Bezug auf die Anforderungen.

Abbildung in dieser Leseprobe nicht enthalten

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

Es wird deutlich, dass bei der Anwendungsnutzung in einem Büro oder einem Stadtgebiet alle Architekturen ähnlich bzw. gleich gut hinsichtlich einer möglichen Verbindung zu einem mobilen Netzwerk geeignet sind. Soll die Anwendung in ländlichem Gebiet genutzt werden sind ggf. die beiden Always-Online Architekturen nicht so gut geeignet. Hier müsste im Vorfeld die genaue Verbindungsleistung getestet werden.

Bei der Datenaktualität kommt es darauf an, ob Daten in Echtzeit gewünscht sind, eine relativ hohe Aktualität benötigt wird oder ob auch eine geringere Aktualität der Daten möglich wäre. Werden Echtzeitdaten benötigt, kommen, aufgrund ihrer ständigen Verbindung mit dem Netzwerk, nur die Always-Online Architekturen in Frage. Auch bei relativ hoher Aktualität sind diese Architekturen zu wählen, wobei dort auch die Rich-Client Hybrid-Architektur in Frage kommt, da sie für eine permanente Verbindung ausgelegt ist und auch immer verbunden ist, wenn die Möglichkeit einer Verbindung besteht. Bei geringem Aktualitätswunsch können alle Architekturen gleich gut verwendet werden.

Kann die Softwareverteilung offline erfolgen können alle Architekturen gewählt werden. Soll die Verteilung online erfolgen, sind alle bis auf die Fat-Client Offline-Architektur geeignet, da bei dieser nicht gewährleistet werden kann, wann die Verteilung dann auch wirklich erfolgt. Ist keine Verteilung gewünscht, ist nur die webbasierte Always-Online Architektur geeignet, da nur dort die komplette Anwendungslogik auf dem Server liegt.

Beim Design der Benutzerschnittstelle sind bis auf eine Ausnahme alle Architekturen gleich gut geeignet, egal ob die Oberfläche vergleichsweise umfangreich oder einfach implementiert werden soll. Die Ausnahme liegt in der webbasierten Always-Online Architektur. Diese ist nicht so gut geeignet bei dem Wunsch nach einer umfangreichen Implementierung, da bei dieser Architektur die komplette Präsentationslogik auf dem Server liegt und je umfangreicher diese ist, desto mehr Daten müssen zum Client übertragen werden.

Als letzte Anforderung spielt die Sicherheit der Anwendung eine Rolle. Hier ist die Frage nach der Art der gewünschten Organisation zu stellen. Kann es eine dezentrale Organisation geben sind wieder alle Architekturen gleich gut geeignet. Soll es allerdings eine zentrale Organisation geben sind nur die beiden Always-Online Architekturen gut geeignet, da nur diese beiden absolut sicher stellen, dass immer mit dem zentralen Datenbestand gearbeitet wird.

Man kann also zusammenfassend sagen, dass es nicht „die eine“ Architektur für die mobile Anwendungsentwicklung gibt, sondern dass zu jeder Anwendung individuell eine geeignete Architektur gewählt werden muss. Jede Anwendung hat ihre eigenen unterschiedlichen Anforderungen und somit kann dieser Überblick lediglich als eine Hilfe bei der Bestimmung der zu wählenden Architektur verstanden werden.

2.4 Empfehlung einer Architektur für die Entwicklung mobiler Anwendungen im Rahmen eines Ambient Campus Systems

In diesem Kapitel geht es darum aus den gewonnenen Informationen zu Anforderungen an eine mobile Anwendung und deren Abdeckungen durch die verschiedenen Architekturen eine Empfehlung für eine Architektur für ein Ambient Campus System zu geben.

Wie allerdings am Schluss des vorigen Kapitels festgestellt wurde, gibt es keine Architektur, die für ein ganzes System global gewählt die Richtige sein kann. Es muss für jede einzelne Anwendung des Systems im Vorfeld geprüft werden, welche Architektur in Frage kommt bzw. die beste Wahl darstellt.

Es kann in diesem Fall also nur beispielhaft für die in Kapitel 1.2 vorgestellten Anwendungen eine Empfehlung abgeben werden.

2.4.1 Das Ortungssystem

Für diese Anwendung käme meiner Ansicht nach generell nur eine der beiden Always-Online Architekturen in Frage, da für eine Ortung sinngemäß immer Echtzeitdaten benötigt werden. Außer man verzichtet auf die dynamische Einbeziehung sich bewegender Objekte wie Personen. Man würde in diesem Fall das Kartenmaterial einmal laden und sich wieder verbinden, um von der jetzigen Position aus den Weg zu einem definierten Ort (bspw. Büro oder Mensa) zu bekommen. In diesem Fall wäre dann auch die Rich-Client Hybrid-Architektur denkbar.

Je nachdem wie hoch das benötigte Datenvolumen für die Ortung an sich schon ist (ohne die Übertragung der Präsentationslogik) und wie umfangreich die Benutzeroberfläche der Anwendung gestaltet werden soll, ist jeweils eine der beiden Always-Online-Architekturen vorzuziehen. Wird durch die Ortungsfunktion, also die Geschäftslogik, schon ein sehr hohes Datenvolumen benötigt und soll die Oberfläche zusätzlich aufwändig gestaltet werden so ist die Rich- Client Always-Online Architektur vorzuziehen. Bei dem Wunsch nach einer vergleichsweise weniger aufwändigen Oberfläche wäre die webbasierte Always-Online Architektur eine gute Alternative, genauso wie bei einer Geschäftslogik, die nicht so viel des zur Verfügung stehenden Datenvolumens aufbraucht.

2.4.2 Das Nachrichtensystem

Hier ist nicht nur eine Always-Online Architektur denkbar, sondern durchaus auch eine Architektur, bei der nur ab und zu eine Verbindung mit dem Netzwerk aufgebaut wird (wie bei der Rich-Client Hybrid-Architektur). Der Einsatz der Rich-Client Hybrid-Architektur würde es dem Anwender ermöglichen jederzeit, auch wenn er einmal keine Verbindungsmöglichkeit hat, eine Nachricht auf seinem Endgerät zu verfassen. Sobald die Verbindung wieder verfügbar ist kann er dann die Nachricht abschicken und auch selber Nachrichten empfangen. Dies erscheint sinnvoll, da zum eigentlichen Verfassen nicht unbedingt eine Verbindung benötigt würde, sofern die Präsentationsschicht und ein Teil der Geschäftslogik auf dem Client implementiert wurden.

Sollte allerdings im ganzen Nutzungsbereich der Anwendung eine konstant gute Verbindungsmöglichkeit herrschen wäre auch eine der beiden Always-Online Architekturen denkbar, je nachdem wie umfangreich die Benutzerschnittstelle gestaltet werden soll wäre eine der beiden vorzuziehen.

3 Beschreibung ausgewählter Plattformen und Frameworks

Im folgenden Kapitel wird eine einführende Beschreibung der ausgewählten Entwicklungsplattformen gegeben. Dies soll dem Leser einen ersten Überblick geben, worum es sich bei den einzelnen Plattformen genau handelt.

3.1 Java ME

Java ME wird von Sun Microsystems speziell für die Anwendungsentwicklung auf mobilen Endgeräten zur Verfügung gestellt. Es handelt sich dabei um eine Teilmenge der bekannten Java Plattform. Die Entwicklungssprache ist also ausschließlich Java.

Im Hinblick auf besondere Herausforderungen bei der Anwendungsentwicklung für mobile Endgeräte (wie bspw. die geringe Speicherkapazität) beinhaltet Java ME nur eine speziell ausgewählte Anzahl an APIs. Java ME wird in den JSRs 30 (J2ME Connected Limited Device Configuration) und 37 (Mobile Information Device Profile for the J2ME Platform) festgelegt. JSR steht für “Java Specification Request” und bezeichnet „eine Anforderung einer neuen Java- Spezifikation oder einer wichtigen Änderung einer existierenden Java-Spezifikation“ [Mis07c]. Anhand der JSRs kann definiert werden, welches Endgerät welche Funktionen unterstützt.

Eine weitere in diesem Kontext nennenswerte JSR ist die JSR-82 (API für Bluetooth). Diese JSR wird nämlich nicht von jedem Handy unterstützt. Es kann also durchaus sein, dass eine Anwendung, die auf einer bestimmten JSR basiert, auf einem Handy nicht lauffähig ist, obwohl dieses Handy Java ME als Plattform zunächst grundsätzlich unterstützt.

Die Grundlage von Java ME wird durch die sogenannten Konfigurationen und Profile gebildet. Zudem können auch optional Erweiterungen enthalten sein (siehe Abbildung 6).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 6: Java ME im Überblick [angelehnt an [Ted06]

Die Konfigurationen (siehe Abbildung 6) stellen in diesem Zusammenhang jeweils Kern- Bibliotheken (Core Libraries), eine virtuelle Maschine (Java Virtual Machine) und Java als Sprache zur Verfügung. Es gibt derzeit zwei mögliche Konfigurationen, die diese drei Bestandteile beinhalten:

- Die Connected Limited Device Configuration (CLDC)
- Die Connected Device Configuration (CDC)

Die CLDC setzt ihren Fokus dabei eher auf Endgeräte mit beschränkter Speicherausstattung, geringer Rechenleistung und Bandbreite sowie oftmals instabilen Netzwerkverbindung, wie es z.B. bei Mobiltelefonen der Fall ist. Die CDC hingegen eignet sich für Endgeräte mit größerer Speicherausstattung, dauerhaften Netzwerkverbindungen und vielfältigen Benutzerschnittstellen, wie z.B. bei Autonavigationssystemen oder Bildtelefonen [Tan07].

Derzeit gibt es nur diese zwei Konfigurationen, wobei die CLDC einen starken Zuwachs verzeichnet, da sehr viele aktuelle Handys diese Konfiguration nutzen [Mis08b].

Einen Überblick über die Anwendungsbereiche von CDC und CLDC gibt Abbildung 7. Sie verdeutlicht noch einmal die unterschiedlichen Einsatzbereiche der beiden Konfigurationen und gibt zudem einen Überblick über die eingegrenzte Nutzung von Java ME (J2ME) im Vergleich zu den anderen Java Plattformen J2SE und J2EE.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 7: Anwendungsbereiche von CDC und CLDC [angelehnt an [Tan07]

Bei den Profilen (siehe Abbildung 6) handelt es sich um die APIs, die es zu einer Konfiguration gibt. Vor allem für Handys existiert das MIDP Profil zusammen mit der CLDC Konfiguration. Zudem gibt es sogenannte MIDlets. Dies sind Java-Anwendungen, die auf der Grundlage der MIDP entwickelt wurden (bspw. diverse Java Spiele für Handys) [Mis08b]. Das MIDP wurde derzeit bis zur Version 3.0 weiter entwickelt und unterstützt nun höhere Auflösungen und eine größere Farbpalette zur Wiedergabe der GUI [Hop07]. Diese Version wird derzeit allerdings noch von keinem Endgerät unterstützt und die gängige Version ist 2.0. Sie wird von fast jedem Handy unterstützt, das nicht älter als zwei Jahre ist [ET07].

3.2 Android

Android ist eine noch sehr junge Plattform zur Entwicklung von Anwendungen für mobile Endgeräte. Am 5. November 2007 verkündete Google, dass sie und 33 weitere Mitglieder der Open Handset Alliance ein Handy-Betriebssystem namens Android entwickeln. Es ist angedacht, dass die ersten Endgeräte mit diesem Betriebssystem in der zweiten Hälfte des Jahres 2008 auf den Markt kommen [Mis08a].

Es handelt sich bei Android um eine Sammlung von Software für mobile Geräte, die ein Betriebssystem, eine Middleware sowie Schlüsselapplikationen enthält. Android selbst basiert auf einem Linux Kernel. Entwickler können mittels der bereits verfügbaren Android SDK Anwendungen für die Plattform entwickeln. Diese Anwendungen werden ausschließlich in Java programmiert und laufen auf der angepassten virtuellen Maschine Dalvik [Goo08d].

Die folgende Abbildung gibt einen Überblick über die wichtigsten Komponenten des Android Betriebssystems.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 8: Android Überblick [angelehnt an [Goo08d]

Applications sind dabei eine Reihe an Kernanwendungen, die mit Android mitgeliefert werden (wie bspw. ein Browser) [Goo08d].

Das Application Framework ermöglicht es dem Entwickler mit denselben Framework APIs zu arbeiten, die auch von den Kernanwendungen genutzt werden [Goo08d].

Android enthält zudem eine Reihe an C/C++ Bibliotheken (Libraries), die von verschiedenen Komponenten des Systems genutzt werden. Diese Möglichkeiten werden dem Entwickler durch das Application Framework zugänglich gemacht [Goo08d].

Android beinhaltet weiterhin sogenannte Kernbibliotheken, die fast alle Funktionalitäten abdecken, die auch die Kernbibliotheken von Java bieten. Zudem läuft jede Android Anwendung mit einer eigenen Instanz der virtuellen Dalvik Maschine [Goo08d].

Der Linux Kernel agiert als abstrakte Schicht zwischen Hardware und der restlichen Softwareschicht. Er beinhaltet diverse Services (bspw. Treiber) für den Systemkern. Android basiert auf der Version 2.6 des Kernels [Goo08d].

3.3 .NET Compact Framework

Das .NET Compact Framework ist als Teil des .NET-Frameworks zu verstehen. Es wurde extra für die Nutzung auf mobilen Endgeräten ausgelegt, so dass .NET Entwickler leichter Anwendungen für mobile Endgeräte entwickeln zu können [Mis08d].

Technisch ist das .NET Compact Framework eine Laufzeitumgebung bzw. Klassenbibliothek. Es ist allerdings, verglichen mit dem normalen .NET Framework, um eine Vielzahl an Klassen gekürzt worden, da viele Klassen entweder in dem Entwicklungszusammenhang für mobile Endgeräte gar nicht benötigt werden oder durch sie ein zu hoher Speicherbedarf geschaffen wurde [Mis08d].

Eingeführt wurde das .NET Compact Framework 1.0 im Jahre 2003 in Verbindung mit Microsoft Visual Studio 2003. Anwendungen für dieses Framework können mit einer der .NET- Sprachen entwickelt werden (VB.NET und C#). Es ist auch möglich einen Handheld am PC zu emulieren, dies geschieht mit Hilfe der Smart Device Extensions für Microsofts Entwicklungsumgebung Visual Studio [Mis08d]. Das Compact Framework wird, abhängig von seiner jeweiligen Version und Entwicklungsumgebung, ab Microsoft Pocket PC 2002 (später in Windows Mobile umbenannt) und Smartphone 2003 unterstützt [Rob05]. Pocket PC basiert auf dem Betriebssystemkern von Windows CE und erweitert dessen Funktionsumfang um speziell auf Taschencomputer abgestimmte Features [Mis08e]. Windows Smartphone basiert auch auf Windows CE und ist für Mobiltelefone ausgelegt, die, im Gegensatz zu einem Pocket PC, meist keinen Touchscreen besitzen und eher einem Handy als einem PDA ähneln [Mis08e].

Um einen genaueren Überblick über die bislang existierenden Versionen von Pocket PC und Smartphone zu erhalten folgen Versionsübersichten beider Systeme:

Microsoft Windows CE und Pocket PC (übernommen aus [Mis08e]):

- Microsoft Windows CE 1.0
- Microsoft Windows CE 1.1
- Microsoft Windows CE 2.0 gefolgt von 2.01 und 2.02
- Microsoft Windows CE 2.1 gefolgt von 2.11 und 2.12
- Microsoft Pocket PC 2000 (basiert auf Windows CE 3.0)
- Microsoft Pocket PC 2002 (basiert ebenfalls auf Windows CE 3.0)
- Microsoft Windows Mobile 2003 für Pocket PC (basiert auf WinCE 4.2)
- Microsoft Windows Mobile 2003 Second Edition (basiert auf WinCE 4.21)
- Microsoft Windows Mobile 5.0 (basiert auf Windows CE 5.0)
- Microsoft Windows Mobile 6.0 (basiert auf Windows CE 5.2)

Windows Powered Smartphone (übernommen aus [Mis08g]):

- Windows Smartphone 2002
- Windows Mobile for Smartphones 2003
- Windows Mobile for Smartphones 2003 Second Edition
- Windows Mobile 5.0 (ehemals Windows Mobile for Smartphones 2005)
- Windows Mobile 6 Standard

Die Tatsache, dass verschiedene Versionen des Frameworks in Kombination mit verschiedenen Versionen der Entwicklungsumgebung teilweise, nur begrenzt oder auch gar nicht diverse Versionen von Smartphones und Pocket PCs unterstützen, dürfte demnach die Entwicklung für möglichst viele unterschiedliche mobile Endgeräte deutlich erschweren.

Da das .NET Compact Framework eine Teilmenge des normalen .NET-Frameworks ist, erbt es die vollständige .NET Framework-Architektur der Common Language Runtime für die Ausführung verwalteten Codes. Die Architektur ermöglicht die Zusammenarbeit mit dem Windows CE-Betriebssystem eines Geräts, damit der Entwickler auf systemeigene Funktionen zugreifen und bevorzugte systemeigene Komponenten in eine Anwendung integrieren kann. So können verwaltete und systemeigene Anwendungen gleichzeitig ausgeführt werden, da eine Instanz der Common Language Runtime für die Ausführung von verwaltetem Code gestartet wird [Mic08c].

Eine Übersicht über die Plattformarchitektur des .NET Compact Frameworks ist in Abbildung 9 dargestellt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 9: .NET Compact Framework Architektur [angelehnt an [Mic08c]

Das Betriebssystem Windows CE wird vom .NET Compact Framework für die Kernfunktionen und diverse gerätespezifische Features eingesetzt (siehe Abbildung 9). Durch die Neuerstellung mehrerer Typen und Assemblys (bspw. für Windows Forms, Grafiken, Zeichenvorgänge und Webdienste), können diese auf Geräten ausgeführt werden ohne sie vorher aus dem vollständigen .NET Framework kopieren zu müssen [Mic08c].

Auch die Common Language Runtime des .NET Compact Frameworks (siehe Abbildung 9) wurde abgeändert. So sollen Ressourcen mit begrenztem Arbeitsspeicher ausgeführt und Akkukapazitäten besser genutzt werden können. Weiterhin besteht eine in der Abbildung nicht dargestellte Anpassungsschicht für Plattformen zwischen der Runtime und Windows CE. Diese Schicht ermöglicht die Zuordnung der von der Runtime und dem Framework benötigten Diensten zu Windows CE-Diensten und –Schnittstellen [Mic08c], Das Framework an sich umfasst, wie bereits erwähnt, einen Teil der Funktionalität des .NET Frameworks und enthält darüber hinaus weitere Features, die ausschließlich für das .NET Compact Framework entwickelt wurden [Mic08c].

Zu den möglichen Entwicklungsumgebungen lässt sich festhalten, dass es zwar freie Tools, wie bspw. Embedded Visual Basic/C++ von Microsoft, gibt, diese allerdings längst nicht so umfangreich und komfortabel sind wie Visual Studio von Microsoft.

3.4 Webbasierte Implementierung

Unter webbasierter Entwicklung ist eine Entwicklung zu verstehen, bei der die spätere Anwendung komplett auf einem Server läuft und für den Client nur mittels eines Browsers erreichbar ist. Hier käme dann die bereits in Kapitel 2.2.1 erwähnte webbasierte Always-Online Architektur zum Einsatz, sofern eine ständige Verbindung benötigt würde. Es ist allerdings auch denkbar, dass der gesamte Kontext auf dem Server liegt, man aber trotzdem nicht immer eine Verbindung benötigt, bspw. durch JavaScript-Unterstützung des Clients. Dies wäre eine alternative Architekturvariante.

Wie in Abbildung 10 dargestellt sind die Clients (in diesem Fall die mobilen Endgeräte) durch das Internet mit dem Webserver verbunden. Als Webserver kann bspw. der Webserver von Apache gewählt werden. In diesem Kontext verweise ich auf die in Kapitel 2.2.1 enthaltene Abbildung 1, die einen genaueren Einblick in die Struktur zwischen Client und Server vermittelt. Auch wenn hier der Client nicht, wie in Kapitel 2.2.1 angedacht, ständig online sein muss, bildet die Abbildung die Verteilung von Logik und GUI zwischen Client und Server dennoch passend ab.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 10: Webbasierte Implementierung Überblick [angelehnt an [Misd]

[...]