konkretisiert

Wie sichs liest

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

Konzept

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)

Ablauf

Abb. 6: »Der Startbildschirm«

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.

Abb. 7: »Neues Dokument«

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

Abb. 8: »Text aus der Zwischenablage«

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.

Abb. 9: »Buchmodus«

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.

Abb. 10: »RSVP-Modus«

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.

3737

Umsetzung

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.

Anhang

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