Issuu on Google+

Wie sichs liest konkretisiert


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 Bakkalaureatsarbeit 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 concerns 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 verschieden 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


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 Rechenleistung der Geräte gestalten das Lesen unkomfortabel. Vor allem Dokumente im weit verbreiteten PDF-Format sind nur sehr schwer lesbar, da die einzelnen 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) einzulesen. Daher sind die Hauptgesichtspunkte die Unterstützung üblicher Dateiformate und die schnelle Darstellung der Dokumente. Die Verarbeitung der Dateien soll auch unterwegs möglich sein und ressourcenschonend ausgeführt werden können. Neben dem normalen Lesemodus, bei dem der Benutzer 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 worden, stellen aber meist nur Dokumente in speziellen, proprietären Formaten dar. Damit sind sie unbrauchbar um externen Dateien schnell aufzubereiten.

15


Schematischer Aufbau

Internet 4 2

3 1

1

Die ausgewählte Datei wird an den Server geschickt.

2

Der Server empfängt die Datei und wandelt sie in ein Sanskread-Dokument um

3

Das Dokument wird an das Smartphone zurückgesandt.

4

Das Smartphone speichert das Dokument und stellt es dar.

Abb. 1: »Schematischer Aufbau von Sanskread«


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 Dokument 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 umgewandelt, 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 einzelnen 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 Programmiersprachen C & C++ geschrieben, das User-Interface sowie Applikationen

17


Android-Versionen

Abb. 2: »Android 1.6, Donut«

Abb. 3: »Android 2.3, Gingerbread«

Abb. 4: »Android 1.5, Cupcake«

Abb. 5: »Android 2.1, Eclaire«


können in Java implementiert werden. (Vgl. Android, online) (Vgl. Becker, Android, v) Android wurde von der 2003 gegründeten Firma Android Inc. entwickelt. 2005 kaufte Google das damals erst 22 Monate alte Startup-Unternehmen. (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, Google, online) Anfängliche Spekulationen, Google würde sich durch den Kauf von Android mit einem eigenen gPhone in direkter Konkurrenz zu Apples iPhone positionieren, wurden mit der Gründung der Open Handset Alliance (OHA) zerstreut. (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 Betriebssysteme 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 Mitglieder 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 Öffentlichkeit. (Vgl. Morrill, Announcing, online). Mittlerweile ist Android in der Version 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)

19


Da Google selbst keine Hardware für Mobiltelefone fertigt, entwickeln Partner aus der OHA Geräte für Android. Dabei haben Unternehmen wie HTC, Samsung, Sony Ericsson oder Motorala in den letzen Jahren über 70 verschiedene 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, Tablets, Home Entertainment Geräte setzen auf die offene Plattform. (Vgl, Devices, online) Ähnlich wie Apple oder Samsung bietet Google für Android einen eigenen Market, wo Applikationen online gestellt und heruntergeladen werden können. Im Gegensatz zu Apple, wo Entwickler jährlich 100 USD für die Mitgliedschaft 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 denen über 60% kostenfrei genutzt werden können. Google verzichtet weiters auf einen Einreichungsprozess wie bei Apples Store, wo das Programm inhaltlich 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«


Der Entwicklungsprozess von Sanskread wurde mit der Erstellung von Wireframes der späteren Benutzeroberfläche begonnen. Dadurch konnten einerseits von Anfang an der spätere Screenaufbau und die Reihenfolge der Screens entwickelt werden, andererseits dienten die Wireframes dazu, die grundsätzlichen Use-Cases des Programms herauszufiltern und zu strukturieren. Daraus ergaben sich folgende 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 schnellen Zugriff auf die Grundfunktionen des Programms ermöglichen. Dazu zählen: das zuletzt gelesene Dokument wiederherstellen, die Sanskread-Dokument-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 angezeigt wird. Es bietet drei Grundfunktionen, die im gesamten Programm immer erreichbar sind: Hilfe, Einstellungen und Beenden.

25


Abb. 7: »Neues Dokument«


Neues Dokument erstellen Nach dem Auswählen des Buttons am Hauptbildschirm erscheint ein Dateibrowser, der dem Benutzer die Möglichkeit gibt, ein Dokument, das von Sanskread 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 Ebene 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 Dokument 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 verwendet werden, nur ohne automatische Silbentrennung. Neben dem Dateinamen 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 langen 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-ServerApplikation 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 aufgenommen. 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-Dokumente für hoch- oder querformatige Anzeigen optimiert. Das Dokument

27


Abb. 8: »Text aus der Zwischenablage«


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 kopierte Text wird gleich wie ausgewählte Dateien in ein Sanskread-Dokument umgewandelt 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 wurde. 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 SanskreadDokumenten, zeigt eine Fortschrittsanzeige den aktuell laufenden Verarbeitungsschritt an. Nachdem der Server seine Arbeit beendet hat, wird das Sanskread-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.

29


Abb. 9: »Buchmodus«


Beim Öffnen eines Dokuments im Buchmodus wird die Android eigene Statuszeile am oberen Ende des Bildschirms versteckt, um den Benutzer nicht vom Text abzulenken und ihn durch womöglich erscheinende Statusmeldungen nicht in seinem Lesefluss zu stören. Bis auf eine kleine Fortschrittsanzeige am unteren Rand, die dem Leser die aktuelle sowie die Seitenanzahl des Dokuments anzeigt, nimmt der Text den Rest des Bildschirms ein. Die Fortschrittsanzeige soll dem Benutzer helfen, nicht die Orientierung zu verlieren und ihm ein kleines »Erfolgserlebnis« bereiten, wenn er eine Seite fertig gelesen 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ängeres 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 aufgerufen 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 Benutzer über einen sogenannten Toast, einen kleinen Popup-Dialog, hingewiesen. Über das Optionsmenü sind neben den Standardoptionen noch weitere Funktionen 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.

31


Abb. 10: »RSVP-Modus«


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 Regressionssakkade, 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örtern pro Minute eingestellt ist. Die Geschwindigkeit kann aber auf einen beliebigen 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. Findet der Reader im Text einen Punkt, dem ein Großbuchstabe folgt, wird eine kurze Pause eingelegt, um das Ende eines Satzes zu markieren. Bei Beistrichen 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 gesprungen 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.

33


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 durchsucht werden. Neben dem eingegebenen Titel wird noch angezeigt, für welche 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-Dokumente mit kurzer Information über Länge und aktuelle Leseposition. Durch Drücken wird das gewählte Dokument an der aktuellen Leseposition im gewählten Standard Lesemodus geöffnet. Über das Kontextmenü kann das Dokument 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 zurückgesetzt.


Umsetzung 37


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 werden 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 Darstellung am Client zu optimieren. Anhand des Dateityps werden unterschiedliche Verfahren angewandt, um den Text zu extrahieren. Bei Word-Dokumenten wird mit einem Skript, basierend auf Open Source Code, (http://www.webluncher.com/arifinblog/archives/ tag/parse-word) gearbeitet. Dabei wird im ersten Schritt das Dokument eingelesen, 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 Zeichen, die ungleich x00 (NUL) sind, temporär gespeichert. Sind alle Zeichen umgespeichert, werden noch die Steuerzeichen mit einer Regexabfrage ersetzt 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

39


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 circumstance was made known aft, the carpenter was at once commanded to do Queequegâ&#x20AC;&#x2DC;s bidding, whatever it might include. There was some heathenish, coffin-coloured old lumber aboard, which, upon a long previous voyage, had been cut from the aboriginal groves of the Lackaday islands, and from these dark planks the coffin was recommended to be made. No sooner was the carpenter apprised of the order, than taking his rule, he </page> <page number="2"> â&#x20AC;Ś </page> </document>


fehleranfälliger als die von Word-Dokumenten. Zuerst wird dabei der Inhalt des PDF-Dokuments eingelesen, der dann anhand der Struktur, die von Adobe für den Aufbau von PDF-Dokumenten festgelegt ist, (Vgl. Document, online) 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 weiterverarbeitet werden. Nach der Umwandlung in Reintext wird im nächsten Schritt der Text in Zeilen und Seiten, deren Größe auf die übergebenen Bildschirmdaten optimiert ist, aufgeteilt. Um die ermittelten Seiten speichern zu können, wird ein temporä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 Zeichenbreite die Pixellänge einer Zeile, wird eine neue Zeile begonnen. Um den geringen 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 Silbentrennungsalgorithmus von Franklin Mark Liang zu Nutze, der auch in Open Office oder Latex verwendet wird. Das abzutrennende Wort wird dabei mit einer Liste von Wortsilben verglichen, um die Wortteile zu ermitteln.

41


Dann wird anhand verschiedener Regeln zur Silbentrennung getrennt. (Vgl. Hyphenator, online) Ist die Silbentrennung durchgeführt, geht das System die weiteren Buchstaben 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 Schriftgröße und Zeilenabstand am Endgerät dividiert und abgerundet wird. Damit dieser Wert, unabhängig von Displaygröße und Auflösung des Endgeräts korrekt 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 einem Display mit Standardauflösung genau diesen 14pt entspricht. Wird aber ein Display mit höherer Auflösung verwendet, wird die Schrift in der gleichen, 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 komprimiert 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. Objektorientierung steht dabei für ein Software-Entwicklungs-Konzept, das versucht, alle das Programm betreffenden realen Vorgänge und die daran Beteiligten,


Schritt für Schritt in ein Softwarekonzept umzulegen. Daraus ergeben sich in sich geschlossene Funktionseinheiten, die sogenannten Klassen. Die Entscheidung, 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 weiterer Vorteil ist, dass durch die einheitliche Codestruktur Erweiterung und Adaptierung der Applikation einfacher möglich sind. Dadurch wird es für einen 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 weiterverwendet oder in neue Applikationen eingebunden werden. Die Klassen sind nach dem 3-Schichten-Modell aufgebaut. Dieses Modell besteht aus den Schichten Grafische Benutzer Oberfläche (Graphical User Interface Layer), Geschäftsschicht (Businesslayer) und Datenschicht (Data Access Layer). Jede dieser drei Schichten ist selbstständig aufgebaut, agiert eigenständig, 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 anderen 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-Dateien, die den Quellcode der Applikation bilden. Von Android generierte Dateien und Klassen, die zum Beispiel Informationen über die Dateien im Ressources

43


Ordner beinhalten, werden im gen-Ordner abgelegt. Im assets-Ordner werden 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 Faden 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 einer Stelle gesammelt werden und müssen bei Bedarf nur einmal geändert werden. Neben einfachen Farbdefinitionen können hier auch sogenannte Color 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 Gruppen 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 unterschiedlichen 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 zweiten 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 dieselbe Datei verwendet. (Vgl. Application, online)


Die Definitionen von Menüs werden als XML im Ordner menu abgelegt. Android 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 beinhaltet meist grundsätzliche Funktionen wie Einstellungen, Hilfe, Beenden und weitere programmspezifische Menüpunkte. Kontextmenüs sind mit einzelnen Elementen einer Bildschirmseite verbunden und können durch längeres Drücken aktiviert werden. Im Gegensatz zu Optionsmenüs kann eine Bildschirmseite 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önnen 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 Programms durch Dateien im raw-Ordner direkt vergrößert. Ein weiterer Nachteil 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, Listen oder auch Farben beinhalten können. Dieser Ordner ist für die Mehrsprachigkeit des Programms sehr wichtig. (Vgl. Providing, online) Bilder, die während der Laufzeit für Hintergründe, Design von Steuerelementen oder als Piktogramme verwendet werden, werden im Ordner drawable gespeichert. Android kann Dateien im jpg, png, gif und im Nine-Patch Format behandeln. Nine-Patch ist ein spezielles Format, bei dem definiert werden

45


Datenbankmodell

Document

Bookmark _id INTEGER

A N P

documentID INTEGER

F

pageNumber INTEGER

N

changedAt TEXT

N

_id INTEGER title TEXT

A N P N

author TEXT filePath TEXT

N

optimizedForPortrait INTEGER

N

pageCount INTEGER

N

LastDocument _id INTEGER

N P

documentID INTEGER

F

lastChangedAt TEXT

N

Abb. 11: »Datenbankmodell«


kann, welche Teile des Bildes skaliert / gestreckt und welche in der Originalgröß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 Dateien im drawable-Ordner bei der Kompilierung komprimiert und direkt ins Programm eingebunden. Das hilft die Größe der fertigen Applikation zu verringern, 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 unterschiedliche 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 XMLDokument, 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, einem 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)

47


Das XML-Dokument wird aber nicht in der Datenbank, sondern im Speicher des Endgeräts abgelegt, um die Datenbank nicht durch zu große Datenmengen zu verlangsamen. Die Sanskread-Dokumente bleiben damit auch leichter für den Benutzer verwaltbar und können auf andere Geräte kopiert oder gesichert werden. Da die Dokumente als XML aufgebaut sind, ist es auch möglich, 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 breite 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 Textteile 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, Eingabefeldern und Auswahlboxen. Dazu kommen noch Spinner, Fortschrittsanzeigen, Dialog- und Benachrichtigungsboxen. Die einzelnen Komponenten werden unter Android als Views bezeichnet. Diese Views können beliebig


kombiniert und verschachtelt werden, um die gewünschte Oberfläche zu erhalten. Neben den Steuerelementen gibt es weiters noch Layoutkomponenten, 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 Geschäftslogik hinter der Oberfläche. (Vgl. Becker 40–­44) Das Aussehen der Komponenten, wie Hintergrundfarbe, -grafik, Schriftfarbe, -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 Erscheinungsbild der Views auch das prinzipielle Erscheinungsbild kompletter Bildschirmseiten, 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 Ergebnis, 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

49


Querformat aufzubauen. (Vgl. Becker, Android 31–33) Im nächsten Schritt werden 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 JavascriptKlasse, 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 Hintergrund 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 empfohlene 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 interagieren soll, eine entsprechende Größe aufweisen und dem Benutzer auch grafisch Feedback geben. Dazu mussten für alle Schaltflächen die unterschiedlichen Modi als eigene Bilder erstellt werden. Eines der größten Mankos in der Arbeit mit Android ist, dass sich Standardkomponenten 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 Elemente 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-Oberflä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/animationresource.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-racewhile-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-listresource.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 â&#x20AC;&#x201D; Portable document format â&#x20AC;&#x201D; 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-platformand-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/layoutresource.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-android10-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â&#x20AC;Ś (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/providingresources.html, zuletzt aufgerufen am 5. 1. 2011 Resource Types, http://developer.android.com/guide/topics/resources/availableresources.html, zuletzt aufgerufen am 5. 1. 2011 Riegler, Birgit: Gingerbread hebt Android auf die nächste Stufe, http://derstandard.at/1291455019870/Feature-Uebersicht-Gingerbread-hebtAndroid-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



Wie sichs liest II