Post on 06-Mar-2016
description
Danke an meine Betreuerin DI Doris Ulrich,
die mir durch ihre unkomplizierte Art die
Fertigstellung meiner Arbeit sehr erleichtert
hat, und an meine Eltern für das Ausgleichen
meiner diversen Rechtschreibschwächen.
Ich erkläre hiermit eidesstattlich, dass ich die vorliegende Bakkalaureats-
arbeit selbstständig und ohne fremde Hilfe verfasst, keine anderen als die
angegebenen Quellen und Hilfsmittel benutzt und die den benutzten Quellen
wörtlich oder inhaltlich entnommenen Stellen als solche kenntlich gemacht
habe. Die Arbeit wurde bisher in gleicher oder ähnlicher Form keiner anderen
Prüfungskommission vorgelegt und auch nicht veröffentlicht.
Martin Tiefengrabner, Graz am 27. Jänner 2011
As it Reads - Reading on Screens
Wheter on the notebook, the computer in the office or away on your smart
phone: Reading monitor screens is part of our every days live. The readers
will find themselves confronted with substantially different reading situation
compared to reading on paper. The difference between the two medias in con-
cerns of haptics usability and especially the used method for displaying text
make it next to the receiver of the text needed for producers to respect these
differences.
The purpose of the thesis deals with basic differences between the two media
and tries to derive basice rules the help to make text adequately media. The
findings are pracitcally applied to reader application for smart phones.
Wie sichs liest - Lesen am Bildschirm
Ob am Notebook, Computer im Büro oder unterwegs am Smartphone: Lesen
am Bildschirm ist Teil unseres Alltags geworden. Der Leser findet sich mit
einer Lesesituation konfrontiert, die zum Lesen am Papier grundlegend ver-
schieden ist. Die Unterschiede der beiden Medien bei Haptik, Benutzbarkeit
und in der Art, wie Text dargestellt wird, machen es neben dem Recipienten
auch für den Textproduzenten nötig, diese Differenzen zu beachten.
Die vorliegende Arbeit beschäftigt sich mit den prinzipiellen Unterschieden
zwischen den beiden Medien und versucht daraus Grundregelen abzuleiten,
die helfen sollen Text medienadäquat aufzubereiten. Die dabei gewonnenen
Erkenntnisse werden in einer Lese-Applikation für Smartphones praktisch
angewandt.
Konzept
Texte am Smartphone 15
Sanskread 17
Die Plattform 17
Ablauf
Der Entwicklungsprozess 25
Der Startbildschirm 25
Neues Dokument erstellen 27
Text aus Zwischenablage 29
Lesemodi 29
Resume Document 34
Lesezeichenübersicht 34
Sanskread Dokument Library 34
Umsetzung
Die Server-Anwendung 39
Der Client 42
Ein Android Projekt 43
Datenhaltung 47
Weltweit 48
Gestaltung von Oberflächen 48
Grundfarben von Sanskread 50
15
Texte am Smartphone zu lesen
die zum Beispiel als Word-Dokumente, PDF-Dokumente vorliegen, ist nicht
immer sehr einfach und angenehm. Kleine Displays und die geringe Rechen-
leistung der Geräte gestalten das Lesen unkomfortabel. Vor allem Dokumente
im weit verbreiteten PDF-Format sind nur sehr schwer lesbar, da die einzel-
nen Seiten vor der Darstellung erst für die Darstellung aufbereitet werden
müssen. Aus diesem Grund wurde als praktischer Teil dieser Arbeit eine
Reader-Applikation für mobile Endgeräte, die Anwendung Sanskread, erstellt.
Sanskread soll dabei nicht primär zum Lesen von Büchern oder Magazinen
dienen, sondern soll dem Benutzer die Möglichkeit geben, sich unterwegs
schnell in kurze Dokumente (Whitepapers, Reports, Präsentationen) einzule-
sen. Daher sind die Hauptgesichtspunkte die Unterstützung üblicher Datei-
formate und die schnelle Darstellung der Dokumente. Die Verarbeitung der
Dateien soll auch unterwegs möglich sein und ressourcenschonend ausge-
führt werden können. Neben dem normalen Lesemodus, bei dem der Benut-
zer wie durch ein Buch blättern kann, soll noch ein zweiter Schnelllesemodus,
basierend auf dem RSVP-Konzept, verfügbar sein. Der RSVP-Modus bringt
gerade bei kleinen, mobilen Displays einen Vorteil für den Leser, da sich die
negative Auswirkung des kleinen Handy-Bildschirms in Grenzen hält. Da im
RSVP-Modus immer nur einzelne Wörter gezeigt werden, können diese in
einer großen Schriftgröße dargestellt werden. Dadurch kann der Text auch
noch aus einiger Entfernung gelesen werden, der Leser kann eine angenehme
Leseposition einnehmen. Auch bei hellem Umgebungslicht sind die großen
Lettern einfacher erkennbar.
Ebook-Reader, speziell für kleine Displays, sind zwar schon entwickelt wor-
den, stellen aber meist nur Dokumente in speziellen, proprietären Formaten
dar. Damit sind sie unbrauchbar um externen Dateien schnell aufzubereiten.
Abb. 1: »Schematischer Aufbau von Sanskread«
Schematischer Aufbau
1
4
2
3
Internet
1 Die ausgewählte Datei wird an den Server geschickt.
Der Server empfängt die Datei und wandelt sie in ein Sanskread-Dokument um
Das Dokument wird an das Smartphone zurückgesandt.
Das Smartphone speichert das Dokument und stellt es dar.4
2
3
17
Sanskread ist in zwei
Teile gegliedert. Auf der einen Seite steht die Client-Anwendung, die der
Benutzer auf seinem Endgerät installiert. Auf der anderen Seite läuft eine
Server-Anwendung, die über das Internet erreichbar ist. Die Anwendung am
Web-Server übernimmt die rechenintensive Aufbereitung und Umwandlung
der Dateien, die der Benutzer auf seinem Gerät lesen möchte.
Der User wählt die Datei, die er in Sanskread lesen möchte, auf seinem
Smartphone aus. Das Dokument wird auf den Webserver geladen und dort
verarbeitet. Dabei werden Bilder und etwaige Formatierungen aus dem Doku-
ment entfernt. Danach wird der Text unter der Zuhilfenahme automatischer
Silbentrennung auf einzelnen Seiten umgerechnet, die für die Bildschirmgrö-
ße des benutzten Gerätes hin optimiert sind. Sind die Daten fertig umgewan-
delt, erzeugt der Server ein eigenes Sanskread-Dokument, das zurück an die
Applikation des Benutzers geschickt wird, wo es lokal am Gerät gespeichert
wird. Damit steht es dem Benutzer auch zur Verfügung, wenn er nicht mit
dem Internet verbunden ist. Das Programm bietet nun die Möglichkeit das
gespeicherte Sanskread-Dokument als normales Buch oder im RSVP-Modus
anzuzeigen. Im Buchmodus kann der Benutzer mit Paging durch die ein-
zelnen Seiten navigieren. Scrollen ist nicht möglich. Dadurch soll einerseits
erreicht werden, dass der User nicht nur oberflächlich über den Text schaut,
sondern sich Seite für Seite durchs Dokument tasten muss. Zusätzlich soll
das eine gewisse haptische Nähe zum Blättern in einem Buch erzeugen.
Die Wahl der Plattform
fiel auf Android, eine unter Apache Lizenz verfügbare Open Source Plattform
für mobile Endgeräte. Der Software-Kern von Android wurde in den Program-
miersprachen C & C++ geschrieben, das User-Interface sowie Applikationen
Abb. 5: »Android 2.1, Eclaire«Abb. 4: »Android 1.5, Cupcake«
Abb. 2: »Android 1.6, Donut« Abb. 3: »Android 2.3, Gingerbread«
Android-Versionen
19
können in Java implementiert werden. (Vgl. Android, online) (Vgl. Becker, An-
droid, v) Android wurde von der 2003 gegründeten Firma Android Inc. entwi-
ckelt. 2005 kaufte Google das damals erst 22 Monate alte Startup-Unterneh-
men. (Vgl. Elgin, Google, online) Über den tatsächlichen Kaufpreis gibt es nur
Spekulationen, das Wired-Magazin geht von einem Kaufpreis von rund 50
Millionen US-Dollar aus. (Vgl. Roth, Google, online) Zum Verkauf an Google
meinte Andy Rubin, Co-Founder von Android Inc., in einem Interview mit
Wired: »Google‘s model is to build a killer app, then monetize it later« (Roth, Goog-
le, online)
Anfängliche Spekulationen, Google würde sich durch den Kauf von Android
mit einem eigenen gPhone in direkter Konkurrenz zu Apples iPhone positi-
onieren, wurden mit der Gründung der Open Handset Alliance (OHA) zer-
streut. (Vgl. Roth, Google, online) Google ging dabei eine Kooperation mit 34
Unternehmen ein, um einheitliche, offene Standards für mobile Endgeräte
zu schaffen. Damit sollte dem Wildwuchs proprietärer mobiler Betriebssys-
teme entgegengewirkt werden. Unter den Gründerunternehmen befanden
sich Softwareentwickler, Mobiltelefonhersteller, Netzbetreiber, Chiphersteller
und Marketingunternehmen, darunter eBay, HTC, Intel, T-Mobile, Samsung,
Motorola. (Vgl. Industry, online) Mittlerweile ist das Konsortium auf 79 Mit-
glieder angewachsen, es konnten unter anderem Firmen wie Acer, Lenovo,
Samsung und Sony Ericsson zur Mitarbeit gewonnen werden. (Vgl. Alliance,
online)
2008 trat Google mit der ersten Android-Version, Android 1, an die Öffent-
lichkeit. (Vgl. Morrill, Announcing, online). Mittlerweile ist Android in der Ver-
sion 2.3 verfügbar, die wie alle Releases ab der Version 1.5 als Beinamen den
Namen einer Süßspeise erhalten hat: Gingerbread. (Vgl. Ducrohet, Android,
online)
Da Google selbst keine Hardware für Mobiltelefone fertigt, entwickeln Part-
ner aus der OHA Geräte für Android. Dabei haben Unternehmen wie HTC,
Samsung, Sony Ericsson oder Motorala in den letzen Jahren über 70 verschie-
dene Smartphones entwickelt. (Vgl. Phone, online) Dass die Trennung von
Hard- und Softwareproduktion durchaus erfolgreich ist, zeigt sich darin, dass
im August 2010 in den USA erstmalig mehr Android-Smartphones als Apple
iPhones neu angemeldet wurden. Im November desselben Jahres betrug der
Anteil von Android bei den Neuanmeldungen 41%, für Apple waren es noch
27%. Bei allen in Umlauf befindlichen Smartphones in den USA liegt Apple
zwar noch in Front, Android konnte sich aber im November 2010 bis auf
3% annähern. (Vgl. Apple, online) Der Einsatzbereich von Android beschränkt
sich mittlerweile aber nicht mehr nur auf Smartphones, auch Netbooks, Ta-
blets, Home Entertainment Geräte setzen auf die offene Plattform. (Vgl, De-
vices, online)
Ähnlich wie Apple oder Samsung bietet Google für Android einen eigenen
Market, wo Applikationen online gestellt und heruntergeladen werden kön-
nen. Im Gegensatz zu Apple, wo Entwickler jährlich 100 USD für die Mit-
gliedschaft im Developer Programm zahlen müssen, können im Android
Market nach einer einmaligen Zahlung von 25 USD zur Identitätsfeststellung
des Entwicklers Applikationen zum Download angeboten werden. (Vgl. iOs,
online) (Vgl. Android Market, online)
Im Dezember 2010 zählte der Market rund 200.000 Applikationen von de-
nen über 60% kostenfrei genutzt werden können. Google verzichtet weiters
auf einen Einreichungsprozess wie bei Apples Store, wo das Programm in-
haltlich und formell überprüft wird. Dadurch können Applikationen schneller
und einfacher online gestellt werden. Damit einher geht aber eine fehlende
Qualitätskontrolle der verfügbaren Apps. (Vgl. Android Market, online) (Vgl.
App, online)
2525
Der Entwicklungsprozess
von Sanskread wurde mit der Erstellung von Wireframes der späteren Be-
nutzeroberfläche begonnen. Dadurch konnten einerseits von Anfang an der
spätere Screenaufbau und die Reihenfolge der Screens entwickelt werden, an-
dererseits dienten die Wireframes dazu, die grundsätzlichen Use-Cases des
Programms herauszufiltern und zu strukturieren. Daraus ergaben sich fol-
gende Hauptmodule die im fertigen Programm enthalten sein sollten:
• Neues Dokument erstellen
• Text aus der Zwischenablage in den Reader einfügen
• Dokument im Buchmodus lesen
• Dokument im RSVP-Modus lesen
• Dokument verwalten
• Lesezeichen verwalten.
Diese grobe Modulunterteilung bildete die Grundlage für den Aufbau und
Ablauf des Programms, die in der folgenden Projektphase in ein technisches
Konzept verarbeitet wurde.
Der Startbildschirm,
der beim Öffnen von Sanskread anzeigt wird, soll dem Benutzer den schnel-
len Zugriff auf die Grundfunktionen des Programms ermöglichen. Dazu zäh-
len: das zuletzt gelesene Dokument wiederherstellen, die Sanskread-Doku-
ment-Bibliothek durchsuchen, ein neues Dokument erstellen oder Text aus
der Zwischenablage von Sanskread aufbereiten lassen. Über die Menü-Taste
lässt sich ein Optionsmenü aufrufen, das am unteren Ende des Screens an-
gezeigt wird. Es bietet drei Grundfunktionen, die im gesamten Programm
immer erreichbar sind: Hilfe, Einstellungen und Beenden.
2727
Neues Dokument erstellen
Nach dem Auswählen des Buttons am Hauptbildschirm erscheint ein Dateib-
rowser, der dem Benutzer die Möglichkeit gibt, ein Dokument, das von Sansk-
read aufbereitet werden soll, auszuwählen. Durchsucht können dabei all jene
Dateien werden, die sich im Speicher des Gerätes befinden und von Sanskread
unterstützt werden. Durch Drücken auf »Ordner« gelangt der User eine Ebe-
ne höher, durch Benutzen der standardmäßigen Zurücktaste eine Ebene nach
unten. Um die entsprechende Datei auszuwählen, muss sie gedrückt werden
und ein neues Fenster wird angezeigt. Hier hat der Benutzer die Möglichkeit
Titel und Autor des Dokuments festzulegen und die Sprache, in der das Do-
kument verfasst wurde, auszuwählen. Ausgewählt können all jene Sprachen
werden, die von der Silbentrennung am Server unterstützt werden. Ist das
Dokument in einer anderen Sprache abgefasst, kann Sanskread genauso ver-
wendet werden, nur ohne automatische Silbentrennung. Neben dem Dateina-
men bekommt der User auch noch die Größe der Datei angezeigt, da gerade
bei Verarbeitung von großen Files im mobilen Internet auf der einen Seite
hohe Kosten entstehen können, andererseits die Verarbeitungszeit bei lan-
gen Dateien sehr hoch sein kann. Durch Drücken des Buttons »Create« wird
das Einstellungsfenster nach links geschoben und eine Fortschrittsanzeige
wird sichtbar, die über die gerade laufenden Verarbeitungsschritte informiert.
Das Dokument wird im Hintergrund an den Server mit der Sanksread-Server-
Applikation gesendet, um dort verarbeitet und aufbereitet zu werden. Hat der
Server seine Arbeit beendet, wird das erstellte Sanskread-Dokument zurück
an das Gerät geschickt, lokal gespeichert und in die Sanskread-Bibliothek auf-
genommen. Der Benutzer bekommt das Dokument, je nach Einstellung, im
Buch- oder im RSVP-Modus präsentiert.
Abhängig von der Einstellung des Benutzers werden die Sanskread-Doku-
mente für hoch- oder querformatige Anzeigen optimiert. Das Dokument
2929
kann zwar auf beide Weisen gelesen werden, die Silbentrennung wird aber
für die favorisierte Anzeigeart durchgeführt. Dreht der Benutzer das Gerät
um neunzig Grad, wird automatisch auch der Anzeigemodus gewechselt.
Text aus Zwischenablage
Beim Aufruf dieser Funktion hat der Benutzer die Möglichkeit, den Text, den
er zuvor aus dem Browser, aus Emails, oder einer anderen Textquelle in die
Zwischenablage kopiert hat, von Sanskread aufbereiten zu lassen. Der kopier-
te Text wird gleich wie ausgewählte Dateien in ein Sanskread-Dokument um-
gewandelt und kann dann in der Applikation gelesen werden.
Dazu bekommt der Benutzer als erstes einen Bildschirm angezeigt, auf dem
der Text aus der Zwischenablage automatisch in ein Textfeld eingefügt wur-
de. Der Benutzer hat hier die Möglichkeit den Text noch zu verändern, bevor
er verarbeitet wird. Mit Drücken des »Create-Buttons« wird der Text an den
Server geschickt. Gleich wie beim Konvertieren von Dateien zu Sanskread-
Dokumenten, zeigt eine Fortschrittsanzeige den aktuell laufenden Verarbei-
tungsschritt an. Nachdem der Server seine Arbeit beendet hat, wird das Sans-
kread-Dokument wieder an das Endgerät zurückgesendet, gespeichert und
angezeigt.
Lesemodi
Sanskread bietet dem Leser zwei Modi, um Texte zu lesen. Beide Varianten
arbeiten mit dem gleichen Sanskread-Dokument und der Wechsel von einem
Modus in den anderen ist einfach über das Optionsmenü möglich. Über das
Einstellungsmenü kann ausgewählt werden, in welchem Modus Dokumente
standardmäßig angezeigt werden sollen.
3131
Beim Öffnen eines Dokuments im Buchmodus wird die Android eigene Sta-
tuszeile am oberen Ende des Bildschirms versteckt, um den Benutzer nicht
vom Text abzulenken und ihn durch womöglich erscheinende Statusmeldun-
gen nicht in seinem Lesefluss zu stören. Bis auf eine kleine Fortschrittsanzei-
ge am unteren Rand, die dem Leser die aktuelle sowie die Seitenanzahl des
Dokuments anzeigt, nimmt der Text den Rest des Bildschirms ein. Die Fort-
schrittsanzeige soll dem Benutzer helfen, nicht die Orientierung zu verlieren
und ihm ein kleines »Erfolgserlebnis« bereiten, wenn er eine Seite fertig ge-
lesen hat und zur nächsten blättert. Durch eine horizontale Wischbewegung
nach rechts wird eine Seite vor geblättert, bei einer Bewegung nach links eine
Seite zurück.
Über das Kontextmenü, das bei Android-Geräten standardmäßig durch län-
geres Drücken auf ein Bildschirmelement aufgerufen wird, hat der User die
Möglichkeit Lesezeichen zu setzen oder direkt zu einer beliebigen Seite im
Dokument zu springen. Lesezeichen werden auf Seiten gesetzt und können
in einem Dialogfeld, das nach Auswahl der »Set Bookmark« Option aufgeru-
fen wird, benannt werden. Für eine Seite können beliebig viele Lesezeichen
erstellt werden. Lesezeichen werden für das geöffnete Dokument gespeichert
und sind jederzeit abrufbar, können editiert oder gelöscht werden. Wählt der
User im Kontextmenü die Option »Go to Page«, erscheint ein Dialogfeld, wo
er die Seitennummer eingeben kann. Auf ungültige Eingaben wird der Benut-
zer über einen sogenannten Toast, einen kleinen Popup-Dialog, hingewiesen.
Über das Optionsmenü sind neben den Standardoptionen noch weitere Funk-
tionen des Book Readers abrufbar. Der Benutzer kann sich eine Übersicht
über alle Lesezeichen im aktuell geöffneten Sanskread-Dokument anzeigen
lassen oder direkt in den zweiten Lesemodus den RSVP-Modus wechseln.
Beim Wechsel der Modi bleibt die aktuelle Leseposition erhalten und das erste
Wort des ersten Satzes wird angezeigt.
3333
Wird ein Dokument im RSVP-Modus geöffnet, wird das erste Wort des ersten
vollständigen Satzes der aktuellen Seite angezeigt und der Reader pausiert.
Am unteren Rand des Bildschirms ist eine Kontrollleiste sichtbar, mit der sich
das Verhalten des Readers regeln lässt und im Text navigiert werden kann. Die
Schaltfläche links mit dem einzelnen Pfeil bewegt die aktuelle Leseposition
um ein Wort zurück, die daneben liegende Doppelpfeil-Schaltfläche springt
um einen ganzen Satz zurück. Damit kann, ähnlich einer Regressionssakka-
de, zu einer Passage zurückgesprungen werden, um sie noch einmal zu lesen.
Der Schieberegler in der Mitte steuert die Geschwindigkeit des Readers, die
standardmäßig auf die durchschnittliche Lesegeschwindigkeit von 240 Wör-
tern pro Minute eingestellt ist. Die Geschwindigkeit kann aber auf einen be-
liebigen Wert zwischen 180 WpM und 320 WpM je nach Lesegewohnheit
verändert werden. Mit den beiden letzten Schaltflächen kann die Größe der
Schrift variiert werden.
Durch Drücken auf den Bildschirm beginnt der Reader zu laufen und zeigt
ein Wort nach dem anderen in der eingestellten Lesegeschwindigkeit an. Fin-
det der Reader im Text einen Punkt, dem ein Großbuchstabe folgt, wird eine
kurze Pause eingelegt, um das Ende eines Satzes zu markieren. Bei Beistri-
chen und Semikolons stoppt der Reader kürzer. Damit soll der Leser in einen
möglichst natürlichen Leserhythmus kommen.
Das Kontext- und Optionsmenü bietet die gleichen Funktionalitäten wie im
Bücher-Modus. Auch hier kann zu einer bestimmten Seite im Dokument ge-
sprungen oder ein Lesezeichen geöffnet werden. Dabei beginnt der Reader
mit dem ersten Wort des ersten vollständigen Satzes auf der Seite, um dem
Benutzer einen leichteren Einstieg in die gewählte Seite zu ermöglichen.
Resume Document
Das zuletzt geöffnete Dokument kann an der Stelle, an der es geschlossen
wurde, wieder geöffnet werden. Ob als Buch oder im RSVP-Modus, kann der
Benutzer in den Grundeinstellungen ändern.
Lesezeichenübersicht
Für jedes Sanskread-Dokument können alle erstellten Lesezeichen durch-
sucht werden. Neben dem eingegebenen Titel wird noch angezeigt, für wel-
che Seite das Lesezeichen angelegt wurde. Durch Drücken des Lesezeichens
wird das Dokument an der gewählten Stelle geöffnet. Bei längerem Drücken
eines Lesezeichens wird das Kontextmenü aufgerufen, das Möglichkeiten
zum Editieren und Löschen des Lesezeichens gibt.
Sanskread Dokument Library
Die Library gibt eine Übersicht über alle gespeicherten Sanskread-Doku-
mente mit kurzer Information über Länge und aktuelle Leseposition. Durch
Drücken wird das gewählte Dokument an der aktuellen Leseposition im ge-
wählten Standard Lesemodus geöffnet. Über das Kontextmenü kann das Do-
kument bearbeitet oder gelöscht und die Lesezeichen des Dokuments können
angezeigt werden. Über »Open New« wird das Dokument am Anfang und
nicht an der letzten Leseposition geöffnet und die aktuelle Leseposition zu-
rückgesetzt.
39
Die Server-Anwendung kümmert
sich um die Aufbereitung der Dokumente für die Applikation am Endgerät.
Sie kann reinen Text, PDF-, Word-, und RichText-Dokumente verarbeiten.
Die Client-Applikation sendet die vom Benutzer ausgewählte Datei oder den
Text aus der Zwischenablage per GET-Request an den Server. Neben der Datei
werden noch die Informationen, die der Benutzer eingegeben hat (Titel und
Autor), sowie Pixelhöhe, Pixelbreite und Auflösung vom Display des Geräts,
und ob das Dokument für hoch- oder querformatige Ansicht optimiert wer-
den soll, an den Server mitübergeben.
Im ersten Schritt werden am Server alle Formatierungsinformationen, Bilder
und Steuerzeichen aus dem Dokument entfernt und es wird in reinen Text
umgewandelt. Das ist nötig, um es in den nächsten Schritten für die Darstel-
lung am Client zu optimieren.
Anhand des Dateityps werden unterschiedliche Verfahren angewandt, um
den Text zu extrahieren. Bei Word-Dokumenten wird mit einem Skript, basie-
rend auf Open Source Code, (http://www.webluncher.com/arifinblog/archives/
tag/parse-word) gearbeitet. Dabei wird im ersten Schritt das Dokument einge-
lesen, alle Zeilenumbrüche, die durch Carriage Return markiert sind, werden
erkannt und der Text in eine einzelne Zeile umgewandelt, die in einer Liste
zwischengespeichert wird. Diese Liste wird danach durchiteriert und alle Zei-
chen, die ungleich x00 (NUL) sind, temporär gespeichert. Sind alle Zeichen
umgespeichert, werden noch die Steuerzeichen mit einer Regexabfrage er-
setzt und der Reintext liegt vor.
Für die Umwandlung von PDF-Dokumenten wird ein Skript verwendet, das
auf http://www.webcheatsheet.com/php/reading_clean_text_from_pdf.php
basiert. Die Umwandlung von PDF-Dokumenten ist deutlich komplexer und
Sanskread-Dokument
<document title="Moby Dick" author="Herman Melville" screenResolution="1.0" screenWidth="320" screenHeight="480" orientation="portrait"> <page number="1">
Now, when this strange cir-cumstance was made known aft,the carpenter was at once com-manded to do Queequeg‘s bid-ding, whatever it might in-clude. There was some hea-thenish, coffin-coloured oldlumber aboard, which, upon along previous voyage, had beencut from the aboriginal grovesof the Lackaday islands, andfrom these dark planks thecoffin was recommended to bemade. No sooner was the car-penter apprised of the order,than taking his rule, he
</page> <page number="2"> … </page></document>
41
fehleranfälliger als die von Word-Dokumenten. Zuerst wird dabei der Inhalt
des PDF-Dokuments eingelesen, der dann anhand der Struktur, die von Ad-
obe für den Aufbau von PDF-Dokumenten festgelegt ist, (Vgl. Document, on-
line) Schritt für Schritt verarbeitet und in Reintext umgewandelt wird.
Reine Text-Dateien sowie der Text, den der Benutzer aus der Zwischenablage
eingefügt hat, müssen nicht mehr geparsed und können direkt weiterverar-
beitet werden.
Nach der Umwandlung in Reintext wird im nächsten Schritt der Text in Zei-
len und Seiten, deren Größe auf die übergebenen Bildschirmdaten optimiert
ist, aufgeteilt. Um die ermittelten Seiten speichern zu können, wird ein tem-
poräres XML-Dokument angelegt, das neben dem umgewandelten Text auch
die vom Client mitgesendeten Informationen über das Dokument beinhaltet.
Um den Text auf die Größe des benutzten Bildschirms anpassen zu können,
wird zuerst die Anzahl an Zeichen je Zeile ermittelt. Dazu wird eine Liste
verwendet, in der die Pixelbreiten aller Unicode-Zeichen bei einer Schriftgrö-
ße von 14 Punkt gespeichert sind. Damit ist es möglich, zu berechnen wie
breit eine Anzahl von Zeichen am Bildschirm ist. Dabei wird der gesamte Text
Zeichen für Zeichen durchgegangen und die zugehörige Zeichenbreite der
jeweiligen Zeichen zusammengezählt. Übersteigt die Summe der Zeichen-
breite die Pixellänge einer Zeile, wird eine neue Zeile begonnen. Um den ge-
ringen Platz des Displays am Endgerät noch effektiver ausnutzen zu können,
wird versucht, das letzte Wort jeder abgeschlossenen Zeile abzutrennen. Das
System zur Silbentrennung basiert dabei auf dem phpHyphenator von Nico
Wenig - einer PHP-Portierung vom Java Script Tool hyphenator (http://code.
google.com/p/hyphenator/). Diese beiden Skripte machen sich den Silbentren-
nungsalgorithmus von Franklin Mark Liang zu Nutze, der auch in Open Of-
fice oder Latex verwendet wird. Das abzutrennende Wort wird dabei mit einer
Liste von Wortsilben verglichen, um die Wortteile zu ermitteln.
Dann wird anhand verschiedener Regeln zur Silbentrennung getrennt. (Vgl.
Hyphenator, online)
Ist die Silbentrennung durchgeführt, geht das System die weiteren Buchsta-
ben durch und generiert Zeile für Zeile. Überschreitet die Anzahl der Zeilen
die maximale Anzahl je Seite, wird eine neue Page-Node im XML-Dokument
angelegt und mit dem Seiteninhalt abgespeichert. Die Anzahl der Zeichen je
Seite wird ermittelt, indem die Bildschirmhöhe durch die Summe aus Schrift-
größe und Zeilenabstand am Endgerät dividiert und abgerundet wird. Damit
dieser Wert, unabhängig von Displaygröße und Auflösung des Endgeräts kor-
rekt berechnet werden kann, macht es sich das System zu Nutze, dass es für
Android eine Schriftgrößeneinheit gibt, die auf allen Bildschirmen die gleiche
Größe aufweist. Das bedeutet, dass ein Text mit einer Größe von 14pt bei ei-
nem Display mit Standardauflösung genau diesen 14pt entspricht. Wird aber
ein Display mit höherer Auflösung verwendet, wird die Schrift in der glei-
chen, realen Größe wie am Standarddisplay angezeigt und ist damit in Punkte
umgerechnet größer als die eigentlich eingestellten 14pt. Damit muss bei der
Berechnung von Zeilen- und Seitenlänge nur das Auflösungsverhältnis zum
Standarddisplay mit einberechnet werden, um verschiedene Bildschirmtypen
zu unterstützen.Nachdem alle Zeichen des Textes durchlaufen und in Zeile
und Seite eingeteilt sind, wird das Sanskread-Dokument mit gZip kompri-
miert an den Client zurückgeschickt.
Der Client ist
für Android-Systeme ab der Version 1.6 ausgelegt und wurde mit der Android
SDK für Eclipse. in der Programmiersprache Java umgesetzt. Die gesamte
Clientanwendung ist objektorientiert designed und umgesetzt. Objektori-
entierung steht dabei für ein Software-Entwicklungs-Konzept, das versucht,
alle das Programm betreffenden realen Vorgänge und die daran Beteiligten,
43
Schritt für Schritt in ein Softwarekonzept umzulegen. Daraus ergeben sich
in sich geschlossene Funktionseinheiten, die sogenannten Klassen. Die Ent-
scheidung, einen objektorientierten Ansatz zu wählen, schlug sich zwar in
einer deutlich höheren Entwicklungszeit nieder, stellt aber auch sicher, dass
der Code gleichförmig aufgebaut und leichter nachvollziehbar ist. Ein wei-
terer Vorteil ist, dass durch die einheitliche Codestruktur Erweiterung und
Adaptierung der Applikation einfacher möglich sind. Dadurch wird es für ei-
nen Dritten leichter, sich in den Code einzulesen und -denken, und es wird
einfacher, neue Funktionalitäten oder gänzlich neue Module hinzuzufügen.
Einzelne Module können ausgegliedert, als eigenständige Applikationen wei-
terverwendet oder in neue Applikationen eingebunden werden.
Die Klassen sind nach dem 3-Schichten-Modell aufgebaut. Dieses Modell be-
steht aus den Schichten Grafische Benutzer Oberfläche (Graphical User Inter-
face Layer), Geschäftsschicht (Businesslayer) und Datenschicht (Data Access
Layer). Jede dieser drei Schichten ist selbstständig aufgebaut, agiert eigenstän-
dig, kann aber mit Komponenten anderer Schichten kommunizieren. (Vgl.
Balzert, Lehrbuch, 371f) Durch den Einsatz dieses Modells kann sehr schnell
und einfach auf geänderte Anforderungen reagiert werden. Sollte Sanskread
einmal für andere Endgeräte verfügbar gemacht werden, die auf einem an-
deren grafischen Konzept basieren, so muss nicht die gesamte Applikation
neu gestaltet werden. Die Geschäfts- und die Datenschicht können erhalten
bleiben, nur die Benutzeroberfläche muss neu adaptiert werden.
Ein Android Projekt
besteht grundsätzlich aus vier verschiedenen Ordnern: assets, gen, res, src.
Der src-Ordner, src steht für source, also Quellcode, verwaltet alle Java-Datei-
en, die den Quellcode der Applikation bilden. Von Android generierte Dateien
und Klassen, die zum Beispiel Informationen über die Dateien im Ressources
Ordner beinhalten, werden im gen-Ordner abgelegt. Im assets-Ordner wer-
den Grafiken und andere Dateien gespeichert, die während der Kompilierung
nicht verändert werden sollen. (Vgl. Developing, online) Der res-Ordner ist der
sogenannte Ressourcen-Ordner. In ihm befinden sich alle in XML erstellten
Oberflächen, Bilder und Daten. (Vgl. Application, online) Der res-Ordner ist in
sich wieder in Unterordner gegliedert: anim, color, layout, menu, raw, values,
drawable. (Vgl. Resource, Types) Anim beinhaltet XML-Files, die als Grundlage
für Animationen, wie zum Beispiel Ein-/Ausblenden von Fenstern oder Fa-
den zwischen zwei Bildern dienen. (Vgl. Animation, online)
Im Ordner color können XML-Dateien hinzugefügt werden, die Definitionen
von Grundfarben beinhalten. So können die Farben einer Applikation an ei-
ner Stelle gesammelt werden und müssen bei Bedarf nur einmal geändert
werden. Neben einfachen Farbdefinitionen können hier auch sogenannte Co-
lor State Lists eingefügt werden. Diese Listen beinhalten Farbdefinitionen für
die verschiedenen Status, die das jeweilige Steuerelement einnehmen kann
(ausgewählt, gedrückt, deaktiviert,...). In beiden Fällen sind Farben als Grup-
pen von Hexadezimalwerten in der Reihenfolge Alpha-Werte, rot, grün, blau
anzugeben. (Vgl. Color, online)
Im layout-Ordner werden die in XML verfassten Definitionen der unter-
schiedlichen Bildschirmseiten gespeichert. (Vgl. Layout, online) Der Ordner
layout kann zweigeteilt werden in einen Standard layout-Ordner und einen
Ordner, der layout-land benannt wird. In beiden werden Layout-Definitionen
mit denselben Namen angelegt, die sich auch auf die gleiche Bildschirmseite
beziehen. Im ersteren sind die Layouts für hochformatige Anzeigen, im zwei-
ten für querformatige Anzeigen optimiert. Je nach Haltung des Endgeräts
wählt Android automatisch den richtigen Ordner für die Anzeige aus. Wird
eine Bildschirmseite nur einmal definiert, wird für beide Ausrichtungen die-
selbe Datei verwendet. (Vgl. Application, online)
45
Die Definitionen von Menüs werden als XML im Ordner menu abgelegt. An-
droid bietet Unterstützung für zwei Menütypen: Options- und Kontextmenü.
Das Optionsmenü wird für eine Bildschirmseite aufgebaut und standardmä-
ßig über Drücken des Menu-Buttons am Endgerät aufgerufen. Es beinhal-
tet meist grundsätzliche Funktionen wie Einstellungen, Hilfe, Beenden und
weitere programmspezifische Menüpunkte. Kontextmenüs sind mit einzel-
nen Elementen einer Bildschirmseite verbunden und können durch längeres
Drücken aktiviert werden. Im Gegensatz zu Optionsmenüs kann eine Bild-
schirmseite mehrere Kontextmenüs besitzen, die mit Steuerelementen der
Seite verbunden sind.
Kontextmenüs sind rein textuell aufgebaut, für Optionsmenüs können Icons
verwendet werden, die entweder direkt von Android übernommen oder selbst
erstellt werden können. (Vgl. Becker, Android, 71–77)
Der raw-Ordner hat eine ähnliche Funktion wie der assets-Ordner. Hier kön-
nen Dateien beliebiger Formate gespeichert werden. Alle in diesem Ordner
befindlichen Elemente werden bei der Kompilierung des Programms weder
komprimiert noch anderweitig bearbeitet. Dadurch wird die Größe des Pro-
gramms durch Dateien im raw-Ordner direkt vergrößert. Ein weiterer Nach-
teil ist, dass die Dateien nicht verschlüsselt werden und jeder, der das fertige
Programm entpackt, diese öffnen kann. (Vgl. Becker, Android 56f)
Der Ordner values beinhaltet XML-Dateien, die Werte wie Texte, Zahlen, Lis-
ten oder auch Farben beinhalten können. Dieser Ordner ist für die Mehrspra-
chigkeit des Programms sehr wichtig. (Vgl. Providing, online)
Bilder, die während der Laufzeit für Hintergründe, Design von Steuerelemen-
ten oder als Piktogramme verwendet werden, werden im Ordner drawable ge-
speichert. Android kann Dateien im jpg, png, gif und im Nine-Patch Format
behandeln. Nine-Patch ist ein spezielles Format, bei dem definiert werden
Abb. 11: »Datenbankmodell«
Datenbankmodell
LastDocument_id INTEGER PNdocumentID INTEGER FlastChangedAt TEXT N
Bookmark
documentID INTEGER FpageNumber INTEGER NchangedAt TEXT N
_id INTEGER PNA
Document_id INTEGER PNAtitle TEXT Nauthor TEXT
filePath TEXT NoptimizedForPortrait INTEGER NpageCount INTEGER N
47
kann, welche Teile des Bildes skaliert / gestreckt und welche in der Original-
größe beibehalten werden sollen. Damit können zum Beispiel Schaltflächen
mit abgerundeten Kanten unabhängig von ihrer späteren Größe, aus einer
einzigen Nine-Patch-Datei erzeugt werden. (Vgl. Becker, Android 52f)
Im Gegensatz zu Dateien im raw-Ordern oder im assets-Ordner werden Da-
teien im drawable-Ordner bei der Kompilierung komprimiert und direkt ins
Programm eingebunden. Das hilft die Größe der fertigen Applikation zu ver-
ringern, ist aber nicht immer ganz unproblematisch. Speziell Verläufe und
Transparenzen können nach der Komprimierung unsauber erscheinen. Auch
die Farbtreue der Komprimierung lässt zum Teil zu wünschen übrig. (Vgl.
PNG, online) Da die erstellte Applikation auf unterschiedlichsten Endgeräten
mit unterschiedlichen Bildschirmgrößen und -auflösungen installiert werden
kann, kann der drawable-Ordner, ähnlich wie der layout-Ordner, in unter-
schiedliche Ordner für unterschiedliche Hardwarevoraussetzungen unterteilt
werden. (Vgl. Providing, online)
Datenhaltung
Bei Sanskread fallen prinzipiell zwei Typen von Daten an, die am Endgerät
des Benutzers gespeichert werden müssen. Auf der einen Seite das XML-
Dokument, das vom Server als Ergebnis der Umwandlung zurückgeschickt
wird. Auf der anderen Seite werden Informationen des Dokuments wie Titel,
Autor, Speicherort, Anzahl der Seiten, letzte Leseposition festgehalten. Um
Daten speichern zu können, bietet Android eine Schnittstelle zu SQLLite, ei-
nem relationalen Datenbanksystem, das eine abgespeckte Version von SQL
darstellt. Der Vorteil von SQLLite gegenüber SQL ist, dass es ohne eigenen
Server auskommt. Die Datenbanken werden einfach als Dateien gespeichert.
(Vgl. About, online)
Das XML-Dokument wird aber nicht in der Datenbank, sondern im Speicher
des Endgeräts abgelegt, um die Datenbank nicht durch zu große Datenmen-
gen zu verlangsamen. Die Sanskread-Dokumente bleiben damit auch leichter
für den Benutzer verwaltbar und können auf andere Geräte kopiert oder ge-
sichert werden. Da die Dokumente als XML aufgebaut sind, ist es auch mög-
lich, sie ohne Hilfsmittel zu lesen oder neue Applikationen zu entwickeln, die
das XML auslesen können.
Durch die unterschiedlichen, weltweit tätigen
Hardwarehersteller, die Android für ihre Systeme verwenden, muss eine brei-
te Benutzerschicht mit unterschiedlichsten Sprachen bedient werden. Die Lö-
sung, die Android dafür bietet, ist simple und leicht umzusetzen. Dazu kann
im res-Ordner ein values Folder für jede Sprache angelegt werden. In jedem
dieser Ordner wird eine values.xml angelegt. In dieser Datei können Texttei-
le geschrieben werden, die durch einen eindeutigen Namen definiert sind.
Überall dort, wo der Text in verschiedenen Sprachen angezeigt werden soll,
wird nicht direkt der Text eingegeben, sondern der Name des betreffenden
Textes in der values-Datei. Android wählt dann automatisch anhand der am
Endgerät eingestellten Sprache aus, welches values.xml aus welchem Ordner
verwendet wird. Dadurch ist es auch möglich, die Sprachunterstützung ohne
Umbauten am Quellcode einfach zu erweitern.
Zur Gestaltung von Oberflächen
bietet Android eine gute Auswahl an Standardkomponenten wie Buttons, Ein-
gabefeldern und Auswahlboxen. Dazu kommen noch Spinner, Fortschrittsan-
zeigen, Dialog- und Benachrichtigungsboxen. Die einzelnen Komponenten
werden unter Android als Views bezeichnet. Diese Views können beliebig
49
kombiniert und verschachtelt werden, um die gewünschte Oberfläche zu er-
halten. Neben den Steuerelementen gibt es weiters noch Layoutkomponen-
ten, denen keine direkte Funktionalität zu Grunde liegt. Sie dienen rein dazu,
die Elemente am Bildschirm anordnen zu können. Jede Oberfläche besteht
aus zwei Teilen. Auf der einen Seite die Informationen über die Views, die
in XML abgefasst werden, auf der anderen eine Java-Klasse, die mit der View
verbunden ist und auf Eingaben des Benutzers reagiert. Sie bildet die Ge-
schäftslogik hinter der Oberfläche. (Vgl. Becker 40– 44)
Das Aussehen der Komponenten, wie Hintergrundfarbe, -grafik, Schrift-
farbe, -schnitt, -größe, kann direkt in das Viewer XML geschrieben oder in
ein eigenes styles.xml ausgelagert werden. Dort können grafische Stile für
Komponenten definiert werden, die dann den Views zugewiesen werden. Das
prinzipielle Konzept dahinter erinnert stark an Cascading Style Sheet, und
ähnlich einfach ist es sich hineinzudenken. Neben den Styles gibt es noch die
Möglichkeit Themes anzulegen. Mit Themes kann neben dem Erscheinungs-
bild der Views auch das prinzipielle Erscheinungsbild kompletter Bildschirm-
seiten, wie zum Beispiel Vorder-, Hintergrundfarbe, Titelleiste eingestellt
werden. Daneben lassen sich auch Grundlayouts für einzelne Steuerelemente
definieren. Dazu wird das Element mit einer Style-Klasse verbunden. Dieser
Darstellungsstil wird dann automatisch auf dieses Element angewandt. (Vgl.
Becker, Android, 88–90)
Um jetzt eine neue Bildschirmseite (View) in Adroid zu kreieren, beginnt
man damit, das grundlegende Layout und alle Komponenten im View-XML
anzulegen und aneinander auszurichten. Umso flexibler und umso relativer
die Komponenten zueinander positioniert sind, umso besser wird das Ergeb-
nis, wenn die Views für ein Endgerät mit unterschiedlicher Bildschirmgröße
und -auflöung skaliert werden müssen. Ist das Layout so aufgebaut, dass es
gut zu skalieren ist, ist es meist auch nicht nötig, extra Views für Hoch- und
Querformat aufzubauen. (Vgl. Becker, Android 31–33) Im nächsten Schritt wer-
den nun die Styles angelegt und mit den Steuerelementen der neuen Views
verbunden. Ist die grafische Oberfläche der neuen Bildschirmseite erstellt,
folgt die eigentliche Programmierung der Funktionalität. In einer Javascript-
Klasse, die beim Instanzieren eine Instanz der View erstellt, kann nun auf
Benutzereingaben reagiert werden.
Die Grundfarben von Sanskread
sind blau (RGB: 33 / 60 / 90) und weiß (RGB: 239 / 243 /239). Der Hinter-
grund ist in blau gehalten, Text und Grafiken basieren auf weiß. Das ergibt
laut der Formel eine Helligkeit für den Hintergrund von 55 und für den Text
255. Die Differenz liegt damit mit über 186 deutlich höher als die empfohle-
ne von 125. Auch der Farbkontrast liegt mit 721 über den empfohlenen 500.
Der Text ist negativ gesetzt, um die Bildschirmhelligkeit möglichst niedrig
zu halten Dadurch soll der Akkuverbrauch des Endgeräts auf ein Minimum
gehalten werden, da die Displaybeleuchtung am meisten Energie verbraucht.
(Vgl. Riegler, Gingerbread, online)
Bei der Gestaltung musste besonders Rücksicht darauf genommen werden,
dass alle Elemente mit denen der Benutzer über den Touch-Screen interagie-
ren soll, eine entsprechende Größe aufweisen und dem Benutzer auch gra-
fisch Feedback geben. Dazu mussten für alle Schaltflächen die unterschiedli-
chen Modi als eigene Bilder erstellt werden.
Eines der größten Mankos in der Arbeit mit Android ist, dass sich Standard-
komponenten teilweise nur sehr aufwendig mit eigenem Design versehen
lassen. Gerade bei Dialogfeldern und Popup-Info-Boxen war es besonders
schwierig, sie an das Grunddesign von Sanskread anzupassen. Beide Elemen-
te mussten neu programmiert und deren grafischer Aufbau neu gezeichnet
werden. Dabei wurde versucht, von der Grundstruktur her möglichst nahe an
der Standardkomponente von Android zu bleiben, um den Benutzer nicht zu
sehr zu verwirren.
Insgesamt wurde versucht, der Applikation eine eigene grafische Identität zu
verleihen, die sich aber nicht zu stark vom Grundkonzept der Android-Ober-
flächen unterscheidet.
Quellenverzeichnis
About SQLite, http://www.sqlite.org/about.html, zuletzt aufgerufen am 2. 1. 2011
Alliance Members, http://www.openhandsetalliance.com/oha_members.html, zuletzt aufgerufen am 12. 1. 2011
Android (operating system), http://en.wikipedia.org/wiki/Android_(operating_system), zuletzt aufgerufen am 10. 1. 2011
Android Market, http://de.wikipedia.org/wiki/Android_Market, zuletzt aufgerufen am 19. 1. 2011
Animation Resource, http://developer.android.com/guide/topics/resources/animation-resource.html, zuletzt aufgerufen am 5. 1. 2011
App Store, http://de.wikipedia.org/wiki/App_Store, zuletzt aufgerufen am 15. 1. 2011
Apple Leads Smartphone Race, while Android Attracts Most Recent Customers, http://blog.nielsen.com/nielsenwire/online_mobile/apple-leads-smartphone-race-while-android-attracts-most-recent-customers/, zuletzt aufgerufen am 16. 1. 2011
Application Resources, http://developer.android.com/guide/topics/resources/index.html, zuletzt aufgerufen am 5. 1. 2011
Balzert, Heide: Lehrbuch der Objektmodellierung, Heidelberg: Spektrum, 1999
Becker, Arno / Pant, Marcus: Android 2, Grundlagen der Programmierung, Heidelberg: dpunkt.verlag, 2010
Color State List Resource, http://developer.android.com/guide/topics/resources/color-list-resource.html, zuletzt aufgerufen am 5. 1. 2011
Developing In Eclipse, with ADT, http://developer.android.com/guide/developing/eclipse-adt.html, zuletzt aufgerufen am 13. 1. 2011
Devices, http://android-devices.net/, zuletzt eingesehen am 18. 1. 2011
Document management — Portable document format — Part 1: PDF 1.7, http://www.adobe.com/content/dam/Adobe/en/devnet/acrobat/pdfs/PDF32000_2008.pdf, zuletzt aufgerufen am 15. 1. 2011
Ducrohet, Xavier: Android 2.3 Platform and Updated SDK Tools, http://android-developers.blogspot.com/2010/12/android-23-platform-and-updated-sdk.html, zuletzt aufgerufen am 18. 1. 2011
Elgin, Ben: Google Buys Android for Its Mobile Arsenal, http://www.businessweek.com/technology/content/aug2005/tc20050817_0949_tc024.htm, zuletzt aufgerufen am 5. 1. 2011
Hyphenator, http://code.google.com/p/hyphenator/, zuletzt aufgerufen am 5. 1. 2011
Industry Leaders Announce Open Platform for Mobile Devices, http://www.openhandsetalliance.com/press_110507.html, zuletzt aufgerufen am 12. 1. 2011
iOS Developer Program, http://developer.apple.com/programs/ios/, zuletzt aufgerufen am 18. 1. 2011
Layout Resource, http://developer.android.com/guide/topics/resources/layout-resource.html, zuletzt aufgerufen am 12. 1. 2011
Morrill, Dan: Announcing the Android 1.0 SDK, release 1, http://android-developers.blogspot.com/2008/09/announcing-android-10-sdk-release-1.html, zuletzt aufgerufen am 7. 1. 2011
Phone Gallery, http://www.google.com/phone/#, zuletzt aufgerufen am 16. 1. 2011
PNG compression in Android… (You have got to be kidding), http://www.gotow.net/creative/wordpress/?p=79, zuletzt aufgerufen am 5. 1. 2011
Providing Resources, http://developer.android.com/guide/topics/resources/providing-resources.html, zuletzt aufgerufen am 5. 1. 2011
Resource Types, http://developer.android.com/guide/topics/resources/available-resources.html, zuletzt aufgerufen am 5. 1. 2011
Riegler, Birgit: Gingerbread hebt Android auf die nächste Stufe, http://derstandard.at/1291455019870/Feature-Uebersicht-Gingerbread-hebt-Android-auf-die-naechste-Stufe, zuletzt aufgerufen am 12. 12. 2010
Roth, Daniel: Google‘s Open Source Android OS Will Free the Wireless Web, http://www.wired.com/techbiz/media/magazine/16-07/ff_android?currentPage=all, zuletzt eingesehen am 12. 1. 2011
Abbildungsverzeichnis
Abbildung 1: »Schematischer Aufbau von Sanskread«, selbest erstellt 16
Abbildung 2: »Android 1.6, Donut«, http://www.android.com/media/wallpaper/eps/donut_2009.ps 18
Abbildung 3: »Android 2.3, Gingerbread« 18
Abbildung 4: »Android 1.5, Cupcake«, http://www.android.com/media/wallpaper/eps/cupcake_2009.ps 18
Abbildung 5: »Android 2.1, Eclaire«, http://www.android.com/media/wallpaper/eps/eclair_2009.ps 18
Abbildung 6: »Der Startbildschirm«, selbst erstellt 24
Abbildung 7: »Neues Dokument«, selbst erstellt 26
Abbildung 8: »Text aus der Zwischenablage«, selbst erstellt 28
Abbildung 9: »Buchmodus«, selbst erstellt 30
Abbildung 10: »RSVP-Modus«, selbst erstellt 32
Abbildung 11: »Datenbankmodell«, selbst erstellt 46