Thesis - netzprofis.de

Bachelor Thesis
zur Erlangung des akademischen Grades
Bachelor of Science (B.Sc.)
an der
Fachhochschule Dortmund
im Fachbereich Informatik
im Studiengang Praktische Informatik
Entwicklung einer Applikation für mobile Endgeräte
mit Anbindung an bestehende Server-Software
Auswahl einer Entwicklungsplattform und
Sportwetten-Prototyps auf Basis von Android
Autor:
Marco Alexander Schmitz
Email:
[email protected]
Matrikel-Nr.:
7040521
Erstprüfer:
Prof. Dr. Johannes Ecke-Schüth
Zweitprüfer:
Prof. Dr. Sabine Sachweh
Abgabe am:
14.09.2009
Realisierung
eines
Inhaltsverzeichnis
Inhaltsverzeichnis
1
2
Einleitung ......................................................................................................................... 1
1.1
Motivation................................................................................................................ 1
1.2
Hintergrund .............................................................................................................. 1
1.3
Vorgehen .................................................................................................................. 2
Wahl einer geeigneten Entwicklungsplattform ............................................................... 3
2.1
2.1.1
Übersicht der Java-Plattformen ....................................................................... 3
2.1.2
Architektur ....................................................................................................... 4
2.1.3
Softwareentwicklung ....................................................................................... 5
2.1.4
Alternative GUI Frameworks .......................................................................... 10
2.1.5
Zusammenfassung und Bewertung................................................................ 16
2.2
Apple iPhone .......................................................................................................... 17
2.2.1
Produktlinie .................................................................................................... 17
2.2.2
Betriebssystem ............................................................................................... 18
2.2.3
iTunes und Alternativen ................................................................................. 19
2.2.4
Softwareentwicklung ..................................................................................... 20
2.2.5
Zusammenfassung und Bewertung................................................................ 21
2.3
Google Android ...................................................................................................... 22
2.3.1
Google Inc. ..................................................................................................... 22
2.3.2
Android........................................................................................................... 23
2.3.3
Open Handset Alliance ................................................................................... 24
2.3.4
Android Developer Challenge ........................................................................ 27
2.3.5
Zusammenfassung und Bewertung................................................................ 29
2.4
3
Java Platform, Micro Edition .................................................................................... 3
Gegenüberstellung und Bewertung der Plattformen ............................................ 30
Android im Detail ........................................................................................................... 32
3.1
Architektur ............................................................................................................. 32
3.1.1
Applications .................................................................................................... 33
3.1.2
Application Framework .................................................................................. 33
3.1.3
Libraries .......................................................................................................... 34
3.1.4
Android Runtime ............................................................................................ 35
3.1.5
Linux Kernel .................................................................................................... 36
III
Inhaltsverzeichnis
4
3.2
Software Development Kit ..................................................................................... 37
3.3
Entwicklungswerkzeuge ......................................................................................... 38
3.3.1
Android Emulator ........................................................................................... 38
3.3.2
Hierarchy Viewer ............................................................................................ 40
3.3.3
Draw 9-patch .................................................................................................. 40
3.3.4
Dalvik Debug Monitor Service ........................................................................ 42
3.3.5
Android Debug Bridge .................................................................................... 43
3.3.6
Android Asset Packaging Tool ........................................................................ 43
3.3.7
Android Interface Description Language........................................................ 44
3.3.8
sqlite3 ............................................................................................................. 44
3.3.9
mksdcard ........................................................................................................ 45
3.3.10
Dalvik Cross-Compiler .................................................................................... 45
3.3.11
UI/Application Exerciser Monkey ................................................................... 46
3.3.12
activitycreator ................................................................................................ 46
3.4
Android Development Toolkit Plug-In für Eclipse .................................................. 47
3.5
Endgeräte mit Android-Betriebssystem ................................................................. 48
3.5.1
T-Mobile G1 – HTC Dream.............................................................................. 48
3.5.2
Vodafone G2 – HTC Magic.............................................................................. 50
3.5.3
HTC Hero ........................................................................................................ 51
3.5.4
Kogan Agora ................................................................................................... 52
3.5.5
Lenovo OPhone .............................................................................................. 53
3.5.6
Samsung I7500 Galaxy.................................................................................... 54
Entwicklung eines Anmeldeformulars ........................................................................... 55
4.1
Anforderungen ....................................................................................................... 55
4.2
Erstellung von einem Android Project ................................................................... 55
4.2.1
Manifest ......................................................................................................... 56
4.2.2
Strings-Ressource ........................................................................................... 57
4.2.3
Layout ............................................................................................................. 58
4.2.4
Ressourcen in Java ......................................................................................... 59
4.2.5
Activity ............................................................................................................ 59
4.2.6
Lebenszyklus einer Activity ............................................................................ 60
4.3
Umsetzung ............................................................................................................. 62
4.3.1
Layout ............................................................................................................. 62
4.3.2
Benutzerereignisse ......................................................................................... 63
IV
Inhaltsverzeichnis
4.3.3
Modaler Fehlerdialog ..................................................................................... 64
4.3.4
Kontextmenü.................................................................................................. 65
4.3.5
Persistenz ....................................................................................................... 66
4.4
4.4.1
Hintergrundgrafik ........................................................................................... 67
4.4.2
Button mit NinePatch-Grafik .......................................................................... 68
4.5
5
Anpassung der GUI-Komponenten ........................................................................ 67
Internationalisierung .............................................................................................. 69
4.5.1
Strings-Ressource ........................................................................................... 69
4.5.2
Umschalten der Ländereinstellung ................................................................ 71
Entwicklung eines Sportwetten-Prototyps .................................................................... 72
5.1
Sportwetten ........................................................................................................... 72
5.2
Grafische Benutzerschnittstelle ............................................................................. 73
5.2.1
Aktivitätsdiagramm ........................................................................................ 73
5.2.2
Listen .............................................................................................................. 74
5.2.3
Dynamisches Layout mit Java ........................................................................ 75
5.3
Integration des Frameworks log4j ......................................................................... 77
5.3.1
log4J ............................................................................................................... 77
5.3.2
Probleme bei der Integration ......................................................................... 77
5.3.3
Logging mit Android ....................................................................................... 78
5.3.4
Problemlösungen ........................................................................................... 78
5.4
Integration der bestehenden Klasse EntityStore ................................................... 81
5.4.1
Serialisierung und Deserialisierung ................................................................ 81
5.4.2
Fehlende Klassen............................................................................................ 82
5.4.3
Core-Library.................................................................................................... 83
5.5
Dependency Viewer ............................................................................................... 84
5.5.1
Classycle ......................................................................................................... 85
5.5.2
Ant .................................................................................................................. 85
5.5.3
Verarbeitung der XML-Datei .......................................................................... 86
5.5.4
Algorithmus .................................................................................................... 86
5.5.5
Ausgabe als HTML .......................................................................................... 86
5.5.6
DependencyViewer als Ant-Task.................................................................... 87
5.6
Serveranbindung .................................................................................................... 88
5.6.1
Servlet ............................................................................................................ 89
5.6.2
Client .............................................................................................................. 90
V
Inhaltsverzeichnis
6
Fazit ................................................................................................................................ 91
Abkürzungsverzeichnis ........................................................................................................... 93
Abbildungsverzeichnis ............................................................................................................ 95
Tabellenverzeichnis ................................................................................................................ 97
Literaturverzeichnis ................................................................................................................ 99
Eidesstattliche Erklärung ...................................................................................................... 106
VI
1 Einleitung
1 Einleitung
Dieses Kapitel bietet eine Einleitung in das Thema „Entwicklung einer Applikation für
mobile Endgeräte mit Anbindung an bestehende Server-Software – Auswahl einer
Entwicklungsplattform und Realisierung eines Sportwetten-Prototyps auf Basis von
Android“. Im ersten Abschnitt wird die Entwicklung einer solchen Applikation motiviert.
Anschließend wird der Hintergrund dieser Arbeit geschildert. Im letzen Abschnitt wird das
Vorgehen dieser Arbeit beschrieben.
1.1 Motivation
„Spiele, Routenplaner, Wetterinfos, Trinkgeldrechner und so weiter – stündlich steigt die
Zahl der Anwendungen, die man aufs Handy laden kann. Offiziell heißen die Programme
mobile Applikationen, umgangssprachlich werden sie Apps genannt. In Apples App Store
gibt es davon die größte Auswahl: mehr als 60.000 Anwendungen. Die Amerikaner haben
im Geschäft mit den mobilen Applikationen die Nase vorn – im Juli 2009, ein Jahr nach
Eröffnung des App Stores, wurde bereits die Marke von 1,5 Milliarden Downloads
durchbrochen. […] Der Geschäftserfolg des App Stores hat die Wettbewerber auf den Plan
gerufen: Nokias Ovi Store ist im Mai 2009 an den Start gegangen. […] Googles Pendant, der
Android Market, bietet sogar über 5.000 Programme für diverse Mobiltelefon-Modelle an.
[…] Blackberry betreibt die App World, und vor kurzem hat Sony Ericsson die Pforten der
PayNow Arena für Spiele, Musik und anderes eröffnet. Und die Zahl der appfähigen
Mobiltelefone wächst stetig.“ 1
1.2 Hintergrund
In dem Zeitraum 1.5.2008 bis 13.7.2009 hat der Autor freiberuflich für die Firma netzprofis
GmbH & Co. KG in Dortmund gearbeitet 2. Das mittelständische Unternehmen, unter der
Geschäftsführung von Dipl.-Inf. Thomas Louis und Dipl.-Inf. Marcel Gleis, ist spezialisiert auf
die Entwicklung von Individualsoftware für Unternehmen. Für die Firma Booxware GmbH,
mit Geschäftssitz in Karlsruhe, wird seit vielen Jahren komplexe Software im Bereich der
Sportwetten entwickelt, getestet und gepflegt. Der Autor wurde damit beauftragt, diese in
der Programmiersprache Java geschriebene Software auf mobile Endgeräte nachzubilden
und dabei möglichst viele Quelltexte zu adaptieren. Nach sorgfältiger Recherche und
Evaluation fiel die gemeinsame Wahl auf die Entwicklungsplattform Android.
1
2
[Davi09]
Fortan wird die Firma netzprofis GmbH & Co. KG als Auftragsgeber bezeichnet.
1
1 Einleitung
1.3 Vorgehen
Am Anfang steht die Wahl einer geeigneten Entwicklungsplatform für mobile Endgeräte. Es
werden Java ME, iPhone und Android einzeln vorgestellt und bewertet. Am Ende des
Kapitels erfolgen eine Gegenüberstellung und die Entscheidungsfindung.
In Kapitel 3 wird Android detailliert betrachtet. Hierbei stehen die die Architektur, das SDK
und die Entwicklungswerkzeuge im Mittelpunkt. Der letzte Abschnitt gilt den Endgeräten
mit Android-Betriebssystem samt kritischen Stimmen.
Kapitel 4 beinhaltet die exemplarische Entwicklung einer Anmeldeformular-Applikation mit
Android. Nach der Zusammenfassung der Anforderungen wird gezeigt, wie mit der Eclipse
ein Projekt erstellt und die Anforderungen umgesetzt werden. Anschließend werden GUIKomponenten angepasst und die Applikation internationalisiert.
Kapitel 5 erklärt Sportwetten im Allgemeinen und die Realisierung des Prototyps. Aufgrund
der Schwierigkeiten bei der Integration bestehender Java-Bibliotheken in Android wird ein
spezielles Werkzeug zur Darstellung von Abhängigkeitsbäumen entwickelt und vorgestellt.
Im Anschluss daran wird der Prototyp an bestehende Server-Software angebunden.
Im letzen Kapitel folgt das Fazit, in dem die Umsetzung bewertet wird und gewonnene
Erkenntnisse und Erfahrungen geschildert werden.
2
2 Wahl einer geeigneten Entwicklungsplattform
2 Wahl einer geeigneten Entwicklungsplattform
In diesem Kapitel wird nach einer geeigneten Entwicklungsplattform für mobile Endgeräte
gesucht. Oberstes Ziel ist es, möglichst viele Java-Quelltexte der bereits existierenden
Software aus dem Bereich der Sportwetten zu adaptieren. Zur Wahl dabei stehen:
Plattform
Java ME
Apple iPhone
Google Android
Beschreibung
seit vielen Jahren etablierter Standard im Java-Umfeld
modernes Smartphone mit ansprechender Oberfläche
Betriebssystem und Softwareplattform für Smartphones
und Mobiltelefone
Tab. 1: Übersicht Entwicklungsplattformen
In den ersten drei Unterkapiteln werden die Plattformen einzeln vorgestellt und bewertet.
Am Ende des Kapitels erfolgen eine Gegenüberstellung und die Auswahl der geeigneten
Entwicklungsplattform.
2.1 Java Platform, Micro Edition
In diesem Unterkapitel wird die Java Platform, Micro Edition vorgestellt. Im ersten Schritt
wird diese unter den anderen existierenden Java-Plattformen eingeordnet und die
Architektur erläutert. Anschließend wird untersucht, wie Software mit Java ME entwickelt
wird, welche Werkzeuge existieren und welche zusätzlichen oder alternativen Frameworks
benötigt werden. Im letzen Abschnitt erfolgt eine Zusammenfassung und Bewertung.
2.1.1
Übersicht der Java-Plattformen
„Auf der weltweit größten Java-Entwicklerkonferenz, der JavaOne in San Francisco stellte
Alan Baratz, Präsident von Java-Software, 1999 die neue Plattformarchitektur vor [sic!]. Die
etablierte Java 2 Technologie wurde aufgrund der Komplexität und des wachsenden
Marktes in drei Ausbaustufen unterteilt: die Java 2 Enterprise Edition (J2EE) für den Einsatz
auf Serversystemen, die Java 2 Standard Edition (J2SE) für normale Desktoprechner und die
Java 2 Micro Edition, welche speziell auf Nicht-PC-Geräte zugeschnitten ist.“ 3 Folgende
Abbildung zeigt die unterschiedlichen Java-Plattformen:
3
[Karb05, S. 9]
3
2 Wahl einer geeigneten Entwicklungsplattform
Abb. 1: Die unterschiedlichen Java-Plattformen [Java09]
Die Java-Plattformen Java Platform, Enterprise Edition (Java EE) 4 und Java Platform,
Standard Edition (Java SE) 5 können für mobile Endgeräte nicht verwendet werden, da diese
aufgrund der Batterietechnologie bezüglich Prozessorleistung und Speicherausstattung
eingeschränkt sind. Ebenfalls ist die Größe des Displays beschränkt, da der Trend zu immer
kleineren Geräten geht.
2.1.2
Architektur
Um der ungeheuren Vielfalt an technischen Möglichkeiten gerecht zu werden besteht die
Plattform Java Platform, Micro Edition (Java ME) 6 aus einer Vielzahl Spezifikationen und
Technologien, die speziell für mobile Endgeräte zugeschnitten sind. Die Architektur basiert
auf Konfigurationen, die von Profilen erweitert werden. Hinzu kommen optionale Pakete
für Spezialfälle wie XML-Parser oder Datenbankanbindungen. Es lassen sich zwei
Konfigurationen unterscheiden: 7
■ Connected Device Configuration (CDC)
■ Connected Limited Device Configuration (CLDC)
4
Wurde früher auch als Java 2 Enterprise Edition (J2EE) bezeichnet.
Wurde früher auch als Java 2 Standard Edition (J2SE) bezeichnet.
6
Wurde früher auch als Java 2 Micro Edition (J2ME) bezeichnet.
7
Vgl. [BrMo06, S. 19 f.]
5
4
2 Wahl einer geeigneten Entwicklungsplattform
CDC und CLDC
Das CDC ist für leistungsfähige High-End PDAs und eingebettete Geräte ausgelegt. Hier wird
von mindestens 2 MB Speicher ausgegangen. Enthalten ist eine Java Virtual Machine (JVM),
ein minimierter Satz von Klassenbibliotheken, das Foundation Profile und das Personal
Profile. 8
Das CLDC wurde für einfache PDAs und Mobiltelefone mit langsamen Prozessoren und
wenig Speicherplatz entwickelt. Die Kilobyte Virtual Machine (KVM) arbeitet mit 128 KB bis
512 KB Speicher und ist als Untermenge der normalen JVM zu verstehen. Zusammen mit
dem Mobile Information Device Profile (MIDP) stellt es folgende benötigte Kernfunktionen
für mobile Anwendungen zur Verfügung: 9
■
■
■
■
Netzwerkanbindung
Lokale Datenhaltung
Benutzerschnittstelle
Anwendungsmanagement
Einschränkungen
Die Klassenbibliotheken von CLDC und KVM sind im Vergleich zu J2SE reduziert und auch im
Funktionsumfang eingeschränkt. Zusammengefasst sind die folgenden Änderungen: 10
■ Bei der Oberklasse Object wurden die Methoden clone und finalize entfernt.
■ Die Fehlerbehandlung ist insofern vereinfacht, als dass ein Error-Objekt zurückgegeben
wird.
■ Der ClassLoader kann nicht durch einen eigenen ausgetauscht werden.
■ Die Klasse ThreadGroup wurde entfernt.
■ Für Klassen, die von Thread erben, gibt es die Methode setDaemon nicht mehr, so dass
keine Daemon Threads mehr möglich sind.
■ Es werden asynchrone Exceptions nicht unterstützt.
■ Es erfolgt immer eine Verifizierung des Bytecodes von Java-Programmen.
2.1.3
Softwareentwicklung
In diesem Unterkapitel werden unterschiedliche Werkzeuge vorgestellt, die für die
Entwicklung einer Software mit Java ME benötigt werden. Anschließend werden die APIs
für die grafische Benutzeroberfläche vorgestellt.
Sun Java Wireless Toolkit for CLDC (WTK)
Um eine Java ME Anwendung, MIDlet genannt, für die Konfiguration CLDC und das Profil
MIDP zu entwickeln, wird neben einem Texteditor und einem installiertem Java SE SDK
noch das Sun Java Wireless Toolkit for CLDC (WTK) benötigt. Dieses aus mehreren
8
Vgl. [BrMo06, S. 19 f.]
[BrMo06, S. 20]
10
Vgl. [BrMo06, S. 36 f.]
9
5
2 Wahl einer geeigneten Entwicklungsplattform
Komponenten bestehende Werkzeug bietet die Möglichkeit Projekte anzulegen und zu
laden, die Quelltexte zu kompilieren und den Bytecode zu verifizieren. Um das MIDlet zu
testen sind verschiedene Emulatoren enthalten. Folgende Abbildung zeigt die
verschiedenen Emulatoren vom WTK 2.2:
Abb. 2: Verschiedenen Emulatoren vom WTK 2.2 [Karb05, S. 52]
Das erzeugte MIDlet besteht aus zwei Dateien, dem Java Archive (JAR) mit den
komprimierten Kompilaten, Bibliotheken und Metadaten sowie dem zugehörigen Java
Application Descriptor (JAD), einer Textdatei mit Informationen über Konfiguration, Profil,
Name und Icon der Anwendung und einer Referenz auf das JAR. Zum Ausführen der
Anwendung auf einem Mobiltelefon müssen beide Dateien mittels Bluetooth oder USBDatenkabel übertragen und anschließend installiert werden. Alternativ besteht die
Möglichkeit die Dateien auf einen Webserver zu legen und vom Mobiltelefon aus
herunterzuladen. Dies wird als Over The Air (OTA) Provisioning bezeichnet. 11
Obfuscator
Es besteht die Möglichkeit einen Obfuscator in den Entwicklungsprozess zu integrieren.
Dabei handelt es sich um ein Programm, welches den erzeugten Bytecode verschleiert.
Dadurch wird das MIDlet vor Revere Engineering geschützt und der Code minimiert. Denn
im Bytecode sind immer noch viele Informationen wie Zeilennummern oder die Namen von
Variablen, Methoden und Parameter enthalten. Diese werden vom Obfuscator durch
sinnlose und meistens kürzere Zeichenketten ersetzt. Die unter die GNU General Public
License (GPL) gestellte Software ProGuard ist ein typischer Vertreter und im Java ME
Umfeld weit verbreitet. 12 13
EclipseME
Für die integrierte Entwicklungsumgebung (IDE) Eclipse existiert das Plug-In namens
EclipseME, welches im Juni 2009 umgetauft wurde in Eclipse Mobile Tools for Java (MTJ). 14
Dadurch ist es sowohl möglich MIDlets innerhalb einer IDE zu programmieren, zu starten als
11
Vgl. [Uebe]
Vgl. [BrMo06, S. 26]
13
Vgl. [Lafo09]
14
Vgl. [Sete09]
12
6
2 Wahl einer geeigneten Entwicklungsplattform
auch auszuliefern. Hervorzuheben ist die Möglichkeit des Debuggings, welche den
Benutzern von WTK nicht zugänglich ist. Zusätzlich werden folgende Toolkits anderer
Hersteller, bestehend aus Konfigurationen, Profilen, optionalen Paketen und Emulatoren,
E
15
unterstützt:
■
■
■
■
■
■
■
MOTODEV 16 SDK for JavaME
Nokia SDK S40/S60
Sony Ericsson J2ME SDK
Sprint PCS Wireless Toolkit for Java
Siemens SMTK for Series 60
MPowerPlayer
MicroEmulator
MPowerPlayer
MPowerPlayer ist zwar aus technischer Sicht ein freier Java ME Emulator, aber das
Kerngeschäft des Unternehmens mplayit besteht darin, der Industrie für Videospiele ein
Webportal bereitzustellen, in dem Videospiele in beschränkter Version für Mobiltelefone
getestet werden können. Mittels der Technologien Java-Applet
Java Applet und Java Web Start wird der
Emulator in Webseiten integriert bzw. mit nur einem Klick ausgeführt. 17 Folgende
Abbildung zeigt MPowerPlayer im Webbrowser Firefox mit dem Spiel Guitar Hero:
Abb. 3:: MPowerPlayer im Webbrowser Firefox mit dem Spiel Guitar Hero [M
Mpla09a]
15
Vgl. [Dsdp]
MOTODEV ist das Motorola Developer Network
17
Vgl. [Mpla09b]
16
7
2 Wahl einer geeigneten Entwicklungsplattform
MicroEmulator
Das Projekt MicroEmulator wurde im Jahr 2001 gegründet und ist unter die GNU Lesser
General Public License (LGPL) gestellt. Es ist eine reine Java SE-Implementierung von Java
ME. Der Emulator wird mittels der Techniken Java Web Start und Java-Applet für
Webseiten bereitgestellt. Dem Entwickler wird direkter Zugriff auf das Subversion (SVN)
Projektarchiv gewährt und Möglichkeiten für automatisierte Lasttests bereitgestellt. Die
Oberfläche des Emulators ist mittels Skins beliebig gestaltbar, so dass das Aussehen
jeglicher Mobiltelefone angenommen werden kann. Es ist anzumerken, dass MPowerPlayer
auf MicroEmulator basiert. 18
Graphical User Interface
Damit der Entwickler auf das Display des Mobiltelefons zugreifen kann, werden vom MIDP
sowohl ein Low- als auch ein High-Level API zur Verfügung gestellt. Unter der Angabe von
Koordinaten können mit dem Low-Level API Pixel, Kreise, Linien oder Vierecke gezeichnet
werden. 19 Das High-Level API hingegen enthält vordefinierte Elemente wie:
■
■
■
■
■
■
■
Textausgabefeld
Checkbox
Radiobutton
Liste
Form
Fortschrittsbalken 20
Texteingabefeld.
Das Aussehen und das Bedienungskonzept hängen dabei vom jeweiligen Mobiltelefon bzw.
von der Implementierung des Herstellers ab. Der Entwickler hat hier kaum Möglichkeiten
das Aussehen maßgeblich zu beeinflussen. Dadurch ist eine mit dem High-Level API
entwickeltes Graphical User Interface (GUI) sehr leicht zu portieren. 21 Folgende Abbildung
zeigt „die Klassenhierarchie für darstellbare Elemente des MIDP“: 22
18
Vgl. [Micr09]
Vgl. [SzRö06]
20
Fortschrittsbalken werden im Java ME Umfeld Gauge genannt
21
Vgl. [Karb05, S. 24]
22
[SzRö06]
19
8
2 Wahl einer geeigneten Entwicklungsplattform
Abb. 4: Klassenhierarchie für darstellbare Elemente des MIDP [SzRö06
SzRö06]
Auch wenn vieles für den Einsatz vom High-Level
Level API spricht, so es ist nicht von der Hand zu
weisen, dass das API bereits zehn Jahre alt ist. Seitdem hat sich das Design von
Anwendungen, Betriebssystemen,
Betriebssystemen Webseiten und Mobiltelefonen stark gewandelt. Um
dem
m Geist der Zeit zu entsprechen, sollte eine moderne Anwendung für Mobiltelefone vor
allem visuell ansprechend sein.
sein
Gemäß dem Motto „ein Bild sagt mehr als tausend Worte“ wird nun ein typisches MIDlet
dargestellt, entwickelt mit dem
de High-Level
Level API von Java ME, bestehend aus:
■ einer Form namens Sign in
■ zwei Texteingabefeldern mit den Bezeichnungen LoginID und Password
■ zwei Buttons mit den Beschriftungen Cancel und Login
Folgende Abbildung zeigt exemplarisch ein Login MIDlet:
Abb. 5: Login MIDlet [Logi08]
9
2 Wahl einer geeigneten Entwicklungsplattform
2.1.4
Alternative GUI Frameworks
Es wurden viele unabhängige Frameworks entwickelt, mit dem Ziel, Java ME um eine
moderne Oberfläche zu erweitern und Anwendungen für Mobiltelefone optisch viel
ansprechender zu gestalten. Einige dieser GUI Frameworks werden nun vorgestellt und
näher betrachtet.
Micro Window Toolkit
Das Open Source Framework Micro Window Toolkit (MWT) wurde speziell für kleine Geräte
entwickelt. Inspiriert wurde es von Java SE Frameworks Abstract Window Toolkit (AWT),
Swing und Standard Widget Toolkit (SWT). Es bietet die Möglichkeit bestehende
Komponenten anzupassen. Eine Stärke besteht darin, grafische Schriftarten (Bitmap Fonts)
zu benutzen, für deren Erstellung das Werkzeug MicroFont-Maker bereitgestellt wird. Das
Framework ist mit 10 KB extrem klein. Dieses Framework wird nicht weiter gepflegt, denn
das letze Update stammte von Anfang 2007. Es liegen Dokumentationen in Form mehrerer
kleiner Tutorials und als Javadoc vor.
Folgende Abbildung zeigt mehrere Demo-MIDlets: 23
Abb. 6: Demo-MIDlets vom Micro Window Toolkit [Micr07b]
Aufgrund dieser Screenshots erscheint das Framework für seriöse Anwendungen wenig
geeignet. Die Oberfläche wirkt sehr verspielt und die Demos konnten nicht überzeugen, da
sie wie auf der Webseite vorgestellt, nur ein Viertel des Displays ausfüllen.
23
Vgl. [Micr07a]
10
2 Wahl einer geeigneten Entwicklungsplattform
Light-Weight Visual Component Library
Das Framework Light-Weight Visual Component Library (LwVCL) ist für die
Softwareplattformen .NET, Java SE, Java ME und Standard Widget Toolkit (SWT) ausgelegt.
Die Grafikbibliothek umfasst rund 30 Komponenten, darunter Button, Label, Panel, aber
auch komplexere wie Grid und Tree. 24 Es existieren zwei verschiedene Arten von Lizenzen,
zum einen die GNU General Public License (GPL) und zum anderen eine kommerzielle mit
folgender Staffelung: 25
Lizenz
Corporate
Corporate Unlimited
Individual
Beschreibung
480 EUR pro Entwickler einer Firma
1.999 EUR für sämtliche Entwickler einer Firma
29 EUR für eine Privatperson
Tab. 2: Kommerzielle Lizenzen für LwVCL
Bis auf den Java ME-Branch liegen für die Plattformen Dokumentationen in Form von
Tutorial, How-To, FAQ und API vor. Mit 160 KB für Java und 200 KB für .NET ist die
Bibliothek relativ klein.
Folgende Abbildung zeigt mehrere Screenshots vom Demo-MIDlet:
Abb. 7: Demo-MIDlet von der Light-Weight Visual Component Library [Vish06c]
Für Entwickler, die eine Anwendung für mehrere Plattformen entwickeln möchten, hat
dieses Framework seine Vorteile. Auch für Java ME bringt es den Vorteil zahlreicher
Komponenten mit sich. Optisch wirkt LwVCL überarbeitungsbedürftig. Transitionen zum
Ein- und Ausblenden von Screens sowie Transparenzeffekte wie Schatten fehlen gänzlich.
24
25
Vgl. [Vish06a]
Vgl. [Vish06b]
11
2 Wahl einer geeigneten Entwicklungsplattform
TagsMe
Das kommerzielle Framework TagsMe stammt von dem spanischen Unternehmen Media
Delivery Technologies SL. Vertrieben wird das Framework auf der Homepage vom
Unternehmen als Bestandteil der Entwicklungsplattform TagsMe GUI, die auf der IDE
NetBeans basiert. Entwickelt werden Anwendungen für Mobiltelefone in XML und einer
einfachen Script Sprache. Auch wenn aus technischer Sicht Java ME-MIDlets erzeugt
werden, so bleibt dies vor dem Entwickler verborgen bzw. hat dieser keinerlei Möglichkeit
eigene Java-Quelltexte zu integrieren. Die IDE TagsMe GUI bietet neben typischer
Funktionalitäten wie Syntax Highlighting, Autoformatter, Code Completion und XML
Validierung mittels XSD auch die bereits besprochene Java ME-Implementierung
MicroEmulator, in dem die Anwendung bereits beim Editieren betrachtet werden kann.
Folgende Abbildung zeigt die Entwicklungsplattform TagsMe GUI: 26 27
Abb. 8: Entwicklungsplattform TagsMe GUI [Tags09b]
Das Framework beinhaltet ein weit gefächertes Spektrum an GUI-Komponenten. Hinzu
kommen zahlreiche Animationen, mit denen Komponenten oder ganze Screens beliebig
ein- und ausgeblendet werden können. Vervollständigt wird die Funktionsvielfalt von
Audiounterstützung und Mehrsprachigkeit. Die Dokumentation ist ebenso umfassend wie
gut verständlich und wird von Video-Tutorials abgerundet. Folgende Abbildung zeigt
mehrere Screenshots der Demo-Anwendung:
26
27
Vgl. [Tags09a]
Vgl. [Tags09b]
12
2 Wahl einer geeigneten Entwicklungsplattform
Abb. 9: Demo-Anwendung von TagsMe [Tags09c]
Für Entwickler, die eine Anwendung für Mobiltelefone auf Basis von XML entwickeln
wollen, ist dieses Framework samt Entwicklungsumgebung geeignet. Der Funktionsumfang
ist vielfältig, und auch optisch ist TagsMe ansprechend. Die fehlende Java-Anbindung ist
dafür verantwortlich, dass dieses Framework nicht eingesetzt werden kann.
13
2 Wahl einer geeigneten Entwicklungsplattform
Lightweight User Interface Toolkit
Das Lightweight User Interface Toolkit (LWUIT) von Sun Microsystems wurde ursprünglich
von einem Angestellten für ein internes Projekt entwickelt. Nachdem das Toolkit stark
gewachsen war und sich immer größerer Beliebtheit erfreute, wurde es als Open Source
freigegeben. Das Framework ist stark an die Grafikbibliothek Swing angelehnt. Es werden
folgende GUI-Komponenten angeboten:
■
■
■
■
■
■
■
■
Form
Label
Button
RadioButton
ButtonGroup
ComboBox
TextArea
TabbedPane
Die Anordnung der Komponenten erfolgt durch folgende Layout-Manager, die bereits durch
Swing bekannt sind:
■
■
■
■
■
BorderLayout
BoxLayout
FlowLayout
GridLayout
GroupLayout
Das optische Erscheinungsbild aller Komponenten kann bezüglich Farbe, Bild, Schriftart,
Transparenz, Rahmen, Margin und Padding frei gestaltet werden. Hinzu kommen viele
Effekte, Animationen und Transitionen, mit denen Komponenten und Screens ein- und
ausgeblendet werden können. Die Unterstützung von Logging, Mehrsprachigkeit und 3D
runden das Framework ab.
Für die Trennung von Quellcode und Design wurden Themes eingeführt. Dabei beinhaltet
ein Theme die Gestaltungsvorschriften aller Komponenten. Ein Theme wird in einer
Ressource gespeichert, welche komfortabel mit dem LWUIT Resource Editor editiert
werden kann. Folgende Abbildung zeigt den LWUIT Resource Editor: 28
28
Vgl. [Sun09]
14
2 Wahl einer geeigneten Entwicklungsplattform
Abb. 10: LWUIT Resource Editor [Knud08]
Innerhalb einer Anwendung kann der Benutzer das Theme umschalten.
Folgende Abbildung zeigt mehrere Screenshots der Demo Anwendung, einmal mit Star
Theme und einmal den gleichen Screen mit Java Theme:
Abb. 11: Demo Anwendung von LWUIT [Knud08]
Durch die Anlehnung an Swing wird dem Entwickler der Einstieg erleichtert. Die
Auslagerung in Ressourcen hat den Vorteil, dass hier eine Arbeitsteilung zwischen
Entwickler und Designer stattfinden kann. Inhaltlich wirkt das Framework vollständig, da
alle üblichen Komponenten bereitgestellt werden. Die Dokumentation ist mit Javadocs und
einem über 120 Seiten langem E-Book ebenso umfangreich. Einziges Manko an dem
Framework ist die Performance. Die Reaktionsgeschwindigkeit ist spürbar träge, und die
Transitionen und Animationen könnten flüssiger sein.
15
2 Wahl einer geeigneten Entwicklungsplattform
2.1.5
Zusammenfassung und Bewertung
Die Java Platform, Micro Edition wurde vor rund 10 Jahren entwickelt und stellt ein
reduziertes Java, spezialisiert für mobile Endgeräte, dar. Die technische Vielfalt dieser
Geräte wird dabei auf eine Architektur von Konfigurationen und Profilen abgebildet. Für die
Entwicklung einer grafischen Oberfläche werden zwei APIs bereitgestellt, mit denen der
Entwickler entweder eigene pixelgenaue Zeichenroutinen implementiert oder vordefinierte
Elemente benutzt, deren Aussehen vom jeweiligen Mobiltelefon abhängen. Um diesen
Zwiespalt zu überbrücken wurden diverse GUI Frameworks untersucht, wobei sich LWUIT
von Sun Microsystems als klarer Favorit herauskristallisiert hat. Nichts desto trotz bleibt das
Problem bestehen, dass die Mobiltelefone stark unterschiedliche Displays bezüglich
Auflösung, Farbtiefe und Seitenausrichtung wie Hochformat oder Querformat besitzen. Der
Entwickler muss dafür Sorge tragen, dass die Anwendung für alle unterschiedlichen
Gerätekategorien optisch angepasst und getestet wird. Hinzu kommt, dass Java ME ein
reduziertes Java ist, wodurch der Entwickler gewissen Einschränkungen bei der
Wiederverwendung bereits existierender Java-Quelltexte unterliegt.
16
2 Wahl einer geeigneten Entwicklungsplattform
2.2 Apple iPhone
In diesem Unterkapitel wird das Apple iPhone vorgestellt. Im ersten Schritt wird die
Produktlinie rund um das iPhone erläutert. Es folgt eine Betrachtung des Betriebssystems
und der Software iTunes samt Alternativen. Anschließend wird untersucht, wie
Anwendungen für das iPhone entwickelt und ausgeliefert werden. Im letzen Abschnitt
erfolgt eine Zusammenfassung und Bewertung.
2.2.1
Produktlinie
Es existieren mehrere verschiedene Smartphones, die unter dem Oberbegriff iPhone
zusammengefasst werden. Diese werden nun im Detail vorgestellt.
iPhone
Anfang Januar 2007 wurde das iPhone von Apple Inc. angekündigt. Ende Juni 2007 wurde es
in den Markt eingeführt, zuerst in den USA und später weltweit. Es handelt sich dabei um
ein Smartphone mit 3,5 Zoll Multi-Touch-Display 29 im Breitbildformat und einer Auflösung
von 480 x 320 Pixeln. Der Prozessor ist ein Samsung 32-bit RISC ARM 1176JZ(F)-S mit einer
Taktfrequenz von 630 MHz, der auf 412 MHz untertaktet ist um den Stromverbrauch zu
reduzieren. Es unterstützt den Mobilfunkstandard Quadband GSM der zweiten Generation
(2G) und bietet Schnittstellen für WLAN (IEEE 802.11b/g), USB 2.0 und Bluetooth 2.0. Die 2
Megapixel Digitalkamera verfügt über Geotagging, womit Bildern anhand von GPSPositionsbestimmung geographische Informationen zugeordnet werden. Dadurch können
beispielsweise Sehenswürdigkeiten auf einem Foto automatisch identifiziert werden 30.
Weiterhin ist ein Kopfhörer mit einem Frequenzbereich von 20 Hz bis 20 KHz samt
integriertem Mikrofon im Lieferumfang enthalten.
iPhone 3G
Seit Juli 2008 steht das iPhone 3G zum freien Verkauf. Die Neuerung hierbei waren Assisted
GPS zur satellitenunterstützen Positionsbestimmung und UMTS, dem Mobilfunkstandard
der dritten Generation (3G). Darüber hinaus wurde der Akku gegen einen leichteren und
leistungsstärkeren ausgetauscht.
iPod touch
Das iPod touch wurde Anfang September 2007 von Apple Inc. vorgestellt und besteht
weitgehend aus den gleichen Komponenten wie dem iPhone. Entfernt wurden lediglich die
Kamera und das Telefon sowie einige Softwarekomponenten. Funktional reiht sich das iPod
touch nahtlos in die Reihe der MP3-Player von Apple ein, wie z.B. iPod classic, iPod mini,
iPod nano und iPod shuffle. Optisch und kinästhetisch gleicht es dem iPhone.
29
Multi-Touch erlaubt die Bedienung mit mehreren Fingern gleichzeitig. Dadurch sind beispielsweise
Vergrößern und Drehen von Bildern möglich.
30
Vgl. [Wiki09b]
17
2 Wahl einer geeigneten Entwicklungsplattform
iPhone 3GS
Mitte Juni 2009 kam das iPhone 3GS in den Handel. Bei diesem Modell wurde die
Graphikleistung verbessert und mit 256 MB DRAM mehr Hauptspeicher verbaut. Der ARM
Cortex-A8 Prozessor mit einer Taktfrequenz von 833 MHz ist auf 600 MHz untertaktet. Die 3
Megapixel Digitalvideokamera ist mit automatischem Fokus, Weißabgleich und Belichtung
ausgestattet. Neu hinzugekommen sind der Beschleunigungssensor Nike+ und ein digitaler
Kompass. Wiederum wurde die Kapazität des Akkus verbessert. 31 32 Folgende Abbildung
zeigt ein Apple iPhone 3G:
Abb. 12: Apple iPhone 3G [Appl09a]
2.2.2
Betriebssystem
Das Betriebssystem von iPhone, iPhone 3G, iPhone 3GS und iPod touch 33 wurde gleichfalls
von Apple Inc. entwickelt und wird als iPhone OS oder OS X iPhone bezeichnet. Genau wie
Mac OS X, von dem es abgeleitet wurde, benutzt es das unixähnliche Darwin als
Kernkomponente. Insgesamt benötigt das Betriebssystem weniger als 240 MB Speicher.
Das iPhone OS ist in vier Abstraktionsschichten aufgeteilt: 34
■ Core OS Layer
■ Core Services Layer
■ Media Layer
■ Cocoa Touch Layer
31
Vgl. [Wiki09c]
Vgl. [Tmob]
33
Fortan werden diese vier Geräte unter dem Begriff iPhone zusammengefasst.
34
Vgl. [Wiki09d]
32
18
2 Wahl einer geeigneten Entwicklungsplattform
2.2.3
iTunes und Alternativen
Um beispielsweise Lieder auf das iPhone zu laden, bedarf es der Software iTunes, die für
Mac OS X, Windows XP und Windows Vista frei erhältlich ist. Das Programm durchsucht
dafür die gesamte Festplatte des Rechners und synchronisiert den Datenbestand mit dem
iPhone. Hierfür werden die Daten temporär in ein kompatibles Format konvertiert. Auch ist
es damit möglich Musikstücke, Filme und Anwendungen beim iTunes Music Store käuflich
zu erwerben. Folgende Abbildung zeigt die Software iTunes:
Abb. 13: Apple iTunes [Appl09b]
Alternativen
Für Benutzer des Betriebssystems Linux, für die kein iTunes existiert, und für solche, die
andere Software einsetzen möchten, existieren folgende Freeware Alternativen: 35
Windows
dopisp
Ephpod
Floola
iPod shuffle DB Builder
iPod shuffle Manager
JakPod
Media Monkey
PoddoX
reTune
SharePod 3
Songbird
vPod
Winamp
Yamipod
Linux
Amarok
Banshee
Floola
GTKpod
Ipod shuffle DB Builder
JakPod
reTune
Songbird
Ymipod
Mac OS X
Floola
iPod shuffle DB Builder
JakPod
reTune
Songbird
Yamipod
Tab. 3: Freeware Alternativen zu iTunes
35
Vgl. [Oest07]
19
2 Wahl einer geeigneten Entwicklungsplattform
2.2.4
Softwareentwicklung
In diesem Unterkapitel wird untersucht wie für das iPhone Anwendungen entwickelt und
ausgeliefert werden. Da erst durch einen Hack bedingt überhaupt ein SDK bereitgestellt
wurde, wird dieser kurz vorgestellt.
Jailbreaking mittels TIFF Exploit
Apple vertrat die Position, dass Webanwendungen, die im nativen iPhone Browser Safari
ausgeführt werden, den Drittanbietern genügen. „Nachdem im Juli 2007 ein Hack publiziert
wurde, wie trotz der eingebauten Hürden, Anwendungen nativ auf dem Gerät ausgeführt
werden können, hat Apple kurze Zeit später die eigene Politik geändert […]“ 36 und ein
Software Development Kit (SDK) veröffentlicht. Die Technik, Software ohne kryptografische
Signatur von Apple auf dem iPhone nativ auszuführen, wird Jailbreaking genannt. Der Hack
wird als TIFF Exploit bezeichnet, da im Header des Grafikformats TIFF ein Offset auf eine
Stelle jenseits des physischen Dateiendes verweist, was unweigerlich zu einem
inkonsistenten Zustand im Betriebssystem führt. 37
iPhone SDK
Ende März 2008 erschien die erste Version vom iPhone SDK, mit dem Entwickler native
Anwendungen für das iPhone entwickeln konnten. Das 2 GB umfassende Paket kann von
registrierten Entwicklern kostenlos heruntergeladen werden. Die Installation setzt einen
Macintosh mit Mac OS X voraus. Die integrierte Entwicklungsumgebung (IDE) ist Xcode,
unter der auch Anwendungen für Macintosh entwickelt werden. Die Programmiersprache
ist Objective-C, einer Erweiterung der Programmiersprache C um objektorientierte
Konzepte. Neben der IDE werden noch ein Interface Builder, verschiedene Optimierungsund Debugging-Werkzeuge und ein iPhone Simulator mitgeliefert, so dass auf Hardware
verzichtet werden kann. 38 Das Framework setzt sich aus folgenden Teilen zusammen: 39
Bestandteil
Cocoa Touch 40
Media
Core Services
OS X Kernel
Beschreibung
Multi-Touch, Beschleunigungssensoren, Kamera
Audio, Video, Grafikformate, Animation, OpenGL
Netzwerk, SQLite-Datenbank, Threads
TCP/IP, Sockets, Dateisystem, Sicherheit
Tab. 4: Framework Bestandteile vom iPhone SDK
36
[Prin09, S.5]
Vgl. [Wiki09e]
38
Vgl. [Prin09, S.10]
39
Vgl. [Wiki09d]
40
Erweiterung des Frameworks Cocoa, mit dem Macintosh Anwendungen entwickelt werden
37
20
2 Wahl einer geeigneten Entwicklungsplattform
AppStore
Der AppStore ist die einzige Plattform, von der der Benutzer Anwendungen für das iPhone
herunterladen kann. Erreichbar ist der AppStore direkt vom iPhone aus oder mittels iTunes.
Möchte ein Entwickler seine Anwendung der breiten Masse verfügbar machen, so muss
dieser dem iPhone Developer Program beitreten. Dabei stehen das Standard Program und
das Enterprise Program zur Wahl. Das Standard Program kostet 99 USD jährlich und ist für
Entwickler von freien oder kommerziellen Anwendungen bestimmt. Apple verlangt weitere
30 Prozent vom Umsatz bei kommerziellen Anwendungen. Soll die Anwendung nicht über
den öffentlichen sondern über einen eigens dafür eingerichteten AppStore bereitgestellt
werden, so ist das Enterprise Program zu wählen, welches jährlich 299 USD kostet. 41 42
2.2.5
Zusammenfassung und Bewertung
Auch wenn sich das iPhone großer Beliebtheit erfreut, bereits über 10 Millionen mal
verkauft wurde und in 80 Ländern erhältlich ist 43, so sind rund 1.800 Euro für eine
adäquate Entwicklungsumgebung zu investieren. Der Betrag setzt sich aus zusammen aus:
■ Anschaffung iPhone 3G für ca. 600 Euro 44
■ Anschaffung iMac für ca. 1.100 Euro 45
■ Teilnahme am iPhone Developer Program – Standard Program für 99 USD
Die Kosten könnten durch folgende Einsparungen reduziert werden:
■ Einsatz der Software iPhone Simulator anstelle der iPhone Anschaffung
■ Einsatz einer Virtual Machine (VM) 46 mit Installation von Mac OS X anstelle der iMac
Anschaffung
Neben den wirtschaftlichen Faktoren stellt sich das unüberwindbare Problem der
Programmiersprache Objective-C. Diese ist unbedingt einzusetzen bei der Entwicklung einer
iPhone Anwendung. Da auf dem iPhone keine Java Virtual Machine (JVM) implementiert
wurde, ist es unmöglich die bestehenden Java-Quelltexte wiederzuverwenden. Dem Autor
ist auch kein einziges Konvertierungswerkzeug bekannt, mit dem Java-Quelltext zu
Objective-C-Quelltext umgewandelt werden kann.
41
Vgl. [http://developer.apple.com/iphone/program/]
Vgl. [Wiki09f]
43
Vgl. [Wiki09g]
44
Vgl. [Guen]
45
Vgl. [Appl09c]
46
Eine Virtual Machine (VM) ist ein aus Software bestehender virtueller Computer.
42
21
2 Wahl einer geeigneten Entwicklungsplattform
2.3 Google Android
In diesem Unterkapitel wird das Betriebssystem und die Softwareplattform Android
untersucht. Da Google maßgeblich für die Entwicklung verantwortlich ist, handelt der erste
Abschnitt vom Unternehmen und den Dienstleistungen. Es folgt eine nähere Betrachtung
der Open Handset Alliance, der auch eine tragende Rolle an Android zuteilwird.
Anschließend werden die Android Developer Challenge und exemplarisch drei Finalisten
samt Anwendungen vorgestellt. Im letzen Abschnitt erfolgt eine Zusammenfassung und
Bewertung.
2.3.1
Google Inc.
Der Name Google geht zurück auf den Mathematiker Edward Kasner, der der Zahl 10100 den
Namen googol verliehen hat. 47
Firmengeschichte
Nachdem sich 1995 Lawrence Edward Page und Sergei Brin an der Standford University
begegneten, konzipierten und entwickelten sie eine Internet-Suchmaschine, dem Vorläufer
von Google. Im September 1998 gründeten beide das Unternehmen Google Inc. in
Mountain View, Kalifornien, USA. Die Kombination der Suchmaschine mit kontextsensitiver
Werbung, Google AdSense genannt, brachte den wirtschaftlichen Durchbruch. Anfang
Januar 2009 zählten 24.400 Mitarbeiter zu dem Unternehmen mit einem Jahresumsatz von
21,8 Milliarden USD in 2008. 48 49
Dienstleistungen
Auch wenn das Kerngeschäft die Suche bleibt, so wurden viele weitere Softwarelösungen
finanziert. Zu den bekanntesten und wichtigsten zählen: 50
47
Vgl. [Wiki09h]
Vgl. [Wiki09h]
49
Vgl. [Wiki09i]
50
Vgl. [Wiki09i]
48
22
2 Wahl einer geeigneten Entwicklungsplattform
Dienstleistung
Google AdSense
Google Books
Google Chrome
Google Desktop Search
Google Earth
Google Groups
Google Calendar
Google Mail
Google Maps
Google Picasa
Google Scholar
Google Docs
Google Toolbar
Google Video
Beschreibung
Webbasierter Anbieter von inhaltsbezogene Werbeanzeigen
Webbasierte Volltextsuche über digitalisierte Bücher
Webbrowser für Windows, Linux und Mac OS X, der auf die
Rendering-Engine WebKit51 aufbaut
Suchprogramm für Windows, Linux und Mac OS X
Virtueller Globus für Windows, Linux und Mac OS X basierend
auf Satelliten- und Luftbildern
Webseite mit Usenet-Archiv und Schnittstelle zum Versenden
von Artikeln
Webbasierter Terminkalender, der mit anderen Benutzern
geteilt werden kann
Webbasierter Email-Dienst mit 1 GB Postfachgröße
Webbasierte Land- und Straßenkarte mit Volltextsuche und
Routenplaner
Webbasierte Bildbearbeitung und -verwaltung
Webbasierte
Volltextsuche
über
wissenschaftliche
Publikationen
Webbasierte Textverarbeitung und Tabellenkalkulation
Symbolleiste für die Webbrowser Firefox und Internet Explorer,
integriert Dienste oder stellt Verknüpfungen zu diesen her
Webportal zum Suchen, Ansehen und Einstellen von
Filmsequenzen
Tab. 5: Dienstleistungen von Google Inc.
2.3.2
Android
Eine der ersten Nachrichten über Android besagt, dass Google im August 2005 das 22
Monate alte Startup-Unternehmen Android Inc. aufgekauft hat. 52
„Mit großem Interesse wurde am 5. November 2007 eine Ankündigung durch die USamerikanische Internetfirma Google und weitere [sic] 33 Unternehmen der Open Handset
Alliance verfolgt: der Start von Android.“ 53
„Am 12. November 2007 veröffentlichte Google eine Vorabversion des Android-SDK [sic!],
einer Entwicklungsumgebung für die Android-Plattform. Die überwiegend positive Reaktion
darauf verdeutlicht, wie groß das Interesse des Marktes und der Entwickler an einer
offenen Plattform für mobile Computer mittlerweile ist.“ 54
Android ist eine kostenlose Softwareplattform für mobile Endgeräte und basiert auf dem
Betriebssystem Linux. Große Teile der Android Plattform sind unter die Open-SourceLizenzen Apache 2.0 und GNU Public License Version 2 (GPLv2) gestellt worden. Durch eine
51
Die Rendering-Engine WebKit wird auch im Browser Safari von Apple Inc. eingesetzt.
Vgl. [Elgi05]
53
[MoKo09, S. 1]
54
[BePa09, S. V]
52
23
2 Wahl einer geeigneten Entwicklungsplattform
Gleichberechtigung der Anwendungen wird kein Unterschied zwischen den vorinstallierten
und denen von Drittanbietern gemacht. Mit dem Android Software Development Kit (SDK)
werden Anwendungen in der Programmiersprache Java entwickelt. Für das Design der
graphischen Benutzeroberfläche (GUI) wird die Auszeichnungssprache Extensible Markup
Language (XML) verwendet. Rund ein Jahr lang mussten sich die Entwickler mit einem
Software-Emulator begnügen, da erst im Herbst 2008 das erste Android Smartphone
erschien. 55 56
2.3.3
Open Handset Alliance
„Am 5. November 2007 haben 34 Firmen unter Führung des Internetunternehmens Google
die Open Handset Alliance (OHA) gegründet. Etwa ein Jahr später, am 9. Dezember 2008,
sind weitere 14 Firmen der OHA beigetreten. Das OHA-Konsortium entwickelt gemeinsam
die Softwareplattform Android.“ 57 Die mittlerer weile 50 Mitglieder der OHA stammen aus
folgenden Geschäftsbereichen: 58
■
■
■
■
■
10 Mobilfunkbetreiber
13 Halbleiterfirmen
10 Endgerätehersteller
11 Softwarefirmen
6 Vermarktungsfirmen
(engl. Mobile Operators)
(engl. Semiconductor Companies)
(engl. Handset Manufacturers)
(engl. Software Companies)
(engl. Commercialization Companies)
Folgende Tabelle zeigt alle 50 Firmen der Open Handset Alliance:
55
Vgl. [MoKo09, S. 1 f.]
Vgl. [Andr]
57
[MoKo09, S.10]
58
Vgl. [Open]
56
24
2 Wahl einer geeigneten Entwicklungsplattform
Mobilfunkbetreiber
Halbleiterfirmen
Endgerätehersteller
Softwarefirmen
Tab. 6: Alle 50 Firmen der Open Handset Alliance [Open]
Vermarktungsfirmen
25
2 Wahl einer geeigneten Entwicklungsplattform
Mobilfunkbetreiber
„Es ist der Open Handset Alliance (OHA) gelungen, [sic] mit China Mobile, Vodafone sowie
Telefónica die drei (nach Kundenzahl) größten Mobilfunkbetreiber der Welt als Mitglieder
zu gewinnen […]. In Deutschland sind drei der vier Netzbetreiber direkt oder durch ihre
Muttergesellschaften in der OHA vertreten […].“ 59 Die Mitgliedschaft von
Mobilfunkbetreibern in der OHA ist deswegen wichtig, weil diese durch Subventionierung
der Endgeräte und attraktive Datentarife den Verkauf maßgeblich fördern können.
Halbleiterfirmen
Die Hardware, die von den Endgeräteherstellern für die Android Smartphones verbaut wird,
wird von den Halbleiterfirmen hergestellt. Besonders erwähnenswert sind: 60
Firma
Intel
nVidia
ARM
Texas Instruments
Beschreibung
weltweit führender Prozessorhersteller
einer der größten Entwickler von Grafikprozessoren
Designer für RISC-Prozessoren
einer der größten Hersteller von Digitalen Signalprozessoren (DSP)
Tab. 7: Bekannte Halbleiterfirmen der OHA
Endgerätehersteller
Bis auf den Marktführer Nokia sind folgende vier der fünf weltweit größten
Endgerätehersteller in der Open Handset Alliance vertreten: 61 Samsung, LG Electronics,
Motorola und Sony Ericsson. Erwähnenswert sind auch die Computerhersteller ASUSTeK
und Toshiba als auch der Navigationsgerätehersteller Garmin, die bisher keine
Mobilfunkgeräte entwickelt haben.
Softwarefirmen
Es ist bemerkenswert, dass Google die treibende Kraft hinter der OHA ist, und kein
Endgerätehersteller
oder
Mobilfunkbetreiber.
Auch
das
weltweit
größte
Internetauktionshaus eBay ist in der OHA vertreten, wobei die Rolle dem Autor bisher
unklar ist. Weitere nennenswerte Softwarehersteller sind: 62
Firma
Ascender Corporation
Nuance
PacketVideo (PV)
SONiVOX
Beschreibung
Hersteller von Schriftarten, insb. Droid Fonts für Android
Entwickler von Sprachsynthese und -erkennung
Integration von Multimedia auf mobile Endgeräte
Spezialist für Audiosysteme auf Mobilfunkgeräte
Tab. 8: Bekannte Softwarefirmen der OHA
59
[MoKo09, S.12]
Vgl. [MoKo09, S.14]
61
Vgl. [MoKo09, S. 10]
62
Vgl. [MoKo09, S. 13]
60
26
2 Wahl einer geeigneten Entwicklungsplattform
Vermarktungsfirmen
„Diese Firmen arbeiten mit den Netzbetreibern und Endgeräteherstellern zusammen, um
Software in eine Hardwarebasis zu integrieren und diese dann auf den Markt zu bringen.
Bei Firmen wie z.B. Noser Engineering, Teleca und Wind River Systems handelt es sich um
spezielle Zulieferer für die Endgerätegersteller und Netzbetreiber.“ 63
2.3.4
Android Developer Challenge
Die Android Developer Challenge (ADC) ist ein von Google ausgeschriebener Wettbewerb
um die innovativste Anwendung für das Android-Betriebssystem. Insgesamt 10 Millionen
USD wurden als Preisgelder ausgesetzt. Die Anmeldung fand zwischen Januar und April
2008 statt, wobei sich 1.788 Kandidaten qualifizierten. Darunter wurden 50 Kandidaten von
zahlreichen Preisrichtern im Mai 2008 ausgewählt. Sie erhielten je 25.000 USD um ihre
Anwendung weiterzuentwickeln. Im September 2008 wurden die Gewinner
bekanntgegeben. Je zehn Gewinner erhielten ein Preisgeld von 275.000 USD, weitere zehn
Finalisten gewannen 100.000 USD. 64
Im Mai 2009 wurde die Android Developer Challenge 2 (ADC 2) bekannt gegeben. Die
Anmeldung endet am 31. August 2009. Die Kandidaten müssen sich dabei für eine von zehn
Kategorien wie Erziehung, Spiele, Lifestyle und Reisen entscheiden. Voraussichtlich im
Oktober werden die Gewinner der ersten Runde bekanntgegeben, und rund einen Monat
später endet der Wettbewerb. Die Preisrichter sind diesmal alle Besitzer eines Android
Smartphones, die eine Anwendung zum Testen und Bewerten herunterladen können. Pro
Kategorie wird es drei Gewinner geben mit einer Preisstaffelung von 100.000 USD für den
ersten Platz, 50.000 USD für den zweiten Platz und 25.000 USD für den dritten Platz.
Zusätzlich gibt es ein Preisgeld unabhängig von den Kategorien mit einer Staffelung von
150.000 USD, 50.000 USD und 25.000 USD. 65
Es folgen nun exemplarisch drei Anwendungen der Android Developer Challenge 1 (ADC 1):
63
[MoKo09, S. 14]
Vgl. [Brow08]
65
Vgl. [Andr09a]
64
27
2 Wahl einer geeigneten Entwicklungsplattform
Compare Everywhere
Der Autor Jeffrey Sharkey gewann bei der ADC 1 mit seiner Anwendung Compare
Everywhere ein Preisgeld in Höhe von 275.000 USD-Dollar. Ziel der Anwendung ist es den
Barcode eines beliebigen Produktes zu fotografieren und den Preis zu vergleichen zu lassen.
Dem Anwender werden dann Kaufhäuser in seiner näheren Umgebung angezeigt, die das
Produkt im Sortiment haben. Folgende Abbildung zeigt die Android-Applikation Compare
Everywhere:
Abb. 14: Die Android-Applikation Compare Everywhere [Andr09b]
Cooking Capsules
Die Autoren Mary Ann Cotter aus San Francisco und Muthu Ramadoss aus Indien gewannen
bei der ADC 1 mit ihrer Anwendung Cooking Capsules ein Preisgeld in Höhe von 100.000
USD. Ziel der Anwendung ist es den Benutzer beim Kochen zu unterstützen. Kleinere
Kochvideos bieten Erklärungen und Inspirationen, Tools helfen beim Planen und Einkaufen
und zeigen Supermärkte in der näheren Umgebung an. Folgende Abbildung zeigt die
Android-Applikation Cooking Capsules:
Abb. 15: Die Android-Applikation Cooking Capsules [Andr09c]
28
2 Wahl einer geeigneten Entwicklungsplattform
Wikitude
Der Autor Philipp Breuss aus Salzburg in Österreich gewann bei der ADC 1 mit seiner
Anwendung Wikitude 25.000 USD. Die Anwendung informiert den Benutzer über
Sehenswürdigkeiten eines beliebigen Reiseziels oder seiner näheren Umgebung. Dabei
werden die textuellen Informationen, die aus Wikipedia und anderen Wikis extrahiert und
aufbereitet werden, in die Bildansicht der Digitalkamera eingeblendet. Folgende Abbildung
zeigt die Android-Applikation Wikitude:
Abb. 16: Die Android-Applikation Wikitude [Andr09d]
2.3.5
Zusammenfassung und Bewertung
Die Softwareplattform und das Betriebssystem Android wurde von Google und der Open
Handset Alliance erschaffen. Mit 50 namenhaften Firmen, die teilweise marktführend in
ihrem Sektor sind, deckt die Allianz alle Bereiche ab, die für ein Smartphone relevant sind:
Mobilfunk, Hardware, Software und Vermarktung. Android steht unter der Open-SourceLizenz und alle Quelltexte sind frei verfügbar. Durch zwei Wettbewerbe wurde dafür
gesorgt, dass innovative Anwendungen für die neue Plattform bereitstehen. Entwickelt
werden diese in Java und XML.
In diesem Kapitel wurden einleitend die verschiedenen Dienstleistungen und
Softwarelösungen von Google vorgestellt, da Android diese anbindet und bereitstellt.
Es wurde darauf verzichtet Smartphones mit Android-Betriebssystem vorzustellen, da
Android im Rahmen der Evaluation als reine Softwareplattform zu verstehen ist.
29
2 Wahl einer geeigneten Entwicklungsplattform
2.4 Gegenüberstellung und Bewertung der Plattformen
In diesem Unterkapitel werden die drei Plattformen miteinander verglichen und eine Wahl
getroffen.
Java Platform, Micro Edition
Die Java Platform, Micro Edition existiert bereits seit rund 10 Jahren, was insofern ein
großer Vorteil ist, da inzwischen ein Großteil der mobilen Endgeräte diese etablierte
Plattform unterstützen. Es existieren viele Emulatoren und Toolkits für die
unterschiedlichsten Mobiltelefone. Diese kommen zum Einsatz, wenn der Entwickler die
speziellen Eigenschaften eines Gerätes unterstützen möchte oder um die Anwendung für
das jeweilige Display zu optimieren. Das API bietet zwar einige GUI-Komponenten an, aber
das Aussehen hängt vom jeweiligen Endgerät ab. Ein weiterer Nachteil ist die
Programmiersprache, ein reduziertes Java. Bei der Adaption existierender Java-Quelltexte
stellt dies ein großes Problem dar, da der Entwickler den Code extra anpassen und
portieren muss.
Apple iPhone
Die Plattform Apple iPhone besteht aus einem SDK für vier sehr ähnliche Zielgeräte.
Software für diese technisch sehr innovativen Geräte zu entwickeln stellt einen großen Reiz
dar. Einzig auf dem Betriebssystem Mac OS X und mit der Programmiersprache Objective-C
ist dies möglich. Um die fertige Software bereitzustellen zahlt der Entwickler mindestens 99
USD für die Teilnahme am Developer Program, und zusätzlich, sollte die Software
kommerziell sein, weitere 30 Prozent vom Umsatz.
Google Android
Mindestens genau so reizvoll ist Android, eine kostenlose Softwareplattform der OHA unter
Führung von Google. Diese Allianz stellt die treibende Kraft von Android dar, da die 50
Firmen aus den Bereichen Mobilfunk, Hardware, Software und Vermarktung, für den Erfolg
maßgeblich verantwortlich sind. Zusätzlich „erschließt sich Android die Innovationskraft der
Open-Source-Community“ 66 , da das auf Linux basierende Betriebssystem, die
umfangreichen Bibliotheken, die Laufzeitumgebung und die mobilen Schlüsselapplikationen
unter die Open-Source-Lizenz gestellt wurden. 67 Ein weiterer Vorteil ist die
Gleichberechtigung der Anwendungen. Dadurch können neue Anwendungen geschaffen
werden, die der Benutzer gegen bestehende austauschen kann. Vermutlich enthält Android
noch Fehler, da es sehr neu ist. Es ist jedoch anzunehmen, dass durch die Wahl von Java als
Programmiersprache die große Community dabei helfen wird, diese zu finden und zu
beseitigen.
Gegenüberstellung
Folgende Tabelle stellt die Fakten der drei Entwicklungsplattformen gegenüber:
66
67
[MoKo09, S. 1]
Vgl. [MoKo09, S. 1]
30
2 Wahl einer geeigneten Entwicklungsplattform
Java Platform,
Micro Edition
1999
alle Java ME
fähigen
Mobiltelefone
Erscheinungsjahr
Zielgeräte
Zielgerätbetriebssystem
Programmiersprache
Entwicklungsumgebung
Entwicklungsbetriebssystem
Voraussetzungen
Lizenz
Vorteile
Nachteile
beliebig
reduziertes Java
Eclipse mit MTJ
Windows,
Linux, Mac OS X
Java SE und
WTK
Open Source
viele Millionen
Endgeräte mit
Java ME
ausgestattet
GUI abhängig
vom Endgerät,
reduziertes Java
Apple iPhone
Google Android
2007
iPhone,
iPhone 3G,
iPod touch,
iPhone 3GS
iPhone OS
Objective-C
Xcode
Mac OS X
2007
Smartphones mit
Android-Betriebssystem
iPhone SDK
kommerziell
technisch
innovativ
nicht
kompatibel
zu Java
Android (Linux)
Java
Eclipse mit ADT 68
Windows, Linux,
Mac OS X
Java SE und Android SDK
Open Source
technisch innovativ,
Google und OTA sehr
erfolgsversprechend,
Gleichberechtigung der
Anwendungen
Vermutlich
Kinderkrankheiten weil
sehr neu
Tab. 9: Gegenüberstellung der drei Plattformen
Entscheidungsfindung
Für die Entscheidung der geeigneten Entwicklungsplattform ist wiederholt festzuhalten,
dass viele bestehende Java-Quelltexte adaptiert werden sollen. Da für das iPhone nur in
Objective-C entwickelt werden kann und diese Programmiersprache nicht kompatibel zu
Java ist, fällt aus diesem Grund die Entscheidung gegen das iPhone aus.
Nach Meinung des Autors hat sich Java ME bis heute nicht richtig durchsetzen können.
Einerseits sind die Displays der meisten Mobiltelefone zu klein, um Anwendungen wie
einen Webbrowser bequem benutzen zu können. Andererseits ist die Internetfähigkeit als
Zusatz zum üblichen Mobilfunkvertrag zu verstehen. Darüber hinaus sind das reduzierte
Java und die Abhängigkeit von GUI-Frameworks negativ zu verbuchen. Deswegen fällt die
Entscheidung gegen Java ME aus.
Wünschenswert ist ein modernes Smartphone mit großem Display, optisch ansprechender
GUI und vollständigem Java. Auch sollte der Zugang zum Internet integraler Bestandteil des
Mobilfunkvertrags sein. Aus Sicht eines Entwicklers ist eine Integration des SDKs in bereits
etablierte Entwicklungsumgebungen sehr vorteilhaft. Des Weiteren sollte das SDK moderne
und etablierte Technologien einsetzen sowie bereitstellen. Frei zugängliche Quelltexte sind
eine zusätzliche Erleichterung. Da all dies nur von einer Plattform erfüllt wird, fällt die
Entscheidung zugunsten von Android aus.
68
Das Android Development Toolkit (ADT) ist ein Plug-In für Eclipse. Dieses wird im nächsten Kapitel
detailliert untersucht.
31
3 Android im Detail
3 Android im Detail
In diesem Kapitel wird Android im Detail betrachtet. Im ersten Abschnitt wird die
Architektur mit ihren einzelnen Schichten vorgestellt. Es folgen nähere Erläuterungen zum
SDK, den Entwicklungswerkzeugen und dem ADT Plug-In für Eclipse. Der letzte Abschnitt gilt
den Endgeräten mit Android-Betriebssystem samt kritischen Stimmen.
Diese Reihenfolge wurde mit der Absicht gewählt, die Tatsache nachzubilden, dass für die
Entwickler rund 1 Jahr lang nur das SDK und die Werkzeuge verfügbar waren, bevor die
ersten Endgeräte erschienen.
3.1 Architektur
„Generell beschreibt die Softwarearchitektur die strukturierte Anordnung der einzelnen
Systemkomponenten.“ 69 Bei der Architektur von Android werden die einzelnen
Komponenten einer Schicht zugeordnet. Die Gesamtheit aller Schichten wird als Software
Stack bezeichnet, welcher sich aus Betriebssystem, Middleware und Schlüsselanwendungen
zusammensetzt. 70 Folgende Abbildung zeigt den Android Software Stack:
Abb. 17: Android Software Stack, bestehend aus fünf Schichten [Andr09e]
69
70
[MoKo09, S. 5]
Vgl. [Andr09e]
32
3 Android im Detail
3.1.1
Applications
Die oberste Schicht beinhaltet folgende, in Java geschriebene, Applikationen:
Anwendung
Dialer
Contacts
Browser
Maps
Alarm Clock
Calculator
Camera
Email
Messaging
Music
Pictures
Android Market
Beschreibung
Telefon mit Verbindung zum Adressbuch
Adressbuch mit Verbindung zu Telefon, Email und SMS
Webbrowser
Anwendung für Google Maps
Wecker
Taschenrechner
Kamera zum Aufnehmen von Bildern
Anwendung für Emails, vorausgesetzt wird ein Account bei Google
Mail, zusätzlich sind andere Provider möglich
Anwendung für SMS
Musikverwaltung
Bilderverwaltung
Schnittstelle zum Herunterladen und Bewerten neuer Anwendungen,
nicht verfügbar im Emulator
Tab. 10: Anwendungen der Applications-Schicht
3.1.2
Application Framework
Wie bereits erwähnt sind alle Anwendungen gleichberechtigt. Der Benutzer kann diese
gegen andere beliebig austauschen. Ferner ist es möglich eigene Anwendungen zu
entwickeln. Diese Mechanismen werden von dem Application Framework bereitgestellt:
Mechanismus
Activity Manager
Window Manager
Content Provider
View System
Package Manager
Telepony Manager
Resource Manager
Location Manager
Notification Manager
Beschreibung
steuert den Lebenszyklus der Aktivitäten, stellt einen globalen
Stack für die Zurück-Taste bereit
lässt sich über eine Java-API ansteuern und greift auf den Surface
Manager 71 zu
ermöglicht das Lesen und Speichern von Daten, dient dem
Datenaustausch zwischen Applikationen
steuert die Views 72
protokolliert die installierten Applikationen
steuert die Telefonfunktionalität wie Anklopfen, Gespräch halten
oder das neue Gespräch entgegen nehmen
ermöglicht Zugriff auf Ressourcen (z.B. internationalisierte Strings,
Grafiken, Layouts)
stellt geografische Informationen über den aktuellen Standort
bereit
ermöglicht
Applikationen,
textuelle
Benachrichtigungen
anzuzeigen
Tab. 11: Mechanismen der Application Framework-Schicht [MoKo09, S. 9] [Andr09e]
71
72
Siehe Libraries-Schicht.
Views sind Basis-Bausteine für die GUI.
33
3 Android im Detail
3.1.3
Libraries
Android beinhaltet in C / C++ geschriebenen Bibliotheken. Deren Funktionalität wird über
die Application Framework-Schicht bereitgestellt:
Bibliothek
Surface Manager
Media Framework
SQLite
OpenGL | ES
FreeType
WebKit 74
SGL
SSL
libc
Beschreibung
steuert den Zugriff auf das Anzeigesystem, stellt 2D- und 3DGrafiken unterschiedlicher Applikationen kombiniert dar
stellt Bibliotheken für Wiedergabe und Aufnahme von Audio und
Video bereit, basiert auf einer Bibliothek von PacketVideo 73
Relationales Datenbanksystem für ressourcenbeschränkte Geräte
3D-Grafikbibliothek für eingebettete Systeme
Bibliothek zur Darstellung von Schriftarten
Rendering-Engine für Webseiten
Software zum Rendern von Vektorgrafik
Netzwerkprotokoll zur absicherten Übertragung von Daten
Standard-Bibliothek für die Programmiersprache C
Tab. 12: Bibliotheken der Libraries-Schicht [MoKo, S. 7] [Andr09e]
73
74
PacketVideo ist Mitglied der Open Handset Alliance.
Google Chrome benutzt ebenfalls die Rendering-Engine WebKit.
34
3 Android im Detail
3.1.4
Android Runtime
Die Laufzeitumgebung von Android besteht aus den Core Libraries und der Dalvik Virtual
Machine (VM). Sie ist auf der gleichen Schicht wie die Libraries-Schicht angesiedelt.
Core Libraries
Hierbei handelt es sich um viele Java-Pakete der Java Platform, Standard Edition. Folgende
Pakete werden dabei unterstützt:
Paket
Beschreibung
Eingabe und Ausgabe von Dateien und Streams
java.lang
elementare Grundklasse
java.math
Zahlendarstellung
java.net
Netzwerkprogrammierung
java.nio
Ergänzung zu java.io
java.security
Sicherheit
java.sql
Datenbankanbindung
java.text
Internationalisierung von Zahlen und Strings
java.util
List, Map, Set, Array, Collection
javax.crypto
Kryptografie
javax.net
Netzwerkprogrammierung
javax.security
Sicherheit
javax.sound
Audioverarbeitung
javax.sql
Datenbankanbindung
javax.xml.parsers XML-Parser
org.w3c.dom
DOM
org.xml.sax
SAX-Parser
java.io
Tab. 13: Core Libraries der Android Runtime-Schicht [MoKo09, S. 8] [Burn08]
Hinzu kommen Pakete von Drittanbietern wie:
Paket
Beschreibung
Werkzeuge für Encodierung und Decodierung
org.apache.commons.httpclient Unterstützung der Protokolle HTTP und HTTPS
org.bluez
Anbindung von Bluetooth
org.json
Datenformat, kompakter kodiert als XML
org.apache.commons.codec
Tab. 14: zusätzliche Core Libraries der Android Runtime-Schicht [Burn08]
35
3 Android im Detail
Dalvik Virtual Machine
Die Dalvik Virtual Machine (Dalvik VM) ist eine Java Virtual Machine (JVM), die für mobile
Geräte optimiert wurde. Der Google-Mitarbeiter Dan Bornstein hat seiner Erfindung den
Namen Dalvik verliehen, nach der gleichnamigen Stadt in Island, aus dem einige seiner
Vorfahren stammen. Im Gegensatz zur JVM, die auf einer Stack Machine basiert, beruht die
Dalvik VM auf der Architektur einer Register Machine. Der Vorteil dabei ist, dass dieser
Bytecode auf ARM-Prozessoren, die in mobilen Endgeräten eingesetzt werden und selbst
auf einer Stack Machine basieren, wenig Speicherplatz benötigt und effizient ausgeführt
wird.
Auf den Just-in-time Compiler (JIT), der in einer JVM den Bytecode bei Bedarf in nativen
Maschinencode übersetzt, wird verzichtet. Stattdessen wird bereits vorher der Bytecode
mit dem Dalvik Cross-Compiler von Stack Machine- in Register Machine-Architektur
umgewandelt.
Für die Entwicklung einer Applikation lassen sich folgende Schritte zusammenfassen:
Schritt
Erstellung von Quelltext
Kompilierung in Bytecode (Stack Machine)
Umwandlung in Bytecode (Register Machine)
Erstellung eines Android Packages
Ausführung in Dalvik VM
Werkzeug
Texteditor
Java Compiler
Dalvik Cross-Compiler
AAPT
Android
Dateiendung
.java
.class
.dex
.apk
Tab. 15: Entwicklungsschritte einer Android-Applikation
Es bleibt anzumerken, dass jede Anwendung in einem Prozess in einer Instanz der Dalvik
VM ausgeführt wird. Daher wurde Dalvik so entwickelt, dass mehrere VMs auf einem Gerät
parallel betrieben werden. 75 76
3.1.5
Linux Kernel
Die unterste Schicht fungiert als ein Hardware Abstraction Layer (HAL) zwischen der
physischen Hardware und dem Android Software Stack. Da Android von einem Linux Kernel
in der Version 2.6 Gebrauch macht, werden von der Linux Kernel-Schicht folgende
Funktionalitäten bereitgestellt: 77
■
■
■
■
■
75
Sicherheit
Speichermanagement
Prozessmanagement
Netzwerkanbindung
Treiber
Vgl. [MoKo, S. 7]
Vgl. [Andr09e]
77
Vgl. [Ande09e]
76
36
3 Android im Detail
3.2 Software Development Kit
In diesem Unterkapitel wird beschrieben, wie das Android SDK heruntergeladen und
installiert wird. Auch wird erklärt, wie mit den Quelltexten zu verfahren ist. Des Weiteren
werden alle Werkzeuge vom SDK einzeln vorgestellt. Der letze Abschnitt handelt von einem
Plug-In für Eclipse, welches die Werkzeuge in die IDE integriert.
Herunterladen
Auf der Android Developers-Homepage 78 stehen folgende SDKs für die Betriebssysteme
Windows, Mac OS X und Linux zum Herunterladen bereit: 79
SDK
Android 1.5 SDK, r3
Android 1.5 NDK, r1
Datum
07.2009
06.2009
Android 1.1 SDK, r1
Android 1.0 SDK, r2
02.2009
11.2008
Beschreibung
Neuste Version (irrelevant für diese Arbeit)
Erweiterung zum SDK 1.5, ermöglicht Benutzung der
Programmiersprache C / C++ und nativen Zugriff auf
Bibliotheken der Library-Schicht
Relevant für diese Arbeit
Veraltete Version (irrelevant für diese Arbeit)
Tab. 16: Verschiedene Android SDKs [Andre09g]
Installation
Für die Installation muss lediglich die ZIP-Datei, welche rund 80 MB groß ist, extrahiert und
das Unterverzeichnis tools in den Pfad aufgenommen werden:
■ Unter
Linux
wird
die
Datei
.bashrc
um
folgende
Zeile
erweitert:
export PATH=${PATH}:/home/schmitz/android-sdk-linux_x86-1.1_r1/tools
■ Unter Windows wird die Umgebungsvariable PATH um folgenden Pfad erweitert:
D:\android-sdk-windows-1.1_r1\tools;
Quelltexte
Die Quelltexte von Android sind nicht in dem SDK enthalten. Diese befinden sich in einem
Git-Repository. Git ist, wie auch Subversion (SVN) und Concurrent Versions System (CVS),
ein Softwaresystem zur Versionsverwaltung von Quelltexten. Für den Benutzer besteht
lediglich die Möglichkeit, das vollständige und 2,1 GB große Repository auf einmal
herunterzuladen. Dafür werden die Programme Git und Repo benötigt, die nur für Linux
und Mac OS verfügbar sind. Die Quelltexte für das Android SDK sind im heruntergeladenen
Repository zu finden unter mydroid/frameworks/base/core/java. Es wird empfohlen, im
Android SDK den Ordner source anzulegen und die Quelltexte dorthin zu kopieren.
Dadurch kann ein Entwickler in einer IDE wie Eclipse die Quelltexte komfortabel öffnen und
studieren. 80 81
78
Vgl. [Andr09g]
Stand vom 5.9.2009
80
Vgl. [Burk08]
81
Vgl. [Andr09h]
79
37
3 Android im Detail
3.3 Entwicklungswerkzeuge
Im Unterordner tools vom installierten Android SDK befinden sich Werkzeuge, die bei der
Entwicklung von Applikationen hilfreich sind bzw. sie erst möglich machen. Diese werden
nun im Einzelnen vorgestellt.
3.3.1
Android Emulator
Der Android Emulator ist ein virtuelles Smartphone auf dem Entwicklungscomputer, das
den vollständigen Android System Stack abbildet. Bis auf die Möglichkeit zu telefonieren
stehen dem Benutzer die Hardware und Software eines typischen Android Smartphones zur
Verfügung. Folgende Hardware wird emuliert: 82
■
■
■
■
■
■
■
ARMv5 Prozessor mit entsprechender Speicherausstattung
16-bit LCD-Display
Tastatur
Soundchip
SD Memory Card
GSM Modem
SIM Karte
Der Emulator wird auf der Kommandozeile mit dem Befehl emulator gestartet und durch
zahlreiche Parameter konfiguriert. Einige wichtige Parameter lauten: 83
Parameter
-sdcard <filepath>
-wipe-data
-noaudio
-skin <skinId>
Beschreibung
Es wird eine SD Memory Card eingebunden, welche durch eine
Image-Datei repräsentiert wird. Diese lässt sich mit dem
Werkzeug mksdcard erzeugen.
Setzt den Emulator auf Werkseinstellung zurück. Alle
Änderungen und installierte Applikationen gehen verloren.
Schaltet die Audioeigenschaften vom Emulator ab.
Startet den Emulator mit der angegebenen Oberfläche.
Tab. 17: Parameter für den Android Emulator
Standardmäßig wird die Oberfläche HVGA-P mit einer Auflösung von 320x480 Pixeln im
Hochformat geladen. Insgesamt werden vier verschiedene Oberflächen im SDK
bereitgestellt. Diese befinden sich im Unterordner tools\lib\images\skins vom
installiertem Android SDK:
82
83
Vgl. [Andr09i]
Vgl. [Andr09i]
38
3 Android im Detail
Name
HVGA-L
Beschreibung
480x320, Querformat
HVGA-P
320x480, Hochformat
QVGA-L
320x240, Querformat
Aussehen
QVGA-P 240x320, Hochformat
Tab. 18:: Vier verschiedene Skins vom Android Emulator [Andr09i]
Im Internet sind viele weitere Oberflächen zu finden. Diese sind insofern sinnvoll, als dass
ein Entwickler seine Applikation in den unterschiedlichsten Auflösungen testen kann.
Erwähnenswert ist die Oberfläche namens T-Mobile
T Mobile G1, da es das erste erschienene
erschiene
84
Android Smartphone nachbildet, inklusive der aufklappbaren Tastatur.
84
Die Oberfläche T-Mobile
Mobile G1 ist zu finden auf: [Shark08].
39
3 Android im Detail
Detai
3.3.2
Hierarchy Viewer
Hierarchy
chy Viewer ist ein Werkzeug um die Benutzeroberfläche einer Applikation detailliert
zu untersuchen. Gestartet wieder dieser auf der Kommandozeile mit dem Befehl
hierarchyviewer. Es wird ein laufender Emulator oder ein angeschlossenes Endgerät
vorausgesetzt,, da der aktuelle Screen die Basis für die Analyse darstellt. Im Layout View
kann der Benutzer die GUI-Komponenten
Komponenten in einer Baumdarstellung betrachten. Die zweite
Ansicht wird als Pixel Perfect View bezeichnet und bietet die Möglichkeit, mit einer
virtuellen
en Lupe den Screen pixelgenau zu analysieren.85
3.3.3
Draw 9-patch
Draw 9-patch
patch ist ein WYSIWYG-Editor
WYSIWYG
zur Erstellung von NinePatch-Grafiken.
Grafiken. Dabei handelt
es sich um Grafiken mit zusätzlichen Informationen über Streckverhalten sowie
Textpositionierung, die in Android für GUI-Komponenten
GUI Komponenten wie z.B. Buttons verwendet
werden. Gestartet wird
d der Editor auf der Kommandozeile mit dem Befehl draw9patch.
Anhand eines Beispiels soll der Vorteil von NinePatch-Grafiken
NinePatch Grafiken verdeutlicht werden:
Für eine GUI wurde von einem Designer
Desig
folgender Button erzeugt:
Abb. 18: Beispiel-Button
Der Button soll in einer GUI mit einem langen Text gefüllt werden. Damit der Text in den
Button passt, muss die Grafik in X-Richtung
X
gestreckt werden. Das Ergebnis sieht so aus:
Abb. 19: Beispiel-Button in X-Richtung gestreckt
Die Probleme sind klar ersichtlich: Da die Grafik proportional gestreckt wurde, sind die
Rahmen als auch die Schatten ebenso gestreckt worden. Zum Zweiten
weiten ragt der Text über
die Begrenzungen hinaus.
Die Lösung für das Problem besteht darin, mit Draw 9-patch
9 patch die ursprüngliche Grafik um
zusätzliche Informationen über Streckverhalten und Textpositionierung zu versehen. Das
Ergebnis sieht erwartungsgemäß ansprechender aus:
85
Vgl. [MoKo09, S. 27 f]
40
3 Android im Detail
Abb. 20: Beispiel-Button als NinePatch-Grafik
Folgende
olgende Abbildung zeigt Draw 9-Patch
9
mit dem Beispiel-Button
Button als NinePatch-Grafik:
NinePatch
Abb. 21:
21 Draw 9-patch mit Beispiel-Button als NinePatch-Grafik
Indem der Benutzer außerhalb des Bildes schwarze Pixel setzt, werden die zusätzlichen
Informationen hinzugefügt. Der linke und obere Bereich repräsentieren dabei den
Ausschnitt vom Bild, der gestreckt werden darf. Da sich der Beispiel-Button
Beispiel Button innerhalb der
Rahmen in X-Richtung
Richtung wiederholt, reicht es im oberen Bereich nur einen Pixel zu setzen. Im
linken Bereich wurden so viele Pixel wie möglich ausgewählt und nur die Krümmung der
Ecken ausgespart. Der rechte und untere Bereich repräsentiert die Fläche, in die Text
eingefügt werden soll. Hier wurde so viel Platz wie möglich vergeben. Lediglich die Ecken
wurden wieder ausgespart.
Nachdem die Grafik so erweitert wurde, kann es unter der Dateiendung .9.png gespeichert
werden. Die Interpretation der zusätzlichen Informationen
Informationen und deren Umsetzung in der
Applikations-GUI werden von Android selbständig übernommen.
41
3 Android im Detail
3.3.4
Dalvik Debug Monitor Service
Mit dem Dalvik Debug Monitor Service (DDMS) können Applikationen und Prozesse, die auf
dem Emulator oder auf einem angeschlossenem Endgerät laufen, überwacht werden.
Gestartet wird dieser auf der Kommandozeile mit dem Befehl ddms. Es werden folgende
Funktionen angeboten: 86
■
■
■
■
■
Screenshot vom aktuellen Screen
Port-Weiterleitung
Informationen über Threads und Heap
LogCat
Simulation von Anrufen und SMS
Folgende Abbildung zeigt Dalvik Debug Monitor Service:
Abb. 22: Dalvik Debug Monitor Service
Im linken Bereich sind die Applikationen und die Endgeräte bzw. Emulatoren zu sehen. Der
untere Bereich LogCat zeigt das Protokoll aller Log-Ausgaben. Es können verschiedene LogLevel wie Debug, Info, Warning oder Error gewählt werden. Aufgrund der vielen LogEinträge durch Betriebssystem und laufende Prozesse kann die Ausgabe nach Tags oder
Prozess-IDs gefiltert werden. Im rechten Bereich sind verschiedene Informationen über
Threads und Heap verfügbar. Beispielsweise können hier eine Garbage-Collection
erzwungen oder Prozesse beendet werden. Außerdem können in diesem Bereich Ereignisse
wie eingehende Anrufe, Empfang von SMS und GPS-Positionsänderungen im Emulator
simuliert werden.
86
Vgl. [MoKo09, S. 31}
42
3 Android im Detail
3.3.5
Android Debug Bridge
Die Android Debug Bridge (ADB) ist ein konsolenbasiertes Programm, mit dem der Emulator
oder ein angeschlossenes Endgerät angesteuert werden kann. Das Programm besteht aus
folgenden drei Teilen: 87
■ Client, der auf dem Entwicklungsrechner läuft
■ Dämon, der als Hintergrundprozess auf jedem Emulator bzw. Endgerät läuft
■ Server, der als Hintergrundprozess auf dem Entwicklungsrechner läuft und die
Kommunikation zwischen Client und Dämon steuert
ADB wird auf der Kommandozeile mit dem Befehl adb gestartet und durch zahlreiche
Parameter konfiguriert. Einige wichtige Aufrufe lauten: 88
Aufruf
adb devices
adb install <apk>
adb uninstall <package>
adb pull <remote> <local>
adb push <local> <remote>
adb kill-server
adb start-server
adb shell
Beschreibung
Zeigt eine Liste der Geräte wie Emulator oder
angeschlossenes Endgerät an.
Installiert oder updatet eine Applikation. Diese lässt sich
mit dem Werkzeug Android Asset Packaging Tool
erzeugen.
Deinstalliert
eine
Applikation
anhand
ihres
Paketnamens.
Kopiert eine Datei vom Emulator oder Endgerät.
Kopiert eine Datei zum Emulator oder Endgerät.
Beendet den Server auf dem Entwicklungsrechner.
Startet den Server auf dem Entwicklungsrechner.
Startet eine Shell auf dem Emulator oder
angeschlossenem Endgerät.
Tab. 19: Aufrufe der Android Debug Bridge
3.3.6
Android Asset Packaging Tool
Das Android Asset Packaging Tool (AAPT) dient dazu, Archive wie JAR, ZIP und Android
Package (APK) zu betrachten, erzeugen und zu aktualisieren. Eine APK-Datei ist eine
Android-Applikation, die sowohl Register Machine-Bytecode als auch binäre Ressourcen
beinhaltet und mit ADB auf dem Emulator oder einem angeschlossenem Endgerät installiert
wird. AAPT wird auf der Kommandozeile mit dem Befehl aapt gestartet und durch
zahlreiche Parameter konfiguriert. 89
87
Vgl. [Andr09j]
Vgl. [Andr09j]
89
Vgl. [Andr09k]
88
43
3 Android im Detail
3.3.7
Android Interface Description Language
Android Interface Description Language (AIDL) ist eine Interface Description Language (IDL),
bekannt durch die Verwendung bei Remote Procedure Call (RPC). Sie dient der
Kommunikation zwischen verschiedenen Prozessen, Interprocess Communication (IPC)
genannt. Da bei Android jede Applikation in einem eigenen Prozess läuft, kann der Fall
eintreten, dass Objekte ausgetauscht werden müssen. Zu diesem Zweck wird in der
Programmiersprache IDL ein Interface (Dateiendung .aidl) geschrieben. Auf der
Kommandozeile wird der Befehl aidl abgesetzt und ein Java-Interface generiert. Der
Entwickler schreibt eine Stub-Klasse und implementiert die Methoden vom Interface. Die
Prozesse können nun über diese Stub-Klasse die Objekte austauschen. 90
3.3.8
sqlite3
Sqlite3 ist ein kommandozeilenbasiertes Program, welches innerhalb einer ADB-Shell
ausgeführt wird. Dadurch wird der Zugriff auf die SQLite-Datenbanken auf den Emulator
oder angeschlossenen Endgerät gewährt. In der Datenbanksprache Structured Query
Language (SQL) werden die Daten der relationalen Datenbanken definiert, abgefragt und
manipuliert.
Folgendes Beispiel erzeugt eine Datenbank mit einer Tabelle und drei Datensätzen, und gibt
diese aus:
Aufruf
adb shell
sqlite3 data/data/test.db
CREATE TABLE adressen
(id INT PRIMARY KEY, name VARCHAR(30));
INSERT INTO adressen(id, name)
VALUES (1, 'Schmitz');
INSERT INTO adressen(id, name)
VALUES (2, 'Sachweh');
INSERT INTO adressen(id, name)
VALUES (3, 'Ecke-Schüth');
SELECT * FROM adressen;
.exit
exit
Tab. 20: Beispiel für sqlite3
90
Vgl [Andr09l]
Beschreibung
Shell starten
sqlite3 starten
Tabelle erzeugen
Datensatz einfügen
Datensatz einfügen
Datensatz einfügen
Daten abfragen
sqlite3 verlassen
Shell verlassen
44
3 Android im Detail
3.3.9
mksdcard
Das Werkzeug mksdcard wird auf der Kommandozeile ausgeführt und erzeugt ein FAT32Disk-Image. Die Parameter für den Aufruf lauten: 91
Argument
Beschreibung
Bezeichnung für Datenträger
<size>[K|M] Größe in Byte, Kilobyte oder Megabyte
<file>
Pfad und Dateiname für das Image
[-l label]
Tab. 21: Parameter für mksdcard
Beispielsweise erzeugt folgender Aufruf ein 64 MB großes Image mit der Bezeichnung
BeispielImage und dem Dateinamen beispiel.img:
mksdcard -l BeispielImage 64M beispiel.img
Die SD Memory Card, welche durch die Image-Datei repräsentiert wird, lässt sich wie folgt
in den Emulator einbinden:
emulator -sdcard beispiel.img
Im Hauptverzeichnis vom Emulator-Dateisystem befindet sich nun der Ordner sdcard. Um
eine Datei wie z.B. ein Bild auf die simulierte Memory SD Card zu kopieren, wird folgender
ADB-Befehl auf der Kommandozeile ausgeführt:
adb push Bild.jpg sdcard
In einer ADB-Shell kann auf diesen Ordner mittels Linux-Kommandos zugegriffen werden.
3.3.10 Dalvik Cross-Compiler
Der Dalvik Cross-Compiler dx wird auf der Kommandozeile ausgeführt und wandelt den
Stack Machine-Bytecode (Dateiendung .class) in Register Machine-Bytecode
(Dateiendung .dex) um. Nur dieser transformierte Bytecode kann in der Dalvik VM als
Applikation ausgeführt werden.
91
Vgl. [Andr09m]
45
3 Android im Detail
3.3.11 UI/Application Exerciser Monkey
Das Werkzeug UI/Application Exerciser Monkey wird auf der Kommandozeile ausgeführt
und sendet dem Emulator oder einem angeschlossenem Endgerät eine Reihe zufälliger
Benutzerereignisse. Dadurch wird eine Applikation einem Stresstest unterzogen. Es stehen
dabei Optionen aus vier Kategorien zur Auswahl: 92
■
■
■
■
Anzahl der Ereignisse
Beschränkung auf bestimmte Pakete
Art und Frequenz der Benutzerereignisse
Debugging-Einstellungen
Beispielsweise öffnet folgenden Aufruf die Applikation im Paket android.monkey.test und
versendet 500 zufällige Benutzerevents: 93
adb shell monkey -p android.monkey.test -v 500
3.3.12 activitycreator
Das Werkzeug activitycreator generiert alle notwendigen Dateien und Ordner für eine
Applikation: 94
Datei oder Ordner
AndroidManifest.xml
build.xml
res
src
bin
Beschreibung
Manifest-Datei der Applikation
Ant-Script zum Erzeugen der Applikation
Ressourcen-Ordner
Quelltext-Ordner samt Activity-Klasse
Ordner für Bytecode- und APK-Dateien
Tab. 22: Von activitycreator generierte Dateien und Ordner
Folgender Aufruf erzeugt im aktuellen Ordner das Notwendige für die Applikation im Paket
android.activitycreator mit der Activity-Klasse namens TestActivity:
activitycreator android.activitycreator.TestActivity
92
Vgl. [Andr09n]
Vgl. [Andr09n]
94
Vgl. [MoKo09, S. 38]
93
46
3 Android im Detail
3.4 Android Development Toolkit Plug-In für Eclipse
Android Development Toolkit (ADT) ist ein Plug-In für Eclipse, durch das die meisten
Entwicklungswerkzeuge in die IDE integriert werden. Sämtliche Funktionen vom Dalvik
Debug Monitor Service sind über die neue Perspektive DDMS erreichbar. Mit einem Wizard
wird ein neues Android-Projekt aufgesetzt, und die notwendigen Dateien und Ordner
werden durch activitycreator erzeugt. Beim Kompilieren der Quelltexte werden
automatisch Dalvik Cross-Compiler und Android Asset Packaging Tool ausgeführt. Zum
Testen der Applikation wird Android Emulator gestartet, nachdem mittels Android Debug
Bridge die Applikation installiert wurde.
Erweiterungen
Da bei der Entwicklung einer Android-Applikation neben Java auch XML eingesetzt wird,
existieren folgende Erweiterungen für Eclipse:
■
■
■
■
■
■
Android Java Editor
Android Layout Editor
Android Manifest Editor
Android Menu Editor
Android Resource Editor
Android Xml Resources Editor
Installation
Da auf der Android Developer-Homepage mehrere SDKs zum Herunterladen angeboten
werden, existieren auch verschiedene Plug-Ins. Folgende Tabelle zeigt, welches Plug-In zu
welcher SDK kompatibel ist: 95
SDK
Android 1.5 SDK, r3
Android 1.1 SDK, r1
Android 1.0 SDK, r2
Plug-In
Android Development Toolkit 0.9.1
Android Development Toolkit 0.8.0
Android Development Toolkit 0.8.0
Tab. 23: Android SDKs und Plug-Ins
Die Installation erfolgt über die üblichen Mechanismen. Nach dem Neustart von Eclipse ist
lediglich der Ordner vom installiertem Android SDK einzutragen.
95
Vgl. [Androi09o]
47
3 Android im Detail
3.5 Endgeräte mit Android-Betriebssystem
In diesem Unterkapitel werden die aktuell bekannten Endgeräte mit AndroidBetriebssystem vorgestellt. Auch wird Kritik über das erste Android Smartphone, dem HTC
Dream alias T-Mobile G1, wiedergegeben.
3.5.1
T-Mobile G1 – HTC Dream
Die High Tech Computer (HTC) Corporation, Hersteller von Mobiltelefonen mit Hauptsitz in
Taiwan, fertigt das Smartphone HTC Dream. Zusammen mit der Mobilfunkgesellschaft
T-Mobile wurde im Herbst 2008 das erste Endgerät mit Android-Betriebssystem unter dem
Produktnamen T-Mobile G1 auf den Markt gebracht. Seit Oktober 2008 ist es in den USA
und in England verfügbar, seit Anfang 2009 in Österreich und Holland, und seit Februar
2009 auch in Deutschland. Der Preis in den USA beträgt 149,99 USD mit einem speziellen
Mobilfunkvertrag bei T-Mobile und 399 USD ohne Vertragsbindung.
Das amerikanische Smartphone wird mit einem SIM-Lock für T-Mobile vertrieben, so dass
Kunden anderer Mobilfunkanbieter ihre SIM-Karten nicht benutzen können. Findige Hacker
haben es geschafft, diesen Schutz auszuhebeln. Dafür benötigt der Interessierte die
Seriennummer des Gerätes, die sogenannte International Mobile Equipment Identity
(IMEI), welche auf der Batterie aufgedruckt ist. Diese 15-stellige Nummer wird per Email
versendet, und nach erfolgter Überweisung von 23,99 USD erhält der Interessierte einen
einzigartigen Unlock-Code. Nach erfolgreicher Eingabe kann das G1 nun mit den SIM-Karten
sämtlicher Mobilfunkanbieter betrieben werden. 96
Android Dev Phone 1
Seit Dezember 2008 wird von Google das Android Dev Phone 1 angeboten, eine spezielle
Version vom HTC Dream, welches nur für registrierte Entwickler zugänglich ist. Nachdem
sich der Entwickler beim Android Market registriert hat und 25 USD gezahlt hat, besteht die
Möglichkeit genau ein Exemplar des Android Dev Phone 1 für 399 USD zu erwerben. Das
Besondere daran ist, dass kein SIM-Lock existiert, voller Zugriff auf alle Dateien gewährt
wird, der Benutzer über Superuser-Rechte verfügt, der Bootloader und das OS beliebig
überspielt werden können und spezielle Entwicklerwerkzeuge vorinstalliert sind.
Aus technischer Sicht ist das T-Mobile G1 mit Quadband GSM und UMTS ausgestattet, dem
Mobilfunkstandard der dritten Generation (3G). Das Display ist ein 3,2 Zoll LCD-TFTTouchscreen mit einer Auflösung von 480x320 Pixel und 65.536 Farben. Die Speichergröße
beträgt 256 MB ROM und 192 MB RAM und ist mittels einer SD Memory Card beliebig
erweiterbar. Der Prozessor ist ein Qualcomm MSM7201A, der dynamisch getaktet ist
zwischen 82 und 384 MHz. Es werden WLAN (IEEE 802.11b/g) und Bluetooth 2.0 mit
erhöhter Datenrate unterstützt und eine Kombination aus Audioanschluss und Mini-USB
bereitgestellt. Des Weiteren ist eine 3,2 Megapixel Kamera mit Autofokus und 2-fach
digitalem Zoom integriert. Die Besonderheiten sind die ausziehbare QWERTY Tastatur, ein
96
Vgl. [Unlo]
48
3 Android im Detail
GPS-Empfänger für satellitenunterstützte Positionsbestimmung und Zeitmessung, ein
digitaler Kompass, Beschleunigungssensoren und ein 2-Achsen Lagesensor. 97
Auch ohne ausgezogene Tastatur sind folgende Tasten verfügbar:
Taste
Hörer abheben
Haus
Trackball
Zurück
Hörer auflegen
Menü
Beschreibung
zum Anrufen oder Entgegennehmen eingehender Anrufe
zum Anzeigen des Desktops bzw. zum Verlassen der Anwendung
zum Navigieren ohne Touchscreen
zeigt den vorherigen Screen an
zum Beenden des Telefonates oder zum Aktivieren
Energiesparmodus
zeigt das Kontextmenü zum aktuellen Screen
vom
Tab. 24: Funktionstasten vom T-Mobile G1
Folgende Abbildung zeigt das T-Mobile G1 in weißer Farbe mit ausgezogener Tastatur:
Abb. 23: T-Mobile G1 – HTC Dream [Spar09]
Kritik
Kurze Zeit nach der Markteinführung des T-Mobile G1 erschien auf Spiegel Online ein
Artikel, der kritische Stimmen wiedergibt: „Matthew Miller (ZDnet) bemängelt, dass das G1
keinen normalen Kopfhöreranschluss hat - sondern einen Kopfhörer-Adapter für den USBPort braucht. Ihn stört auch, dass die Kamera keine Videos aufzeichnen kann. […] Walt
Mossberg (Wall Street Journal) kritisiert vor allem die Benutzeroberfläche des Telefons.
Besonders problematisch findet er, dass die Möglichkeiten, Kalender, E-Mails und Adressen
mit einem Computer zu synchronisieren, höchst eingeschränkt sind. […] David Pogue (New
York Times) […] stört auch, dass das Bild auf dem Schirm des G1 nicht automatisch rotiert,
97
Vgl. [Wiki09a]
49
3 Android im Detail
wenn man das Telefon auf die Seite dreht (wie beim iPhone), dass die
die Batterie so schnell
schlappmache (Pogue spricht von drei bis fünf Stunden unter Last) und dass es einfach nicht
so hübsch ist wie das Apple--Telefon.
Telefon. […] Peter Ha (CrunchGear) beklagt, dass sich das G1
nur mit einem einzigen Googlemail-Account
Googlemail
koppeln lässt.
sst. Für Menschen mit einem
privaten und einem geschäftlichen E-Mail-Konto
E
Konto ist es derzeit kaum geeignet.“ 98
3.5.2
Vodafone G2 – HTC Magic
Fast zeitgleich mit der Einführung des T-Mobile
T Mobile G1 in Deutschland wurde im Februar 2009
auf dem Mobile World Congress von Vodafone
dafone das HTC Magic unter dem Produktnamen G2
vorgestellt. Optisch und technisch ähnelt es sehr stark seinem Vorgänger. Hauptsächlich
wurde die ausklappbare Tastatur weggelassen, was das Smartphone 40 Gramm leichter
macht. Über eine Touchscreen-Tastatur,
Touchscreen
die Teil der neusten Android-Version
Version ist, werden
die Benutzereingaben entgegen genommen. Display und Prozessor sind identisch mit dem
Vorgänger, einzig die Speichergröße wurde auf 512 MB ROM und 288 MB RAM erweitert. 99
Folgende Abbildung zeigt das Vodafone G2:
Abb. 24: Vodafone G2 – HTC Magic [Kret09a]
98
99
[Spie08]
Vgl. [Kret09]
50
3 Android im Detail
3.5.3
HTC Hero
Im Juni 2009 wurde von der HTC Corporation das dritte Smartphone mit AndroidBetriebssystem angekündigt. Technisch und optisch ähnelt das HTC Hero erneut seinem
Vorgänger, dem HTC Magic. Display, Prozessor und Speicher sind identisch. Die
Digitalkamera wurde durch eine 5 Megapixel Kamera mit Autofokus abgelöst.
Hinzugekommen ist eine 3,5 mm Audiobuchse, so dass mittels handelsüblicher Kopfhörer
Musik gehört werden kann statt wie bisher über spezielle USB-Kopfhörer. Auch wurde der
Lithium-Ionen-Akku mit 1350 mAh mit etwas mehr Kapazität ausgestattet. Die wirkliche
Neuerung ist die neue Bedienoberfläche HTC Sense, die der Hersteller künftig bei all seinen
Smartphones mitliefern will. Mittels spezieller Profile kann der Benutzer auf
unterschiedliche
Inhalte
und
Anwendungen
zugreifen.
Verschiedene
Kommunikationskanäle wie Telefonanrufe, Emails oder SMS werden in eine einheitliche
Ansicht integriert. 100 Folgende Abbildung zeigt das HTC Hero:
Abb. 25: HTC Hero [Kret09b]
100
Vgl. [Kret09b]
51
3 Android im Detail
3.5.4
Kogan Agora
Ende Januar 2009 sollte das ursprünglich zweite Android Smartphone vom australischen
Hersteller Kogan weltweit in den Handel kommen. Das Smartphone sollte es in zwei
Varianten geben, als Agora und Agora Pro. Beide Smartphones sollten mit einem 2,5 Zoll
großem Touchscreen-Display ausgestattet sein, einer QWERTY-Tastatur auf der
Vorderseite, UMTS und Bluetooth Schnittstellen und einen 3,5 mm Kopfhöreranschluss. Der
Prozessor ist mit 624 MHz getaktet und der interne Speicher 256 MB groß. Der Preis sollte
für das Modell Agora 299 AUD und für Agora Pro 399 AUD betragen. Das teurere Modell
sollte zusätzlich ein GPS-Empfänger, Unterstützung für WLAN und eine 2 Megapixel
Digitalkamera bieten. 101 Die Auslieferung beider Smartphones wurde zwei Wochen vor
Markteintritt gestoppt. Als Grund dafür wurde die vergleichsweise niedrige Auflösung von
320x240 Pixel angegeben. Im Vergleich dazu bietet das T-Mobile G1 eine Auflösung von
480x320 Pixel, welches bereits als Referenz für Softwareentwickler gilt. 102 Folgende
Abbildung zeigt das Kogan Agora (Pro):
Abb. 26: Kogan Agora (Pro) [Kret09c]
101
102
Vgl. [Kret09c]
Vgl. [Kret09d]
52
3 Android im Detail
3.5.5
Lenovo OPhone
Der durch seine Notebooks bekannt gewordene Hersteller Lenovo produziert auch ein
Android Smartphone, welches firmenintern unter dem Namen OPhone geführt wird. Da das
Gerät für den asiatischen Markt ausgelegt ist, ist die Wahrscheinlichkeit sehr gering dass es
in Deutschland verfügbar sein wird. Auf eine ausziehbare Tastatur und sogar auf die
Menütasten wird gänzlich verzichtet, da die Eingabe über eine virtuelle Tastatur erfolgen
soll, wahlweise in Chinesisch oder Englisch. Über Prozessor und Speicherausstattung ist
bisher nichts bekannt. Allerding soll das Gerät über eine 5 Megapixel Kamera mit
Autofokus, Blitz und Videofunktion verfügen. 103 Folgende Abbildung zeigt das Lenovo
OPhone:
Abb. 27: Lenovo OPhone [Melz08]
103
Vgl. [Melz08]
53
3 Android im Detail
3.5.6
Samsung I7500 Galaxy
Seit Juni 2009 ist beim Mobilfunkanbieter O2 auch ein Smartphone mit AndroidBetriebssystem erhältlich, das Samsung I7500 Galaxy. Das 3,2 Zoll Touchscreen Display
benötigt durch die Active Matrix Organic Light Emitting Diode (AMOLED) Technik keine
Hintergrundbeleuchtung wie bei LCD und hat dadurch einen erheblich verbesserten
Kontrast. 104 Die Speicherausstattung ist mit 8 GB konkurrenzlos und lässt sich mittels
microSD-Karte auf bis zu 32 GB erweitern – allerdings nur, wenn vorher das Gerät
ausgeschaltet und der Akku entfernt wird. Im Gegensatz zum T-Mobile G1 mit 1150 mAh
verfügt die Batterie mit 1500 mAh über deutlich mehr Kapazität. Zu den üblichen
Schnittstellen zählt auch ein 3,5 Millimeter Kopfhöreranschluss. Des Weiteren ist das Gerät
mit einer 5 Megapixel Digitalkamera mit LED-Blitz ausgestattet. 105 Folgende Abbildung zeigt
das Samsung I7500 Galaxy:
Abb. 28: Samsung I7500 Galaxy [Kret09e]
104
105
Vgl. [Webf09]
Vgl. [Kret09e]
54
4 Entwicklung eines Anmeldeformulars
4 Entwicklung eines Anmeldeformulars
In diesem Kapitel wird am Beispiel eines Anmeldeformulars gezeigt, wie eine AndroidApplikation entwickelt wird. Dabei werden zuerst die Anforderungen zusammengefasst und
anschließend die Erstellung eines Projektes und die Umsetzung erläutert. Die späteren
Unterkapitel demonstrieren, wie GUI-Komponenten angepasst und die Applikation
internationalisiert wird.
4.1 Anforderungen
Es soll ein typisches Anmeldeformular entwickelt werden. Der Benutzer soll seinen Namen
und ein Passwort eingeben können, wobei das Passwort, wie in einem Browserformular,
unleserlich erscheinen soll. Die Bestätigung des Formulars erfolgt über einen Button. Über
die Menü-Taste soll der Benutzer zu einem Hilfe-Dialog gelangen. Zusätzlich soll eine
Checkbox verfügbar sein, die im aktivierten Zustand die Daten des Benutzers speichert und
beim nächsten Aufruf des Dialogs automatisch in die Texteingabefelder einfügt.
4.2 Erstellung von einem Android Project
Unter Eclipse wird mit dem Wizard ein Android Project erstellt. Der Projektname
Anmeldeformular ist nur für Eclipse relevant und nicht für Android. Beim Paketnamen wird
de.android.login eingetragen. Einige der Entwicklungswerkzeuge benötigen diesen
Paketnamen, der im Emulator oder im angeschlossenen Endgerät einzigartig sein muss. Der
Name der Activity repräsentiert den Klassennamen, der vom Wizard im benannten Paket
erzeugt wird. Hier wird LoginActivity gewählt. Zuletzt gilt es die Applikation zu
benennen. Es wird Anmeldeformular gewählt.
Vom Wizard wurde das Projekt Anmeldeformular mit folgenden Dateien erzeugt:
55
4 Entwicklung eines Anmeldeformulars
Abb. 29: Das Android-Projekt: Anmeldeformular
Diese werden nun detailliert erläutert, da sie maßgeblich für das Verständnis sind, wie
Applikationen entwickelt werden.
4.2.1
Manifest
Die Datei AndroidManifest.xml ist die oberste Instanz einer jeden Applikation.
1 <?xml version="1.0" encoding="utf-8"?>
encoding
2 <manifest xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:android "http://schemas.android.com/apk/res/android"
3
package="de.android.login"
"de.android.login"
4
android:versionCode=
="1"
5
android:versionName=
="1.0.0">
6
7
<application android:icon="@drawable/icon"
android:icon
8
adroid:label="@string/app_name"
"@string/app_name">
9
10
<activity android:name=".LoginActivity"
android:name
11
android:label="@string/app_name"
"@string/app_name">
12
13
<intent-filter>
14
<action android:name="android.intent.action.MAIN"
android:name
/>
15
<category android:name="android.intent.category.LAUNCHER"
android:name "android.intent.category.LAUNCHER" />
16
</intent-filter>
>
17
18
</activity>
19
20
</application>
21
22 </manifest>
56
4 Entwicklung eines Anmeldeformulars
Das äußerste Element ist manifest (Zeilen 2-5). Dieses beinhaltet die Attribute XMLNamespace, Paketname, der im Wizard angegeben wurde, Versionscode und
Versionsname. Die letzeren beiden müssen vor jeder Auslieferung erhöht werden, damit
Android die Applikation als Update erkennt.
Das Element application (Zeilen 7-8) beinhaltet die Attribute icon und label. Beide sind
als Referenzen zu verstehen, wie sie in Android häufig verwendet werden. Mit dem Inhalt
@drawable/icon wird die Datei icon.png im Ordner res/drawable, ein Bild mit einer
Größe von 48x48 Pixel, als Icon für die Applikation gesetzt. Der Inhalt @string/app_name
referenziert den String Anmeldeformular in der Ressource res/values/strings.xml, die
später noch erläutert wird.
Da die Applikation nur aus einer Activity besteht, gibt es hier auch nur ein Element
activity (Zeilen 10-11). Dieses beinhaltet die Attribute name, welches den Klassennamen
wiedergibt, und label, welches wieder auf den String Anmeldeformular verweist, der in
der Titlebar der Activity zu sehen sein wird.
Das Element intent-filter (Zeilen 14-15) gibt an, dass diese Activity als erstes bei
Programmstart dargestellt wird. Bei mehreren Activities würde nur eine diesen Intent-Filter
besitzen, die restlichen wären leer.
4.2.2
Strings-Ressource
Die Datei res/values/strings.xml ist die Ressource für alle Strings innerhalb einer
Applikation:
1 <?xml version="1.0" encoding="utf-8"?>
2 <resources>
3
<string name="hello">Hello World, LoginActivity</string>
4
<string name="app_name">Anmeldeformular</string>
5 </resources>
Das oberste Element ressources (Zeile 2) hat keine Attribute. Es beinhaltet lediglich ein
oder mehrere string-Elemente. Diese werden über das Attribut name eindeutig
identifiziert. Der String hello (Zeile 3) wurde vom Wizard erzeugt und wird im Layout
res/layout/main.xml referenziert. Da aber das Layout neu gestaltet werden wird, kann
dieses Element ignoriert bzw. gelöscht werden. Wie bereits erwähnt wird der String
app_name (Zeile 4) in anderen Ressourcen folgendermaßen referenziert: @string/app_name
57
4 Entwicklung eines Anmeldeformulars
4.2.3
Layout
Zu jeder Activity gehört in der Regel ein Layout. Die Date res/layout/main.xml wurde
vom Wizard erzeugt, damit das Projekt lauffähig ist. Obwohl das Layout neu gestaltet wird,
soll dieses einen ersten Einblick gewähren:
1 <?xml version="1.0" encoding="utf-8"?>
2 <LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
android:orientation="vertical"
3
4
android:layout_width="fill_parent"
android:layout_height="fill_parent">
5
6
7
<TextView android:layout_width="fill_parent"
8
android:layout_height="wrap_content"
9
android:text="@string/hello" />
10
11 </LinearLayout>
Das oberste Element LinearLayout (Zeilen 2-5) ist ein Container, der die inneren
Komponenten linear ausrichtet. Durch das Attribut orientation mit dem Wert vertical
(Zeile 3) werden alle Komponenten waagerecht nebeneinander ausgerichtet. Die
Alternative horizontal würde alle Komponenten untereinander anordnen. Mittels der
Attribute layout_width und layout_height wird die Größe eingestellt (Zeilen 4-5). Der
Wert fill_parent bedeutet, dass so viel Platz in Anspruch genommen wird, wie durch die
übergeordneten Elemente bereitgestellt wird. Da LinearLayout das oberste Element ist,
wird hier das gesamte Display beansprucht. Die Alternative wrap_content würde nur so
wenig Platz wie nötig benötigen.
Das einzige innere Element ist TextView (Zeilen 7-9). Es ist so breit wie das übergeordnete
Element erlaubt, also so breit wie das Display. Die Höhe ist minimal und hängt von der
Größe der Schriftart ab. Es wird der Text angezeigt, der in der Strings-Ressource mit dem
Namen hello eindeutig identifiziert wird: Hello World, LoginActivity.
58
4 Entwicklung eines Anmeldeformulars
4.2.4
Ressourcen in Java
Die Klasse src/de/android/login/R.java wird automatisch erzeugt und bei Änderungen
an den Ressourcen aktualisiert. Sie beinhaltet Konstanten, durch die in einem JavaQuelltext auf die Ressourcen zugegriffen werden kann:
1 package de.android.login;
2
3 public final class R {
public static final class attr {
4
5
}
6
public static final class drawable {
7
public static final int icon=0x7f020000;
8
}
9
public static final class layout {
10
public static final int main=0x7f030000;
11
}
12
public static final class string {
public static final int app_name=0x7f040001;
13
14
public static final int hello=0x7f040000;
15
}
16 }
4.2.5
Activity
Die Activity, die laut dem Manifest zu Programmstart ausgeführt werden soll, ist die Klasse
src/de/android/login/LoginActivity.java. Vom Wizard wurde folgendes Gerüst
erzeugt:
1
2
3
4
5
6
7
8
9
10
11
12
13
package de.android.login;
import android.app.Activity;
import android.os.Bundle;
public class LoginActivity extends Activity {
@Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.main);
}
}
Die Klasse LoginActivity erbt von der Klasse android.app.Activity (Zeile 6). Dadurch ist
die gesamte Funktionalität verfügbar, die eine Applikation benötigt. Um ein verändertes
Verhalten zu erreichen, müssen Methoden der Oberklasse überschrieben werden. Durch
die Annotation @Override (Zeile 8) wird dies zum Ausdruck gebracht.
Die Callback-Methode onCreate (Zeilen 9-12) wird ausgeführt, sobald die Activity erzeugt
wird. Als erstes wird die Funktionalität der Oberklasse aufgerufen, die überschrieben wurde
(Zeile 10). Anschließend wird mittels der Klasse R das Layout res/layout/main.xml
geladen und gesetzt.
59
4 Entwicklung eines Anmeldeformulars
4.2.6
Lebenszyklus einer Activity
Folgende Abbildung zeigt den Lebenszyklus einer Activity. Die Funktionalitäten der
aufgeführten Callback-Methoden
Methoden werden, wie bereits erwähnt, von der Elternklasse
android.app.Activity bereitgestellt:
Abb. 30: Lebenszyklus einer Activity [Andr09p]
Der Lebenszyklus einer Activity hängt vom Laufzeitsystem ab, welches alle Activities auf
einen Stack legt. Wird eine Activity erzeugt, so wird sie oben auf den Stack gelegt. Der Stack
wächst also mit der
er Anzahl der Activities. Die oberste Activity ist die derzeit aktive. Drückt
der Benutzer die Zurück-Taste,
Taste, so werden die Positionen der obersten beiden Activities auf
60
4 Entwicklung eines Anmeldeformulars
dem Stack vertauscht. Damit wird die aktive Activity deaktiviert und die vorherige
reaktiviert. Müssen nun Ressourcen freigegeben werden, so wird die unterste Activity vom
Stack entfernt und zerstört. 106
Die verschiedenen Zustände einer Activity sind: 107
Zustand
aktiv
pausiert
gestoppt
zerstört
Beschreibung
Die Activity ist das oberste Element auf dem Stack. Sie ist im
Vordergrund sichtbar und hat den Fokus. Eine aktive Activity wird nur
im Notfall vom Laufzeitsystem vom Stack genommen.
Tritt eine neue Activity in den Vordergrund und verdeckt die alte aber
nicht vollständig 108 , so wechselt die alte Activity in den Zustand
pausiert. Eine pausierte Activity wird nur sehr selten vom
Laufzeitsystem vom Stack genommen.
Tritt eine neue Activity in den Vordergrund und verdeckt die alte
vollständig, so wechselt die alte Activity in den Zustand gestoppt. Sie
bleibt aus Performancegründen im Speicher, für den Fall dass sie
erneut aufgerufen wird. Eine gestoppte Activity wird nur dann vom
Laufzeitsystem vom Stack genommen, wenn sie die unterste Position
einnimmt.
Eine Activity, die vom Laufzeitsystem vom Stack genommen wird,
wechselt in den Zustand zerstört. Sie wird aus dem Speicher entfernt
und belegt keine Ressourcen.
Tab. 25: Alle Zustände einer Activity
106
Vgl. [MoKo, S. 86]
Vgl. [Moko09 S. 86 ff]
108
z.B. aufgrund von transparentem Hintergrund
107
61
4 Entwicklung eines Anmeldeformulars
4.3 Umsetzung
In diesem Unterkapitel werden alle relevanten Schritte aufgeführt,
aufgeführt, die für die Umsetzung
der Anforderungen wichtig sind.
4.3.1
Layout
Für die Umsetzung von dem Anmeldeformular wurde als erstes ein neues Layout erzeugt.
Das neue Layout login.xml benutzt als oberstes Element ein RelativeLayout, mit dem
sich die inneren Elemente abhängig von einander positionieren lassen.
Rechts oben wird das Texteingabefeld für den Benutzernamen platziert. Ein solches Feld
wird durch das Element EditText abgebildet. Die Position erhält es mittels
android:layout_alignParentRight="true"
t_alignParentRight="true". Damit andere Elemente in Abhängigkeit
dazu positioniert werden können, bedarf es einer ID. Dies wird mit dem Attribut
android:id="@+id/edit_user" gewährleistet.
Links oben wird das Label Benutzer: platziert. Ein Label wird durch das Element TextView
abgebildet. Damit es sich auf gleicher Höhe mit dem Texteingabefeld befindet, wird das
Attribut android:layout_alignBaseline="@+id/edit_user" benutzt.
Das Texteingabefeld für das Passwort ist ebenfalls ein EditText. Damit der eingegebene
eingegeb
Text unleserlich ist, wird das Attribut android:password="true" benutzt.
Die CheckBox mit der Bezeichnung Daten speichern wird unterhalb vom Passwortfeld
positioniert. Dies wird mit dem Attribut android:layout_below="@+id/edit_password"
erreicht.
Unterhalb der CheckBox wird ein Button mit dem Text anmelden positioniert.
Damit ist folgendes Layout erreicht:
Abb. 31: Layout vom Anmeldeformular
62
4 Entwicklung eines Anmeldeformulars
4.3.2
Benutzerereignisse
Der Button hat als Attribut mittels dem Attribut android:id="@+id/button_login" eine
ID zugewiesen bekommen. In Java erben alle Komponenten von der Oberklasse
android.view.View. Die Methode findViewById liefert einen solchen View, der mittels
der Klasse R eindeutig identifizierbar ist. Um auf den Button zuzugreifen, ist folgender
Aufruf samt Casting notwendig:
Button login = (Button) findViewById(R.id.button_login);
Um auf ein auf ein Benutzerereignis wie das Betätigen des Buttons zu reagieren, bedarf es
Listener, die mittels Setter mit dem jeweilige Objekt verknüpft werden. Die gesuchte
Methode lautet setOnClickListener und erwartet als Parameter eine Instanz der Klasse
android.view.View.OnClickListener. Dafür existieren zwei Möglichkeiten.
Entweder wird eine eigene Klasse LoginListener geschrieben, die als lokale Unterklasse
von LoginActivity definiert wird.
private class LoginListener implements OnClickListener {
public void onClick(View v) {
}
}
Das Setzen des Listeners funktioniert wie folgt:
login.setOnClickListener(new LoginListener());
Oder es wird eine anonyme Klasse benutzt, die bei der Parameterübergabe definiert wird.
login.setOnClickListener(new OnClickListener() {
public void onClick(View view) {
}
});
Der Nachteil besteht darin, dass der Code nicht wiederverwendet werden kann. Daher wird
innerhalb dieser Arbeit ausschließlich die erste Möglichkeit benutzt.
63
4 Entwicklung eines Anmeldeformulars
4.3.3
Modaler Fehlerdialog
Im LoginListener soll als erstes Benutzername und Passwort ausgelesen werden. Dazu wird
wieder die Methode findViewById aufgerufen.
TextView tv
String user
= (TextView) findViewById(R.id.edit_user);
= tv.getText().toString();
tv
= (TextView) findViewById(R.id.edit_password);
String password = tv.getText().toString();
Ist die Länge gleich null, so wurde vom Benutzer keine Eingabe getätigt und es wird ein
modaler Fehlerdialog ausgegeben. Dieser wird durch eine Instanz der Klasse
android.app.AlertDialog gewährleistet. Mittels Setter wird eine Überschrift, eine
Meldung, ein Button mit der Bezeichnung OK und ein Icon gesetzt:
Builder builder = new AlertDialog.Builder(LoginActivity.this);
builder.setTitle("Wichtig");
builder.setMessage("Bitte geben Sie Ihre Daten ein.");
builder.setPositiveButton("OK", null);
builder.setIcon(R.drawable.important);
builder.show();
Folgender modaler Fehlerdialog wird angezeigt:
Abb. 32: Modaler Fehlerdialog vom Anmeldeformular
64
4 Entwicklung eines Anmeldeformulars
4.3.4
Kontextmenü
Beim Erzeugen der Activity wird eine Callback-Methode aufgerufen, die die Erzeugung vom
Kontextmenü regelt. Durch die Annotation @Override wird zum Ausdruck gebracht, dass
eine Methode der Oberklasse überschrieben wird. Als erstes muss in der Methode
onCreateOptionsMenu die Funktionalität der Oberklasse aufgerufen werden. Anschließend
werden beliebig viele Objekte der Klasse android.view.MenuItem mit einer eindeutigen ID,
einem Text und einem Icon erzeugt und der übergebenen Instanz der Klasse
android.view.Menu zugewiesen:
@Override
public boolean onCreateOptionsMenu(Menu menu) {
super.onCreateOptionsMenu(menu);
MenuItem miHilfe = menu.add(0, 0, 0, "Hilfe");
miHilfe.setIcon(R.drawable.light);
return true;
}
Drückt der Benutzer die Menü-Taste, so wird die Methode onOptionsItemSelected
aufgerufen. Diese ist in der Elternklasse android.app.Activity definiert und wird
überschrieben. Der Getter getItemId vom Parameter android.view.MenuItem liefert die
eindeutige ID zurück. Mittels einer switch-Anweisung können so alle verschiedenen
Menüpunkte abgearbeitet werden. Der Hilfe-Dialog wird analog zum modalen Fehlerdialog
durch eine Instanz der Klasse android.app.AlertDialog erzeugt:
@Override
public boolean onOptionsItemSelected(MenuItem item) {
switch (item.getItemId()) {
case 0:
Builder builder = new AlertDialog.Builder(this);
...
return true;
}
return false;
}
Abb. 33: Kontextmenü (links) und Hilfe-Dialog (rechts) vom Anmeldeformular
65
4 Entwicklung eines Anmeldeformulars
4.3.5
Persistenz
Die letzte Anforderung, die es zu erfüllen gilt, ist die Persistenz. Der Benutzername und das
Passwort sollen gespeichert werden. Es besteht die Möglichkeit, die beiden Strings in einer
Datei zu serialisieren. Auch ist es möglich, von der bereits besprochenen SQLite-Datenbank
Gebrauch zu machen. Dafür müssten im Quelltext verschiedene SQL-Statements abgesetzt
werden:
■ Erzeugung der Tabelle mittels CREATE-Statement
■ Einfügen des Datensatzes mittels INSERT-Statement
■ Abfragen der Daten mittels SELECT-Statement
Da der Einsatz einer Datenbank für diese Aufgabe mit zu viel Arbeit verbunden ist, wird
nach
einer
weiteren
Alternative
gesucht.
Android
stellt
die
Klasse
android.content.SharedPreferences zur Verfügung, die bestimmte Daten pro
Applikation speichern kann.
Das Speichern der beiden Strings lässt sich folgendermaßen umsetzen:
SharedPreferences prefs = getSharedPreferences("Login", MODE_PRIVATE);
Editor ed = prefs.edit();
ed.putString("Benutzer", user);
ed.putString("Passwort", password);
ed.commit();
Durch MODE_PRIVATE sind die gespeicherten Daten nur für diese Applikation verfügbar. Der
Name Login bezeichnet dabei die SharedPreferences eindeutig.
Das Lesen der beiden Strings erfolgt analog:
SharedPreferences prefs = getSharedPreferences("Login", MODE_PRIVATE);
String user = prefs.getString("Benutzer", "");
String password = prefs.getString("Passwort", "");
Neben der Klasse String werden folgende unterstützt:
■
■
■
■
Boolean
Float
Int
Long
In dem Fall, dass lesend auf nicht existente SharedPreferences zugegriffen wird, erfolgt
der zweite Parameter als Rückgabe, also ein Leerstring. Dadurch werden dem Entwickler
Abfragen auf null erspart.
66
4 Entwicklung eines Anmeldeformulars
4.4 Anpassung der GUI-Komponenten
GUI
Es soll der Versuch unternommen werden, die GUI-Komponenten
GUI Komponenten anzupassen. Dabei wird
im ersten Abschnitt die Hintergrundgrafik ausgetauscht. Im zweiten Abschnitt wird ein
Button durch eine NinePatch-Grafik
NinePatch
abgewandelt.
4.4.1
Hintergrundgrafik
Da das Display eine Auflösung von 320x480 Pixel hat, wurde eine Hintergrundgrafik
wallpaper.png mit gleicher Auflösung erzeugt und in den Ordner res/drawable kopiert.
Jede GUI-Komponente
Komponente hat das Attribut android_background. Die oberste Komponente im
Layout login.xml ist, wie bereits erwähnt, das RelativeLayout und beansprucht das
gesamte Display. Durch folgende Zeilen wird das Hintergrundbild gesetzt:
<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"
xmlns:android "http://schemas.android.com/apk/res/android"
android:layout_width
android:layout_width="fill_parent"
android:layout_height
android:layout_height="fill_parent"
android:background
android:background="@drawable/wallpaper">
Bei einigen Endgeräten wie z.B. dem T-Mobile
T Mobile G1 muss der Benutzer, um Benutzername
und Passwort auf der Tastatur einzugeben, dieses aufklappen
aufklappen und um 90 Grad im
Uhrzeigersinn drehen. Das System streckt bzw. staucht die Hintergrundgrafik proportional,
damit diese das gesamte Display ausfüllt. Folgende Abbildung gibt beide Ansichten wieder:
Abb. 34:: Anmeldeformular im Hochformat (links) und im Querformat (rechts)
Das Problem, dass die Hintergrundgrafik auf dem aufgeklappten Endgerät verzerrt aussieht,
lässt sich durch mehrere Layouts lösen. Dafür muss die Layout-Datei
Layout
login.xml im Ordner
res/layout gelöscht werden und in zwei neu erzeugte Ordner kopiert werden:
res/layout-land und res/layout-port
res/layout
. Der erste Ordner beinhaltet Layouts im
Querformat (engl. landscape
andscape)) und der zweite solche im Hochformat (engl. portrait). Es wird
67
4 Entwicklung eines Anmeldeformulars
eine neue Hintergrundgrafik mit der Auflösung 480x320 Pixel erstellt und im QuerformatLayout referenziert. Durch die identischen Dateinamen beider Layouts erkennt das System,
dass es sich um das gleiche Layout in unterschiedlichen Formaten handelt und benutzt je
nach aktiver Auflösung das entsprechende Layout. Durch diese Technik ist es möglich, das
Layout vollständig für die jeweilige Auflösung anzupassen. Es sollte lediglich darauf
geachtet werden, dass in den Layout-Dateien die gleichen GUI-Komponenten mit gleichen
IDs benutzt werden.
4.4.2
Button mit NinePatch-Grafik
Um die Grafik eines Buttons durch eine andere zu ersetzen, wird erneut von dem Attribut
android_background Gebrauch gemacht. Analog zur Hintergrundgrafik wird die Grafikdatei
button.9.png in den Ordner res/drawable kopiert. Es handelt sich dabei um die
NinePatch-Grafik aus „Kapitel 3.3.3 Draw 9-patch“. Diese wurde mit dem
Entwicklungswerkzeug Draw 9-patch erzeugt und beinhaltet zusätzliche Informationen über
Streckverhalten und Textpositionierung. Folgende Abbildung zeigt den angepassten
Anmelden-Button:
Abb. 35: Anmeldeformular mit angepasstem Anmelden-Button
Auf den ersten Blick wirkt das Ergebnis korrekt. Die Grafik wird wie gewünscht gestreckt
und auch der Text ist richtig positioniert. Bei Betätigung des Buttons wird auch das richtige
Benutzerereignis ausgeführt. Allerdings erscheint der Button leblos, da es kein visuelles
Feedback gibt. Durch Benutzung des Trackballs lassen sich die GUI-Komponenten
fokussieren. Dies wird durch eine orangene Umrandung bzw. Einfärbung dargestellt. Wird
ein Button betätigt, so wird dies durch eine gelbe Einfärbung repräsentiert. Folgende
Abbildung zeigt die verschiedenen Zustände eines Buttons:
Abb. 36: Zustände eines Buttons: normal (links), fokussiert (Mitte), gedrückt (rechts)
68
4 Entwicklung eines Anmeldeformulars
All dies trifft auf den angepassten Anmelden-Button nicht zu. Die Suche nach
entsprechenden Layout-Attributen blieb erfolglos. Somit ist das Problem zu diesem
Zeitpunkt nicht lösbar.
4.5 Internationalisierung
In diesem Unterkapitel wird erläutert, wie eine Applikation zu entwickeln ist, damit sie
ohne Änderung des Quellcodes an andere Sprachen angepasst werden kann.
Die Bezeichnung Internationalisierung (I18N
Bereiche:
■
■
■
■
■
■
■
109
) umfasst in der Informatik folgende
Sprache der Benutzeroberfläche
Zeichensatz
Tastaturlayout
Zahlenformat
Währungsformat
Datumsformat
Zeitformat
Da in dieser Arbeit nur exemplarisch gezeigt wird, wie sich Mehrsprachigkeit mit Android
umsetzen lässt, werden die restlichen Bereiche übergangen.
4.5.1
Strings-Ressource
Wie bereits am Anfang des Kapitels erwähnt ist die Datei res/values/strings.xml die
Ressource für Strings innerhalb einer Applikation. Für die Umsetzung von Mehrsprachigkeit
ist es zwingend erforderlich, die Texte aus den Layouts zu extrahieren und zentral in einer
Strings-Ressource zu speichern.
Am Beispiel von login.xml bedeutet dies:
<TextView android:text="Benutzer:" />
<TextView android:text="Passwort:" />
<Button android:text="anmelden" />
Wird zu:
<TextView android:text="@string/user" />
<TextView android:text="@string/password" />
<Button android:text="@string/login" />
109
Die englische Übersetzung „internationalization“ wird häufig mit I18N abgekürzt, da sich 18
Buchstaben zwischen „I“ und „N“ befinden.
69
4 Entwicklung eines Anmeldeformulars
Die Datei res/values/strings.xml wird erweitert um:
<string name="user">Benutzer:</string>
<string name="password">Passwort:</string>
<string name="login">anmelden</string>
Um die Applikation für die Sprachen Deutsch, Englisch und Französisch zu
internationalisieren, ist es notwendig, für jede Sprache eine Kopie der Datei strings.xml
anzulegen und in folgende Unterordner zu kopieren:
■ res/values-de für Deutsch
■ res/values-en für Englisch
■ res/values-fr für Französisch
Der Namen der Ordner bildet sich demzufolge aus der Zeichenkette „values-“ und einem
Länderkürzel nach ISO 639-1.
Nachdem diese Dateien übersetzt wurden, hat z.B. die französische Strings-Ressource
res/values-fr/strings.xml folgenden Inhalt:
<?xml version="1.0" encoding="utf-8"?>
<resources>
<string name="user">client:</string>
<string name="password">mot de passe:</string>
<string name="login">s'inscrire</string>
</resources>
Da die XML-Dateien in UTF-8 kodiert sind, stellen sämtliche Sprachen samt Sonderzeichen
kein Problem dar. Die für XML reservierten Zeichen werden durch den Android Resource
Editor in passende Entitäten gewandelt.
Da die Strings noch in der Datei res/values/strings.xml definiert sind, wird Android
beim Programmstart diese Strings benutzen. Erst wenn explizit auf eine andere Sprache
umgeschaltet wird, lädt das System die entsprechende länderabhängige Ressource. Wenn
die Strings dort entfernt werden, startet jede Applikation mit englischer Ländereinstellung.
Das liegt daran, dass bisher nur englische Versionen von Android verfügbar sind.
70
4 Entwicklung eines Anmeldeformulars
4.5.2
Umschalten der Ländereinstellung
Für das Umschalten auf eine bestimmte Ländereinstellung wird die in Java gebräuchliche
Klasse java.util.Locale benutzt. Die Methode getResources der Elternklasse
android.app.Activity liefert eine Instanz der Klasse android.content.res.Resources
zurück.
Diese
Ressource
beinhaltet
eine
Instanz
der
Klasse
android.content.res.Configuration, in die das jeweilige Locale einzutragen ist:
Im folgenden Beispiel wird auf deutsche Ländereinstellung umgeschaltet:
Resources resource = getResources();
Configuration conf = resource.getConfiguration();
DisplayMetrics dm = resource.getDisplayMetrics();
conf.locale = Locale.GERMANY;
resource.updateConfiguration(conf, dm);
Locale.setDefault(conf.locale);
setContentView(R.layout.login);
Im letzen Schritt wird das Layout erneut gesetzt. Dabei gehen alle Benutzereingaben
verloren. Diese sind ggfs. zu sichern und anschließend zu restaurieren.
71
5 Entwicklung eines Sportwetten-Prototyps
5 Entwicklung eines Sportwetten-Prototyps
In diesem Kapitel wird der Prototyp einer Sportwetten-Applikation entwickelt. Im ersten
Schritt werden Sportwetten erläutert. Es folgt ein Unterkapitel über die grafische
Benutzerschnittstelle. Anschließend wird versucht, bestehende Java-Bibliotheken in
Android zu integrieren. Aufgrund der Schwierigkeiten wurde ein spezielles Werkzeug zur
Darstellung von Abhängigkeitsbäumen entwickelt, welches im nächsten Abschnitt
vorgestellt wird. Zuletzt wird der Prototyp an bestehende Server-Software angebunden.
5.1 Sportwetten
Bei einer Sportwette werden Geldeinsätze auf das Eintreffen eines bestimmten
Sportereignisses getätigt. Um eine solche Sportwette abzuschließen begibt sich der Kunde
in ein Wettlokal, füllt einen Wettschein aus und hinterlegt den Wetteinsatz. Der potentielle
Gewinn hängt von der Gewinnquote ab, die von einem Buchmacher angeboten wird.
Folgendes Beispiel zeigt ein Wettereignis auf einem Wettschein: 110
Ereignis
1
X
2
Bayern München vs. Borussia Dortmund 1,80 3,20 4,0
Tab. 26: Wettereignis auf einem Wettschein
Der Ausgang „1“ repräsentiert den Sieg der zuerst benannten Mannschaft Bayern
München. Analog dazu bezeichnet „2“ den Sieg von Borussia Dortmund. Ein Unentschieden
in dem Fußballspiel wird durch „X“ symbolisiert. Wird nun eine Wette in Höhe von 15 EUR
auf Borussia Dortmund abschlossen, so wäre der Gewinn 60 EUR. Dies wird berechnet,
indem der Wetteinsatz 15 EUR mit der Gewinnquote 4,0 multipliziert wird. Der Reingewinn
beträgt 45 EUR, da von dem Gewinn 60 EUR die 15 EUR Wetteinsatz zu subtrahieren sind.
In der Praxis ist noch die Buchmacher-Marge abzuziehen, die meistens prozentual vom
Wetteinsatz berechnet wird. 111
Systemwette
Neben dieser Einzelwette gibt es die Systemwette, bei der auf Kombinationen von
Einzelwetten gewettet wird. Beispielsweise bezeichnet die Systemwette „3 aus 5“ alle
Dreierkombinationen von 5 Einzelwetten. Rechnerisch sind dies 10 unterschiedliche
Dreierkombinationen. Der Gewinn errechnet sich hierbei aus der Anzahl richtig getippter
Kombinationen und ist vergleichbar mit dem Lottospiel „6 aus 49“. 112
110
Vgl. [Wiki09j]
Vgl. [Wiki09j]
112
Vgl. [Wiki09j]
111
72
5 Entwicklung eines Sportwetten-Prototyps
5.2 Grafische Benutzerschnittstelle
In diesem Unterkapitel wird die GUI des Sportwetten-Prototyps besprochen. Da bereits im
vorherigen „Kapitel 4 Entwicklung eines Anmeldeformulars“ detailliert die Entwicklung
dargestellt wurde, werden hier nur einige Besonderheiten gezielt erläutert.
5.2.1
Aktivitätsdiagramm
Folgendes Aktivitätsdiagramm zeigt die einzelnen Activities und damit den Workflow der
Applikation:
Abb. 37: Aktivitätsdiagramm des Sportwetten-Prototyps
Von jeder Activity außer Splashscreen und Anmeldung lässt sich das Hauptmenü über die
Menü-Taste erreichen. Dies wurde aus Gründen der Lesbarkeit nicht extra modelliert. Der
Knoten „finaler Flow“ wurde an mehreren Stellen gewählt um das Ende eines Workflows
darzustellen. Dies wird durch eine Activity mit dem Text This activity is currently
under construction dargestellt. Als Begründung dafür ist aufzuführen, dass der
Auftraggeber dem Autoren Designvorschläge in HTML bereitgestellt hat, die an diesen
Stellen nicht weiterführen.
73
5 Entwicklung eines Sportwetten-Prototyps
5.2.2
Listen
In den Activities Hauptmenü und Konto aufladen stehen dem Benutzer mehrere
Möglichkeiten zur Auswahl. Hinzu kommen die Activities Sportart, Land und Liga, die im
Diagramm vereinfach modelliert wurden.
Android stellt für solche Fälle die Klasse android.app.ListActivity zur Verfügung. Es ist
lediglich eine Liste zu füllen, die anschließend dargestellt wird. Jedes Element dieser Liste
besteht aus einem Text und einem Intent. Die Klasse android.content.Intent stellt in
Android die Möglichkeit bereit, von einer Activity zur nächsten zu gelangen. Folgender
Quellcode beendet die aktive Activity und zeigt das Hauptmenü an:
Intent intent = new Intent();
intent.setClass(this, HauptmenuListActivity.class);
startActivity(intent);
Um das Layout der Liste anzupassen besteht die Möglichkeit, das Layout einer Zeile gegen
ein selbst erstelltes auszutauschen. Es soll nicht nur ein Text dargestellt werden, sondern
auch ein Icon links daneben. Dafür existiert die Klasse android.widget.SimpleAdapter.
Um diese zu benutzen, muss der Entwickler die Liste selbständig verwalten. Die
Entscheidung fiel zu Gunsten einer Struktur aus, die aus einer ArrayList besteht, deren
Elemente Maps sind. In diese Maps werden nun pro Listeneintrag das Icon, der Text und das
Intent gefüllt. Die Liste wird dann als Variable so definiert:
List<Map<String, Object>> list = new ArrayList<Map<String, Object>>();
Das Layout für die Listenzeile hauptmenu_list_row.xml ist ein LinearLayout. Dieses
besteht aus den Komponenten ImageView mit der ID @+id/icon und einem TextView mit
der ID @+id/item.
Alle Informationen werden dem SimpleAdapter übergeben und für die Activity aktiviert:
private static final String ITEM = "item";
private static final String ICON = "icon";
private static final String[] PARAM = { ITEM, ICON };
SimpleAdapter notes = new SimpleAdapter(this, list,
R.layout.hauptmenu_list_row, PARAM, new int[] { R.id.item,
R.id.icon });
setListAdapter(notes);
74
5 Entwicklung eines Sportwetten-Prototyps
Folgende Abbildung zeigt die Activity Hauptmenü mit den angepassten Listenzeilen:
Abb. 38: Die Activity Hauptmenü des Sportwetten-Prototyps
5.2.3
Dynamisches Layout mit Java
In der Activity Quoten werden mehrere Wettereignisse wie auf einem Wettschein
dargestellt. Dafür muss jede Zeile das Ereignis und die drei Quoten „1“, „X und „2“
beinhalten. Die drei Quoten werden mit einem ToggleButton abgebildet. Der Versuch,
erneut eine ListActivity zu benutzen, schlug fehl, da der Adapter alle Click-Events der
Listenzeile verarbeitet und dadurch die Callback-Methoden der ToggleButtons nicht
aufgerufen werden.
Um dieses Problem zu lösen, wurde ein TableLayout gewählt. Dieses Layout besteht aus
TableRows, die wiederum beliebige Komponenten beinhalten können. Folgendes Layout
zeigt ein Wettereignis:
<TableLayout android:orientation="vertical">
<TableRow>
<TextView android:text="Bayern München vs. Borussia Dortmund"/>
<ToggleButton android:textOn="1,80" android:textOff="1,80"/>
<ToggleButton android:textOn="3,20" android:textOff="3,20"/>
<ToggleButton android:textOn="4,0" android:textOff="4,0"/>
</TableRow>
</TableLayout>
Pro Wetterereignis muss nun eine TableRow samt TextView und drei ToggleButtons
erzeugt werden. Da die Klassen in Java verfügbar sind, kann eine Methode createGame
entwickelt werden:
75
5 Entwicklung eines Sportwetten-Prototyps
public void createGame(TableLayout tl, String game, String quote0, String
quote1, String quote2) {
TableRow tr = new TableRow(this);
TextView tv = new TextView(this);
tv.setText(game);
tr.addView(tv);
ToggleButton tb1 = new ToggleButton(this);
tb1.setTextOn(quote0);
tb1.setTextOff(quote0);
tr.addView(tb1);
ToggleButton tb2 = new ToggleButton(this);
tb2.setTextOn(quote1);
tb2.setTextOff(quote1);
tr.addView(tb2);
ToggleButton tb3 = new ToggleButton(this);
tb3.setTextOn(quote2);
tb3.setTextOff(quote2);
tr.addView(tb3);
tl.addView(tr);
}
Es ist anzumerken, dass ToggleButtons zwei verschiedene Beschriftungen erhalten
können, für die Zustände „eingedrückt“ und „nicht eingedrückt“. Daher wurde die Quote
doppelt gesetzt.
Da Wettereignisse an verschiedenen Tagen stattfinden, wird in der Tabelle eine weitere
Zeile mit Datum und Überschrift eingefügt. Dafür wurde analog verfahren. Folgende
Abbildung zeigt die Activity Quoten mit zwei Wettereignissen an zwei verschiedenen Tagen.
Abb. 39: Die Activity Quoten des Sportwetten-Prototyps
76
5 Entwicklung eines Sportwetten-Prototyps
5.3 Integration des Frameworks log4j
Bisher wurden viele Klassen aus dem Android SDK vorgestellt. Da für den SportwettenPrototyp möglichst viele bestehende Java-Quelltexte wiederverwendet werden sollen, die
nicht mit Android sondern mit Java SE und Java EE entwickelt wurden, wird in diesem
Unterkapitel versucht diese zu integrieren. Da das Logging-Framework log4j von allen
bestehenden Klassen des Auftraggebers benutzt wird, hat die Anbindung dieses
Frameworks die oberste Priorität.
5.3.1
log4J
Das Open-Source-Framework log4j der Apache Software Foundation ist der De-factoStandard zum Loggen von Meldungen in Java-Anwendungen. Über Logger gelangen die
Nachrichten ins System und werden dort nach Wichtigkeit eingeteilt. Mittels einer
Properties-Datei wird das Format der Meldungen konfiguriert und die Appender eingestellt.
Appender sind dafür verantwortlich, wohin das Log geschrieben wird. Zur Auswahl dabei
stehen beispielsweise Standardausgabe, Textdateien oder HTML-Dateien. Auch kann in der
Properties-Datei die Wichtigkeit der Nachrichten eingestellt werden. Dadurch können
Debug-Ausgaben im Quellcode bestehen bleiben, und werden dennoch nicht geloggt. Es
gibt folgende Wichtigkeitsstufen:
■
■
■
■
■
■
Trace
Debug
Info
Warn
Error
Fatal
5.3.2
Probleme bei der Integration
Damit eine Klasse log4J benutzen kann, muss als erstes das Java-Archiv log4j.jar
eingebunden werden. Pro Klasse wird dann eine statische Variable definiert, der ein Logger
zugewiesen wird. Als Parameter wird dabei ein Class-Objekt übergeben:
private static Logger logger = Logger.getLogger(LoginActivity.class);
Innerhalb der Klasse kann dann mittels folgenden Aufrufs in der Wichtigkeitsstufe Debug
geloggt werden:
logger.debug("Test");
Das erste Problem besteht darin, log4j zu initialisieren. Es wurde vom Autor keine
Möglichkeit gefunden, dem Framework die Properties-Datei zu übergeben. Weiterhin
besteht das Problem, dass kein Appender für Android existiert. Eine Ausgabe auf die
Standardausgabe wird ignoriert und in eine Log-Datei zu schreiben erweist sich als ebenso
schwierig.
77
5 Entwicklung eines Sportwetten-Prototyps
5.3.3
Logging mit Android
Unter Android existiert die Klasse android.util.Log, die statische Methoden wie d
bereitstellt. d ist dabei als Abkürzung für das Log-Level Debug zu verstehen:
Log.d("LoginActivity", "Test");
Im Dalvik Debug Monitor Service und in Eclipse gibt es einen View namens LogCat. Dorthin
werden alle Nachrichten geschrieben. Es besteht die Möglichkeit Nachrichten anhand eines
Schlagwortes zu filtern. Der erste Parameter LoginActivity ist genau dieses Schlagwort.
Es wird empfohlen bei allen Activities einer Application das gleiche Schlagwort zu
verwenden und im Filter einzustellen.
5.3.4
Problemlösungen
Für die Probleme, log4j unter Android zu integrieren, wurden folgende Lösungen gefunden:
■ Programmierung von einem Appender für LogCat
■ Initialisierung von log4j im Quellcode und ohne Properties-Datei
Um einen Appender für log4j zu programmieren, ist es wichtig von der Klasse
org.apache.log4j.AppenderSkeleton zu erben und die Methode append zu
überschreiben. Durch den Parameter LoggingEvent werden alle Informationen
bereitgestellt. Innerhalb einer switch-Anweisung werden die verschiedenen Log-Levels
verarbeitet und die entsprechenden Logging-Methoden von Android aufgerufen.
78
5 Entwicklung eines Sportwetten-Prototyps
private class LogCatAppender extends AppenderSkeleton {
public LogCatAppender(Layout layout) {
setLayout(layout);
}
protected void append(LoggingEvent le) {
String name = "Log4j";
switch (le.getLevel().toInt()) {
case Level.FATAL_INT:
Log.e(name, getLayout().format(le));
case Level.ERROR_INT:
Log.e(name, getLayout().format(le));
case Level.WARN_INT:
Log.w(name, getLayout().format(le));
case Level.INFO_INT:
Log.i(name, getLayout().format(le));
case Level.DEBUG_INT:
Log.d(name, getLayout().format(le));
case Level.TRACE_INT:
Log.v(name, getLayout().format(le));
}
}
break;
break;
break;
break;
break;
break;
public void close() {
}
public boolean requiresLayout() {
return true;
}
}
Die Schwierigkeit beim Initialisieren von log4j besteht aus dem richtigen Zeitpunkt. Eine
Activity erbt von der Elternklasse. Die erste Methode, die aufgerufen wird, ist die
überschriebene Callback-Methode onCreate. Zu diesem Zeitpunkt ist die Klasse bereits
instanziiert und es können Fehler aufgetreten sein, die nicht mehr ins Log gelangen. Die
Konstruktoren zu überschreiben ermöglicht die gleiche Fehlerquelle. Das Framework muss
also vor der Ausführung des Konstruktors der Elternklasse initialisiert werden. In der
Programmiersprache Java existiert die Möglichkeit einen parameterlosen Konstruktor zu
implementieren. Dieser wird vom ClassLoader aufgerufen, wenn die Klasse das erste Mal
geladen wird:
1 {
2
3
4
5
6 }
PatternLayout pl = new PatternLayout("[%5p]%23c{1}:%4L - %m%n");
Logger.getRootLogger().addAppender(new LogCatAppender(pl));
Logger.getRootLogger().setLevel(Level.TRACE);
Logger.getRootLogger().info("Log4j initialized");
79
5 Entwicklung eines Sportwetten-Prototyps
Sportwetten
Der Parameter im Konstruktor von PatternLayout (Zeile 2) konfiguriert das Format der
Log-Meldung und bedeutet:
■
■
■
■
■
■
schreibe das 5 Zeichen lange Log-Level
Log
rechtsbündig in eckige Klammern
schreibe den 23 Zeichen langen
lange Klassennamen rechtsbündig
schreibe einen Doppelpunkt
schreibe die 4 Zeichen lange Zeilenangabe
Zeile
rechtsbündig
schreibe Leerzeichen, Trennstrich, Leerzeichen
schreibe die Log-Nachricht
Nachricht
Folgende Abbildung zeigt die Log-Ausgaben
Log
in LogCat in Eclipse:
Abb. 40: log4j-Ausgaben in LogCat
80
5 Entwicklung eines Sportwetten-Prototyps
5.4 Integration der bestehenden Klasse EntityStore
Da möglich viele Quelltexte des Auftraggebers adaptiert werden sollen, wird in diesem
Unterkapitel versucht die zentrale Klasse sportbet.client.common.store.EntityStore
aus der Java-Bibliothek ebet-client-common.jar einzubinden. Diese Klasse stellt in Form
eines Caches alle Objekte bereit, die für Sportwetten relevant sind.
Es ist festzuhalten, dass das Einbinden der Bibliothek und das Instanziieren der Klasse
EntityStore durch den Default-Konstruktor reibungslos verliefen.
5.4.1
Serialisierung und Deserialisierung
Damit die Klasse EntityStore in einer Android-Applikation adäquat benutzt werden kann,
muss sie mit Daten gefüllt sein. Die bequemste Art diese Daten dem Sportwetten-Prototyp
bereitzustellen, besteht darin, die gesamte Klasse innerhalb einer existierenden und
laufenden Anwendung zu serialisieren. Dabei werden alle Objekte und Referenzen in einer
sequentiellen Datei als Folge von Bytes gespeichert. Innerhalb von Android kann diese Datei
geladen und die Klasse EntityStore in den gleichen Zustand gebracht werden, in dem sie
gespeichert wurde. Einlesen der Datei und das Wiederherstellen des serialisierten
Zustandes wird als Deserialisierung bezeichnet.
Damit eine Klasse serialisiert werden kann, muss das Interface java.io.Serializable
implementiert werden. Es existieren keine zu implementierenden Methoden. Folgender
Quellcode serialisiert die Instanz entityStore in die Datei entitystore.ser:
FileOutputStream fos = new FileOutputStream("entitystore.ser");
ObjectOutputStream oos = new ObjectOutputStream(fos);
oos.writeObject(entityStore);
Der folgende Quellcode deserialisiert die Datei entitystore.ser und erzeugt eine neue
Instanz der Klasse EntityStore:
FileInputStream fis = new FileInputStream(("entitystore.ser");
ObjectInputStream ois = new ObjectInputStream(fis);
EntityStore entityStore = (EntityStore) ois.readObject();
Da innerhalb von Android die bekannten Schwierigkeiten mit Dateien bestehen, wurde die
Lösung verwendet, die Datei von einem Webserver herunterzuladen. Damit eine
Application überhaupt aufs Internet zugreifen kann, muss innerhalb vom Manifest folgende
Berechtigung vergeben werden:
<uses-permission android:name="android.permission.INTERNET" />
Wie im „Kapitel 3.1.4 Android Runtime“ erwähnt, existieren innerhalb der Android
Runtime-Schicht Pakete von Drittanbietern für die Unterstützung der Protokolle HTTP und
HTTPS. Daher wird die Klasse org.apache.http.impl.client.DefaultHttpClient
benutzt, um eine mittels HTTP-GET die Datei von einem Webserver anzufragen. Die mittels
HTTP-RESPONSE erhaltene Datei wird in ein Byte-Array überführt und von dort mit einem
ObjectInputStream in eine Instanz von EntityStore deserialisiert:
81
5 Entwicklung eines Sportwetten-Prototyps
DefaultHttpClient client = new DefaultHttpClient();
HttpGet get = new HttpGet(new URI("http://www.server.de/entitystore.ser"));
HttpResponse res = client.execute(get);
byte[] buffer = EntityUtils.toByteArray(res.getEntity());
ObjectInputStream ois = new ObjectInputStream(new
ByteArrayInputStream(buffer));
EntityStore entitystore = (EntityStore) ois.readObject();
5.4.2
Fehlende Klassen
Nachdem nun die Klasse EntityStore mittels Deserialisierung in den Zustand gebracht
werden kann, in dem sie in der laufenden Anwendung gespeichert wurde, tauchen neue
Probleme auf: Android registriert erst zu Laufzeit, dass die Klasse
java.beans.PropertyChangeListener fehlt und bricht mit der entsprechenden
Fehlermeldung ab:
03-18 17:24:07.317: WARN/dalvikvm(1783): VFY: unable to resolve new-instance 303
(Ljava/beans/PropertyChangeSupport;) in Lsportbet/common/i18n/LangString;
Laut einer Internet-Recherche sind folgende Pakete nicht in Android vorhanden: 113
■
■
■
■
■
■
■
■
■
■
■
■
■
■
■
■
■
■
■
■
■
.
java.applet
java.awt
java.beans
java.lang.management
java.rmi
javax.accessibility
javax.activity
javax.imageio
javax.management
javax.naming
javax.print
javax.rmi
javax.security.auth.kerberos
javax.security.auth.spi
javax.security.sasl
javax.swing
javax.transaction
javax.xml
org.ietf
org.omg
org.w3c.dom
Damit sind die Richtigkeit der Fehlermeldung und das Fehlen der Klasse bestätigt. Da die
Quelltexte der Java SDK frei verfügbar sind, ist es naheliegend, die fehlende Klasse zu
kopieren und dem Android-Projekt hinzuzufügen. Vom Java-Compiler wird die Klasse
akzeptiert, da keine weiteren Abhängigkeiten bestehen. Der Dalvik Cross-Compiler bricht
mit folgender Fehlermeldung ab:
113
Vgl. [Burn08]
82
5 Entwicklung eines Sportwetten-Prototyps
Attempt to include a core VM class in something other than a core library. It is likely that
you have attempted to include the core library from a desktop virtual machine into an
application, which will most assuredly not work. If you really intend to build a core library -which is only appropriate as part of creating a full virtual machine binary, as opposed to
compiling an application -- then use the "--core-library" option to suppress this error
message. If you go ahead and use "--core-library" but are in fact building an application,
then please be aware that your build will still fail at some point; you will simply be denied
the pleasure of reading this helpful error message.
5.4.3
Core-Library
Die Fehlermeldung vom Dalvik Cross-Compiler besagt, dass durch den Parameter
-–core-library das Problem behoben werden kann. Daher wurde in der IDE Eclipse nach
einer Möglichkeit gesucht, diesen Parameter zu setzen. Da keine entsprechenden
Einstellungen gefunden wurden, bestand die nächste Idee darin, den Quellcode vom
Android Development Toolkit Plug-In für Eclipse zu beschaffen und dort die passende Stelle
abzuändern. Der Autor verfügt über keinerlei Erfahrung mit der Entwicklung von EclipsePlug-Ins, so dass diese Idee wieder verworfen wurde.
Patch für Dalvik Cross-Compiler
Da der Fehler vom Dalvik Cross-Compiler ausgegeben wird, wurde das Werkzeug dx näher
betrachtet. Diese Batchdatei im Ordner tools vom installierten SDK startet die Datei
dx.jar. Ein Java-Archiv beinhaltet immer ein Manifest, in dem angegeben wird, welche
Klasse ausgeführt werden soll. Die Zeile im MANIFEST.MF im dx.jar lautet:
Main-Class: com.android.dx.command.Main
Dadurch wird klar, dass der Dalvik Cross-Compiler ein Java-Programm ist. Wie im
„Kapitel 3.2 Software Development Kit“ beschrieben, wurden mittels Git alle Dateien von
Android heruntergeladen und die Quelltexte für dx gefunden. Mit diesen Quelltexten
wurde ein neues Java-Projekt in Eclipse erzeugt, so dass bequem nach der Fehlermeldung
als String gesucht werden kann. Diese taucht nur an einer einzigen Stelle auf: in der Klasse
com.android.dx.command.dexer.Main in der Methode checkClassName. Dort wird
überprüft, ob ein Paketname mit java oder javax anfängt oder ob folgende Pakete
vorkommen:
83
5 Entwicklung eines Sportwetten-Prototyps
■
■
■
■
■
■
■
■
■
■
■
■
■
■
accessibility
crypto
imageio
management
naming
net
print
rmi
security
sound
sql
swing
transaction
xml
Wird ein entsprechendes Paket gefunden, so wird die Fehlermeldung ausgegeben. Ein
Unterdrücken der Fehlermeldung würde keinen Sinn machen. Daher wurde nach der Stelle
gesucht, an der der Parameter --core-library ausgewertet wird:
} else if (arg.equals("--core-library")) {
coreLibrary = true;
Die Variable coreLibrary wird mit false initialisiert und nur an dieser Stelle auf true
gesetzt. Die Lösung besteht demzufolge darin, die Variable immer mit true zu initialisieren.
Dadurch wird der Dalvik Cross-Compiler vermeidlich immer mit dem Parameter
-–core-library aufgerufen.
Im letzen Schritt wurde das Projekt kompiliert, die JAR-Datei dx.jar erzeugt und gegen die
bestehende ausgetauscht.
5.5 Dependency Viewer
Durch den Patch für Dalvik Cross-Compiler und durch das Hinzufügen der fehlenden Klasse
java.beans.PropertyChangeListener waren noch nicht alle Probleme behoben. Es folgt
eine Liste der Klassen, die fehlten und erfolgreich ersetzt wurden:
■
■
■
■
■
■
■
javax.swing.event.EventListenerList
javax.ejb.FinderException
org.apache.commons.collections.IteratorUtils
org.apache.commons.beanutils.BeanComparator
java.rmi.ServerException
javax.ejb.EJBException
javax.security.auth.login.LoginContext
Bei der Klasse javax.naming.InitialContext klappte dieser Lösungsansatz nicht mehr, da
zu viele Abhängigkeiten zu anderen Klassen vom SDK existieren. Zu diesem Zeitpunkt wurde
84
5 Entwicklung eines Sportwetten-Prototyps
klar, dass die bestehenden Quelltexte abgeändert werden müssen. Die Frage dabei war,
welche der rund 3.000 Quelltexte zu viele Abhängigkeiten hat. Die Lösung für dieses
Problem ist ein Werkzeug, welches die Abhängigkeiten einer Klasse wie EntityStore in
einer Baumstruktur ausgibt. Damit ist es möglich die richtige Klasse zu finden, anzupassen
und dabei die Anzahl der Änderungen zu minimieren.
Auch wenn keins der evaluierten Tools dafür in Frage kam, so werden der Vollständigkeit
halber alle benannt:
■
■
■
■
■
■
■
■
■
JDepend
JarAnalyser
JavaDepend
Java Dependency Smart Analyser
Class Dependency Analyzer
Oops!
Java structural analysis
eDepend
ispace
5.5.1
Classycle
Bei der Suche nach einem Werkzeug zur Darstellung von Abhängigkeiten in Baumstruktur
fiel die Wahl auf Classycle. Dieses Java-Programm analysiert JAR-Dateien und versucht
zyklische Abhängigkeiten zu finden. Eine solche Abhängigkeit wird erzeugt, wenn sich zwei
Klassen gegenseitig referenzieren. Als Ergebnis wird eine XML-Datei erzeugt, die durch eine
XSL Transformation (XSLT) in einem Webbrowser betrachtet werden kann. Beim näheren
Betrachten dieser XML-Datei fiel auf, dass die Informationen für eine zu entwickelnde
Anwendung benutzt werden können.
5.5.2
Ant
Aufgerufen wird Classycle mit einem Ant-Script. Das Open Source Projekt Apache Ant 114 ist
ein in Java geschriebenes Werkzeug um XML-Batchdateien auszuführen. Dabei werden
viele Möglichkeiten bereitgestellt ganze Java-Projekte zu kompilieren, zu archivieren und
auszuliefern. Deswegen wird Ant auch häufig als Build-Werkzeug bezeichnet.115
Folgendes Beispiel zeigt, wie Classycle in einem Ant-Script aufgerufen wird. Dabei wird die
Bibliothek log4j.jar analysiert und die XML-Datei log4j.xml erzeugt:
<classycleReport reportFile="log4j.xml">
<fileset dir=".">
<include name="log4j.jar"/>
</fileset>
</classycleReport>
114
115
Ant (dt. Ameise) ist ein Akronym für Another Neat Tool (dt. Noch ein hübsches Werkzeug)
Vlg. [HaLo04 S. 34]
85
5 Entwicklung eines Sportwetten-Prototyps
5.5.3
Verarbeitung der XML-Datei
Für die Verarbeitung der XML-Datei gibt es neben der bekannten SAX- und DOM-Parser das
Framework Castor. Damit ist es möglich, anhand des XML Schemas (XSD) Java-Quelltexte
automatisch erzeugen zu lassen. Durch einen einzigen Aufruf im Programm wird dann die
XML-Datei geladen und die Klassen gefüllt. Dieser Vorgang wird als Unmarshalling
bezeichnet. Da für Classycle keine solche XSD-Datei existiert, ist dieses Framework nicht
einzusetzen.
Als Alternative wurde das Framework XStream benutzt. Der Entwickler hat einige Klassen zu
entwickeln um die XML-Datei nachzubilden. Dabei wird jedes XML-Element auf eine Klasse
und jedes XML-Attribut auf eine Variable der Klasse abgebildet. Wenn das XML-Element ein
oder mehrere Kind-Elemente enthält, so ist dies in der Klasse mit einer Liste nachzustellen.
Mit der Methode alias der Klasse com.thoughtworks.xstream.XStream wird dann das
Mapping festgelegt.
5.5.4
Algorithmus
Im ersten Schritt sind die Daten, die durch die Verarbeitung der XML-Datei bereitgestellt
wurden, in eine andere Form zu bringen. Es bietet sich eine HashMap an, in der als Schlüssel
der Klassenname und als Wert die Liste der abhängigen Klassen gespeichert werden.
Nach dieser Transformation ist der Algorithmus zu implementieren. Dabei ist die
Entscheidung zugunsten einer Rekursion getroffen worden. Nachdem eine Klasse als
Parameter an der Methode showDependency übergeben wurde, wird der Klassenname
ausgegeben. In der HashMap wird über alle abhängigen Klassen iteriert. Dabei wird für jede
abhängige Klasse die Methode rekursiv aufgerufen. Damit der Algorithmus terminiert, wird
jede bereits benutzte Klasse protokolliert. Für eine protokollierte Klasse wird die Rekursion
übersprungen. Denn durch eine zyklische Abhängigkeit zwischen zwei Klassen würde die
Rekursionstiefe unendlich werden.
5.5.5
Ausgabe als HTML
Im ersten Schritt wurde die Ausgabe vom Algorithmus auf die Konsole geschrieben. Mittels
Leerzeichen pro Rekursionsstufe wurde die Einrückung erreicht, die letztendlich die
Baumstruktur ergibt. Da aber eine Webseite besser lesbar und benutzerfreundlicher ist,
wurde nach einer Möglichkeit gesucht, den erzeugten Abhängigkeitsbaum als Webseite
auszugeben. In HTML existiert das Tag <pre>, mit dem sich ein Text samt Umbrüche in
nicht-proportionaler Schriftart darstellen lässt.
Da es sinnvoll ist, die in „Kapitel 5.4.2 Fehlende Klassen“ benannten fehlenden Pakete
farblich zu markieren, wurde überprüft, welche Tags innerhalb von <pre> erlaubt sind.
Dabei fiel auf, dass nur folgende Tags gültig sind:
86
5 Entwicklung eines Sportwetten-Prototyps
Tag
<b>
<i>
<u>
Bedeutung
bold (dt. fett)
italic (dt. kursiv)
underline (dt. unterstrichen)
Tab. 27: Gültige Tags innerhalb von <pre>
Um eine rote Färbung der fehlenden Klassennamen zu erhalten, wird das Tag <b> benutzt.
Mittels CSS wird die Schriftdicke auf normale Breite und die Farbe auf rot gesetzt:
<style type="text/css">
b {
color: red;
font-weight: normal;
}
</style>
5.5.6
DependencyViewer als Ant-Task
Damit der Benutzer zum Betrachten vom Abhängigkeitsbaum nicht ein Ant-Script und ein
Java-Programm ausführen muss, wurde der DependencyViewer um eine Anbindung an Ant
erweitert. Dafür ist eine Klasse zu schreiben, die von der Oberklasse
org.apache.tools.ant.Task erbt. Dafür muss die Methode execute überschrieben
werden. Es genügt dort den Konstruktor der Klasse DependencyViewer aufzurufen. Einen
Konstruktor braucht die Klasse DependencyViewerTask nicht zu implementieren. Damit aus
dem Ant-Script heraus Parameter übergeben werden können, müssen lediglich Variablen
definiert werden und passende Getter und Setter implementiert werden.
Um aus einem Ant-Script heraus Classycle und anschließend DependencyViewer
aufzurufen, ist folgender Code notwendig. In diesem Beispiel wird wieder log4j.jar
analysiert, die XML-Datei log4j.xml erzeugt und für die Klasse org.apache.log4j.Logger
ein Abhängigkeitsbaum in der Datei org.apache.log4j.Logger.html erstellt:
<classycleReport reportFile="gen/log4j.xml">
<fileset dir=".">
<include name="gen/log4j.jar"/>
</fileset>
</classycleReport>
<dependencyViewer root="gen"
xml="log4j.xml"
classname="org.apache.log4j.Logger"/>
Der Parameter root gibt lediglich den Unterordner gen an, in dem die JAR-Datei liegt und
die XML- und HTML-Datei geschrieben werden.
Folgende Abbildung zeigt den Abhängigkeitsbaum im Webbrowser:
87
5 Entwicklung eines Sportwetten-Prototyps
Abb. 41: Abhängigkeitsbaum der Klasse org.apache.log4j.Logger
5.6 Serveranbindung
Mit dem DependencyViewer konnte nun überprüft werden, welche Klasse zu viele
Abhängigkeiten zu Paketen besitzt, die in Android nicht enthalten sind: die Klasse
BSLHelper. Diese Klasse bietet die Schnittstelle zu der gesamten Controller-Schicht. Dafür
wird die Klasse BusinessServiceLocator benutzt, um auf dem Server mittels RMI die
jeweiligen Methoden auszuführen.
Da Android kein RMI unterstützt, bestand das Problem diese Anbindung herzustellen. Wie
bereits im „Kapitel 5.4.1 Serialisierung und Deserialisierung“ erwähnt unterstützt Android
die Protokolle HTTP und HTTPS. Dadurch besteht die Möglichkeit, auf der Server-Seite ein
Servlet zu implementieren, welches die Methodenaufrufe an BusinessServiceLocator
delegiert. Damit die Klasse EntityStore mit Referenzen auf BSLHelper nach dem
Deserialisieren funktioniert, muss auf der Client-Seite eine neue Klasse BSLHelper
geschrieben werden, die die Aufrufe an das Servlet und damit an den
BusinessServiceLocator weiterreicht.
88
5 Entwicklung eines Sportwetten-Prototyps
5.6.1
Servlet
Ein Servlet ist ein Java-Programm, welches auf einem Server in einer JVM ausgeführt wird
und wie eine Webseite angesprochen werden kann. Bei einer Webseite ist es üblich, die
Parameter über die URL zu übergeben. Dafür müssen die Sonderzeichen, die in einer URL
nicht erlaubt sind, encodiert werden. Ein solcher Aufruf mit dem Parameter Name und mit
dem Wert Müller lautet:
http://www.server.de/seite.html?Name=M%FCller
Auf diese Art ist es sehr schwierig ist, komplexe Objekte zu übertragen.
Eine Servlet-Klasse muss von der Oberklasse javax.servlet.http.HttpServlet erben und
die Methoden doGet oder doPost oder beide überschreiben. Beide Methoden besitzen die
Parameter HttpServletRequest und HttpServletResponse:
protected void doPost(HttpServletRequest requ, HttpServletResponse resp)
throws ServletException, IOException {
}
Beide Parameter verfügen über Methoden, die einen ServletOutputStream bzw.
ServletInputStream zurückgeben. Daher liegt die Vermutung nahe, dass ganze Objekte
vom Client zum Servlet über einen Stream übertragen werden können. Nach mehreren
Versuchen hat sich dieses Szenario als das einzige funktionierende erwiesen:
■
■
■
■
Client schickt Objekt A über den ObjectOutputSteam
Servlet empfängt Objekte A über den ObjectInputStream
Servlet schickt Objekt B über den ObjectOutputSteam
Client empfängt Objekt B über den ObjectInputStream
Nun stellt sich die Frage, von welchem Typ das Objekt ist, welches der Client dem Servlet
schickt. Das Servlet muss das Objekt auf den richtigen Typen casten, bevor er es
weitergeben kann. Beispielsweise kann ein Protokoll zwischen Client und Server vereinbart
werden, in dem der Klassenname als erster Parameter vom Typ String versendet wird. Dies
hätte viele Fallunterscheidungen zur Folge, da BusinessServiceLocator mehrere hundert
Methoden bereitstellt.
Am bequemsten ist es, dies über Java Reflection zu lösen. Mit diesem API, das sowohl in
Java SE als auch in Android integriert ist, ist es möglich sämtliche Informationen über eine
Klasse zu erhalten, ohne diese zu instanziieren:
■ Name der Klasse
■ Name der Methoden
■ Anzahl und Typen der Methoden-Parameter
Da die Lösung über die Client-Server-Kommunikation eine Brücke zwischen BSLHelper und
BusinessServiceLocator in einem funktionierenden System darstellt, ist nur dafür zu
sorgen, dass die Kommunikation fehlerfrei funktioniert.
89
5 Entwicklung eines Sportwetten-Prototyps
Daher wird als Protokoll vereinbart:
■
■
■
■
■
■
Client sendet dem Servlet den Service-Namen als String
Client sendet dem Servlet den Methoden-Namen als String
Client sendet dem Servlet die Anzahl der Parameter als Integer
Client sendet dem Servlet die Parameter als Object-Array
Servlet sendet dem Client ein Rückgabewert als Object
Servlet sendet dem Client eine Exception als Object
5.6.2
Client
Damit der Client mit dem Servlet kommunizieren kann, wird eine Instanz der Klasse
URLConnection benötigt. Diese muss in beide Richtungen geöffnet werden, damit die
Objekte mittels Streams übertragen werden können:
URL url = new URL(SERVLET);
URLConnection connection = url.openConnection();
connection.setDoOutput(true);
connection.setDoInput(true);
connection.connect();
Wie bereits erwähnt gibt es mehrere hundert Methoden, die der Client dem Servlet zu
überreichen hat. Damit nicht alle Methoden implementiert werden müssen, besteht auch
hier die Möglichkeit dies generisch zu lösen. Dafür wird eine Klasse HttpInvoker
entwickelt, die das Interface InvocationHandler implementiert und folgende Methode
bereitstellt: 116
Object invoke(Object proxy, Method methode, Object[] args) throws Throwable
Um das Protokoll erfüllen zu können, werden noch folgende Objekte benötigt:
■ Service-Name:
String serviceName = proxy.getClass().getInterfaces()[0].getName()
■ Methoden-Name:
method.getName()
■ Anzahl der Parameter:
args.length
■ Parameter als Object-Array:
args
Zuletzt ist eine Kopie der Klasse BSLHelper für den Client zu erzeugen. In den Methoden
wird anstelle von BusinessServiceLocator nun HttpInvoker aufgerufen.
116
Vgl. [Nowa05, S. 183]
90
6 Fazit
6 Fazit
Um diese Arbeit abschließend zu beurteilen, muss zwischen den Erfahrungen mit Android
und der Umsetzung des Prototyps unterschieden werden.
Android
Die ersten Schritte bei der Entwicklung verliefen schleppend. Als Grund dafür ist die
unübersichtliche Online-Dokumentation zu benennen. Diese wurde jedoch in den letzen
Monaten deutlich verbessert. Dem Autor bot sich lediglich die Möglichkeit, die Fragen in
Foren und der Google Groups „Android Developers“ zu stellen. Es ist positiv festzuhalten,
dass die Google-Entwickler persönlich sehr präsent waren und bestmöglich geholfen haben,
Lösungen zu finden. Die optische Gestaltung von Android ist trotz der technischen
Möglichkeiten nicht sehr ansprechend. Als Beispiel sind weiße GUI-Komponenten auf
schwarzem Hintergrund zu benennen, die bei Betätigung orange aufleuchten. Hier ist
seitens eines Applikationsentwicklers viel zusätzliche Designarbeit zu leisten. Des Weiteren
wurde die Benutzung der aufklappbaren Tastatur vom Autoren und den Auftraggebern als
umständlich empfunden. In der neusten Android-Version 1.5 ist eine virtuelle Tastatur
enthalten, wie sie vom iPhone bekannt ist. Laut Internetquellen ist Multi-Touch mit Android
möglich. Dass dieses innovative Bedienungskonzept bisher nicht integriert wurde, hat
urheberrechtliche Gründe, da Apple dafür ein Patent angemeldet hat. Abschließend ist
festzuhalten, dass Android für ein Open Source-Projekt erstaunlich ausgereift ist und
vielfältige Entwicklungswerkzeuge bereitstellt. Es bleibt zu hoffen, dass in Zukunft viele
Entwickler dazu beitragen Android weiterhin zu verbessern.
Umsetzung des Prototyps
Für den Lösungsansatz, möglichst viel Logik auf dem Server zu belassen und Android
(beispielsweise durch einen Patch am Dalvik Cross-Compiler) zu zwingen diese anzubinden,
sind größtenteils die Auftraggeber verantwortlich. Diese Strategie wurde mit
akademischem Interesse betrachtet und erfolgreich umgesetzt. Nach Meinung des Autors
wäre es vorteilhafter gewesen, zu einem frühen Zeitpunkt die Quelltexte zu refaktorieren
und die Logik auf Android auszulagern. Dadurch würde die Applikation deutlich schneller
auf Benutzereingaben reagieren und weniger kostspielige Internetverbindungen benötigen.
Zusammenfassend ist festzuhalten, dass das oberste Ziel, möglichst viele Java-Quelltexte
der bereits existierenden Software zu adaptieren, erreicht und ein funktionierender
Prototyp realisiert wurde.
91
Abkürzungsverzeichnis
Abkürzungsverzeichnis
2G
3G
AAPT
ADB
ADC
ADT
AIDL
AMOLED
ANT
APK
AUD
AWT
CDC
CLDC
CSS
CVS
Dalvik VM
DDMS
DOM
DSP
DX
EITO
EUR
GPL
GPLv2
GUI
HAL
HTC
I18N
IDE
IDL
IMEI
ISO
JAD
JAR
Java EE
Java ME
Java SE
JVM
KVM
LGPL
LwVCL
MIDP
MTJ
MWT
OHA
Second Generation
Third Generation
Android Asset Packaging Tool
Android Debug Bridge
Android Developer Challenge
Android Development Toolkit
Android Interface Description Language
Active Matrix Organic Light Emitting Diode
Another Neat Tool
Android Package
Australischer Dollar ($)
Abstract Window Toolkit
Connected Device Configuration
Connected Limited Device Configuration
Cascading Style Sheets
Concurrent Versions System
Dalvik Virtual Machine
Dalvik Debug Monitor Service
Document Object Model
Digital Signal Processing
Dalvik Cross-Compiler
European Information Technology Observatory
Euro (€)
GNU General Public License
GNU Public License Version 2
Graphical User Interface
Hardware Abstraction Layer
High Tech Computer
Internationalization
Integrated Development Environment
Interface Description Language
International Mobile Equipment Identity
Internationale Organisation für Normung
Java Application Descriptor
Java Archive
Java Plattform, Enterprise Edition
Java Platform, Micro Edition
Java Platform, Standard Edition
Java Virtual Machine
Kilobyte Virtual Machine
GNU Lesser General Public License
Light-Weight Visual Component Library
Mobile Information Device Profile
Eclipse Mobile Tools for Java
Micro Window Toolkit
Open Handset Alliance
93
Abkürzungsverzeichnis
OTA
PV
RPC
SAX
SD (Memory Card)
SDK
SIM (Card)
SQL
SSL
SVN
SWT
USD
UTF-8
VM
WTK
WYSIWYG
XML
XSD
XSL
XSLT
Over The Air
PacketVideo
Remote Procedure Call
Simple API for XML
Secure Digital (Memory Card)
Software Development Kit
Subscriber Identity Module (Card)
Structured Query Language
Secure Sockets Layer
Subversion
Standard Widget Toolkit
United States Dollar ($)
8-bit Unicode Transformation Format
Virtual Machine
Sun Java Wireless Toolkit for CLDC
What You See Is What You Get
Extensible Markup Language
XML Schema Definition
Extensible Stylesheet Language
XSL Transformation
94
Abbildungsverzeichnis
Abbildungsverzeichnis
Abb. 1: Die unterschiedlichen Java-Plattformen [Java09] ...................................................................... 4
Abb. 2: Verschiedenen Emulatoren vom WTK 2.2 [Karb05, S. 52] ......................................................... 6
Abb. 3: MPowerPlayer im Webbrowser Firefox mit dem Spiel Guitar Hero [Mpla09a] ......................... 7
Abb. 4: Klassenhierarchie für darstellbare Elemente des MIDP [SzRö06] .............................................. 9
Abb. 5: Login MIDlet [Logi08] ................................................................................................................. 9
Abb. 6: Demo-MIDlets vom Micro Window Toolkit [Micr07b] ............................................................. 10
Abb. 7: Demo-MIDlet von der Light-Weight Visual Component Library [Vish06c] ............................... 11
Abb. 8: Entwicklungsplattform TagsMe GUI [Tags09b] ........................................................................ 12
Abb. 9: Demo-Anwendung von TagsMe [Tags09c] ............................................................................... 13
Abb. 10: LWUIT Resource Editor [Knud08] ........................................................................................... 15
Abb. 11: Demo Anwendung von LWUIT [Knud08] ................................................................................ 15
Abb. 12: Apple iPhone 3G [Appl09a] .................................................................................................... 18
Abb. 13: Apple iTunes [Appl09b] .......................................................................................................... 19
Abb. 14: Die Android-Applikation Compare Everywhere [Andr09b] .................................................... 28
Abb. 15: Die Android-Applikation Cooking Capsules [Andr09c] ........................................................... 28
Abb. 16: Die Android-Applikation Wikitude [Andr09d] ........................................................................ 29
Abb. 17: Android Software Stack, bestehend aus fünf Schichten [Andr09e] ....................................... 32
Abb. 18: Beispiel-Button ....................................................................................................................... 40
Abb. 19: Beispiel-Button in X-Richtung gestreckt ................................................................................. 40
Abb. 20: Beispiel-Button als NinePatch-Grafik ..................................................................................... 41
Abb. 21: Draw 9-patch mit Beispiel-Button als NinePatch-Grafik ........................................................ 41
Abb. 22: Dalvik Debug Monitor Service ................................................................................................ 42
Abb. 23: T-Mobile G1 – HTC Dream [Spar09] ....................................................................................... 49
Abb. 24: Vodafone G2 – HTC Magic [Kret09a] ...................................................................................... 50
Abb. 25: HTC Hero [Kret09b] ................................................................................................................ 51
Abb. 26: Kogan Agora (Pro) [Kret09c] ................................................................................................... 52
Abb. 27: Lenovo OPhone [Melz08] ....................................................................................................... 53
Abb. 28: Samsung I7500 Galaxy [Kret09e] ............................................................................................ 54
Abb. 29: Das Android-Projekt: Anmeldeformular ................................................................................. 56
Abb. 30: Lebenszyklus einer Activity [Andr09p] ................................................................................... 60
Abb. 31: Layout vom Anmeldeformular ............................................................................................... 62
Abb. 32: Modaler Fehlerdialog vom Anmeldeformular ........................................................................ 64
Abb. 33: Kontextmenü (links) und Hilfe-Dialog (rechts) vom Anmeldeformular .................................. 65
Abb. 34: Anmeldeformular im Hochformat (links) und im Querformat (rechts) .................................. 67
Abb. 35: Anmeldeformular mit angepasstem Anmelden-Button ......................................................... 68
Abb. 36: Zustände eines Buttons: normal (links), fokussiert (Mitte), gedrückt (rechts)....................... 68
Abb. 37: Aktivitätsdiagramm des Sportwetten-Prototyps .................................................................... 73
Abb. 38: Die Activity Hauptmenü des Sportwetten-Prototyps ............................................................. 75
Abb. 39: Die Activity Quoten des Sportwetten-Prototyps .................................................................... 76
Abb. 40: log4j-Ausgaben in LogCat ....................................................................................................... 80
Abb. 41: Abhängigkeitsbaum der Klasse org.apache.log4j.Logger ....................................................... 88
95
Tabellenverzeichnis
Tabellenverzeichnis
Tab. 1: Übersicht Entwicklungsplattformen ........................................................................................... 3
Tab. 2: Kommerzielle Lizenzen für LwVCL............................................................................................. 11
Tab. 3: Freeware Alternativen zu iTunes .............................................................................................. 19
Tab. 4: Framework Bestandteile vom iPhone SDK ................................................................................ 20
Tab. 5: Dienstleistungen von Google Inc. ............................................................................................. 23
Tab. 6: Alle 50 Firmen der Open Handset Alliance [Open] ................................................................... 25
Tab. 7: Bekannte Halbleiterfirmen der OHA ......................................................................................... 26
Tab. 8: Bekannte Softwarefirmen der OHA .......................................................................................... 26
Tab. 9: Gegenüberstellung der drei Plattformen .................................................................................. 31
Tab. 10: Anwendungen der Applications-Schicht ................................................................................. 33
Tab. 11: Mechanismen der Application Framework-Schicht [MoKo09, S. 9] [Andr09e] ...................... 33
Tab. 12: Bibliotheken der Libraries-Schicht [MoKo, S. 7] [Andr09e] .................................................... 34
Tab. 13: Core Libraries der Android Runtime-Schicht [MoKo09, S. 8] [Burn08] ................................... 35
Tab. 14: zusätzliche Core Libraries der Android Runtime-Schicht [Burn08] ......................................... 35
Tab. 15: Entwicklungsschritte einer Android-Applikation .................................................................... 36
Tab. 16: Verschiedene Android SDKs [Andre09g] ................................................................................. 37
Tab. 17: Parameter für den Android Emulator ..................................................................................... 38
Tab. 18: Vier verschiedene Skins vom Android Emulator [Andr09i] ..................................................... 39
Tab. 19: Aufrufe der Android Debug Bridge ......................................................................................... 43
Tab. 20: Beispiel für sqlite3 ................................................................................................................... 44
Tab. 21: Parameter für mksdcard ......................................................................................................... 45
Tab. 22: Von activitycreator generierte Dateien und Ordner ............................................................... 46
Tab. 23: Android SDKs und Plug-Ins ...................................................................................................... 47
Tab. 24: Funktionstasten vom T-Mobile G1 .......................................................................................... 49
Tab. 25: Alle Zustände einer Activity .................................................................................................... 61
Tab. 26: Wettereignis auf einem Wettschein ....................................................................................... 72
Tab. 27: Gültige Tags innerhalb von <pre> ........................................................................................... 87
97
Literaturverzeichnis
Literaturverzeichnis
[Alby08]
Alby, T.: Das mobile Web. München, Carl Hanser Verlag 2008.
[Andr]
Android: What is Android?
http://www.android.com/about/
oJ, Abruf am 17.8.2009.
[Andr09a]
Android Developer Challenge: ADC 2.
http://code.google.com/intl/de-DE/android/adc/
2009, Abruf am 17.8.2009.
[Andr09b]
Android Developer Challenge: Compare Everywhere.
http://code.google.com/intl/deDE/android/adc/adc_gallery/app.html?id=8
2009, Abruf am 17.8.2009.
[Andr09c]
Android Developer Challenge: Cooking Capsules.
http://code.google.com/intl/deDE/android/adc/adc_gallery/app.html?id=9
2009, Abruf am 17.8.2009.
[Andr09d]
Android Developer Challenge: Wikitude.
http://code.google.com/intl/deDE/android/adc/adc_gallery/app.html?id=50
2009, Abruf am 17.8.2009.
[Andr09e]
Android Developers: What is Android?
http://developer.android.com/guide/basics/what-is-android.html
2009, Abruf am 1.9.2009.
[Andr09f]
Android Developers: Tools Overview.
http://developer.android.com/guide/developing/tools/index.html
2009, Abruf am 5.9.2009.
[Andr09g]
Android Developers: Android 1.5 SDK, Release 3.
http://developer.android.com/sdk/1.5_r3/index.html
2009, Abruf am 5.9.2009.
[Andr09h]
Android Open Source Project: Get source.
http://source.android.com/download
2009, Abruf am 5.9.2009.
[Andr09i]
Android Developers: Android Emulator.
http://developer.android.com/guide/developing/tools/emulator.html
2009, Abruf am 6.9.2009.
99
Literaturverzeichnis
[Andr09j]
Android Developers: Android Debug Bridge.
http://developer.android.com/guide/developing/tools/adb.html
2009, Abruf am 6.9.2009.
[Andr09k]
Android Developers: Android Asset Packaging Tool.
http://developer.android.com/guide/developing/tools/aapt.html
2009, Abruf am 7.9.2009.
[Andr09l]
Android Developers: Designing a Remote Interface Using AIDL.
http://developer.android.com/guide/developing/tools/aidl.html
2009, Abruf am 7.9.2009.
[Andr09m]
Android Developers: mksdcard.
http://developer.android.com/guide/developing/tools/othertools.html
2009, Abruf am 7.9.2009.
[Andr09n]
Android Developers: UI/Application Exerciser Monkey.
http://developer.android.com/guide/developing/tools/monkey.html
2009, Abruf am 7.9.2009.
[Andr09o]
Android Developers: Download the ADT Plugin Zip File
http://developer.android.com/sdk/adt_download.html
2009, Abruf am 8.9.2009.
[Andr09p]
Android Developers: Activity
http://developer.android.com/reference/android/app/Activity.html
2009, Abruf am 9.9.2009.
[Appl09a]
Apple: iPhone - Galerie - Fotos.
http://www.apple.com/de/iphone/gallery/#hardware02
2009, Abruf am 12.8.2009.
[Appl09b]
Apple: iTunes - iTunes laden.
http://www.apple.com/de/itunes/download/
2009, Abruf am 12.8.2009.
[Appl09c]
Apple: iMac - Der All-in-One-Computer für Fotos, Filme und Musik.
http://www.apple.com/de/imac/
2009, Abruf am 15.8.2009.
[BaGa02]
Backschat, M.; Garden, O.: Enterprise JavaBeans. Grundlagen - Konzept Praxis. Berlin, Spektrum Akademischer Verlag 2002.
[BePa09]
Becker, A., Pant, M.: Android. Grundlagen und Programmierung. 1. Aufl.,
Heidelberg, dpunkt.verlag GmbH 2009.
[BrMo06]
Breymann, U., Mosemann, H.: Java ME. Anwendungsentwicklung für
Handys, PDA und Co. München, Wien, Carl Hanser Verlag 2006.
100
Literaturverzeichnis
[Brow08]
Brown, E.: Android Developer Challenge announces first-round winners.
http://www.linuxfordevices.com/c/a/News/Android-Developer-Challengeannounces-firstround-winners/
2008, Abruf am 16.8.2009.
[Burk08]
Burke, E.: Browsing Android Source in Eclipse.
http://stuffthathappens.com/blog/2008/11/01/browsing-android-sourcein-eclipse/
2008, Abruf am 5.9.2009.
[Burn08]
Burnette, E.: Java vs. Android APIs.
http://blogs.zdnet.com/Burnette/?p=504
2008, Abruf am 1.9.2009.
[Davi09]
David, P.: Mobile Zauberei. fondsmagazin, Seite 45, Ausgabe 03/2009.
[Dsdp]
DSDP-MTJ: Supported Wireless Toolkits.
http://www.eclipse.org/dsdp/mtj/development/tutorial/supported.php
2009, Abruf am 19.8.2009.
[Elgi05]
Elgin, B.: BusinessWeek: Google Buys Android for Its Mobile Arsenal.
http://www.businessweek.com/technology/content/aug2005/tc20050817
_0949_tc024.htm
2005, Abruf am 17.8.2009.
[Emme03]
Emmerich, W.: Konstruktion von verteilten Objekten. Heidelberg,
dpunkt.verlag GmbH 2003.
[Guen]
Guenstiger.de: Apple IPhone 3G.
http://www.guenstiger.de/gt/main.asp?produkt=771056
oJ, Abruf am 14.8.2009.
[HaLo04]
Hatcher, E., Loughran, S.: Java-Entwicklung mit Ant. 1. Aufl., Bonn,
mitp-Verlag 2004.
[Java09]
Java ME Technology.
http://java.sun.com/javame/technology/index.jsp
2009, Abruf am 18.8.2009.
[Karb05]
Karbacher, N.: Diplomarbeit: Kommunikation und Austausch von
Multimediadaten in spontanen Bluetooth-Netzwerken mittels J2ME.
http://www.n3po.com/daten/Diplomarbeit.pdf
2005, Abruf am 18.8.2009.
[Knud08]
Knudsen, J.: The Lightweight User Interface Toolkit (LWUIT): An
Introduction.
http://java.sun.com/developer/technicalArticles/javame/lwuit_intro/
2008, Abruf am 25.8.2009.
101
Literaturverzeichnis
[Kret09a]
Kretschmann, T.: Zweites Android-Handy kommt im April.
http://www.tomshardware.com/de/Vodafone-Android-HTC-MagicGoogle,news-242407.html
2009, Abruf am 5.8.2009.
[Kret09b]
Kretschmann, T.: HTC: Android-Smartphone mit »Sense«.
http://www.tomshardware.com/de/HTC-Hero-Android-Sense,news243047.html
2009, Abruf am 5.8.2009.
[Kret09c]
Kretschmann, T.: Zweites Android-Phone angekündigt.
http://www.tomshardware.com/de/Agora-Smartphone-Open-SourceGoogle,news-242050.html
2009, Abruf am 6.8.2009.
Kretschmann, T.: Kogans Android-Phone kommt doch nicht.
http://www.tomshardware.com/de/Android-Display-G1,news242234.html
2009, Abruf am 6.8.2009.
[Kret09d]
[Kret09e]
Kretschmann, T.:Samsung mit eigenem Handy.
http://www.tomshardware.com/de/I7500-Samsung-Android-GoogleO2,news-242809.html
2009, Abruf am 6.8.2009.
[Lafo09]
Lafortune, E.: ProGuard FAQ: What is obfuscation?
http://proguard.sourceforge.net/FAQ.html#obfuscation
2009, Abruf am 19.8.2009.
[Logi08]
Login Midlet.
http://www.java2s.com/Code/Java/J2ME/LoginMidlet.htm
2008, Abruf am 23.8.2009.
[Melz08]
Elzer, R.: Lenovo OPhone: Das Google-Phone im schicken Business-Anzug.
http://www.areamobile.de/news/10334-lenovo-ophone-das-googlephone-im-schicken-business-anzug
2008, Abruf am 6.8.2009.
[Micr07a]
Micro Window Toolkit: Home.
http://j2me-mwt.sourceforge.net/index.html
2007, Abruf am 23.8.2009.
[Micr07b]
Micro Window Toolkit: Demo Midlets.
http://j2me-mwt.sourceforge.net/demomidlets.html
2007, Abruf am 23.8.2009.
[Micr09]
MicroEmulator: Introduction.
http://snapshot.microemu.org/index.html
2009, Abruf am 19.8.2009.
[MoKo09]
Mosemann, H., Kose, M.: Android. Anwendungen für das HandyBetriebssystem erfolgreich programmieren. München, Wien, Carl Hanser
Verlag 2009.
102
Literaturverzeichnis
[Mpla09a]
mplayit: free mobile games demos.
http://mplayit.com/#GuitarHeroWorldTourMobile
2009, Abruf am 19.8.2009.
[Mpla09b]
mplayit SDK: About.
http://mpowerplayer.com/sdk
2009, Abruf am 19.8.2009.
[Nowa05]
Nowak, J.: Fortgeschrittene Programmierung mit Java 5. Generics,
Annotations, Concurrency und Reflection. 1. Aufl., Heidelberg,
dpunkt.verlag GmbH 2005.
[Oe2409]
oe24.at: 2009 wird 4 Milliarden-Marke erreicht.
http://www.oe24.at/digital/2009-wird-4-Milliarden-Marke-erreicht0507136.ece
2009, Abruf am 10.8.2009.
[Oest07]
Oestreich, N.: Freeware-Roundup: Alle iTunes-Alternativen.
http://www.ifun.de/content/view/2949/1/
2007, Abruf am 12.8.2009.
[Open]
Open Handset Alliance: Members.
http://www.openhandsetalliance.com/oha_members.html
oJ, Abruf am 10.8.2009.
[Prin09]
Prinz, M.: Ausarbeitung zum Masterseminar WS 08/09: J2ME, Android und
iPhone SDK im Vergleich.
http://cart.kolix.de/wpcontent/uploads/2009/01/vergleich_j2me_android_iphone.pdf
2009, Abruf am 12.8.2009.
[Sete09]
Setera, C.: Eclipse ME: Eclipse Mobile Tools for Java Passes Release Review.
http://eclipseme.org/
2009, Abruf am 19.8.2009.
[Shark08]
Sharkey, J.: Leveraging the Android Emulator.
http://jsharkey.org/blog/2008/10/10/leveraging-the-android-emulator/
2008, Abruf am 6.9.2009.
[Spar09]
Sparhandy: T-Mobile G1 - ich habe es fast verstanden.
http://www.sparhandy.de/blog/t-mobile-g1-ich-habe-s-fast-verstanden/
2009, Abruf am 4.8.2009.
[Spie08]
Spiegel Online: Google-Handy in der Kritik: Akku grauenhaft, Software Eins
minus.
http://www.spiegel.de/netzwelt/mobil/0,1518,584639,00.html
2008, Abruf am 4.8.2009.
[Sun09]
Sun Microsystems: Developer’s Guide - Lightweight UI Toolkit.
https://lwuit.dev.java.net/files/documents/8797/138819/LWUIT_1_2.zip
2009, Abruf am 25.8.2009.
Szczygiel S., Röwekamp, L.: Application Development in J2ME. Teil I. Seite
[SzRö06]
103
Literaturverzeichnis
III.
http://www.areamobile.de/specials/J2ME/teil_III.php
2006, Abruf am 20.8.2009.
[Tags09a]
TagsMe: Build Mobile Device Applications.
http://tech.tagsme.com/
2009, Abruf am 23.8.2009.
[Tags09b]
TagsMe GUI Editor.
http://tech.tagsme.com/index.php?option=com_content&task=view&id=4
4&Itemid=63
2009, Abruf am 23.8.2009.
[Tags09c]
TagsMe: Gallery Screen Shots.
http://tech.tagsme.com/index.php?option=com_content&task=view&id=6
&Itemid=6
2009, Abruf am 23.8.2009.
[Tmob]
T-Mobile: Technische Details des iPhone 3G.
http://www.t-mobile.de/iphone/technische-details
oJ, Abruf am 12.8.2009.
[Uebe]
Ueberthings: J2ME Tutorial: Provisioning.
http://www.uberthings.com/mobile/index.html#provisioning
oJ, Abruf am 19.8.2009.
[Unlo]
Unlock your Google Phone: How to Activate and Unlock Boxed Packed
T-Mobile G1.
http://www.unlock-tmobileg1.com/procedures/activate.php
oJ, Abruf am 4.8.2009.
[Vish06a]
Vishneuvski, A.: Light Weight Components: Overview.
http://www.lwvcl.com/index.php
2006, Abruf am 23.8.2009.
[Vish06b]
Vishneuvski, A.: Light Weight Components: Purchase.
http://www.lwvcl.com/price.php
2006, Abruf am 23.8.2009.
[Vish06c]
Vishneuvski, A.: Light Weight Components: J2ME Screen Shots.
http://www.lwvcl.com/j2me-screens.php
2006, Abruf am 23.8.2009.
[Webf09]
Webflashers: Was ist AMOLED?
http://www.oled.at/aktive-matrix-oled.htm
2009, Abruf am 6.8.2009.
[Wiki09a]
Wikipedia: HTC Dream - Technische Daten.
http://de.wikipedia.org/wiki/HTC_Dream
2009, Abruf am 5.8.2009.
[Wiki09b]
Wikipedia: Geotagging.
104
Literaturverzeichnis
http://en.wikipedia.org/wiki/Geotagging
2009, Abruf am 12.8.209.
[Wiki09c]
Wikipedia: List of iPhone and iPod Touch models.
http://en.wikipedia.org/wiki/List_of_iPhone_and_iPod_Touch_models
2009, Abruf am 12.8.2009.
[Wiki09d]
Wikipedia: iPhone OS.
http://en.wikipedia.org/wiki/IPhone_OS
2009, Abruf am 12.8.2009.
[Wiki09e]
Wikipedia: Tagged Image File Format – Exploits.
http://en.wikipedia.org/wiki/Tagged_Image_File_Format#Exploits
2009, Abruf am 13.8.2009.
[Wiki09f]
Wikipedia: Apple Developer Connection.
http://de.wikipedia.org/wiki/Apple_Developer_Connection
2009, Abruf am 14.8.2009.
[Wiki09g]
Wikipedia: Apple iPhone.
http://de.wikipedia.org/wiki/Apple_iPhone
2009, Abruf am 14.8.2009.
[Wiki09h]
Wikipedia: Google.
http://de.wikipedia.org/wiki/Google
2009, Abruf am 15.8.2009.
[Wiki09i]
Wikipedia: Google Inc.
http://de.wikipedia.org/wiki/Google_Inc.
2009, Abruf am 15.8.2009.
[Wiki09j]
Wikipedia: Sportwette
http://de.wikipedia.org/wiki/Sportwette
2009, Abruf am 12.9.2009
105
Eidesstattliche Erklärung
Eidesstattliche Erklärung
Gemäß § 26 (1) der DPO erkläre ich an Eides statt, dass ich die vorliegende Arbeit
selbständig angefertigt habe. Ich habe mich keiner fremden Hilfe bedient und keine
anderen, als die angegebenen Quellen und Hilfsmittel benutzt. Alle Stellen, die wörtlich
oder sinngemäß veröffentlichten oder nicht veröffentlichten Schriften und anderen Quellen
entnommen sind, habe ich als solche kenntlich gemacht. Diese Arbeit hat in gleicher oder
ähnlicher Form noch keiner Prüfungsbehörde vorgelegen.
Dortmund, 14.09.2009
_____________________________________
(Marco Alexander Schmitz)
106