Technische Universität Ilmenau Fakultät für ... - TU Ilmenau

Technische Universität Ilmenau 

Fakultät für Elektrotechnik und Informationstechnik 

Bachelorarbeit 

Nutzung eines Smartphones als Rückkanal für digitalen 

Rundfunk 

vorgelegt von: Florian Schlembach 

eingereicht am: 02. 05. 2011 

geboren am: 

Studiengang: Medientechnologie 

Studienrichtung: Informations- und Kommunikationstechnik 

Matrikelnummer: 

Anfertigung im Fachgebiet: Kommunikationsnetze 

Fakultät für Elektrotechnik und Informationstechnik 

Verantwortlicher Professor: Prof. Dr. rer. nat. habil. Jochen Seitz 

Wissenschaftlicher Betreuer: Dipl.-Ing. Karsten Renhak

Kurzfassung 

Durch den demographischen Wandel und den damit verbundenen sinkenden Geburtenraten 

sowie einer steigenden Lebenserwartung unterliegt Deutschland einem Alterungsprozess. 

Es ist daher wichtig einen erhöhten Fokus auf das Gesundheitswesen, 

speziell die Altenpflege zu legen. Das WEITBLICK-Projekt, in dem die TU Ilmenau 

als einer der Projektpartner fungiert, hat sich zum Ziel gesetzt ein zentralisiertes Assistenzsystem 

zu entwickeln, womit Senioren ihren Alltag leichter meistern können. U. 

a. bietet das Projekt WEITBLICK Vermittlung von Dienstleistungen (Pflege, soziale 

Kontakte, Hobby, Wellness, ...) und Assistenz bei der Wahrnehmung dieser Angebote 

an, welche Gegenstand dieser Bachelorarbeit sind. 

Ziel dieser Bachelorarbeit ist die Nutzung eines Smartphones als Rückkanal für 

herkömmlichen Fernsehrundfunk, da sich Fernsehstandards, wie DVB-RCS/C/T oder 

HbbTV, zum Senden von Daten bisher nicht durchgesetzt haben bzw. nicht umgesetzt 

wurden. Demnach soll das Smartphone über das Internet einen Rückkanal zum 

Fernsehrundfunk bilden, um Buchungsinformationen senden zu können. Die Idee dabei 

ist eine über das Fernsehbild eingeblendete optische Marke mit dem Smartphone abzufotografieren, 

diese zu interpretieren und die Buchung in Form einer Nachricht mit 

einer auf dem Smartphone gespeicherten Nutzer-ID an eine vom WEITBLICK-Projekt 

entwickelte Middleware zu senden. 

Demnach gliedert sich die Arbeit in zwei Teile. Erstens in die Recherche, die Anforderungsanalyse 

und die Wahl einer geeigneten optischen Marke. Zweitens in die 

praktische Umsetzung, die das Dienstbuchungssystem sowohl auf der Client- als auch 

auf der Server-Seite behandelt. 

Im ersten Teil wurde nach Charakterisierung und Kategorisierung von optischen 

Marken eine Anforderungsanalyse für eine geeignete WEITBLICK Marke durchgeführt. 

Die sich daraus ergebenden Codes Code-128, Data Matrix und QR Code wurden 

in einer praktischen Testreihe gegenübergestellt. Die Wahl fiel letztendlich auf den QR 

Code, da sich dieser bzgl. des Leseabstands und des horizontalen Betrachtungswinkels 

am flexibelsten vom Fernsehgerät auslesen lässt. 

Der zweite Teil bezieht sich auf die praktische Umsetzung des Dienstbuchungssystems. 

Als Smartphone Betriebssystem wurde das von Google entwickelte Android OS 

verwendet. Zum Scannen des QR Codes wurde die Android App ZXing Barcode Scanner 

benutzt, die auf der Open-Source ZXing Bildverarbeitungsbibliothek basiert. Die 

buchbaren Dienstleistungen werden auf einem mySQL-Server zentral gespeichert. Die 

Dienstbuchung erfolgt durch das Senden einer Nachricht an eine vom WEITBLICK- 

Projekt verwendete Kommunikations-Middleware namens openMQ. Da Android zur 

Dienstabfrage und -buchung keine externen SQL-Anfragen unterstützt und kein JMS 

Interface implementiert hat, wurde ein Universal Message Service (UMS) und ein 

PHP-Skript zur Server-Seite hinzugefügt. Diese beiden Zwischeninstanzen fungieren 

dabei jeweils als ein RESTful Interface, womit der Android Client mittels einfacher 

HTTP-Nachrichten mit dem Dienstbuchungssystem kommunizieren kann.

Abstract 

Due to demographic change and associated factors like decreasing birthrates and increasing 

life expectancy, germany is subject of an aging process. Therefore, it is important 

to bring health care, especially elderly care, into focus. The WEITBLICK-Project the 

TU Ilmenau is involved in as one of the project partners, has targeted to build up 

a centralized assistence system for making elderlys’ lifes easier. Among other things 

the Project WEITBLICK is providing both the brokering of service offers (health care, 

social contacts, hobbies, wellness, ...) and the assistance for accepting these offers. This 

bachelor thesis is focussing on these subjects. 

The scope of this bachelor thesis is the use of a smartphone as a back channel 

for usual television broadcast because broadcasting standards like DVB-RCS/C/T or 

HbbTV for sending data haven’t been established yet. According to that, the smartphone 

should build a back channel of the television broadcast via internet for being 

able to send booking information. The idea is to scan an optical stamp shown on TV, 

to process it and to perform the booking. This is realized by sending the message 

with an user ID which is saved on the smartphone to a middleware developed for the 

WEITBLICK-Project. 

Thus, the thesis is splitted into two parts. First is transaction of an investigation, the 

requirement analysis and the choice for an appropriate WEITBLICK Code. Second is 

the practical application which envelops the service booking system both on its clientand 

its server-side. 

In the first part a definition and a classification in categories for an optical stamp 

and a further requirement analysis for an appropriate WEITBLICK Code was accomplished. 

The resultant Codes Code-128, Data Matrix and QR Code were compared in 

a practical test series. Finally, the choice was made in favor of the QR Code because 

it is, concerning the distance and the horizontal viewing angle to the TV screen, most 

flexibly readable. 

The second part is about the practical application of the service booking system. 

Android OS was employed as the smartphone operating system which was developed 

by Google. For scanning the QR Code the Android App ZXing Barcode Scanner which 

is based on the open-source ZXing image processing library was used. The bookable 

services are saved centrally on a mySQL-server. The service booking is transacted by 

sending a message to a middleware named openMQ which is used for the WEITBLICK- 

Project. Due to the fact that Android supports no external SQL-requests and that it 

has no JMS interface implemented for the service request and service booking, an 

Universal Message Service (UMS) and a PHP-script were added to the server-side. 

These two intermediate instances are acting each as a RESTful Interface which enables 

the Android client to communicate with the service booking system by just sending 

simple HTTP messages.

Inhaltsverzeichnis i 

Inhaltsverzeichnis 

1 Einführung 1 

2 Aufgabenstellung 2 

3 Diskussion der optischen Marke 4 

3.1 Merkmale einer optischen Marke . . . . . . . . . . . . . . . . . . . . . . 5 

3.1.1 Zeichensätze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 

3.1.2 Informationsdichte und zu codierende Nutzdatenmenge . . . . . 5 

3.1.3 Datensicherheit . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 

3.1.4 Flexibilität . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 

3.1.5 Standardisierung . . . . . . . . . . . . . . . . . . . . . . . . . . 7 

3.2 Anforderungsanalyse für den WEITBLICK Code . . . . . . . . . . . . 7 

3.2.1 Standardisierung . . . . . . . . . . . . . . . . . . . . . . . . . . 8 

3.2.2 Datenmenge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 

3.2.3 Flexibilität . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 

3.2.4 Fazit aus den gegebenen Anforderungen . . . . . . . . . . . . . 10 

3.3 Arten von optischen Marken . . . . . . . . . . . . . . . . . . . . . . . . 11 

3.3.1 Strichcodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 

3.3.2 Stapelcodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 

3.3.3 Matrixcodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 

3.4 Praktischer Vergleich der Codes . . . . . . . . . . . . . . . . . . . . . . 17 

3.4.1 Vergleich der Codes in einer Testreihe . . . . . . . . . . . . . . . 18 

3.4.2 Auswertung der Testreihe und Auswahl der optischen Marke . . 19 

4 Praktische Umsetzung 21 

4.1 Anforderungen an das Dienstbuchungssystem . . . . . . . . . . . . . . 21 

4.2 Struktur des Dienstbuchungssystems . . . . . . . . . . . . . . . . . . . 22 

4.2.1 Client des Dienstbuchungssystems . . . . . . . . . . . . . . . . . 23 

4.2.1.1 Konventionen zur Generierung des QR Codes . . . . . 23 

4.2.1.2 Android als mobiles Betriebssystem . . . . . . . . . . . 23 

4.2.1.3 Fehlende Java-Bibliotheken . . . . . . . . . . . . . . . 24 

4.2.2 Server des Dienstbuchungssystems . . . . . . . . . . . . . . . . . 25 

4.2.2.1 UMS- und openMQ-Server als eigentliches Dienstbuchungssystem 

. . . . . . . . . . . . . . . . . . . . . . . 26 

4.2.2.2 SQL Server als Dienstserver . . . . . . . . . . . . . . . 29 

4.3 Die WEITBLICK CodeScanner App . . . . . . . . . . . . . . . . . . . 30 

4.3.1 Android Grundlagen . . . . . . . . . . . . . . . . . . . . . . . . 31 

Nutzung eines Smartphones als Rückkanal für digitalen Rundfunk Bachelorarbeit Florian Schlembach

Inhaltsverzeichnis ii 

4.3.1.1 Android Manifest . . . . . . . . . . . . . . . . . . . . . 32 

4.3.1.2 Activities . . . . . . . . . . . . . . . . . . . . . . . . . 33 

4.3.1.3 Application Resources . . . . . . . . . . . . . . . . . . 35 

4.3.2 Aufbau der CodeScanner App . . . . . . . . . . . . . . . . . . . 38 

4.3.3 Datenzugriffsklasse DataAccess . . . . . . . . . . . . . . . . . . 40 

4.3.3.1 Methode parseScanresult(...): Parsen der Scan-Ergebnisse 41 

4.3.3.2 Methode requestService(): Anforderung der Dienstinformationen 

. . . . . . . . . . . . . . . . . . . . . . . . 42 

4.3.3.3 Methode sendMessage(...): Buchen des Dienstes . . . . 43 

4.3.4 Main-Activity CodeScanner . . . . . . . . . . . . . . . . . . . . 46 

4.3.4.1 Methode initScanningLayout(): Aufruf der externen ZXing 

Barcode Scanner App . . . . . . . . . . . . . . . . . . 47 

4.3.4.2 Verarbeiten der Scan-Ergebnisse und Erstellen eines 

DataAccess-Objekts . . . . . . . . . . . . . . . . . . . 48 

4.3.4.3 Methode initBookingLayout(): Anzeige der Dienstleistung 

. . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 

4.3.4.4 Methode makeCall(): Verbindung mit einem Ansprechpartner 

. . . . . . . . . . . . . . . . . . . . . . . . . . 52 

4.4 WEITBLICK QR Code-Generator . . . . . . . . . . . . . . . . . . . . 52 

5 Zusammenfassung und Ausblick 54 

A Quellcodes 57 

A.1 mySQL-Server und PHP-Server als Dienstserver . . . . . . . . . . . . . 57 

A.2 Android Manifest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 

A.3 Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 

A.4 Strings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 

A.5 Datenzugriffsklasse DataAccess() . . . . . . . . . . . . . . . . . . . . . 60 

A.6 CodeScanner Activity-Klasse . . . . . . . . . . . . . . . . . . . . . . . . 65 

Literaturverzeichnis 72 

Abbildungsverzeichnis 75 

Tabellenverzeichnis 76 

Abkürzungsverzeichnis 77 

Quellcodeverzeichnis 79 

Thesen zur Bachelorarbeit 80 

Erklärung 81 


1 Einführung 1 

1 Einführung 

Deutschland ist geprägt von einem demographischen Wandel, welcher sich auf die 

Veränderung der Zusammensetzung der Altersstrukturen in der Gesellschaft bezieht. 

Durch sinkende Geburtenraten und eine höhere Lebenserwartung unterliegt Deutschland 

einem Alterungsprozess. Umso wichtiger ist es daher einen erhöhten Fokus auf 

das Gesundheitswesen, speziell auf die Altenpflege, zu legen. Mit zunehmendem Alter 

sinken die geistigen, körperlichen und sozialen Fähigkeiten älterer Menschen. Sie haben 

demzufolge Schwierigkeiten Aktivitäten des Alltags selbstständig zu meistern. Die Kosten 

für die nötige Altenpflege werden zumeist nur für die grundlegenden Aufgabengebiete 

durch gesetzliche Sozialversicherungen abgedeckt. Für weitere Zusatzleistungen, 

die nötig wären, um älteren Menschen die Möglichkeit zu geben ein weitestgehend 

normales Leben zu führen, müssen eigene finanzielle Mittel bzw. eine private Altersvorsorge 

aufgebracht werden. ” Damit besteht Bedarf an kostengünstigen, kommerziell 

verfügbaren, persönlichen und technischen Assistenzangeboten als Dienstleistung für 

den Alltag wie für Notfallsituationen.“ [Pro11] 

Das Projekt WEITBLICK hat sich zum Ziel gesetzt das Leben älterer Menschen 

durch Hinzunahme von technologisch modernen Lösungen zu vereinfachen. Über unterschiedliche 

Kommunikationskanäle sollen kostengünstig persönliche und technische 

Assistenzangebote als Dienstleistung gebucht, aber auch als zentrales Kommunikationssystem 

zum sozialen Austausch zwischen Gleichgesinnten, genutzt werden können. 

Als einer der Punkte für die Funktionalität des Assistenzsystems wird unter [Pro11] 

folgender genannt: 

• Interessen- und befähigungsorientierte Vermittlung von Dienstleistungsangeboten 

(Pflege, soziale Kontakte, Hobby, Wellness, ...) und Assistenz bei der Wahrnehmung 

dieser Angebote 

Gegenstand dieser Bachelorarbeit ist es Dienstleistungsangebote, die über den herkömmlich 

digitalen Fernsehrundfunk empfangen werden, direkt buchen zu können. Da 

Standards wie DVB-RCS/C/T, die einen Fernseh-Rückkanal beschreiben, sich nach 

aktuellem Stand nicht durchgesetzt haben bzw. umgesetzt wurden, ist es nicht so einfach 

möglich vom Fernsehgerät Buchungsinformation zu senden. Das folgende Kapitel 

beschreibt wie durch Nutzung eines Smartphones über das Internet ein Rückkanal zum 

Fernsehrundfunk gebildet wird. 



2 Aufgabenstellung 

Gemäß einer Studie aus dem Jahr 2003 besitzen 95% der Haushalte in Deutschland 

einen Fernsehanschluss [PDK03, S. 97]. Demzufolge ist bereits ein Kommunikationskanal 

geschaffen, der für nahezu jeden erreichbar ist und vor allem wegen seiner Beliebtheit 

präferiert wird. Da der Fernsehrundfunk allerdings nur als unidirektionaler Kommunikationsweg 

fungiert, können Informationen nur empfangen werden. Um empfangene 

Dienstleistungsangebote buchen zu können, könnten demnach keine Informationen 

zur Buchung gesendet werden. 

Ziel dieser Bachelorarbeit ist es, durch Nutzung eines Smartphones 1 einen Rückkanal 

für den Fernsehkanal zu bilden. Abb. 2.1 veranschaulicht eine mögliche Realisierung 

eines solchen Rückkanals: 

Fernsehrundfunk 

TV 

(mit integriertem Receiver) 

Smartphone 

(z.B. iPhone, Android-Phone) 

einlesen interpretieren senden 

Dienstleistung 

mit bestimmter ID 

Abbildung 2.1: Veranschaulichter Ablauf des gebildeten Rückkanals 

anrufen 

Server 

des Dienstanbieters 

persönl. Telefongespräch 

für entspr. Dienstleistung 

Dabei wird eine einmalige ID-Nummer einer Dienstleistung in eine optische Marke 

codiert. Über den Fernsehrundfunk würde diese dann im Anwendungsfall in einer 

Fernsehsendung ausgestrahlt und eingeblendet werden. Nach Abfotografieren der optischen 

Marke mit dem Smartphone, erkennt dieses die optische Marke anhand eines 

Suchmusters, interpretiert diese und zeigt weitere Informationen zum entsprechenden 

Dienstleistungsangebot an. Der Nutzer hat nun zum Einen die Möglichkeit die Buchung 

direkt vorzunehmen und die Anfrage an einen Server des Dienstanbieters zu 

senden. Falls der Nutzer noch Fragen zum angebotenen Dienst hat, soll es zum Anderen 

möglich sein, eine der Dienstleistung entsprechende Telefonnummer anzurufen, 

um sich mit einem persönlichen Ansprechpartner verbinden zu lassen. Aus diesem Usecase 

(engl. Anwendungsfall) ergeben sich entsprechend der Aufgabenstellung folgende 

Teilaufgaben: 

1 Smartphone = fortschrittliches Mobiltelefon mit Computerfunktionalitäten und -konnektivitäten, 

das sich leicht durch Anwendungen (kurz: Apps) von Drittanbietern erweitern lässt[Wik11] 



1. Recherche möglicher Darstellungsformen für die optische Marke 

2. Codierung von Informationen mittels der optischen Marke 

3. Realisierung einer Anwendung auf dem Smartphone zur Erkennung der optischen 

Marke 

4. Übermittlung der Buchungsinformation an einen Server 

5. Anruf einer mitcodierten Telefonnummer 

Damit gliedert sich die Arbeit in zwei Teile: Der erste Teil beschäftigt sich mit der 

Recherche, Charakterisierung und Auswahl einer optischen Marke (Punkt 1 und 2). 

Dahingehend werden zuerst die Merkmale einer optischen Marke definiert. Um eine 

geeignete optische Marke evaluieren zu können, ist eine vorhergehende Anforderungsanalyse 

notwendig. Die sich daraus ergebenden, geeigneten Marken werden in einer 

Testreihe gegenübergestellt und letztlich wird die Wahl einer optischen Marke getroffen. 

Der zweite Teil beschäftigt sich mit der Entwicklung einer Anwendung für ein auf 

dem Android OS basierenden Smartphone, um eine optische Marke erkennen und interpretieren 

zu können. Die interpretierten Informationen des Dienstes sollen auf dem 

Smartphone angezeigt werden und der Nutzer soll eine Buchung direkt über eine Internetverbindung 

vornehmen können. Die Buchungsinformationen sollen dabei an eine 

vom WEITBLICK-Projekt entwickelte Middleware übermittelt werden. Alternativ soll 

es die Möglichkeit geben, sich über einen Telefonanruf persönlich mit einem Ansprechpartner 

verbinden zu lassen (Punkte 3-5). Um bei einer direkten Buchung die über 

eine Internetverbindung gesendeten Buchungsanfragen entgegenzunehmen und zu verarbeiten, 

muss eine entsprechende Serverinfrastruktur geschaffen werden. 



3 Diskussion der optischen Marke 

Die Ursprünge einer optischen Marke liegen in der automatischen Identifikation. Die 

Industrie steht durch eine große Vielfalt an Produkten, immer kürzeren Produkt- und 

Innovationszyklen, Wettbewerbsdruck und die dadurch notwendigen kurzen Lieferzeiten 

unter Druck, immer kostengünstiger und schneller produzieren zu müssen. Dahingehend 

sind moderne Methoden gefordert, um die Prozesse in der Produktion und 

Logistik besser koordinieren zu können. Es sind Identifikationstechniken notwendig, 

mit Hilfe derer Materialien genau identifiziert werden können. In der Logistik, speziell 

auch bei Post-, Paket- und Kurierdiensten, werden Identifikationstechniken im Bereich 

des Tracking und Tracing (Sendungsverfolgung und Rückverfolgbarkeit) benutzt, um 

die Waren vom Absender bis zum Empfänger verfolgen zu können. In Branchen wie 

der Automobil- und Pharmaindustrie helfen diese Prozessketten effizient steuern und 

koordinieren zu können. Die Identifikationstechniken teilen sich in die Kategorien der 

magnetischen, optischen und RF (Radio Frequency)-Identifikation auf [Len05]. 

Diese Bachelorarbeit beschäftigt sich ausschließlich mit der optischen Identifikation. 

Die Grundidee der optischen Identifikation ist Zeichen für eine Maschine lesbar 

zu machen. Ein Zeichen kann zum Einen optisch in Form eines Schriftzeichens oder 

zum Anderen ein codiertes optisches Zeichen sein. Da sich Schriftzeichen in ihrem 

Schriftbild sehr stark unterscheiden können, ist es für Computer nicht ganz unproblematisch 

die einzelnen Schriftzeichen korrekt erfassen zu können und es kommt zu 

Auslesefehlern. [Len05] Durch optische Codierung des Zeichens wird es nach einer von 

der Codeart abhängigen Bildungsvorschrift als Folge von hellen und dunklen Flächen 

binär dargestellt. Damit erfolgt sowohl der Druck als auch das Auslesen einer solchen 

optischen Marke in binärer Form. Da die Breiten der hellen und dunklen Flächen innerhalb 

von bestimmten Toleranzen konstant sind, wird die Eigensicherheit des Auslesens 

von codierten Zeichen erheblich gesteigert. [Len05] hat die Leseraten (Verhältnis richtig 

eingelesener zu allen Zeichen) und Fehlerraten (Verhältnis falsch interpretierter zu 

allen Zeichen) anhand eines Auslesetests von fünf Ziffern zwischen den Zeichenarten 

Klarschrift und OCR/True Type(Standardschriften) verglichen. Nach dem Vergleichstest 

in [Len05, S. 16] (Stand 2004) weisen die Strichcodes eine Leserate von nahezu 

100% auf, die Klarschrift und OCR/True Type dagegen nur etwa 40% und 80%. Der 

Auslesevorgang der Strichcodes wird anhand einer mitcodierten Prüfziffer verifiziert. 

Eine Fehlerrate liegt dabei nicht vor, da im Falle eines fehlerhaften Auslesens das Ergebnis 

wieder verworfen und der Barcode erneut ausgelesen wird. Eine entsprechende 

Fehlerrate ergibt sich dagegen beim Scannen von Klarschrift und OCR-Schriftarten, 

da Zeichen falsch interpretiert und deren Korrektheit nicht überprüft werden können. 

Im Laufe der Zeit wurden eine Vielzahl an Codes entwickelt. Je nach Branche und 

Anwendungsgebiet kommen verschiedene Codearten zum Einsatz. Im Grunde lassen 

sich die optischen Marken in eindimensionale Strichcodes und zweidimensionale Stapel- 



bzw. Matrixcodes einteilen. Die Anzahl der Dimensionen gibt an in wie viele optische 

Achsen die Informationen codiert sind. Durch zwei weitere Dimensionen werden zweidimensionale 

Matrixcodes zum Einen um einen Farbkanal (Farbe, Sättigung) bzw. 

Tiefenkanal erweitert und/oder zum Anderen in einer zeitlichen Abfolge dargestellt. 

Damit ergeben sich dreibzw. vierdimensionale optische Marken. 

3.1 Merkmale einer optischen Marke 

Um aus der Vielzahl von Codes einen geeigneten auswählen zu können, sind vorhergehende 

Definitionen der Merkmale, Eigenschaften und vor allem die Art und Anzahl der 

zu codierenden Zeichen notwendig. Die Begriffsdefinition der optischen Marke bezieht 

sich auf eine Verallgemeinerung des Begriffes Code. Code impliziert dabei die Konvertierung 

(Codierung) nach einer bestimmten Vorschrift mit der Informationen in eine 

optische Marke (Zeichen) umgesetzt werden. Im allgemeinen Sprachgebrauch werden 

zweidimensionale Matrixcodes ebenso als ” Barcodes“ bezeichnet, obwohl diese wörtlich 

übersetzt nur für die Strichcodes stehen. Unter den Bezeichnungen ” Strich“-, ” Stapel“und 

” Matrix“code sind die jeweiligen Codearten gemeint. 

3.1.1 Zeichensätze 

Der Informationsgehalt einer optischen Marke teilt sich in mehrere einzelne Zeichen 

auf. Nach DIN 44300 und [Len02, S. 4] wird bei der Codierung von optischen Marken 

ein Zeichen aus einem festgelegten Zeichenvorrat X einem Zeichen aus einem festgelegten 

Zeichenvorrat Y zugeordnet. Der Zeichenvorrat X ist eine fest definierte Menge 

an Zeichen aus der sich der Anwender bedienen kann. Diese Menge wird daher Anwenderzeichensatz 

genannt. Je nach Anwendungszweck und Codeart finden verschiedene 

Variationen an standardisierten Zeichensätzen wie bspw. ein numerischer, ein 

alphanumerischer, der ASCII oder der ISO-Zeichensatz Verwendung. Die Nutzzeichen 

sowie weitere interne Steuer- und Sonderzeichen werden nach den Gesetzmäßigkeiten 

der verwendeten Codeart in die entsprechenden Codezeichen umgesetzt. Ein Codezeichen 

stellt bei Strichcodes eine bestimmte Sequenz aus unterschiedlichen Strichen und 

Lücken dar. Der Zeichensatz Y ist die Menge aller Codezeichen und wird als Codierungszeichensatz 

bezeichnet. Die maximal in den Code unterzubringende Anzahl an 

Zeichen ist vom verwendeten Anwenderzeichensatz abhängig und aufgrund der Spezifika 

des verwendeten Codes begrenzt. Je kleiner der Zeichenvorrat X ist, desto mehr 

Nutzzeichen können in einen Code untergebracht werden. [Len02] 

3.1.2 Informationsdichte und zu codierende Nutzdatenmenge 

Zur Codierung werden die Nutzzeichen in Codezeichen umgesetzt. Die Informationen 

werden je nach Codeart mehr oder weniger effizient codiert. Die Effizienz der Codierung 

spielt vor allem dann eine Rolle, wenn der zur Verfügung stehende Platz oder 

die optische Auflösung des Lesegerätes begrenzt ist. Bei der Herstellung der optischen 

Marke müssen bestimmte Toleranzgrenzen eingehalten werden, um den Barcode noch 



korrekt auslesen zu können. Die Codes variieren aufgrund ihres unterschiedlichen Aufbaus 

sehr stark. Um die Codes typenübergreifened vergleichen zu können, ist es daher 

nötig einen festen Bezugsrahmen zu definieren. Der Bezugsrahmen stellt das kleinste 

auftretende Element einer optischen Marke dar. Nach Abb. 3.1 wird dieses bei Strichund 

Stapelcodes als Modulbreite und bei zweidimensionalen Matrixcodes als Zellgröße 

bezeichnet. 

Abbildung 3.1: Modulbreite/Zellgröße einer optischen Marke (entnommen aus [Len02]) 

Mit der gegebenen Modulbreite bzw. Zellgröße lässt sich nun eine sogenannte Informationsdichte 

formulieren. Gemessen an der Druckauflösung bzw. der Auflösung des 

verwendeten Herstellungsverfahren gibt die Informationsdichte an wie viele Zeichen 

innerhalb einer bestimmten Fläche codiert werden können. [Len02, S. 21 f.] 

3.1.3 Datensicherheit 

Die optische Identifikation wurde ursprünglich als eine Kategorie der Identifikationstechniken 

eingeführt, um Waren bzw. Materialien korrekt identifizieren zu können. 

Eine falsche Interpretation der in einer optischen Marke codierten Informationen würde 

gegen die Grundidee der optischen Identifikation verstoßen. Es ist daher unerlässlich 

die optische Marke mit allen codierten Informationen korrekt auszulesen. Auslesefehler 

können durch eine fehlerhaft codierte oder eine verschmutzte bzw. beschädigte optische 

Marke verursacht werden. Gleichermaßen kann das korrekte Einlesen der Marke durch 

technische Grenzen, wie eine begrenzte optische Auflösung des Lesegerätes, verhindert 

werden. 

Um Auslesefehler erkennen und korrigieren zu können, werden den Barcodes redundante 

Daten hinzugefügt. Mit einer zusätzlichen Prüfziffer, die bei fast allen Codes 

verwendet wird, lässt sich überprüfen, ob die ausgelesenen Informationen im Kontext 

einen Sinn ergeben. Bei linearen Strichcodes wird zusätzlich noch die Lesesicherheit 

erhöht, indem die Striche in ihrer Höhe vergrößert werden. Dies sind redundante Informationen, 

da sich der Informationsgehalt lediglich in der Strichbreite befindet. Durch 

die zweidimensionale Codestruktur ist es bei Matrixcodes nötig noch weitere Fehlerkorrekturalgorithmen 

wie den Cyclic Redundancy Check (CRC) oder einen Reed Solomon 

Code zu ergänzen, um Auslesefehler korrigieren zu können. 



3.1.4 Flexibilität 

Ein weiteres wichtiges Merkmal stellt die Flexibilität beim Auslesen der optischen Marke 

dar. Je nach Anwendungszweck und Codeart kommen unterschiedliche Lesegeräte 

zum Einsatz. So kann das Auslesen statisch mit einem fest installiertem Lesegerät 

oder flexibel mit einem Handlesegerät (wie es auch bei einem Smartphone der Fall 

ist) geschehen. In beiden Fällen ist nicht immer gewährleistet, dass das Lesegerät eine 

optimale Ausleseposition zur optischen Marke hat. So wäre es möglich, dass der 

Barcode zu klein ist, um diesen mit der begrenzten optischen Auflösung des Lesegerätes 

einlesen zu können. Des Weiteren liegt durch eine schiefe Lage im Raum oft auch 

eine perspektivische Verzerrung vor. Hier kommt es auf die Art des Codes und das 

Lesegerät an, inwieweit die Verzerrung ausgeglichen werden kann, um einen erfolgreichen 

Auslesevorgang zu ermöglichen. Um die Lage der optischen Marken feststellen zu 

können, besitzen lineare Strichcodes am Anfang und Ende ein bestimmtes Start- und 

Stopmuster, Matrixcodes ein bestimmtes, charakteristisches Suchmuster. Damit wird 

bei linearen Codes die Leserichtung, bei Matrixcodes die konkrete Lage festgestellt. 

Durch das Suchmuster der Matrixcodes sind diese omnidirektional, d. h. in alle Richtungen 

lesbar, da diese nach dem Auslesen durch Bildverarbeitungsalgorithmen des 

Bildprozessors intern noch gedreht werden können. [Len05] 

3.1.5 Standardisierung 

[Len05, S. 31 f.] teilt die Standardisierung von optischen Marken in drei Bereiche ein: 

Code, Applikation und Syntax. Der Code-Bereich beschreibt den Aufbau des Codes, 

sowie die Bildungsvorschrift zur Codierung der Zeichen. Als Aufbau werden dabei geometrische 

Abmessungen, sowie Toleranzbereiche, Qualitätskriterien und weitere Randbedingungen 

festgelegt. Die Bereiche Applikation und Syntax definieren die Interpretation 

der Daten und gewährleisten bei Bedarf eine weltweite Eindeutigkeit. Besonders 

im Handel und in der Logistik ist eine eindeutige Zuweisung für das Tracking und Tracing 

von großer Bedeutung. Abhängig von Firma, Branche, Land und Codeart sind 

für die Vergabe von eindeutigen Identifikationsnummern unterschiedliche Vergabestellen 

zuständig. Die für den Handel vorgesehenen GTIN-14-Codes (Global Trade Item 

Number, ursprünglich EAN- und UPC-Codes) werden von der weltweiten Standardisierungsorganisation 

GS1 verwaltet. Der eigentlichen Identifikationsnummer wird bei 

den EAN- und UPC-Nummern eine Länderpräfixnummer vorangeführt. Diese besagt 

welcher nationalen GS1 Mitgliedsorganisation eine weltweit eindeutige EAN-Nummer 

zugeteilt wurde. Ebenso würde der Präfix ” (200-299)“ beispielsweise für eine firmeninterne 

Verwendung stehen, womit die Nummer weltweit nicht eindeutig sein müsste. Die 

GTIN-14 Nummern werden zusätzlich von einem Application Identifier (AI) angeführt. 

Dieses gibt an welche Art von Daten sich im Code befindet. 

3.2 Anforderungsanalyse für den WEITBLICK Code 

Nachdem die allgemeinen Merkmale einer optischen Marke erläutert wurden, erfolgt 

eine Analyse der an den WEITBLICK Code gestellten Anforderungen. Es gilt hierbei 



sich an den vorliegenden Usecase aus der Aufgabenstellung unter Kapitel 2 zu halten 

und diesen entsprechend der gegebenen Randbedingungen anzupassen. 

3.2.1 Standardisierung 

Die WEITBLICK Anwendung, die zum Scannen und Buchen des Dienstes erstellt 

wird, soll auf möglichst vielen Smartphones lauffähig sein. Das von Google aufgekaufte 

Android-Betriebssystem stellt für mobile Geräte eine weit verbreitete Plattform dar. 

Daher soll eine App für das Android Betriebssystem entwickelt werden, was in Kapitel 

4 noch näher erläutert wird. Nach eingehender Recherche bietet sich die bereits 

in Android implementiere App ” Barcode Scanner“ an, die auf der Open-Source 1D- 

/2D-Bildverarbeitungsbibliothek ZXing (siehe [ZXi11a]) basiert. Mit einer einfachen 

Anfrage aus der WEITBLICK App (einem sogenannten Intent, siehe auch Kapitel 4) 

lassen sich Barcodes über die externe ” Barcode Scanner“ App einscannen und die Ergebnisse 

des Scanvorgangs anschließend wieder zurückgeben. Der Barcode Scanner ist 

dadurch sehr leicht implementierbar. 

Aufgrund der gegebenen Implementierungsmöglichkeit sollte die Wahl der optischen 

Marke auf einen von der ZXing Barcode Scanner App unterstützten Code fallen. Da 

ZXing eine Open-Source Bildverarbeitungsbibliothek ist, werden nur Codes unterstützt, 

die ebenfalls frei zu verwenden sind und keine zu entrichtenden Lizenzgebühren 

erfordern. Damit sollte die Entscheidung auf eine ebenso frei verwendbare, optische 

Marke fallen. 

3.2.2 Datenmenge 

Nach [Len04, S. 12-15] wird die Auswahl einer optischen Marke in Abhängigkeit von der 

Anzahl der zu codierenden Nutzzeichen gesetzt. Diesbezüglich muss festgelegt werden, 

welche Arten von Informationen der Dienstleistung im Barcode gespeichert werden 

sollen. Um diese Frage klären zu können, muss zwischen zwei grundsätzlichen Methoden 

unterschieden werden: Der direkten Verlinkung und der indirekten Verlinkung. [Heg10, 

S. 34 f.] 

Bei der indirekten Variante werden die Barcodes lediglich mit einer eindeutigen 

ID-Nummer versehen. Ein Musterbeispiel hierfür wären die üblichen EAN-13 Handelscodes. 

Durch die ID werden Daten wie Artikelname, Preis, Artikelinformationen usw. 

von einer (meist) externen Datenbank indirekt abgefragt. 

Bei der direkten Variante sind in der optischen Marke dagegen schon alle Informationen 

direkt in die Marke codiert. Es entfällt daher eine zusätzliche Abfrage über eine 

externe Datenbank. Dem liegt die Annahme zugrunde, dass die direkte Variante, wegen 

des geringeren Aufwands, die bessere sei. Dies hätte jedoch einen entscheidenden Nachteil: 

Es könnte nicht sichergestellt werden, dass der gebuchte Dienst vor der Buchung 

richtig angezeigt wird. Denkbar wäre demnach, dass sich der Preis einer Dienstleistung 

vor der Ausstrahlung der Fernsehsendung irrtümlicherweise geändert hat und der 

Nutzer demzufolge den Dienst zu dem im Barcode angegebenen, nicht mehr aktuellen 

Preis buchen würde. Ebenso könnte keine missbräuchliche Buchung einer Dienstleistung 

ausgeschlossen werden, bei der ein Barcode vom Nutzer selbst erstellt wird und 



der Dienst zu einem selbst angegebenen Preis gebucht werden kann. Der Nutzer könnte 

vorgeben, den Dienst zu einem günstigeren Preis gebucht zu haben. Eine weitere 

wichtige Information zum Dienst ist der Zeitpunkt zu welchem die Dienstleistung stattfindet. 

Auch hier ist eine korrekte Anzeige sicherzustellen. Demnach erfüllt eine rein 

direkte Verlinkungs-Variante nicht die Bedingungen der Authentizität und Integrität, 

die die Anzeige einer Dienstleistung auf dem Smartphone erfordert. 

Variante 1 Variante 2 Variante 3 

Verlinkung indirekt direkt hybrid 

Anzahl der Zeichen 

ID 5 5 5 

Kurztitel - 30 30 

Kurzbeschreibung - 500 - 

Telefonnummer - 20 20 

Zeichensatz numerisch ASCII ASCII 

Gesamt 5 555 55 

Tabelle 3.1: Anzahl der zu codierenden Zeichen 

Tab. 3.1 beschreibt die Informationen, die direkt in die optische Marke codiert werden. 

Dabei werden jeweils eine indirekte, eine direkte und eine hybride Verlinkungs- 

Variante gegenübergestellt. 

Der Kurztitel und die Kurzbeschreibung dienen dem Nutzer zur reinen Information, 

mit Hilfe der Telefonnummer könnte er sich dann persönlich mit einem Ansprechpartner 

verbinden lassen. Auf die Angabe des Termins und der Kosten für die Dienstleistung 

wurde aufgrund der oben genannten, nicht vorhandenen Bedingungen der Authentizität 

und Integrität verzichtet. In Variante 1 wird lediglich eine fünfstellige ID-Nummer 

gespeichert, durch die weitere Informationen von einer zentralen Datenbank abgefragt 

werden. Variante 2 beinhaltet als direkte Verlinkungs-Variante dagegen, abgesehen von 

einer gekürzten Version der Beschreibung, die vollständigen Dienstinformationen. Eine 

gekürzte Beschreibung wurde gewählt, um die Gesamtzeichenanzahl klein zu halten, 

da mit steigender Anzahl codierter Zeichen die Lesbarkeit des Codes abnimmt [Heg10, 

S. 35]. Vorwegnehmend zum nächsten Abschnitt wirkt sich dies auf die Anforderung 

der Flexibilität beim Auslesen aus, wodurch sich der maximal erreichbare Leseabstand 

zum Fernsehgerät verringert. Folglich ergibt sich die Hybrid-Variante 3, welche sowohl 

eine direkte als auch eine indirekte Verlinkungs-Methode kombiniert. Die Gesamtzeichenanzahl 

wird durch Weglassen der Kurzbeschreibung auf 55 begrenzt. Betrachtet 

man den Fall, dass keine Internetverbindung zur Verfügung steht, so hätte dies einen 

entscheidenden Vorteil: Durch die Direktcodierung in den Code könnte trotzdem der 

Kurztitel angezeigt werden. Der Nutzer kann damit sehen was sich hinter dem Barcode 

verbirgt und sich über die mitcodierte Telefonnummer mit einem persönlichen 

Ansprechpartner verbinden lassen, um den Dienst zu buchen. 

Abschließend wird damit festgelegt, dass die optische Marke eine fünfstellige ID, 

einen Kurztitel und eine Telefonnummer mit einer Gesamtanzahl von maximal 55 Zeichen 

speichern soll. Es kommt daher für die Codierung nur Variante 3 in Frage. 



3.2.3 Flexibilität 

Das Merkmal der Flexibilität einer optischen Marke sagt aus, von welchem Lesegerät 

unter welchen Bedingungen diese gelesen werden kann. 

Im Falle des WEITBLICK-Projekts wird der Code mit einer CCD-Sensor-Kamera 

(CCD steht für Charge-coupled Device) des Smartphones ausgelesen. Aufgrund der 

begrenzten optischen Auflösung des Sensors ist die maximal erreichbare Entfernung, 

von der der Barcode ausgelesen werden kann, begrenzt. Zusätzlich ist davon auszugehen, 

dass der Nutzer nicht frontal zum Fernsehgerät sitzt. Damit kann die optische 

Marke nicht aus einer optimalen Position eingescannt werden und es ergibt sich eine 

perspektivische Verzerrung. Diese wird durch den integrierten Bildprozessor des 

Smartphones durch Bildverarbeitungsalgorithmen ausgeglichen. Ein weiterer Faktor, 

der das Auslesen des Codes erschwert, sind die zu berücksichtigenden Lichtverhältnisse 

denen das Fernsehgerät ausgesetzt ist. Je nach Beschaffenheit der Bildfläche reflektiert 

diese das seitlich einfallende Tageslicht was mit dem Auslesen eines beschädigten Codes 

bei optimalen Lichtverhältnissen gleichzusetzen ist. Die Barcodes besitzen je nach 

Codeart unterschiedliche Fähigkeiten perspektivische Verzerrungen und Beschädigungen 

auszugleichen. Abschnitt 3.3 erläutert den Aufbau der Codearten und die damit 

auftretenden Unterschiede im Lesekomfort. 

Der WEITBLICK Code sollte eine möglichst große Flexibilität besitzen. Zur Maximierung 

des Lesekomforts wird in Abschnitt 3.4.1 eine Testreihe durchgeführt in der 

die Barcodes im Anwendungsfall verglichen werden. 

3.2.4 Fazit aus den gegebenen Anforderungen 

Zusammenfassend aus der Anforderungsanalyse ergeben sich für den WEITBLICK 

Code folgende Kriterien: 

• hoher Standardisierungsgrad: bereits bestehende Implementierung 

in die ZXing-Bildverarbeitungsbibliothek 

• Fähigkeit, Zeichen mindestens im ASCII Zeichensatz zu speichern 

• Fähigkeit, eine ausreichend hohe Datenmenge (mindestens 55 Zeichen) zu speichern 

• hohe Flexibilität beim Auslesen: ausreichend großer Leseabstand und Ausgleich 

von perspektivischer Verzerrung und schlechten Lichtverhältnissen 

Die Wahl eines geeigneten Codes fordert daher einen Kompromiss aus Lesbarkeit und 

Gesamtzeichenanzahl. Die sich aus der Anforderungsanalyse ergebende Datenmenge 

aus 3.2.2 legt sich auf Variante 3 aus der Tabelle 3.1 und damit auf eine Gesamtzeichenanzahl 

von maximal 55 Zeichen fest. Nach Erläuterung der aus der Anforderungsanalyse 

relevanten optischen Marken, wird in der praktischen Testreihe (siehe 3.4.1) 

der bestgeeignetste WEITBLICK Code ermittelt. 



3.3 Arten von optischen Marken 

Wie zu Beginn des Kapitels erwähnt lassen sich optische Marken gemäß ihrer Dimensionen, 

in denen die Informationen codiert sind, einteilen. Die einzelnen Codearten 

besitzen daher unterschiedliche Spezifika mit Vor- und Nachteilen. Um das Ganze 

einzugrenzen, wurde die Ausarbeitung auf diejenigen optischen Marken beschränkt, 

welche die im vorigen Abschnitt erläuterten Anforderungen erfüllen (könnten). 

3.3.1 Strichcodes 

Strichcodes sind eindimensionale Codes, die Informationen in nur einer Dimension in 

Form von Strichen codieren. Sie wurden Anfang der 70er Jahre in den USA mit dem 

Ziel eingeführt Artikel an der Supermarktkasse schnell und sicher einzuscannen. Bekannte 

Handelsstrichcodes wie EAN (European Article Number) oder UPC (Universal 

Product Code) sowie noch weitere sind Barcodes bei denen durch einen codierte ID 

auf externe Inhalte verwiesen wird. Dadurch lassen sich Artikel weltweit eindeutig zuordnen 

und Artikeldaten, wie Artikelname und Preis, aus einer zentralen Datenbank 

abfragen. Aus diesem Grund wurden die meisten der linearen Codes für numerische 

Zeichensätze spezifiziert. Nur wenige Codes, wie beispielsweise der Code-39, Code-93, 

Code-128, verwenden einen ASCII Zeichensatz [Len00]. Dieser Abschnitt geht exemplarisch 

auf den Code-128 ein, da dieser der fortschrittlichste lineare Code zu sein scheint, 

da neuere lizenzpflichtige Standards wie der GS1-128 den Code-128 in seinen technischen 

Spezifikationen übernommen und um Inhaltsspezifikationen erweitert haben. 

[HBF07, S. 57] 

Codeaufbau Code-128 

Der Code-128 ist ein alphanumerischer Strichcode. Die Codierung der Zeichen findet in 

der Variation der Breiten der Striche und Lücken statt. Ein Zeichen wird beim Code- 

128 in elf Module eingeteilt. Ein Strich besteht dabei immer aus einer geraden Anzahl, 

eine Lücke aus einer ungeraden Anzahl an Modulen, womit der Code selbstüberprüfend 

ist. [Len05, S. 107] Er besitzt drei verschiedene Zeichensätze A, B und C. Die 

Zeichensätze A und B besitzen alle alphanumerischen Zeichen, jeweils mit und ohne 

Kleinbuchstaben. Der dritte Zeichensatz C ist ein rein numerischer. Wie auf Abb. 3.2 

zu sehen, wird der Nutzinhalt Code-128, wie bei fast allen anderen Strichcodes, von 

einer Ruhezone und einem Start-und Stoppzeichen umschlossen. Start- und Stoppzeichen 

helfen den Lesegeräten (bei linearen Strichcodes sind dies meist Laserscanner) 

bei der Bestimmung der Codeart und der Leserichtung. Drei verschiedene Startzeichen 

geben an welche der drei Zeichensätze verwendet werden. 

Da sich die Informationen lediglich in der Breites des Codes befinden, wirkt sich eine 

Vergrößerung der Codehöhe nicht auf den Informationsgehalt aus. Dagegen erhöht sich 

mit wachsender Höhe die Lesbarkeit des Codes, um beispielsweise Beschädigungen am 

Code ausgleichen zu können. Zudem ist der Code-128, wie auch andere lineare Codes, 

mit einer Prüfziffer abgesichert, die eine Art Quersumme der codierten Zeichen ist. 

Bei Berechnung der Prüfziffer des Code-128 werden die mit der Position des Nutzzei- 



Abbildung 3.2: Codeaufbau Code-128 

chens gewichteten Referenzzahlen (aus der entsprechenden Zeichensatztabelle) addiert 

und nach Modulo 103 berechnet. Mit dem Vergleich der errechneten und mitcodierten 

Prüfziffer lässt sich überprüfen, ob alle Nutzzeichen des Codes richtig eingelesen 

wurden. 

Zeichensätze und Datenkapazität 

Wie schon in Abschnitt 3.1.1 erläutert, hängt die Anzahl der in einen Code maximal 

zu codierenden Zeichen von der Größe des Anwenderzeichensatzes ab. Je kleiner der 

Anwenderzeichensatz, desto mehr Zeichen können codiert werden. Dies zeigt auch die 

Formel zur Codelängenbestimmung 1 L aus [Len05, S. 109]: 

L = ((5, 5Nc + 11Nab + 35)X) + 2R 

Anhand der Formel ist zu erkennen, dass für eine festgelegte Codelänge erheblich mehr 

Zeichen aus Zeichensatz C als aus A oder B codiert werden können. Eine Maximierung 

der Informationsdichte wird erreicht, indem je nach Art der codierten Daten innerhalb 

des Codes zwischen den drei Zeichensätzen gewechselt wird. Durch Steuerzeichen, die 

in den einzelnen Zeichensätzen definiert sind, wird ein Zeichensatzwechsel signalisiert, 

um so numerische Zeichen effizient codieren zu können. 

Die Eigenschaft der Strichcodes, dass diese mit steigender Anzahl codierter Zeichen 

immer breiter werden, hat zur Folge, dass diese immer schlechter von den Lesegeräten 

aufgelöst werden. Vor allem Lesegeräte mit CCD-Sensor, wie bei einem Smartphone, 

besitzen ein begrenztes, optisches Auflösungsvermögen. Die mit vergrößertem 

Leseabstand immer kleiner werdenden Modulbreiten sind ab einem gewissen Abstand 

nicht mehr auflösbar. Infolgedessen wird die Lesbarkeit linearer Strichcodes stark eingeschränkt, 

wie die Testreihe in Abschnitt 3.4.1 zeigt. 

Zusammenfassend lässt sich sagen, dass das WEITBLICK-Projekt gemäß der Anforderungsanalyse 

einen maximalen Leseabstand fordert und damit, aufgrund der erhöhten 

Breite von Strichcodes, die maximale Anzahl zu codierender Nutzzeichen beschränkt. 

1 Nc,Nab: Anzahl der Zeichen aus den Zeichensätzen C und A/B, X: Modulbreite, R: Ruhezone (10X) 



Abbildung 3.3: ” Projekt WEITBLICK“ codiert mit dem Stapelcode PDF417 (erstellt 

mit [TEC11]) 

3.3.2 Stapelcodes 

Durch die in Strichcodes begrenzte Anzahl an zu codierenden Nutzzeichen wurden neue 

Codes entwickelt, die die bisherigen linearen Strichcodes in mehreren Zeilen stapeln, 

um so die Informationsdichte zu erhöhen. Diese Art von zweidimensionalen Strichcodes 

werden daher Stapelcodes genannt. Eine in der Logistik, beim Transport und 

Paketdiensten häufig verwendete Stapelcodeart ist PDF417, wie Abb. 3.3 beispielhaft 

zeigt. 

Wie auch lineare Strichcodes werden Stapelcodes von einer Ruhezone und jeweils 

einem Start- und Stoppzeichen umschlossen. Der Code kann insgesamt drei bis 90 Zeilen 

umfassen. Dadurch kann neben einer zusätzlichen Datenkompression eine größere 

Anzahl an Zeichen codiert werden. 2 Des Weiteren kommen Fehlerkorrekturverfahren 

wie der Reed Solomon Code in mehreren Fehlerkorrekturstufen zum Einsatz, was den 

Code sehr datensicher macht. [Len05, S. 129] 

Die ZXing-Bildverarbeitungsbibliothek führt den PDF417 Code als unterstütztes 

Codeformat auf. Leider konnte das PDF417-Format in der Testreihe in Abschnitt 3.4.1 

vom ZXing Barcode Scanner nicht erfolgreich eingescannt werden. Es wird an dieser 

Stelle daher auf eine nähere Erläuterung des Codes verzichtet. 

3.3.3 Matrixcodes 

Strich- und Stapelcodes besitzen aufgrund Ihrer Eigenschaft, die Informationen nur 

in ihrer Breite zu speichern, eine gewisse vertikale Redundanz. Die Höhe des Codes 

trägt dabei nicht zum Informationsgehalt bei. Um die Informationsdichte noch weiter 

zu erhöhen und den Platz effizienter zu nutzen, wurden echt-zweidimensionale Matrixcodes 

bzw. Punktcodes entwickelt. Dem Namen nach werden hier die Informationen in 

Form von Punkten bzw. Pixeln 3 in einer Matrixstruktur angeordnet. Ein ausgefüllter 

schwarzer Pixel würde als binärer Wert ” 1“ interpretiert werden. Zum Auslesen der Matrixcodes 

werden CCD-Matrixsensoren verwendet, wodurch diese auch omnidirektional 

lesbar sind. 

Neben zahlreichen proprietären Formaten wie zum Beispiel BeeTag, Shotcode, EZ- 

Code haben die standardisierten Codeformate Aztec Codes, QR Code und Data Matrix 

Code die weiteste Verbreitung gefunden [Heg10, S. 48]. Alle drei Codeformate werden in 

der Dokumentation der ZXing-Bibliothek unter den unterstützten Formaten genannt. 

Leider konnte der Aztec Code in der Testreihe unter 3.4.1 mit dem ZXing Barcode 

2numerisch: max 2710 Ziffern, alphanumerisch: 1850 Zeichen, ASCII: 1400 Zeichen, ISO: 1108 Bytes 

[Len05, S. 120] 

3abhängig von Codeart, bspw. bei Maxicode auch in hexagonaler Form 



Abbildung 3.4: Data Matrix und QR Code: Suchmuster mit Taktzellen (entnommen 

aus [Len05, S. 140 und 150]) 

Scanner nicht gelesen werden. Es wird in diesem Abschnitt daher auf die Erläuterung 

des Aztec Codes verzichtet. 

Der im Jahre 1989 von der Firma International Data Matrix entwickelte gleichnamige 

Code hat sich bereits in vielen Branchen wie der Industrie, der Logistik und bei 

Paketdiensten durchgesetzt. In vielen industriellen Bereichen wird dieser zur Kennzeichnung 

von Produkten eingesetzt. Kleinere Produkte werden mittels Lasergravur 

gekennzeichnet, wodurch die Anwendungsmöglichkeiten sehr vielfältig sind. In weiteren 

Branchen findet der Data Matrix bspw. beim elektronischem Ticketing oder bei 

der elektronischen Briefmarke der Deutschen Post Verwendung. [Len05, S. 131] Wohingegen 

der Data Matrix eher im europäischem Raum verbreitet ist, hat sich der QR 

Code (Quick-Response Code) eher im asiatischen Raum durchgesetzt. Er wurde von 

der Firma Denso Wave in Japan ursprünglich für die Automobilindustrie entwickelt. 

Sowohl Data Matrix als auch QR Code sind in ihren Anwendungsgebieten sowie in 

ihrem Aufbau sehr ähnlich. Beide Codes wurden patentiert, sind aber durch Nichtausübung 

der Patentrechte kommerziell verwendbar [Wan11, S. 34]. Nachfolgend werden 

beide Codearten auf ihre Merkmale untersucht und verglichen. 

Codeaufbau Data Matrix und QR Code 

Beide Codes besitzen eine quadratische Matrixstruktur. Die Zellen der Matrizen sind 

schwarze oder weiße Pixel, die jeweils ein Bit darstellen. Zur Erfassung der Lage und 

der Position sind Suchmuster integriert, wodurch auch perspektivische Verzerrungen 

ausgeglichen werden. Abb. 3.4 zeigt die Suchmuster der beiden Codevarianten Data 

Matrix EC200 und QR Code v2 4 im Vergleich. Da beide Suchmuster sehr charakteristisch 

sind, stellen diese ein Hauptunterscheidungsmerkmal beider Codes dar. 

Die linke Seite der Abb. 3.4 zeigt das L-förmige Suchmuster mit einer zusätzlichen, 

leeren, weißen Zelle in der rechten oberen Ecke (welche die Kennung für die aktuelle, 

zweite Variante EC200 darstellt) des Data Matrix zu sehen. Das Suchmuster dient 

dem schnellen Auffinden des Codes. Die nicht zum L gehörenden, alternierend hellen 

und dunklen Zellen sind die sogenannten Taktzellen. Dadurch kann beim Decodieren 

des Codes eine Referenzmatrix erzeugt werden, die über die eingelesene Matrix gelegt 

4 EC200 und v2 stehen für die verbesserten Versionen der ursprünglichen Codespezifikationen 



wird. Damit wird festgestellt, ob es sich um eine helle oder eine dunkle Zelle handelt, 

d. h. ob eine binäre 1 oder 0 codiert wurde. [Len05, S. 128 f.] 

Der QR Code hat im Gegensatz zum Data Matrix ein viel auffälligeres Suchmuster. 

Dem Namen des Codes nach soll der Code damit noch schneller eingelesen werden 

können. Es besteht aus drei charakteristischen 3 mal 3 breiten Zellen mit einem weißen 

und einem schwarzen Zellrand. Zusätzlich hilft eine einzelne Orientierungszelle mit 

einem weißen und schwarzen Zellrand im rechten unteren Bereich des Codes dazu, 

perspektivische Verzerrungen ausgleichen zu können. Das Taktmuster dient wie beim 

Data Matrix zur Erzeugung einer Referenzmatrix und zum Decodieren des Codes. 

[Len05, S. 151 f.] 

In den verbleibenden Platz der Matrixcodes werden neben den eigentlichen Datenzellen 

noch Versions- und Steuerinformationen untergebracht. Für genaue Definitionen 

sei hier auf die Spezifikationen in ISO/IEC 16022:2000/24720:2008 (Data Matrix) und 

ISO/IEC 18004:2006 (QR Code) verwiesen. 

Aufgrund des größeren Suchmusters des QR Codes hat der Data Matrix einen entscheidenden 

Vorteil: Bei der Codierung des gleichen Inhalts ist der Data Matrix nach 

[Son10, S. 31] gegenüber dem QR Code zwischen 30% bis 60% platzeffizienter, wie 

auch auf Abb. 3.5 zu erkennen ist. 

Abbildung 3.5: ” Projekt WEITBLICK“ codiert in Data Matrix und QR Code, Vergleich 

der Platzeffizienz 

Wird im Hinblick auf die Wahl einer optischen Marke der Usecase der Aufgabenstellung 

betrachtet, so hat die Platzeffizienz des Data Matrix folgende Konsequenzen: 

Durch einen bestimmten, maximal zur Verfügung stehenden Platz und einer festgelegten, 

bestimmten Anzahl an zu codierender Zeichen, werden die beiden Barcodes auf 

die gleiche Größe skaliert. Das bedeutet für den Data Matrix, dass die Zellgröße (Größe 

einer elementaren Zelle) zunimmt bzw. die des QR Codes abnimmt. Infolgedessen 

liegt die Vermutung nahe, dass bei begrenzter optischer Auflösung des Lesegerätes die 

Lesbarkeit des Data Matrix besser wäre. Inwiefern dies dem besseren Suchmusters des 

QR Codes entgegensteht, zeigt die Testreihe in Abschnitt 3.4.1. 



Zeichensätze und Datenkapazität 

Die beiden Matrixcodes Data Matrix und QR Code sind in der Lage den numerischen, 

alphanumerischen, ASCII und ISO Zeichensatz zu codieren. Aufgrund der asiatischen 

Herkunft kann der QR Code zudem den Zeichensatz Kanji codieren. [Len05, S. 132] 

Um die Datensicherheit zu gewährleisten, wird bei beiden Codearten ein Reed Solomon 

Code verwendet. 

Durch ihre hohen Informationsdichten können beide Barcodes je nach verwendeten 

Zeichensätzen eine größere Zeichenanzahl speichern. Mit einer maximalen Matrixgröße 

von 144 mal 144 kann der Data Matrix bis zu 3116 numerische, 2335 alphanumerische 

Zeichen oder 1556 Bytes speichern. [Len05, S. 133] Der QR Code ist mit einer Matrixgröße 

von 21 bis 177 Zellen in der Lage, 7089 numerische, 4296 alphanumerische 

Zeichen oder 2953 Bytes zu codieren. [Len05, S. 147] Hierbei sei angemerkt, dass die 

Zahlen alle nur von theoretischem Belange sind. Aufgrund technischer Grenzen (begrenzte 

optische Auflösung bei den Herstellungs- und Einleseverfahren) und der damit 

verbundenen begrenzten Lesbarkeit ist die Nutzzeichenanzahl eingeschränkt nutzbar. 

Eine weitere Vergrößerung der Datenkapazität wird wie in Abschnitt 3.3.3 durch dreibzw. 

vierdimensionale Codes erreicht. 

Sowohl Data Matrix als auch QR Code finden im Bereich des Mobile Tagging eine 

weite Verbreitung. Beim mobilen Tagging ( ” Markieren“) werden Informationen in 

Barcodes codiert, um diese für Mobiltelefone zur Verfügung zu stellen. Dabei kommen 

direkte sowie indirekte Verlinkungs-Varianten zum Einsatz. Informationen können 

entweder als Texte, Kontaktinformationen (entspricht einer Visitenkarte im Codeformat), 

Termine, WLAN-Netzwerk Daten direkt codiert oder durch Internetadressen, 

Geodaten, Applikationen in den App Stores (abhängig vom jeweiligen verwenden 

Smartphone-System), YouTube-Videos, Twitter- oder Facebook-Accounts auf Informationen 

im Internet indirekt verlinkt werden. Damit ergeben sich eine Vielzahl von 

Anwendungsgebieten. Um eine konsistente Interpretation der optischen Marken zu gewährleisten, 

geben Präfixe, vergleichbar mit dem Application Identifier der GTIN-14 

Nummern (siehe 3.1.5), an, welcher Inhalt im Code gespeichert ist. Der datenbezeichnende 

Präfix wird mit den eigentlichen Daten als reiner Text in den Code untergebracht. 

Konventionen zur Codierung der verschiedenen Inhalte fasst [ZXi11b] zusammen. 

Da es sich beim WEITBLICK Dienst um einen proprietären Inhalt handelt, werden 

die Dienstinformationen als reine Textinformationen im Code gespeichert. Wie die Datenfelder 

in der optischen Marke als Text gespeichert und diese durch das Smartphone 

decodiert werden, wird in Kapitel 4 erläutert. 

3D/4D Codes 

Zur weiteren Erhöhung der Datenkapazität von zweidimensionalen Matrixcodes wurden 

dreidimensionale Codes entwickelt. Die dritte Dimension bildet dabei einen Farbkanal, 

in dem die Elementarzellen codiert sind. Dadurch können noch weitere Informationen 

untergebracht werden. Meist bauen diese auf die Matrixcodes Data Matrix 

oder QR Code auf, es gibt aber auch proprietäre optische Marken. So z. B. der von Mi- 



crosoft entwickelte High Capacity Color Barcode (HCCB). Durch eine Verschachtelung 

von farbigen Dreiecken ist die Informationsdichte drei mal so hoch wie die des Data 

Matrix. [TCK10, S. 89] Der HCCB wurde im Jahre 2007 von der Standardisierungsbehörde 

ISAN International Agency (ISAN-IA) in Vereinbarung mit Microsoft lizenziert 

und steht damit den offenen Formaten Data Matrix und QR Code gegenüber [TCK10, 

S. 92]. 

Die Erweiterung des Data Matrix auf einen Farbkanal als dritte und sogar vierte 

Dimension hat die Bauhaus Universität in Weimar (siehe [LT07]) untersucht. Die 

vierte Dimension stellt dabei eine Integration der Zeit dar und soll die Datenkapazität 

noch weiter erhöhen. In einer praktischen Versuchsreihe mit einem Nokia 6630 

mit VGA-CCD-Kamera (640 mal 480 Pixel) wurde bei unerfahrenen Benutzern bei 

einer Übertragungssicherheit von 82% eine Übertragungsgeschwindigkeit von 23 Zeichen 

pro Sekunde ermittelt [LT07, S. 11]. Schwierigkeiten gibt es bei den Verfahren, 

wenn Darstellungsgeräte mit geringerer Wiederholungsrate von unter 85 Hz (ältere 

CRT-Monitore, ältere Röhrenfernsehgeräte mit 60 Hz) verwendet werden [LT07, S. 4]. 

Die zeitlich aufeinanderfolgenden Codes können nicht richtig erkannt werden und es 

kommt zu Fehlinterpretationen. Gemäß der Aufgabenstellung dieser Arbeit wäre eine 

Verwendung eines Röhrenfernsehers mit 60 Hz (älterer Bauart) denkbar. Demnach 

kommt die Verwendung einer vierten, zeitlichen Dimension für den WEITBLICK Code 

nicht in Frage. 

Ein weiterer Nachteil von 3D/4D Codes ist die mangelnde Verbreitung. Der Bereich 

des Mobile Tagging wird von den zweidimensionalen Codeformaten Data Matrix und 

QR Code dominiert. Drei- und vierdimensionale Codes werden kaum bis gar nicht verwendet. 

Demnach konnte in keinem der App Stores der Smartphone-Betriebssysteme 5 

eine nennenswerte Barcode Scanner App ausfindig gemacht werden, die dreidimensionale 

Codes liest. Einzig die HCCB Reader App von Microsoft wurde im Android 

Market als 3D Code Scanner gefunden. 

Zusammenfassend lässt sich sagen, dass der HCCB-Code und die dreidimensionalen 

Data Matrix und QR Codes wegen fehlender Implementierungsmöglichkeiten und 

mangelnder Verbreitung als WEITBLICK Codes ebenfalls nicht geeignet sind. 

3.4 Praktischer Vergleich der Codes 

Nach der Anforderungsanalyse (siehe 3.2) und der Erläuterung der verschiedenen Arten 

von optischen Marken im letzten Abschnitt, erweisen sich der lineare Strichcode 

Code-128 und die beiden zweidimensionalen Matrixcodes Data Matrix und QR Code 

als mögliche WEITBLICK Codes. Die drei Barcodes erfüllen die festgelegten, theoretischen 

Anforderungen. Damit ist die Lesbarkeit der optischen Marke das entscheidende 

Auswahlkriterium. Um den Code mit der besten Lesbarkeit ermitteln zu können, werden 

in diesem Abschnitt die drei Codes in einer praktischen Testreihe gegenübergestellt. 

5 Apple iOS, Microsoft Windows Phone 7, Nokia Symbian, RIM Blackberry OS, Samsung Bada 



3.4.1 Vergleich der Codes in einer Testreihe 

Die Lesbarkeit von optischen Marken ist stark davon abhängig, wie viele Zeichen darin 

codiert sind. In Abschnitt 3.2.2 wurde bereits die Gesamtzeichenanzahl auf 55 begrenzt. 

Um dem Nutzer ein einwandfreies Nutzungserlebnis zu bieten, wird der komfortabelste 

Fall betrachtet. Folglich sollte der Leseabstand vom Sitzplatz zum Fernseher maximal 

groß sein und die optische Marke auch von Positionen schräg zur Bildfläche des Fernsehgeräts 

abgescannt werden können. Durch die Testreihe soll damit der maximale 

Leseabstand sowie der maximale (horizontale) Betrachtungswinkel ermittelt werden. 

(Der vertikale Betrachtungswinkel wird auf 0 ◦ festgesetzt.) Die Testbedingungen beschreiben 

folgende Punkte: 

• Verwendetes Smartphone: HTC Wildfire mit 5 MP CCD-Kamera und der Android 

Firmware 2.2.22 

• Verwendete Barcode-Scan App: ZXing Barcode Scanner 

• Darstellungsgerät: analoger Röhrenfernseher mit einer Diagonale von 42 cm 

• Darstellung eines von einem PC analog eingespeisten PAL Signals (mit einer 

äquivalenten Auflösung von 768 mal 576 Bildpunkten) 

• Effektive Bildfläche der Codes: Breite des Data Matrix und QR Codes: 20,5 cm; 

Codelänge/-höhe des Code-128 (mit nur fünf Ziffern): 29,5/14,5 cm 

• Seitlich einfallendes Tageslicht 

Damit wurde vom Worst Case ausgegangen: Röhrenfernseher werden heutzutage 

nicht mehr produziert. Stattdessen besitzen immer mehr Haushalte einen hochauflösenden 

Flachbildfernseher, der zudem mit einem qualitativ hochwertigeren digitalen 

Fernsehsignal versorgt wird. Da das HTC Wildfire mit seiner 5 MP Kamera eher zu 

den Smartphones aus der (Low-Budget)Einsteiger-Klasse zählt, ist schließlich davon 

auszugehen, dass die eingebaute 5 MP CCD-Kamera ebenfalls nicht zu den besten 

ihrer Klasse gehört. 

Zur Ermittlung des maximalen Leseabstands wurde bei der Testreihe folgendermaßen 

vorgegangen: 

1. Beginn der Ermittlung durch Scannen (aus freier Hand) aus übergroßem Abstand, 

sodass der Code nicht erkannt werden kann 

2. Schrittweise Annäherung an den Fernseher, bis der Barcode nach einem Annäherungsschritt 

innerhalb von 10 Sekunden erkannt wird 

3. Notierung des Abstands 

4. Wiederholung der Ermittlung mit allen drei Codearten mit Variation des horizontalen 

Betrachtungswinkels (0 ◦ , 25 ◦ und 35 ◦ ) 



Winkel 

Code 

0◦ 25◦ 35◦ Code-128 90 85 75 

Data Matrix 115 90 - 

QR Code 135 115 65 

Tabelle 3.2: Vergleich des maximalen Leseabstands (in cm) der Codes Code-128, Data 

Matrix, QR Code in Abhängigkeit vom horizontalen Betrachtungswinkel 

Aus der Testreihe wurden die Ergebnisse aus Tab. 3.2 ermittelt. Die Gesamtzeichenanzahl 

musste beim Code-128 auf die fünfstellige ID beschränkt werden, da der 

Code-128 bei der Codierung von vollen 55 Zeichen unverhältnismäßig breit geworden 

wäre. Ein folglich zu kurzer Leseabstand würde für den Usecase keinen Sinn ergeben. 

Angemerkt sei hierbei noch, dass das Auslesen von Strichcodes mit dem ZXing Scanner 

in einer bestimmten Lage erfolgen muss. Im Scandialog wird dabei ein fiktiver Laserstrahl 

eingeblendet, der die Striche quer durchsetzen muss. Die beiden Matrixcodes 

sind dagegen omnidirektional lesbar. 

3.4.2 Auswertung der Testreihe und Auswahl der optischen Marke 

Werden die Ergebnisse aus 3.2 bildlich dargestellt, ergibt sich die Abb. 3.6. Die roten 

Kreuze stellen die Messpunkte dar. Daraus ergibt sich für die drei optischen Marken 

jeweils ein approximierter Bereich innerhalb dessen die Lesbarkeit des auf dem Fernsehgerät 

dargestellten Code gewährleistet ist. Dabei liegt die Annahme zugrunde, dass 

die Randbedingungen auf beiden Seiten gleich sind und der Bereich damit symmetrisch 

ist. 

115 cm 

135 cm 

90 cm 

TV 

QR Code 

Data Matrix 

Code 128 

Messpunkt 

Abbildung 3.6: Anschaulich dargestellte Testreihe (aus Tab. 3.2) des praktischen Vergleichs 

von Code-128, Data Matrix und QR Code 



Der lineare Code-128 zeigt trotz der nur fünf codierten Ziffern die schlechteste Lesbarkeit. 

Als die optische Marke mit der besten Lesbarkeit erweist sich der QR Code. In 

der Testreihe hat dieser gegenüber dem Data Matrix eine um 20 cm weitere Lesbarkeit 

und zudem ein besseres Verhalten in Abhängigkeit des horizontalen Betrachtungswinkels. 

Der Vorteil des Data Matrix gegenüber dem QR Code platzeffizienter zu sein, 

um damit durch eine größere Elementarzellgröße besser aufgelöst werden zu können, 

gleicht den Vorteil des besseren Suchmusters des QR Codes nicht aus. 

Die Wahl der optischen Marke fällt hiermit auf den QR Code. 



4 Praktische Umsetzung 

4.1 Anforderungen an das Dienstbuchungssystem 

Im letzten Abschnitt hat sich der QR Code als bestgeeignetste optische Marke herausgestellt. 

Es verbleiben laut Aufgabenstellung aus Kapitel 2 noch folgende drei Punkte: 


Marke 



Demnach ergibt sich die Aufgabe eine Anwendung auf einem Smartphone-Betriebssystem 

zu entwickeln, die einen QR Code einscannt und die codierten Informationen 

weiter verarbeitet. Nachdem die eingelesenen Informationen interpretiert wurden, wird 

eine entsprechende Dienstleistung angezeigt. Der Nutzer hat dann die Möglichkeit den 

Dienst entweder direkt über ein IP-Netz (Internet über WLAN oder UMTS) zu buchen 

oder sich mit einem Gesprächspartner persönlich verbinden zu lassen, falls er noch 

Fragen zur angebotenen Dienstleistung hat. Aus dieser Aufgabenstellung ergibt sich 

ein Dienstbuchungssystem, das die Buchung der Smartphone-Clients verarbeiten kann. 

An das Dienstbuchungssystem werden bestimmte Anforderungen gestellt, auf die in 

den folgenden Absätzen näher eingegangen wird. 

Zur Buchung eines Dienstes ist die Integrität der angezeigten Dienstleistunginformationen 

sicherzustellen. Dies ist vor allem dann wichtig, wenn sich die Dienstleistung 

vor der Ausstrahlung des QR Codes in einer Fernsehsendung kurzfristig ändert. Um 

zu verhindern, dass der Nutzer eine Dienstleistung auf Basis von nicht mehr aktuellen 

Dienstinformationen falsch buchen kann, hat vor Anzeige und Buchung des Dienstes 

die Dienstabfrage von einem zentralen Server zu erfolgen. Durch die Integrität der 

Dienstinformationen ist gleichzeitig die Authentizität des angezeigten Dienstes gesichert. 

Möchte der Nutzer eine direkte Dienstbuchung vornehmen, so wird vom Client eine 

Nachricht an eine vom WEITBLICK-Projekt entwickelte Kommunikations-Middleware 

gesendet, die die Nachricht wiederum an einen Buchungsserver weiterleitet. Die Middleware 

ist genau genommen eine Message Oriented Middleware (MOM), mit Hilfe 

welcher Nachrichten asynchron versendet und empfangen werden können, unabhängig 

von welcher Netzwerkschnittstelle die Nachrichten kommen. Das WEITBLICK- 

Projekt verwendet dazu eine von der Softwarefirma Oracle entwickelte Open-Source- 

MOM namens Open Message Queue (openMQ). Durch die Middleware ist damit eine 



gemeinsame Kommunikationsschnittstelle geschaffen, die Telefondienste sowie auch Internetdienste 

miteinander vereint und kommunizieren lässt. 

Eine weitere wichtige Anforderung stellt die Authentifizierung und Autorisierung des 

Nutzers dar. Hierbei muss bei der Buchung eines Dienstes festgestellt werden von wem 

der Dienst gebucht wird. Ein reines Senden der UserID würde nicht ausreichen, um 

die Authentizität des Nutzer zu gewährleisten. Das System wäre im Falle der Beschaffung 

einer fremden ID anfällig für missbräuchliche Zugriffe. Es muss demzufolge eine 

serverseitige Nutzerauthentifizierung mit einer UserID und einem geheimen Passwort 

stattfinden. Ist der Nutzer authentifiziert, muss dieser noch autorisiert werden, um 

bestimmte Dienste buchen zu können. Eine Nutzerauthentifizierung erfordert sowohl 

eine client- als auch eine serverseitige Anpassung. Ebenso muss die Dienstbuchung 

über eine gesicherte, verschlüsselte Verbindung erfolgen, um missbräuchliche Nutzung 

zu verhindern. 

Zusammenfassend werden als Anforderungen an das Dienstbuchungssystem folgende 

Punkte festgelegt: 

• Buchung des Dienstes über eine vom WEITBLICK-Projekt entwickelte 

Kommunikations-Middleware 

• Sicherstellung der Authentizität und Integrität der zu buchenden Dienste 

• Authentifizierung des Nutzers 

• Gesicherte Übertragung der Dienstbuchung 

4.2 Struktur des Dienstbuchungssystems 

Die im letzten Abschnitt festgelegten Anforderungen erfordern eine getrennte Betrachtung 

der Client- und Serverseite des Dienstbuchungssystems, wie in Abb. 4.1 dargestellt. 

QR Code 

1##Kaeefahrt##49-1234-5678 Smartphone 

Android OS 

Internet über WLAN,UMTS 

Internet 

Client 

gagarin.e-technik.tu-ilmenau.de 

JMS Nachricht 

mit UserLogin+ServiceID 

JMS Nachricht 

mit Bestätigung 

SQL Anfrage 

mit ID 

SQL Antwort 

mit Dienst 

openMQ Server 

Queue: DVB_Rueckkanal 

mySQL Server 

Dienstserver 

Server 

Abbildung 4.1: Struktur des Dienstbuchungssystems 



Für die Anfrage und Buchung eines Dienstes muss das Smartphone über WLAN 

bzw. UMTS mit dem Internet (als gemeinsamer Übertragungskanal von Client und 

Server) verbunden sein. Der zentrale Server ist über einen festen Hostnamen (hier 

gagarin.e-technik.tu-ilmenau.de) über das Internet erreichbar. Auf diesem Server laufen 

verschiedene Anwendungen, mit denen der Android Client über einen bestimmten Port 

kommuniziert. Zur Vereinfachung werden im Folgenden die einzelnen Anwendungen als 

einzelne Serverinstanzen betrachtet, obwohl diese gemeinsam auf dem zentralen Server 

unter gagarin.e-technik.tu-ilmenau.de erreichbar sind. 

4.2.1 Client des Dienstbuchungssystems 

Die Clientseite besteht aus dem QR Code, in dem der Dienst codiert ist, und dem 

Android Client mit der WEITBLICK App. Die Erzeugung des QR Codes muss bereits 

im Produktionsstudio erfolgen und in das Fernsehbild mit eingeblendet werden. Eine 

einfache Möglichkeit die QR Code-Generierung in digitale Compositing-Systeme 1 zu 

implementieren wird in Abschnitt 4.4 erläutert. 

4.2.1.1 Konventionen zur Generierung des QR Codes 

Um sowohl für die Generierung als auch für die Interpretation der QR Codes ein einheitliches 

Format zu schaffen, müssen für die in den QR Code codierten Informationen 

Konventionen getroffen werden. Der Inhalt wurde bereits in 3.2.2 ausreichend diskutiert. 

Dieser besteht aus einer fünfstelligen ID, einem Kurztitel sowie einer Telefonnummer 

aus insgesamt 55 Zeichen. Nachdem der QR Code vom Smartphone eingescannt 

wurde, liegt der Inhalt als Zeichenkette vor. Um ID, Kurztitel und Telefonnummer 

voneinander trennen zu können, sind Trennzeichen zwischen den Inhalten einzufügen. 

Der Aufbau des QR Code-Inhalts setzt sich für einen Dienst beispielhaft wie folgt zusammen: 

1##Kaffeefahrt##49-1234-5678 

(Dienst mit ID=1, Kurztitel=“Kaffeefahrt“ und Telefonnummer ” 49-1234-5678“) 

4.2.1.2 Android als mobiles Betriebssystem 

In Kapitel 3 wurde bereits vorweggenommen, dass es sich bei der WEITBLICK App 

um eine Anwendung handelt, die auf dem mobilen Betriebssystem Android OS basiert. 

Android ist ein von Google veröffentlichtes Betriebssystem für mobile Endgeräte 

wie Smartphones, Netbooks und Tablets. Google hat sich mit 33 anderen Mitgliedern 

der Open Handset Alliance zum Ziel gesetzt ein frei verfügbares und quelloffenes Betriebssystem 

zu entwickeln. Hersteller von mobilen Endgeräten können Android für 

ihre Geräte kostenlos verwenden. Laut einer Marktforschungsstudie der Firma Canalys 

kletterte der Marktanteil an Smartphone-Neuverkäufen von Android mit 32,9% an 

1 Compositing bezeichnet das Zusammenmischen verschiedener Bildteile 



erste Stelle, womit die Neuverkäufe von Android-Smartphones vor Nokias Symbian 

und RIMs Blackberry liegen [Can11]. 

Aus technischer Sicht besteht Android aus dem Betriebssystem, einem Anwendungs- 

Framework und zahlreichen Schlüsselanwendungen (Telefonieanwendung, Kontaktmanager, 

Kalender, Internetbrowser usw.). Es baut auf einem Linux Kernel 2.6 auf. Die 

Laufzeitumgebung ist auf der virtuellen Maschine Dalvik Virtual Machine (DVM) realisiert. 

Die DVM wurde von einem Google Mitarbeiter namens Dan Bornstein entwickelt. 

Im Gegensatz zur Java Virtual Machine (JVM) führt sie einen vorher konvertierten 

DEX-Bytecode (DEX = dalvik executables) anstelle eines Java Bytecodes aus. [BP09, 

S. 17 f.] Aus diesem Grund und dem der fehlenden Namensgebung ” Java“, umgeht 

Android lizenzrechtliche Probleme mit dem Lizenzinhaber Oracle 2 . 

Für die Entwicklung einer Android Applikation wird der Quellcode wie üblich in Java 

geschrieben, ein normaler Java Compiler übersetzt diesen Code und das Tool ” dx“ des 

Android Standard Development Kit (SDK) konvertiert die Java-compilierte .class in 

den Android-üblichen DEX-Bytecode. Damit kann jede Java-Entwicklungsumgebung 

zur Erstellung einer Android Applikation verwendet werden. Benötigt wird neben einer 

Java-SDK zusätzlich die Android-SDK, die von der offiziellen Android Developers 

Homepage unter [Goo11] zu beziehen ist. Zur Entwicklung der Android WEITBLICK 

App wurde die quelloffene, integrierte Entwicklungsumgebung Eclipse verwendet. Für 

eine Installationsanleitung des Android-SDK, eine API-Dokumentation (API steht für 

Application Program Interface) sowie Codebeispiele und alle weiteren Hinweise zur 

Android Entwicklung sei an dieser Stelle auf die offizielle Android Developers Homepage 

[Goo11] verwiesen. Dies gilt folgend für alle weiteren Android Erläuterungen, falls 

nicht anders vermerkt. 

4.2.1.3 Fehlende Java-Bibliotheken 

Mobile Endgeräte wie Smartphones, Netbooks und Tablets sind für den mobilen Betrieb 

ausgelegt. Daher sind sie in ihren Ressourcen, wie bspw. einer begrenzten Akkulaufzeit 

sowie einer beschränkten Rechenleistung und einem beschränkten Speicher, 

limitiert. Android wurde daher für einen möglichst ressourcensparsamen Betrieb optimiert. 

Folglich wurde nicht die vollständige Java-API übernommen. 

Demnach wurde bei der Erstellung der WEITBLICK App festgestellt, dass die für die 

Erstellung einer JMS-Nachricht zwingend benötigte javax.naming Bibliothek von Android 

nicht unterstützt wird. Eine einfache Einbindung aus der Java-API schlägt fehl, 

da es unter den Paketen zu viele Abhängigkeiten gibt. 4.2.2.1 erläutert den Standard 

JMS und wie der Android Client trotz fehlender Unterstützung mit der Middleware 

kommuniziert. 

Die Dienstabfrage soll der Android Client wie in Abb. 4.1 über SQL-Datenbankabfrage 

an einen mySQL-Datenbankserver stellen. Eine solche externe SQL Anfrage 

stellt für einen Android-Client einen besonders ressourcenintensiven Prozess dar und 

wird aus diesem Grund nicht unterstützt. Für die Speicherung lokaler Daten stellt 

Android stattdessen eine lokale, ressourcensparsame, relationale Datenbank SQLite 

2 ursprünglich Sun, wurde Anfang 2010 aber von Oracle übernommen 



bereit. Eine Dienstanforderung über eine externe Datenbank wurde nichtsdestotrotz 

über einen Web-Service in Form eines PHP-Skripts 3 , wie in 4.2.2.2 erläutert, realisiert. 

4.2.2 Server des Dienstbuchungssystems 

Aus dem Schluss des letzten Abschnitts sind aufgrund fehlender Java-Bibliotheken 

im Android System Anpassungen an die Serverstruktur des Dienstbuchungssystem 

nötig, damit der Android Client sowohl für die Abfrage als auch für die Buchung 

des Diensts mit dem Server kommunizieren kann. Beide Anpassungen schalten eine 

weitere Serverinstanz zwischen Client-openMQ Server und Client-SQL Server. Das 

Dienstbuchungssystem wird dann wie folgt erweitert: 

QR Code 

1##Kaeefahrt##49-1234-5678 

Client 

Internet 

Smartphone 

Android OS 

Internet über WLAN,UMTS 

HTTPS Anfrage (SSL) 


HTTPS Antwort (SSL) 


HTTP Anfrage 

mit ID 

HTTP Antwort 

mit Dienst 

gagarin.e-technik.tu-ilmenau.de 

UMS Server 

Tomcat Webserver 

PHP-Skript 

HTTP Webserver 

JMS Nachricht 


JMS Nachricht 


SQL Anfrage 

mit ID 

SQL Antwort 

mit Dienst 

Server 

openMQ Server 

Queue: DVB_Rueckkanal 

mySQL Server 

Dienstserver 

Abbildung 4.2: Erweiterte Struktur des Dienstbuchungssystems 

Die Erweiterung liegt einem sogenannten RESTful Interface zu Grunde. REST steht 

für Representational State Transfer und beschreibt ein Softwarearchitektur-Prinzip, 

durch das Web-Anwendungen auf möglichst einfache Weise miteinander kommunizieren 

können. Dabei sollen die Anwendungen mittels einfacher HTTP-Verbindungen 

Ressourcen (im Begriff einer Informationsressource) austauschen können. Es ist daher 

ressourcenorientiert und benutzt, je nachdem welche Aktion mit der entsprechenden 

Ressource durchgeführt werden soll, die HTTP Methoden POST, GET, PUT oder DE- 

LETE. Folglich kann eine große Anzahl an unterschiedlicher Clients mit dem auf dem 

REST-basierten Web-Service kommunizieren. Mittlerweile verwenden zahlreiche Web- 

Services eine solche Schnittstelle. Bspw. stellt die Suchmaschine Google bzw. Google 

Maps eine RESTful Interface API zur Verfügung. Suchanfragen können dann mittels 

einfacher und schneller HTTP Anfragen gesendet und empfangen werden. [Rod08] 

Die Struktur des WEITBLICK Dienstbuchungssystem wurde damit um ein RESTful 

Interface erweitert. 

3 PHP bezeichnet eine serverseitig interpretierte Skriptsprache 



4.2.2.1 UMS- und openMQ-Server als eigentliches Dienstbuchungssystem 

Um über das Dienstbuchungssystem einen Dienst buchen zu können, muss an die 

openMQ Middleware eine JMS Nachricht geschickt werden. JMS steht für Java Message 

Service und stellt einen auf Java basierenden Standard dar, der eine standardisierte, 

asynchrone Nachrichtenübertragung zwischen einer MOM (aus Abschnitt 4.1) 

und Clients definiert. Da JMS einen API Standard und keinen Protokollstandard beschreibt, 

können alle Clients, die ein JMS Interface implementieren, mit der MOM 

kommunizieren [Ora11a, S. 26]. 

Abbildung 4.3: Architektur eines Universal Message Service (UMS) (entnommen aus 

[Ora11b]) 

OpenMQ stellt für Anwendungen, deren Clients kein JMS Interface implementieren, 

einen sogenannten Universal Message Service (UMS) bereit. Wie in Abb. 4.3 zu sehen, 

fungiert das UMS Interface dabei als transparente Instanz zwischen den Non-JMS- 

Clients und dem JMS Provider 4 . Der UMS stellt für die Clients dabei ein RESTful 

Interface dar. Mittels der UMS-API greifen die Clients auf das UMS zu, das diese 

HTTP Anfragen in eine JMS Nachricht konvertiert und an den JMS Provider weiterleitet. 

Damit kann fast jede Anwendung mit der Zuverlässigkeit und sicheren Zustellung 

eines JMS Services mit der openMQ kommunizieren. Zur Einrichtung und Konfiguration 

ist ein Apache Tomcat Server nötig. Der Tomcat Server ist eine Art Webserver, 

der Java Servlets bzw. JavaServer Pages ausführen kann. Dies sind serverseitige, in 

Java-geschriebene Applets 5 , die auf Anfragen aus dem Internet einen dynamischen Inhalt 

generieren und ausgeben. Das UMS stellt einen solchen Servlet-Container bereit, 

welcher auf dem Tomcat Server installiert und konfiguriert werden muss. Für genaue 

Hinweise zur Installation und Konfiguration des UMS und Tomcat Servers sei hier auf 

die Dokumentationen [Ora11b] und [The11] verwiesen. 

Ein JMS Provider kann die Nachrichten der Clients auf zwei verschiedene Arten 

synchron bzw. asynchron empfangen und senden. Es wird dabei zwischen der point-topoint-Verbindung 

und der publish/subscribe-Verbindung unterschieden. Abb. 4.4 verdeutlicht 

den Unterschied beider Übertragungsarten. 

4 hier der openMQ Server, wird oft auch als Broker bezeichnet 

5 Applet = Mischung aus Application und Snippet (dt. ” Schnipsel“) 



Abbildung 4.4: JMS Nachrichten Domänen (entnommen aus [Ora11a, S. 27]) 

Die elementaren Bestandteile einer JMS Anwendung sind Messages, Messageproducer 

und -consumer, Connections, Destinations und Sessions. Bei der point-to-point- 

Verbindung eröffnet ein Messageproducer eine Session mit einem Broker und sendet 

mehrere Nachrichten an eine Queue (engl. Warteschlange). Die Nachrichten können 

dann von mehreren Messageconsumern abgeholt werden. Keiner der Messageconsumer 

erhält die gleiche Nachricht. Im Gegensatz dazu werden bei einer publish/subscribe- 

Verbindung die an ein Topic gesendeten Nachrichten an alle Messageconsumer (hier: 

die Subscriber des Topics) weitergeleitet. [Ora11a, S. 27 f.] 

Die Middleware des WEITBLICK-Projekts verwendet bei der vorliegenden Aufgabenstellung 

eine point-to-point-Verbindung. Die Nachrichten, in denen sich die Buchungen 

der Dienste befinden, werden an eine bestimmte Queue (hier: ” DVB Rueckkanal“ ) 

gesendet. Die Nachrichten in der Queue werden folglich von einem Messageconsumer 

synchron bzw. asynchron abgeholt, um die Buchungsanforderung des Nutzers weiter 

zu verarbeiten. 

Zur Buchung eines Dienstes ist es zudem nötig, dass der Nutzer serverseitig vom 

Dienstbuchungssystem authentifiziert und zur Buchung eines Dienstes autorisiert wird. 

Demnach muss sich der Nutzer mit einem UserLogin authentifizieren. Beim JMS Standard 

erfolgt die Authentifizierung bei der Erstellung einer Connection. Hierbei muss ein 

beim JMS Provider angelegter UserLogin (mit User und Passwort) angegeben werden, 

um anschließend eine Session zu eröffnen. Der UMS Server des erweiterten Dienstbuchungssystem 

wurde so konfiguriert, dass die Clients sich über das REST Interface 

authentifizieren müssen. Nach der UMS-API (siehe [Ora11b]) wird der Benutzername 

und das Passwort direkt als Schlüsselwertpaar übergeben. 

Die HTTP-POST Nachricht, die vom Android Clienten an den UMS gesendet wird, 

sieht für die Dienstbuchung folgendermaßen aus: 

Listing 4.1: Buchung des Dienstes als HTTP Request 

1 POST /imqums/ simple ? s e r v i c e=send&d e s t i n a t i o n=DVB Rueckkanal&u s e r=Hans&password=Dampf 

HTTP/ 1 . 1 

2 Content−Type : t e x t / p l a i n ; c h a r s e t=UTF−8 

3 Host : g a g a r i n . e−t e c h n i k . tu−ilmenau . de : 8 4 4 3 



4 

5 WEITBLICK 

Ein HTTP Post teilt sich in die beiden Teile Header und Body. Die erste Zeile beinhaltet 

die Art dieses HTTP Requests ( ” POST“ ), dessen Zielpfad des Servers ( ” imqums“ 

), den aufrufenden API-Befehl ( ” simple“ ) mit den dazugehörigen Attributen als 

Schlüsselwertpaare im sogenannten HTTP Query String und schließlich die verwendete 

HTTP Protokollversion. Die weiteren Headers legen die Art des Inhalts (Text 

im Zeichensatz UTF-8 ) und den Host als Zielserver (gagarin.e-technik.tu-ilmenau.de 

mit Port 8443 ) fest. Der Body ist der Inhalt der Nachricht ( ” WEITBLICK“) und wird 

von den Headers durch eine Leerzeile getrennt. In diesem Beispiel wird die Funktion 

send aus der UMS-API (siehe [Ora11b]) mit den Attributen destination, user und 

password aufgerufen. Durch einen send-Request wird der Body der HTTP Nachricht 

durch den UMS in eine JMS TextMessage umgewandelt und an die im HTTP Query 

String angegebene Destination, die in diesem Fall die im JMS Provider angelegte 

Queue ” DVB Rueckkanal“ bezeichnet, gesendet. Die ebenfalls im Query angegeben Logindaten 

benutzt der UMS, um sich beim JMS Provider einzuloggen und den Nutzer 

zu authentifizieren. Wurde die Operation erfolgreich durchgeführt, d. h. der Nutzer erfolgreich 

authentifiziert und autorisiert (vorausgesetzt die nötigen Rechte sind gesetzt), 

so sendet der UMS dem Android Client eine Bestätigung: 

Listing 4.2: HTTP Bestätigungsantwort vom UMS an den Android Client 

1 HTTP/ 1 . 1 200 OK 

2 S e r v e r : Apache−Coyote / 1 . 1 

3 ums . s e r v i c e : s e n d r e p l y 

4 ums . d e s t i n a t i o n : DVB Rueckkanal 

5 ums . domain : queue 

6 ums .mom: openmq 

7 ums . s t a t u s : 200 

8 Content−Type : t e x t / p l a i n ; c h a r s e t=UTF−8 

9 Content−Length : 0 

10 Date : Thu , 24 Mar 2011 1 7 : 4 3 : 2 2 GMT\ r \n 

Jeder HTTP Request wird vom Server mit einer Statusnachricht beantwortet. Diese 

enthält einen der in der HTTP Spezifikation festgelegten HTTP Statuscodes. In diesem 

Fall wurde vom UMS die HTTP Anfrage mit dem Statuscode 200 beantwortet, der für 

eine erfolgreich übertragene Operation steht. Die HTTP Antwort des UMS enthält 

keine Information, dafür zusätzliche Headers, die Auskunft über den Status der JMS 

Connection geben (hier Zeile 3-7). So zeigt der zusätzliche Header ” ums.status“ einen 

erfolgreichen Transfer des Service Requests ” send reply“ (Header ” ums.service“ ) an die 

Destination ” DVB Rueckkanal“ (Header ” ums.destination“ ) an. Um dementsprechend 

feststellen zu können, ob der Dienst richtig gebucht wurde, muss sowohl der HTTP 

Header als auch der zusätzliche Header ” ums.status“ auf den Statuscode 200 geprüft 

werden. 

Bei der Buchung eines Dienstes gibt es zusätzlich noch einen sicherheitsrelevanten 

Aspekt zu betrachten. Die Übermittlung von HTTP Requests findet unverschlüsselt 

statt, womit das HTTP Protokoll als unsicher gilt. Werden also sicherheitssensible 

Daten wie Passwörter bzw. Logindaten übertragen, so könnten diese Daten durch 

einen ” Man-in-the-Middle“ -Angriff ausgespäht werden [Sch06, S. 243]. Leicht möglich 

wäre dies bspw., wenn sich der Nutzer in einem unverschlüsseltem WLAN-Netzwerk 



befindet und einen Dienst bucht. Dabei würde ein Angreifer den Netzwerkverkehr 

mithören und die Logindaten, die sich im Klartext in der HTTP POST Nachricht 

befinden, auslesen und missbräuchlich nutzen können. Es muss daher bei der Buchung 

eines Dienstes eine sichere, verschlüsselte Verbindung verwendet werden. Dazu eignet 

sich die Verwendung des HyperText Transfer Protocol Secure (HTTPS) Protokolls. 

HTTPS verwendet das Verschlüsselungsprotokoll Secure Sockets Layer (SSL) 6 und 

wird genutzt, um sowohl den Verbindungspartner zu authentifizieren als auch um eine 

verschlüsselte Verbindung aufbauen zu können. [Int11a] Um eine Verbindung über 

HTTPS herstellen zu können, muss auf dem Server ein Zertifikat installiert und dieser 

entsprechend konfiguriert werden. Damit kann sich der Server gegenüber dem Client 

authentifizieren. Nach Aufruf einer HTTPS Seite im Browser eines Clients wird der 

Nutzer aufgefordert das SSL Zertifikat des Servers zu installieren. Darüberhinaus gibt 

es die Möglichkeit sich von Zertifizierungsstellen, den CA (Certification Authority), 

ein zertifiziertes Zertifikat ausstellen zu lassen. Diese sind bei Internetbrowsern schon 

vorinstalliert, sodass dem Nutzer beim Aufrufen der Seite ein Dialog zur Bestätigung 

der Zertifikatinstallation erspart bleibt. Eine HTTPS Verbindung wird durch einen 

SSL Handshake auf Basis eines asymmetrischen Verschlüsselungsverfahrens initiiert. 

Mit dem dadurch generierten Sitzungsschlüssel wird zwischen dem Client und dem 

Server eine verschlüsselte Verbindung aufgebaut. [BP09, S. 293] 

Im vorliegenden Usecase muss zur verschlüsselten Übertragung der Buchung eine 

HTTPS Verbindung zwischen dem Android Client und dem UMS Server aufgebaut 

werden. Dazu ist es notwendig den für das UMS verwendeten Tomcat Server für die SSL 

Verbindung zu konfigurieren. Es wird ein von der TU Ilmenau CA erstelltes Zertifikat 

verwendet, wodurch sich das Dienstbuchungssystem gegenüber dem Android Client als 

vertrauensvolle Instanz der TU Ilmenau CA authentifizieren kann. 

4.2.2.2 SQL Server als Dienstserver 

Die bereits in Abschnitt 4.2.1.3 erwähnte fehlende Unterstützung von externen SQL- 

Anfragen beim Android System erfordern Anpassungen der Serverstruktur des Dienstbuchungssystem 

wie in Abb. 4.2 gezeigt. Demnach wird zwischen Android Client und 

openMQ-Server ein HTTP Webserver geschalten, welcher dem Android Client als ein 

vereinfachtes RESTful Interface (siehe 4.2.2.1) dient. Nachdem das Smartphone den 

QR Code eingelesen und daraus eine ID geparst hat, wird diese mittels einer HTTP 

Anfrage an den HTTP Webserver (ebenfalls erreichbar unter gagarin.e-technik.tuilmenau.de) 

gesendet. Ein auf dem Webserver gespeichertes PHP-Skript (Voraussetzung 

für den Webserver ist ein installiertes PHP-Modul) bildet einen Web-Service. 

Dieser stellt, basierend auf der in der HTTP Nachricht enthaltenen ID, eine dynamische 

SQL Anfrage an den mySQL-Server. Der SQL-Server (der eigentliche Dienstserver) 

wählt den angeforderten Dienst-Datensatz aus und gibt diesen an das PHP-Skript zurück, 

welches den Datensatz ausgibt. Die Ausgabe erhält der Android Client wiederum 

als HTTP Nachricht, die den angefragten Dienst anzeigt und weiter verarbeitet. 

Die SQL-Tabelle des SQL-Servers als Dienstdatenbank ist wie folgt aufgebaut: 

6 SSL wird ab Protokollversion 3.1 unter dem Namen Transport Layer Security (TLS) verwendet 



weitblick services 

Feld Typ 

ID int(5) 

title varchar(100) 

shorttitle varchar(30) 

descr varchar(5000) 

date datetime 

duration double 

costs int(5) 

phonenr varchar(20) 

Tabelle 4.1: SQL-Tabelle des mySQL-Servers als Dienstserver 

Jeder Datensatz bzw. Dienst der SQL-Tabelle 4.1 erhält durch das Attribut ” primary 

key“ (des Feldes ID) eine eindeutige ID. Die weiteren Felder dienen der Beschreibung 

des Dienstes, die das PHP-Skript über die folgende SQL-Anfrage abfragt: 

Listing 4.3: SQL Anfrage im PHP-Skript 

1 $myquery = " SELECT title , descr , DATE_FORMAT (date , ’%e.%c.%y um %k:%i Uhr ’) AS fdate , 

costs , phonenr , duration 

2 FROM weitblick_services 

3 WHERE id=’" . $id . "’" ; 

4 

5 $ r e s u l t=mysql query ( $myquery ) or d i e ( m y s q l e r r o r ( ) ) ; 

6 $output [ ] = m y s q l f e t c h a s s o c ( $ r e s u l t ) ; 

Durch die SQL Anfrage in Zeile 1-3 wird aus der SQL-Tabelle weitblick services ein 

Dienst (basierend auf der in Zeile 3 übergebenen ID) mit den Informationen Titel, 

Beschreibung, Zeitangabe, Kosten, Telefonnummer und Dauer abgefragt. Die ID wird 

vorher auf den Datentyp geprüft (siehe im Anhang unter A.1), um das Skript vor 

sogenannten SQL-Injections 7 zu schützen. Die Ergebnisse der SQL Anfrage werden im 

Array $output[] gespeichert und weiterverarbeitet. 

4.3 Die WEITBLICK CodeScanner App 

Nach Erläuterung der Struktur und der Serverseite des Dienstbuchungssystems im 

letzten Abschnitt, wird im Folgenden auf die Entwicklung der Android WEITBLICK 

App eingegangen, mit der der Nutzer interagiert und einen Dienst buchen kann. Dabei 

wurde folgende Entwicklungsumgebung verwendet: 

• Testgerät HTC Wildfire 

• Android 2.2.1 (Froyo) 

• Eclipse IDE (Helios) mit Android Development Tools (ADT) - Plugin 

7 Eine SQL-Injection bezeichnet einen Angriff bei dem versucht wird einen bösartigen Code einzu- 

schleusen 



• Android SDK Plattform Android 2.2, API 8 

• Testen und Debuggen der App auf dem direkt per USB angeschlossenen HTC 

Wildfire 

Zur Erläuterung der Entwicklung der WEITBLICK App ist es notwendig auf die 

Grundlagen des Android Systems und die Android Programmierung einzugehen. Dies 

hat keinen Anspruch auf Vollständigkeit und ist lediglich auf die für das Verständnis 

nötigen Grundlagen eingeschränkt. Für eine vollständige Referenz zum Thema Android 

Programmierung sei hiermit auf die offizielle Android Developers Homepage unter 

[Goo11] verwiesen. Die Informationen aus diesem Abschnitt entstammen dieser Referenz. 

4.3.1 Android Grundlagen 

Um eine Applikation für Android entwickeln zu können, sind neben der eigentlichen 

Programmiersprache Java noch weitere Kenntnisse über die Android Systemarchitektur 

nötig. Abb. 4.5 gibt dazu einen Überblick. 

Abbildung 4.5: Android Systemarchitektur (entnommen aus [Goo11]) 

Die unterste Ebene bildet den schon in 4.2.1.2 erwähnten Linux Kernel, der die 

Schnittstelle zwischen Software und Hardware darstellt. Er kümmert sich um die Sicherheit, 

das Speicher-, Prozess- und Netzwerkmanagement sowie die nötigen Gerätetreiber 

der Systemkomponenten. Darüber folgen verschiedene Bibliotheken mit dem 

Hauptbestandteil der Android-Laufzeitumgebung DVM mit den aus der Java-API 

übernommenen Kernbibliotheken. Die oberen beiden Schichten bilden das Application 

Framework mit Schlüsselanwendungen für Telefonie, Kontaktverwaltung, Internetbrowser 

usw. Diese (Key-)Applications, wie auch Anwendungen Dritter, benutzen 



beide die gleichen Funktionalitäten aus dem Application Framework, womit alle Anwendungen 

ersetzt werden können. Somit kann jede Anwendung bspw. auf die Gerätehardware 

oder die aktuelle Geoposition (GPS-Modul) zugreifen sowie einen Anruf 

tätigen oder auch eine SMS senden. Dadurch ergeben sich für Entwickler eine Vielzahl 

von Anwendungsmöglichkeiten, welche die Entwicklung innovativer Anwendungen erlauben. 

4.3.1.1 Android Manifest 

Das Android Manifest ist eine XML-Datei im Root (engl. Stammverzeichnis) des 

Projektverzeichnisses, welche Android Anwendungen in ihren Komponenten (mit deren 

Eigenschaften) sowie Anforderungen der gesamten Application beschreibt. Als 

Anwendungs-Komponenten werden folgende bezeichnet: 

• Activities 

• Services 

• Broadcast Receiver 

• Content Provider 

Das Manifest der CodeScanner App sieht wie folgt aus: 

Listing 4.4: Das Android Manifest der CodeScanner App 

1 

2 

6 

7 

8 

9 

10 

11 

13 

14 

15 

16 

17 

18 

19 

Aus den XML-Tags ist ersichtlich, dass die CodeScanner App als Komponente nur eine 

einzige Activity (siehe 4.3.1.2) besitzt. Die Anwendung trägt den im Attribut android:label 

gespeicherten Wert ” CodeScanner“. android:icon zeigt auf eine Ressource 

(im Abschnitt 4.3.1.3 wird darauf genauer eingegangen), in der sich das Launcher-Icon 

(Startsymbol auf dem Android-“Desktop“) befindet. Als Eigenschaft bzw. Fähigkeit 

der Activity wird hier ein aufgeführt. 



Intents sind eine Art Anfragen, die an die eigene oder eine externe Anwendung 

(die ebenfalls auf dem Android Smartphone installiert ist) gestellt werden. Als Eigenschaften 

besitzen Activities u. a. . In diesen werden Bedingungen 

für ein Intent festgelegt, durch das die Activity gestartet werden soll. Wird ein Intent 

durch eine App abgeschickt, so sucht das System eine Activity bzw. Application mit 

einem passenden aus und ruft diese auf. Kommen mehrere Activities 

bzw. Anwendungen in Frage, so bietet Android eine Auswahl derer an. Diese Art 

von Intents werden implizite Intents genannt, weil diese eine abstrakte Angabe der 

auszuführenden Operation beinhalten und damit in den Raum“ gestellt werden. Ein 

” 

Anruf kann bspw. durch das Abschicken eines impliziten Intents mit dem Inhalt an- 

” 

droid.intent.action.CALL“ getätigt werden, wodurch sich die Telefonie App mit einem 

Anruf an die übergebene Telefonnummer öffnet. Daneben gibt es noch den Typ der 

expliziten Intents. Dabei wird eine konkrete Klasse aufgerufen, die eine neue Activity 

startet. 

Im -Tag wird das Android Manifest selbst definiert. xmlns:android legt 

den Namespace der XML-Datei fest, der die verwendbaren beschreibt. Zudem 

stehen im der Java-Package Name und die Versionsinformationen zur Application. 

Anhand des android:versionCode wird eine Versionsnummer relativ zur 

vorhergehenden Version und mit android:versionName ein für den Nutzer ersichtlicher 

Versionscode festgelegt. 

Weitere in der festzulegende, wichtige Eigenschaften der Application 

sind die Berechtigungen der Anwendung - die Permissions. Standardmäßig hat eine 

Anwendung nach dem Android Application Framework keine Berechtigungen, um auf 

Systemkomponenten zuzugreifen. Für jede Aktion muss daher im Manifest eine Permission 

eingetragen werden, was für einen Internetzugriff durch INTERNET“, für das 

” 

Tätigen von Telefonanrufen durch CALL PHONE“, für die Abfrage des Netzwerksta- 

” 

tus durch ACCESS NETWORK STATE“ oder für das Lesen des Telefonstatus durch 

” 

” READ PHONE STATUS“ geschieht. Möchte der Nutzer die CodeScanner App auf 

seinem Android Phone installieren, so wird er vor der Installation um die Freigabe dieser 

Berechtigungen einmalig gefragt. Dem Nutzer bleibt hiermit das ständige Erfragen 

von Berechtigungen durch ein Pop-up-Fenster erspart. 

4.3.1.2 Activities 

Eine Activity ist eine der Hauptkomponenten einer Android Application. Sie stellt für 

den Nutzer eine Präsentationsschicht, ein Graphical User Interface (GUI), dar, mit dem 

dieser interagieren kann. Eine Activity beinhaltet eine Art Ansichtsfenster (View), in 

dem wiederum einzelne UI-Elemente platziert werden. Diese Elemente sind z. B. Buttons, 

TextViews oder ImageViews, stellen Inhalte dar und können durch Aktivierung 

Aktionen ausführen. Innerhalb einer Anwendung können sich mehrere Activities befinden, 

die jeweils für sich stehen, aber miteinander agieren können. Wird eine andere 

Activity aufgerufen, so wird die aktuelle gestoppt und auf einen sogenannten ” Back 

Stack“ (engl. Stapel) gelegt. Die aufgerufene wird aktiviert und ist für den Nutzer 

sichtbar. Der ” Back Stack“ funktioniert nach dem ” Last in, First out“-Prinzip. Das 

heißt, wenn der User die ” BACK“-Taste des Smartphones drückt, wird die zuletzt auf 



dem ” Back Stack“ abgelegte Activity wieder reaktiviert und die Anzeige springt in den 

letzten Zustand zurück. Beim Stoppen einer Activity wird der Status dieser destroyed 

(engl. zerstört). Damit werden alle Objekte und Attribute, die innerhalb dieser Activity 

erstellt wurden, gelöscht. Für eine Speicherung des Activity-Status gibt es verschiedene 

Möglichkeiten dessen Zustand zu übergeben. Eine Option wäre die Callback-Methoden 

des Activity Lifecycles (siehe [Goo11]) zu überschreiben, um eine persistente Speicherung 

von bspw. Objekten durchzuführen. Destroyed wird eine Activity auch, wenn 

ein Configuration Change ausgeführt wird. Eine Änderung der Screen Orientation 8 

wäre ebenfalls ein Configuration Change und hätte eine Zerstörung der Activity zur 

Folge. Die CodeScanner Activity würde damit die Informationen eines bereits angefragten 

Dienstes verlieren und der Code müsste erneut gescannt werden. Um dies zu 

verhindern, werden die Dienstinformationen wie folgt übergeben: 

Listing 4.5: Übergabe eines Objekts bei Stoppen einer Activity 

1 @Override 

2 p u b l i c Object onRetainNonConfigurationInstance ( ) { 

3 f i n a l DataAccess data = da ; 

4 r e t u r n data ; 

5 } 

Die Lifecycle Callback-Methode onRetainNonConfigurationInstance() wird im Falle 

eines Screen Orientation Change durch @Override überschrieben. Diese Methode wird 

beim Stoppen und Zerstören der Activity aufgerufen. In Zeile 3 wird ein neues Objekt 

des Typs DataAccess erzeugt, um es persistent in einer höheren Ebene zu speichern 

und anschließend nach einem Configuration Change wieder abrufen zu können. Durch 

Aufruf der Methode getLastNonConfigurationInstance() kann das Objekt in der 

reaktivierten Anwendung dann zurück gespeichert und der Zustand (d. h. die bereits 

angefragten Dienstinformationen) wiederhergestellt werden. 

Ebenso gibt es in jeder Anwendung eine Main-Activity (definiert durch einen 

wie in A.2, Zeile 13-16), die als Einstiegspunkt 9 beim Starten einer Anwendung 

dient. Dazu muss in der Main-Activity-Klasse die onCreate(...) Methode wie im 

Programmcode unter 4.6 überschrieben werden. Eine Klasse wird durch Vererbung der 

Basisklasse Activity aus der Android-API mit public class CodeScanner extends 

Activity zu einer Activity-Klasse. 

Listing 4.6: Einstiegspunkt einer Anwendung: die onCreate(...)-Methode 

1 @Override 

2 p u b l i c void onCreate ( Bundle s a v e d I n s t a n c e S t a t e ) { 

3 super . onCreate ( s a v e d I n s t a n c e S t a t e ) ; 

4 setContentView (R. l a y o u t . codescanner ) ; 

5 

6 ( . . . ) 

7 } 

Beim Aufrufen der onCreate(...)-Methode wird ein Parameter savedInstanceState 

des Typs Bundle (ein ” Bündel“ an Datentypen) übergeben. Damit könnte ebenfalls 

ein zuvor gespeicherter Zustand einer Activity (diesmal mit der Speicherung durch 

8 falls der Nutzer sein Smartphone in der Hand dreht, ändert sich entsprechend die Screen Orientation, 

d. h. die Ausrichtung des UIs, zwischen dem Modus Portrait und Landscape 

9 vergleichbar mit public static void main (String[] args) in Java 



die Lifecycle Callback-Methode onSaveInstanceState(Bundle)) geladen werden. Die 

View der Activity wird durch setContentView(R.layout.codescanner) aus einer 

Layout-Ressource geladen. Dieses Layout (siehe 4.3.1.3) ist in der XML-Datei codescanner.xml 

definiert und befindet sich im Projektverzeichnis im Unterverzeichnis 

/res/layout. 

4.3.1.3 Application Resources 

Unter dem Begriff Resources (engl. Ressourcen) werden in der Informatik im Allgemeinen 

Quellen bezeichnet, die nichts mit dem eigentlichen, in einer Programmiersprache 

geschriebenen Quellcode zu tun haben. So werden auch in Android Ressourcen definiert, 

auf die vom Quellcode (auch: source) aus getrennt zugegriffen wird und welche 

daher auch getrennt abgespeichert werden. Als Resources werden Video-/Bildund 

Audiodateien sowie andere Inhalte wie Animationen, Menüs, UI-Styles, Farben 

und Layouts behandelt. Vorteile der getrennten Behandlung von Sourcecode und Resources 

liegen vor allem darin, Inhalte schnell verändern und die App auf die Vielzahl 

der Gerätekonfigurationen (z. B. Bildschirmauflösung, verwendete Sprache) dynamisch 

anpassen zu können. Die Resources werden als XML-Dateien erstellt und im Projektverzeichnis 

im Unterverzeichnis /res/ wiederum in einem, dem Typ der Resource 

entsprechenden, Unterverzeichnis abgespeichert. Eine Layout-Datei codescanner.xml 

befindet sich dann bspw. im Verzeichnis /res/layout/. Die Verzeichnisnamen sind 

in der Android Dokumentation [Goo11] definiert und können ebenso durch einen im 

Verzeichnisnamen zusätzlichen Qualifier für eine spezielle Gerätekonfiguration 10 konkretisiert 

werden. Je nach Gerätekonfiguration sucht sich das Android System dann die 

entsprechende Resource aus. Das Android Asset Packaging Tool (aapt) generiert eine 

Android-interne R.class-Datei, in der für alle Resource IDs erzeugt werden. Diese Resource 

IDs können dann entweder in den Resource XML-Dateien oder direkt im Code 

verwendet werden. Auf die im Android Manifest aufgeführten Namen der Anwendung 

wird durch 

@string/app name 

zugegriffen. Das @ leitet die Resource ein, string ist der Resource-Typ und app_name 

der Name der Resource. Ein Beispiel für die Referenzierung auf eine Layout-Resource 

aus dem Java-Quellcode wurde bereits im letzten Abschnitt unter 4.6 verwendet: 

setContentView(R.layout.codescanner); 

Dadurch wird beim Erstellen der Main-Activity die View initialisiert. Der Initialisierungs-Methode 

setContentView wird dabei die Resource ID R.layout.codescanner 

zu der sich im Unterverzeichnis /res/layout/ befindenden Layout-XML-Datei codescanner.xml 

übergeben. 

10 das Unterverzeichnis /res/layout-land/ definiert bspw. ein für die Screen Orientation ” Landscape“ 

angepasstes Layout 



Layout Resources und das XML-Layout Das Layout als User Interface des Android 

System wird durch die Android-Klasse android.View beschrieben. Diese dient als 

Basisklasse aller weiteren davon abgeleiteten Unterklassen wie bspw. die der View- 

Group. Diese beinhaltet voll-implementierte Basisobjekte als UI-Elemente wie Text- 

Views, Buttons, ListViews usw. Zudem dient die ViewGroup-Klasse als Basis für bspw. 

LinearLayout und RelativeLayout. 

Abbildung 4.6: Verschachtelung von UI-Elementen (entnommen aus [Goo11]) 

Durch Klassenvererbung sind UI-Elemente View-Objekte und Childs einer View- 

Group bzw. Layouts (siehe Abb. 4.6). Als View-Objekte bestimmen sie den Bereich, 

den sie innerhalb des Layouts einnehmen sowie ihre Eigenschaften. Ebenso werden User 

Interaktionen immer auf ein View-Objekt angewendet. Möglich wäre bspw. ein Event 

Listener, der auf einen Button als View-Objekt angewendet wird und beim Klicken auf 

diesen die Callback-Methode onClick(...) aufruft. Abb. 4.7 zeigt je nach Zustand der 

CodeScanner App zwei Screenshots der beiden möglichen Layouts - das Scanning- und 

das BookingLayout. 

Abbildung 4.7: Scanning- und BookingLayout des User Interface 



Das BookingLayout besteht aus vier TextViews für die Anzeige der Dienstinformationen 

(Titel, Beschreibung, Zeitangabe und Kosten) sowie drei Buttons, die jeweils 

mit einem OnClickListener belegt sind. 

Das ScanningLayout dient als Initialisierungslayout zum Einstieg in die CodeScanner 

App. Es besteht aus einer ImageView und einem Button. Durch Klicken auf den ” Code 

scannen“-Button, wird der OnClickListener aktiviert und die onClick(...) Callback- 

Methode aufgerufen, die den Scanvorgang initiiert. Damit wird die externe ZXing Barcode 

Scanner App gestartet. Der folgende Programmcode 4.7 zeigt den Teil aus der 

codescanner.xml, der das ScanningLayout definiert. 

Listing 4.7: Auszug aus codescanner.xml 

1 

2 

8 

13 

17 

18 

24 

25 

Verschachtelt in einem RelativeLayout befindet sich das Bild (das wiederum verschachtelt 

in einem LinearLayout ist, um das Bild vertikal zu zentrieren) sowie der 

Button. Das RelativeLayout hat die Besonderheit, dass sich die Child-Elemente durch 

entsprechende XML-Attribute (android:layout_above, androidParentBottom usw.) 

relativ zueinander positionieren lassen. Durch das zusätzliche ” +“ in der Angabe der 

android:id wird dem aapt-Tool (siehe 4.3.1.3) signalisiert, eine neue Resource ID 

zu erzeugen. Die Größe eines Elements wird durch die XML-Attribute android:layout_width 

und android:layout_height angegeben. Sie ist mit fill_parent/wrap_content 

entweder Elternelement-füllend bzw. Inhalts-umschließend oder kann auch 

absolut angegeben werden. Statt einer absoluten Pixelangabe empfiehlt [Goo11] hingegen 

die Einheit dip zu verwenden. Dip steht für density independent pixel und bezeichnet 

einen Pixel, der unabhängig von der Dichte des Displays des Smartphones 

ist. Ein dpi ist äquivalent zu einem Pixel auf einem 160-dpi-Bildschirm (also zu einer 

Bildschirmauflösung von 160 Pixel pro Zoll). Damit wird sichergestellt, dass auf 

jedem Smartphone die UI-Elemente unabhängig von der Displayauflösung gleich groß 

dargestellt werden. Die Umrechnung von Pixel und Dips erfolgt in Abhängigkeit der 



Displayauflösung durch die Formel pixels = dips ∗ (density/160) 11 . 

In der codescanner.xml befindet sich sowohl das Scanning- (unter 4.7) als auch das 

BookingLayout. Initialisiert wird die CodeScanner App mit dem ScanningLayout. Nach 

Scannen des QR Codes (durch die ZXing App) und Rückgabe der Ergebnisse wechselt 

das Layout zum BookingLayout. Da unabhängig vom jeweiligen Status durch setContentView(R.layout.codescanner) 

die codescanner.xml initialisiert wird, müssen 

die einzelnen Layouts ausgehend vom Quellcode gesteuert und ein- bzw. ausgeblendet 

werden. Auf die Attribute der Layouts als View-Objekte wird im Quelltext wie folgt 

zugegriffen: 

Listing 4.8: Zugriff auf UI-Elemente aus einer Layout-XML-Datei 

1 RelativeLayout l a y o u t s c a n n i n g = ( RelativeLayout ) findViewById (R. i d . l a y o u t s c a n n i n g ) ; 

2 l a y o u t s c a n n i n g . s e t V i s i b i l i t y ( View . VISIBLE ) ; 

Dazu müssen die UI-Elemente bzw. Layouts im Quellcode zunächst initialisiert (siehe 

Zeile 1) und mit der entsprechenden ID (hier: layout scanning, definiert im Programmcodeabschnitt 

4.7, Zeile 3) verknüpft werden, um anschließend auf die Methoden dieses 

UI-Elements zugreifen zu können. Je nach Zustand der CodeScanner App werden die 

Layouts mit setVisibility(...) ein- bzw. ausgeblendet. 

Andere Resources Neben den Layout-Resources verwendet die CodeScanner App 

noch weitere Resource-Typen. So werden bspw. die konstanten Datentypen Strings 

in einer String-Resource unter /res/values/strings.xml zusammengefasst. Diese 

Strings ändern sich während der Laufzeit nicht und sind damit als Resource zentral 

auffind- und veränderbar. Durch die Verlagerung der verwendeten Strings vom Quellcode 

in eine String-Resource, wäre ebenso eine Erweiterung der App auf die englische 

Sprache leicht implementierbar. Diese würde durch einen zusätzlichen Qualifier im Namen 

des Unterverzeichnis /res/values-en/ gekennzeichnet werden. Bei entsprechend 

eingestelltem Sprachraum würde das Android System die in diesem Verzeichnis deponierte 

strings.xml wählen und die speziell angepassten, englischen String-Werte 

einsetzen. 

Des Weiteren werden Grafiken unterschiedlicher Auflösungen in verschiedenen Ressourcenverzeichnissen, 

deren Name einen zusätzlichen Density Qualifier (wie hdpi, mdpi 

und ldpi) besitzt, unter /res/drawable-qualifier/ abgelegt. Android wählt hier 

wieder ein für die aktuelle Gerätekonfiguration passendes Ressourcenverzeichnis aus. 

Durch die zusätzlichen Qualifiers in den Namen der Ressourcen-Unterverzeichnisse, 

lassen sich Anwendungen erstellen, die auf eine Vielzahl von Geräten angepasst sind. 

4.3.2 Aufbau der CodeScanner App 

In Abschnitt 4.3.1.2 wurde bereits vorweggenommen, dass die CodeScanner App aus 

nur einer Main-Activity besteht. Eine Klasse ist eine Activity-Klasse, falls diese durch 

” extends Activity“ von der Basisklasse Activity erbt. Zudem muss sie als Main- 

Activity im Android Manifest durch einen speziellen (siehe A.2, 

11 Bsp.: 1 dip entspricht auf einem 240 dpi Display 1.5 physikalische Pixel (siehe [Goo11]) 



Zeile 13-16) gekennzeichnet werden. Eine Activity soll laut Definition die Präsentationsschicht 

der App darstellen, mit der der Nutzer interagieren kann. Um für die 

CodeScanner Activity eine übersichtliche und einfache Programmstruktur zu schaffen, 

wurde die CodeScanner App in folgende zwei Klassen aufgeteilt: 

Main-Activity CodeScanner Darstellung des User Interface 

• Initialisierung aller UI-Elemente 

• Initialisierung des Scanvorgangs: Aufruf der ZXing Barcode Scanner App 

• Erstellen eines DataAccess Objekts 

• Darstellung des angefragten Dienstes 

• Dialoge zur Rückmeldung geben 

• Initialisierung eines Anrufs 

• Hinzufügen eines Kalendertermins 

Datenzugriffsklasse DataAccess Durchführen von Datenzugriffsoperationen 

• Verarbeiten der Scanresults 

• Anfragen der Dienstinformationen 

• Handling der Nutzerauthentifizierung 

• Buchung des Dienstes 

Zur weiteren Übersicht wurde aus dem CodeScanner-Quellcode mit dem Eclipse- 

Plugin eUML2 der Firma Soyatec (siehe [Soy11]) ein Klassendiagramm erstellt, welches 

Abb. 4.8 zeigt. Zu sehen ist die Struktur der beiden Klassen CodeScanner und 

DataAccess. 

Neben den verwendeten Methoden- und Attributsnamen verdeutlichen die Pfeile die 

Abhängigkeiten der beiden Klassen. Die in der CodeScanner-Klasse definierten Attribute 

stellen bis auf das DataAccess-Objekt alle UI-Elemente dar, die Aktionen ausführen, 

Inhalte darstellen oder durch Pop-up-Fenster Rückmeldungen geben. Dahinführend 

wird, nach Initialisierung des Scanvorgangs (durch Aufruf der externen ZXing App) 

und Rückgabe der Ergebnisse des QR Code-Scans, ein DataAccess Objekt erzeugt. 

In diesem Objekt werden alle Informationen des Dienstes gespeichert und durch die 

DataAccess-Klasse gehandelt. Die CodeScanner Activity greift auf die im DataAccess- 

Objekt gespeicherten Informationen zu und stellt diese dar. Das Enumeration-Feld 

Status aus der DataAccess-Klasse zeigt dabei den Status der Dienstabfrage an und 

passt die Anzeige darauf an. Falls bspw. keine Internetverbindung vorhanden ist oder 

kein gültiger Code gescannt wurde, wird das Feld mStatus auf einen entsprechenden 

Wert aus der Enumeration Status gesetzt. Die Main-Activity kann dementsprechend 

den Nutzer auffordern die Internetverbindung zu überprüfen oder einen gültigen QR 

Code zu scannen. 



Abbildung 4.8: Klassendiagramm der CodeScanner App 

4.3.3 Datenzugriffsklasse DataAccess 

Nach Abschluss eines erfolgreichen Scanvorgangs wird innerhalb der CodeScanner 

Activity-Klasse ein DataAccess-Objekt erzeugt und dabei der DataAccess-Konstruktor 

aufgerufen: 

Listing 4.9: Konstruktor der DataAccess-Klasse 

1 DataAccess ( Context context , S t r i n g s c a n r e s u l t ) { 

2 mContext = c o n t e x t ; 

3 p a r s e S c a n r e s u l t ( s c a n r e s u l t ) ; 

4 } 

Dem Konstruktur werden zwei Parameter übergeben. Zum Einen ein sogenanntes 

Context-Objekt, zum Anderen das Scan-Ergebnis als String (Codierung des Inhalts 

als Text, siehe Abschnitt 4.2.1.1). Beim Context wird in Android dabei zwischen 

dem Activity-Context und dem Application-Context unterschieden. Der Context einer 

Application ist über die Laufzeit der Anwendung immer gleich und stellt für jede 

Komponente (siehe 4.3.1.1) einen Verweis auf diese dar. Der Activity-Context (durch 

Vererbung ist eine Activity ein Context-Objekt) dient dabei als Schnittstelle für die 

UI-Elemente zur Activity. Oft muss in Android der Context übergeben werden, um 



auf Methoden (bspw. zur Einblendung eines Pop-up-Fenster) oder Resources (bspw. 

String-Resources) der Main-Activity zugreifen zu können. Der Context wird neben 

den anderen Dienstinformationen in einer Membervariable 12 innerhalb des erzeugten 

DataAccess-Objekts gespeichert. Anschließend wird zur Objektinitialisierung die Methode 

parseScanresult(scanresult) mit dem QR Code String-Parameter aufgerufen. 

4.3.3.1 Methode parseScanresult(...): Parsen der Scan-Ergebnisse 

Nach dem Scanvorgang liefert die ZXing Barcode Scanner App der Main-Activity einen 

Text mit dem in den QR Code codierten Inhalt zurück. Dieser Inhalt liegt als String 

vor und muss geparst werden. Parsen bedeutet, maschinenlesbaren Code zu analysieren 

und diesen in einzelne elementare Felder, die sogenannten Tokens zu trennen. Wie 

bereits in Abschnitt 4.2.1.1 diskutiert wurde, liegt der String nach der Decodierung 

wie folgt vor: 

1##Kaffeefahrt##49-1234-5678 

Die parseScanresult(...)-Methode interpretiert das Scan-Ergebnis wie folgt: 

Listing 4.10: Methode parseScanresult(...) 

1 p r i v a t e void p a r s e S c a n r e s u l t ( S t r i n g s c a n r e s u l t ) { 

2 boolean r e s u l t = t r u e ; 

3 S t r i n g [ ] s p l i t p h o n e n r = n u l l ; 

4 

5 S t r i n g [ ] s p l i t r e s u l t = s c a n r e s u l t . s p l i t ( "##" ) ; 

6 i f ( s p l i t r e s u l t . l e n g t h==3) s p l i t p h o n e n r = s p l i t r e s u l t [ 2 ] . s p l i t ( "-" ) ; 

7 

8 i f ( s p l i t r e s u l t . l e n g t h==3 && s p l i t p h o n e n r . l e n g t h==3) { 

9 mId=new I n t e g e r ( s p l i t r e s u l t [ 0 ] ) ; 

10 mTitle=s p l i t r e s u l t [ 1 ] ; 

11 mPhonenr=" tel :+"+s p l i t p h o n e n r [0]+ " ("+s p l i t p h o n e n r [1]+ ") "+ 

s p l i t p h o n e n r [ 2 ] ; 

12 } 

13 e l s e r e s u l t = f a l s e ; 

14 

15 i f ( r e s u l t ) mStatus=Status . VALID ; 

16 e l s e mStatus=Status . INVALID ; 

17 } 

Zum Parsen wird die Methode split(String s) verwendet und das Scan-Ergebnis 

gleichzeitig auf seine Gültigkeit überprüft. Gültig ist der QR Code, wenn er nach dem 

Parsen durch die Trennzeichen ” ##“ in drei Teile, sowie die Telefonnummer als drittes 

Element nochmals in drei Abschnitte (mit ” -“ als Trennzeichen), getrennt werden kann. 

Es liegt dann ein gültiges Ergebnis vor und die Inhalte werden in die Membervariablen 

mId, mTitle und mPhonenr gespeichert. Die Telefonnummer wird dabei in das von 

der Internet Engineering Taskforce (IETF) vorgeschlagene Standardformat tel:(49) 

1234 5678 gebracht. [Int11b] Zeile 15 und 16 speichert letztlich noch den Status der 

Dienstabfrage in die Status-Membervariable. 

12 engl. Feldvariable, beginnen nach Java-Namenskonventionen mit einem kleinen m, gefolgt von einem 

großen Buchstaben 



4.3.3.2 Methode requestService(): Anforderung der Dienstinformationen 

Nach Parsen des Strings liegen nun die ID, der Titel und die Telefonnummer des 

Dienstes vor. Ist das Smartphone nicht mit dem Internet verbunden, so wird lediglich 

der Kurztitel angezeigt sowie die Möglichkeit gegeben sich mit einem Ansprechpartner 

verbinden zu lassen. Der Normalfall ist dagegen, dass eine Internetverbindung besteht 

und der Nutzer die vollständigen Dienstinformationen angezeigt bekommt. Diese auf 

der codierten ID basierenden Informationen werden, wie in Abschnitt 4.2.2.2 erläutert, 

über das PHP-Skript vom SQL Server abgefragt. 

Die Anfrage an das PHP-Skript weitblick_services.php (auf dem Webserver unter 

gagarin.e-technik.tu-ilmenau.de) erfolgt durch einen HTTP POST, dem ein Schlüsselwertpaar 

mit der ID (Zeile 6) übergeben wird: 

Listing 4.11: HTTP POST zur Anfrage der Dienstinformation über das PHP-Skript 

1 POST / w e i t b l i c k s e r v i c e s . php HTTP/ 1 . 1 

2 Host : g a g a r i n . e−t e c h n i k . tu−ilmenau . de 

3 Content−type : a p p l i c a t i o n /x−www−form−urlencoded 

4 Content−l e n g t h : 4 

5 

6 i d=1 

Der HTTP POST wird mit dem HTTP-Client, der in Android standardmäßig implementierten, 

externen Library org.apache.http.*, realisiert: 

Listing 4.12: Auszug aus Methode requestService() 

1 HttpClient c l i e n t = new D e f a u l t H t t p C l i e n t ( ) ; 

2 HttpPost post = new HttpPost (SQLHOST) ; 

3 L i s t nameValuePair = new ArrayList () ; 

4 nameValuePair . add ( new BasicNameValuePair ( "id" , mId . t o S t r i n g ( ) ) ) ; 

5 post . s e t E n t i t y ( new UrlEncodedFormEntity ( nameValuePair ) ) ; 

6 HttpResponse r e s p o n s e = c l i e n t . e x e c u t e ( post ) ; 

7 

8 HttpEntity e n t i t y = r e s p o n s e . g e t E n t i t y ( ) ; 

9 Inputstream i s = e n t i t y . getContent ( ) ; 

10 

11 BufferedReader s e r v i c e r e a d e r = new BufferedReader ( new InputStreamReader ( i s , "UTF -8" ) , 8 ) 

; 

12 S t r i n g r e s u l t=s e r v i c e r e a d e r . readLine ( ) ; 

13 i s . c l o s e ( ) ; 

Zeile 1 und 2 erstellen eine Instanz des HTTP-Clients und einen HTTP POST (mit 

der Adresse gagarin.e-technik.tu-ilmenau.de des SQL Servers). Nachdem dem HTTP 

POST das Schlüsselwertpaar mit der ID aus mId hinzugefügt wurde, wird dieser abgeschickt 

(Zeile 3-6) und die HTTP Antwort des PHP Skripts über einen InputStream 

und einen BufferedReader in einen String geladen (Zeile 8-12). Dieser beinhaltet (siehe 

PHP-Skript unter A.1) den Titel, die Beschreibung, den Zeitpunkt, die Kosten, die 

Telefonnummer sowie die Dauer des angefragten Dienst (basierend auf dem in mId gespeicherten 

Wert). Nach Parsen dieses zusammenhängenden Strings werden die einzelnen 

Datenfelder in einem Array mService des Typs ArrayList gespeichert. 

Die Dienstinformationen können durch den Zugriff auf die Array-Elemente von mService 

des erzeugten DataAccess-Objekts nun von der Activity abgerufen und angezeigt 

werden. 



Das Absenden der Anfrage kann je nach Güte der Verbindung einige hundert Millisekunden 

dauern. Die Android App wird zur Laufzeit so lange warten, bis die HTTP Anfrage 

abgeschickt und wieder eine Antwort zurückgekommen ist. Dies bedeutet gleichzeitig, 

dass das User Interface für diesen Moment stehen bleibt und nicht reagiert. 

Der Grund hierfür liegt darin, dass alle Operationen in einem einzigen Main-Thread, 

auch UI-Thread genannt, ausgeführt werden. Dies betrifft sowohl Operationen, die 

das User Interface zeichnen, als auch zeitintensive Netzwerkzugriffe wie eine solche 

Datenbankabfrage. Für den Nutzer stellt sich ein Einfrieren des UIs als ein sehr unangenehmes 

Nutzungserlebnis dar. Um das Blockieren dieses UI-Threads beim Anfragen 

der Dienstinformationen zu verhindern, wird die Datenbankabfrage in einen separaten 

Worker-Thread ausgelagert. Statt requestService() direkt aufzurufen, wird der 

Aufruf über die Methode requestServiceThread() (über einen Thread) umgeleitet: 

Listing 4.13: Methode requestServiceThread() 

1 p r i v a t e void r e q u e s t S e r v i c e T h r e a d ( ) { 

2 ( ( CodeScanner ) mContext ) . showProgressDialog ( showProgressDlgMsg .LOADSERVICE) ; 

3 // s t a r t a worker−thread 

4 Thread t = new Thread ( ) { 

5 p u b l i c void run ( ) { 

6 r e q u e s t S e r v i c e ( ) ; 

7 mHandler . post ( mUpdateBookingLayout ) ; 

8 } 

9 } ; 

10 t . s t a r t ( ) ; 

11 } 

Innerhalb dieser wird ein neuer Worker-Thread gestartet, der den zeitintensiven Datenbankzugriff 

ausführt (Zeile 4). Das Attribut mHandler startet die Runnable mUpdateBookingLayout 

(eine Art Methode), die die Funktion initBookingLayout() aus 

der CodeScanner Klasse aufruft. Um dem Nutzer eine Rückmeldung über die andauernde 

Operation zu geben, wird durch das Starten einer showProgressDialog(...)- 

Methode (Zeile 2) aus der CodeScanner Activity eine Fortschrittsanzeige angezeigt. 

4.3.3.3 Methode sendMessage(...): Buchen des Dienstes 

Nachdem der Dienst auf dem UI angezeigt wird, hat der Nutzer die Möglichkeit den 

Dienst direkt über das Internet zu buchen. Dazu müssen die Dienstinformationen mit 

der Nutzer-ID an den openMQ Server übermittelt werden. Den Inhalt der Nachricht 

formatiert die Funktion formatMessage(), die die formatierte Nachricht als String 

zurückgibt: 

Listing 4.14: Methode formatMessage() 

1 p u b l i c S t r i n g formatMessage ( ) { 

2 // i f confirmmail i s s e t to true , a booking c o n f i r m a t i o n i s s e n t by mail 

through email−gateway 

3 S t r i n g confirmmail = mContext . g e t R e s o u r c e s ( ) . g e t S t r i n g (R. s t r i n g . confirmMail ) . 

t o S t r i n g ( ) ; 

4 S t r i n g B u f f e r m = new S t r i n g B u f f e r ( ) ; 

5 m. append ( " User :"+mLogin . get ( 0 )+"; " ) ; 

6 m. append ( " ServiceID :"+mId+"; " ) ; 

7 m. append ( " ServiceTitle :"+mService . get ( 0 )+"; " ) ; 

8 m. append ( " ServiceDate :"+mService . get ( 2 )+"; " ) ; 

9 m. append ( " SendConfMail :"+confirmmail ) ; 

10 r e t u r n m. t o S t r i n g ( ) ; 


11 } 


Die zu sendenden Informationen sind in den Attributen mLogin und mService des 

DataAccess-Objekts gespeichert. Dies betrifft den vom Nutzer eingegebenen Loginnamen 

(als Login für den openMQ Server), die ID sowie den Zeitpunkt des Dienstes. 

Zuletzt wird noch ein Boolean-Wert eingesetzt, welcher anzeigt, ob die Buchung durch 

eine E-Mail-Nachricht an den Nutzer sowie den Dienstanbieter bestätigt werden soll. 

Der Boolean-Wert wird in einer String-Resource der Anwendung gespeichert, um diesen 

zentral in der Resource-Datei setzen zu können. 

Die formatierte Nachricht wird anschließend der Sende-Methode sendMessage (String 

message) übergeben. Diese baut mit dem unter 4.2.2.1 erläuterten UMS Server 

eine verschlüsselte SSL Verbindung auf und übermittelt den Inhalt der formatierten 

Nachricht durch einen HTTP POST (siehe Programmcodeabschnitt 4.1) an den UMS 

Server, der diese in einer JMS-konformen Nachricht zum openMQ Server weiterleitet. 

Um mit dem UMS Server eine gesicherte SSL Verbindung aufbauen zu können, muss 

der Tomcat Server (auf dem der UMS läuft) für die SSL Verbindung konfiguriert sein 

und ein SSL Zertifikat installiert werden. Auf Basis dieses Zertifikats findet zunächst ein 

asymmetrischer Schlüsselaustausch statt. Wie in 4.2.2.1 bereits erläutert, gibt es zertifizierte 

Zertifizierungsstellen (Certification Authority, kurz CA), wie z. B. thawte.com, 

die solche ” trusted“ Zertifikate gegen eine jährliche Gebühr ausstellen. Zertifikate der 

meisten CAs sind bereits in den Internetbrowsern sowie SDKs integriert, wodurch der 

Client vor dem Verbindungsaufbau das Zertifikat nicht mehr herunterladen muss. Das 

vorinstallierte Zertifikat wird mit dem sich auf dem Server befindlichen gegengeprüft 

und der Server damit authentifiziert. Die Zertifikate werden beim Client in einem sogenannten 

Keystore, dem Zertifikatsspeicher, aufbewahrt. Wird eine Webseite aufgerufen 

und ist das Zertifikat nicht im Keystore des Browser gespeichert, so wird der Nutzer 

aufgefordert das Zertifikat zu akzeptieren und in den Browser zu importieren. Eine 

Importierung eines Zertifikats in den Android Keystore würde ein erhebliches Sicherheitsrisiko 

darstellen, da alle anderen Anwendungen dem Server des dazugehörigen 

Zertifikats vertrauen würden. Es ist daher bei Android nicht gestattet, Zertifikate in 

den Android Keystore zu importieren. [BP09, S. 295] 

Für die WEITBLICK CodeScanner App wird ein von der TU Ilmenau CA ausgestelltes 

Zertifikat verwendet. Das Zertifikat der TU Ilmenau CA ist als Zwischenzertifizierungsstelle 

standardmäßig nicht in den Keystore der Browser und auch nicht in den 

von Android integriert. Um die CodeScanner App dennoch mit dem UMS Server über 

HTTPS kommunizieren zu lassen, muss hierfür ein eigener Keystore mit dem Zertifikat 

der TU Ilmenau CA erstellt und dieser in die App integriert werden. Dazu wird, wie 

in [BP09, S. 297-299] beschrieben, vorgegangen: 

1. Aufruf des Tomcat Webservers mit dem Internet Explorer unter https://gagarin.etechnik.tu-ilmenau.de:8443 

2. Speicherung und Konvertierung des Zertifikats in das Format ” DER-codiert-binär 

X.509 (.CER)“ 

3. Installation des Bouncy-Castle-Provider ins JDK 

Das JDK beinhaltet das Java Cryptography Extension (JCE)-Modul, welches 



ebenfalls durch das Android SDK implementiert ist. Im JCE sind Verschlüsselalgorithmen, 

die sogenannten Provider implementiert. Da Android den ” Bouncy 

Castle Provider“ verwendet, muss dieser zunächst in das JDK integriert werden, 

um mit dem JDK einen Keystore erzeugen zu können. 

4. Erstellen des Keystores mit dem Keytool des JDK 

keytool -v -import -storetype BKS -storepass KSPASS -trustcacerts -alias weitblick 

-file saved cert.cer -keystore weitblick.bks 

Der Parameter ” storetype BKS“ steht für den verwendeten ” Bouncy Castle Provider“. 

Das angegebene Passwort ” Storepass KSPASS“ wird zur Importierung 

des Keystores in die Android App benötigt. 

Die damit erstellte Keystore-Datei weitblick.bks wird in das ” /res/raw/“ Verzeichnis 

des Android-Projekts kopiert. Die Implementierung des Keystores in die Android 

App, das Herstellen der SSL Verbindung sowie das Senden der Nachricht zeigt der 

folgende Quellcode: 

Listing 4.15: Methode sendMessage(String message) 

1 p u b l i c void sendMessage ( S t r i n g message ) { 

2 s e n t = f a l s e ; 

3 f i n a l S t r i n g UMSSERVER = mContext . g e t R e s o u r c e s ( ) . g e t S t r i n g (R. s t r i n g . 

UMSSERVER) ; 

4 

5 t r y { 

6 // Creates k e y s t o r e 

7 InputStream i s = mContext . g e t R e s o u r c e s ( ) . openRawResource (R. raw 

. w e i t b l i c k ) ; 

8 KeyStore k e y s t o r e = KeyStore . g e t I n s t a n c e ( " BKS " ) ; 

9 k e y s t o r e . load ( i s , " w31tbl1ck " . toCharArray ( ) ) ; 

10 

11 // Creates SSL c o n n e c t i o n 

12 SSLSocketFactory s o c k e t F a c t o r y = new org . apache . http . conn . s s l . 

SSLSocketFactory ( k e y s t o r e ) ; 

13 s o c k e t F a c t o r y . s e t H o s t n a m e V e r i f i e r ( org . apache . http . conn . s s l . 

SSLSocketFactory . STRICT HOSTNAME VERIFIER) ; 

14 

15 f i n a l Scheme h t t p s = new Scheme ( " https " , socketFactory , 8443) ; 

16 

17 HttpClient c l i e n t = new D e f a u l t H t t p C l i e n t ( ) ; 

18 c l i e n t . getConnectionManager ( ) . getSchemeRegistry ( ) . r e g i s t e r ( 

h t t p s ) ; 

19 HttpPost post = new HttpPost (UMSSERVER+"/ imqums / simple ? service = send & 

destination = DVB_Rueckkanal & user ="+mLogin . get ( 0 )+"& password ="+ 

mLogin . get ( 1 ) ) ; 

20 post . addHeader ( " Content - Type " , " text / html ; charset =utf -8" ) ; 

21 HttpEntity e n t i t y = new S t r i n g E n t i t y ( message , "UTF -8" ) ; 

22 post . s e t E n t i t y ( e n t i t y ) ; 

23 HttpResponse r e s p o n s e = c l i e n t . e x e c u t e ( post ) ; 

24 

25 S t a t u s L i n e s t a t u s = r e s p o n s e . g e t S t a t u s L i n e ( ) ; 

26 Header umsservice = r e s p o n s e . g e t F i r s t H e a d e r ( " ums . service " ) ; 

27 Header umsstatus = r e s p o n s e . g e t F i r s t H e a d e r ( " ums . status " ) ; 

28 boolean i s s t a t u s o k = s t a t u s . t o S t r i n g ( ) . c o n t a i n s ( " 200 " ) ; 

29 boolean i s r e p l y o k = u msservice . getValue ( ) . t o S t r i n g ( ) . e q u a l s ( " 

send_reply " ) ; 

30 boolean i s u m s s t a t u s o k = umsstatus . getValue ( ) . t o S t r i n g ( ) . e q u a l s 

( " 200 " ) ; 

31 

32 

33 i f ( i s s t a t u s o k && i s r e p l y o k && i s u m s s t a t u s o k ) s e n t = t r u e ; 



34 } catch ( Exception e ) { 

35 Log . e ( " httppost " , " Error in https connection :"+e . t o S t r i n g ( ) ) ; 

36 } 

37 } 

Zunächst wird in den Zeilen 7-9 der Keystore aus der als Raw-Resource abgelegten 

Keystore-Datei geladen. Die SSLSocketFactory, die als Basis der SSL Verbindung 

dient, wird anschließend in Zeile 12 mit dem zuvor eingelesenen Keystore 

initialisiert. SSL-Zertifikate sind normalerweise an einen DNS-Namen gebunden. 

Das Zertifikat wurde für den DNS-Namen gagarin.e-technik.tu-ilmenau.de von der 

TU Ilmenau CA ausgestellt, wodurch der HostnameVerifier der SSLSocketFactory 

auf STRICT_HOSTNAME_VERIFIER gesetzt wird, um als zusätzliche Sicherheitsstufe den 

Servernamen gegenzuprüfen. Die Erzeugung eines Apache HTTP-Clients erfolgt analog 

zur requestService()-Methode (siehe Programmcodeabschnitt 4.12). Zusätzlich 

muss der Client allerdings mit dem HTTPS-Schema der SSLSocketFactory mit dem 

Keystore und dem Port 8443 (entsprechend der Konfiguration des Tomcat/UMS Servers) 

registriert werden. In Zeile 19 wird die HTTP Anfrage gemäß des POSTs im 

Programmcodeabschnitt 4.1 erstellt. Im Unterschied zum HTTP POST in der requestService()-Methode 

wird statt einem Schlüsselwertpaar ein String mit der über 

formatMessage()-erstellten Nachricht gesendet. Um zu überprüfen, ob die Nachricht 

an den openMQ Server erfolgreich übermittelt wurde, wird in Zeile 25-33 die HTTP 

Antwort des UMS Servers auf den HTTP Statuscode sowie die zusätzlichen Header 

” ums.service“ und ums.status“ untersucht und das Ergebnis in der Boolean-Variablen 

” 

sent gespeichert. Da dieser HTTP Request ebenfalls eine zeitintensive Operation darstellt 

und ein Einfrieren des UI zu vermeiden ist, wird das Ausführen dieser Operation 

über den Aufruf der sendMessageThread()-Methode in einen separaten Worker- 

Thread ausgelagert. Nach Beendigung der sendMessage()-Funktion ruft eine Runnable 

die Methode showBooked(sent) aus der Activity-Klasse auf. Dadurch wird in 

Abhängigkeit des übergebenen Boolean-Parameters über die Activity-Klasse ein entsprechender 

Buchungsbestätigungsdialog (oder im negativem Fall ein Buchungsfehler) 

angezeigt. 

4.3.4 Main-Activity CodeScanner 

Im letzten Abschnitt wurde erläutert, wie die Datenzugriffe der DataAccess-Klasse 

funktionieren. Alle angefragten Daten werden dabei in einem einzigen DataAccess- 

Objekt gespeichert. Die Aufgabe der Main-Activity CodeScanner ist es in Abhängigkeit 

von der im DataAccess-Objekt gesetzten Attribute die Inhalte entsprechend 

darzustellen. Des Weiteren gibt sie über Pop-ups bzw. Dialoge Rückmeldungen zu den 

in der DataAccess-Klasse ausgeführten Aktionen. In diesem Abschnitt wird dabei auf 

Methoden eingegangen, die für die Erfüllung der verbleibenden Teilaufgaben 


Marke 





nötig sind. Zusätzlich wurde bspw. eine addEvent()-Methode implementiert. Der 

Nutzer hat demnach die Möglichkeit den Termin der gebuchten Dienstleistung in dessen 

Kalender auf dem Smartphone eintragen und sich so automatisch an diesen erinnern 

zu lassen. Für diese und weitere Funktionalitäten sowie der Erläuterung des gesamten 

Quellcodes (siehe Kommentarzeilen) sei hiermit auf den Anhang verwiesen. 

4.3.4.1 Methode initScanningLayout(): Aufruf der externen ZXing Barcode 

Scanner App 

Nach Starten der CodeScanner App wird die onCreate(...)-Methode der Activity 

aufgerufen. Nach Initialisierung der UI-Elemente und Prüfung auf ein nicht vorhandenes 

DataAccess-Objekt wird die initScanningLayout()-Prozedur aufgerufen. Diese 

blendet das in der codescanner.xml definierte ScanningLayout ein und belegt den 

Scan-Button wie folgt mit einem onClick Listener: 

Listing 4.16: onClick Listener und Initiierung des Scanvorgangs 

1 btn scan . s e t O n C l i c k L i s t e n e r ( new View . O n C l i c k L i s t e n er ( ) { 

2 @Override 

3 p u b l i c void onClick ( View v ) { 

4 S t r i n g [ ] d l g s c a n n e r d l = g e t R e s o u r c e s ( ) . g e t S t r i n g A r r a y (R. array . d l g s c a n n e r d l ) ; 

5 I n t e n t I n t e g r a t o r . i n i t i a t e S c a n ( CodeScanner . t h i s , d l g s c a n n e r d l [ 0 ] , d l g s c a n n e r d l 

[ 1 ] , d l g s c a n n e r d l [ 2 ] , d l g s c a n n e r d l [ 3 ] , " QR_CODE " ) ; 

6 } 

7 }) ; 

Nach Klicken des Buttons wird die statische Methode initiateScan(...) aus der 

Klasse IntentIntegrator aufgerufen. Der Scanvorgang der externen ZXing Barcode 

Scanner App könnte auch mit einem einfachen Intent gestartet werden. Der Intent 

würde allerdings ins Leere laufen, falls die ZXing App nicht auf dem Smartphone installiert 

ist. Aus diesem Grund wird die Utility-Klasse IntentIntegrator aus dem ZXing 

Projekt mit in die CodeScanner App implementiert. Drückt der Nutzer den ” Code 

scannen“ -Button, so wird die statische Methode initiateScan(...) mit dem aktuellen 

Activity-Context, den Strings zur Darstellung eines Download-Dialogs und die zu 

scannende Codeart ” QR CODE“ (dadurch wird das Scannen eines QR Codes erzwungen) 

aufgerufen. Ist der ZXing Barcode Scanner nicht auf dem Smartphone installiert, 

so blendet die IntentIntegrator Klasse einen Download-Dialog mit den übergebenen 

Strings ein, welcher eine Installation der ZXing App über den Android Market initiiert. 

Nach der Installation kann der QR Code mit der CodeScanner App gescannt 

werden. 

Die initiateScan(...)-Methode der IntentIntegrator-Klasse sendet durch 

Intent intentScan = new Intent( ” com.google.zxing.client.android.SCAN“); 

startActivityForResult(intentScan, REQUEST CODE); 

einen impliziten Intent und ruft damit den Scandialog der ZXing App auf, wodurch 

die CodeScanner Activity pausiert und der Nutzer den WEITBLICK QR Code 

scannen kann. Zusätzlich wird der startActivityForResult(...)-Methode ein 



” REQUEST CODE“ vom Typ Integer übergeben. Nach Abschluss des Scanvorgangs 

schließt sich diese Activity wieder und die Scan-Ergebnisse werden an die reaktivierte 

CodeScanner Activity gesendet. Anhand des vorher übergebenen REQUEST CODE“ 

” 

wird die Rückgabe der Scan-Activity identifiziert und gehandelt. 

4.3.4.2 Verarbeiten der Scan-Ergebnisse und Erstellen eines 

DataAccess-Objekts 

Durch Starten einer anderen Activity wird durch startActivityForResult(...) statt 

mit startActivity(...) von der aufzurufenden Activity ein Ergebnis erwartet. Nach 

Beendigung dieser Activity und beim Reaktivieren der aufrufenden Activity wird in 

dieser die Methode onActivityResult(...) aufgerufen. Diese muss demnach überschrieben 

werden, um die Scan-Ergebnisse der Barcode Scanner App abzufangen: 

Listing 4.17: Überschriebene Methode onActivityResult(...): Abfangen der Scan- 

Ergebnisse und Erstellen eines DataAccess-Objekts 

1 @Override 

2 p u b l i c void o n A c t i v i t y R e s u l t ( i n t requestCode , i n t resultCode , I n t e n t i n t e n t ) { 

3 I n t e n t R e s u l t s c a n R e s u l t = I n t e n t I n t e g r a t o r . p a r s e A c t i v i t y R e s u l t ( requestCode , 

resultCode , i n t e n t ) ; 

4 i f ( s c a n R e s u l t != n u l l ) { 

5 S t r i n g mScanresult=s c a n R e s u l t . getContents ( ) ; 

6 da = new DataAccess ( t h i s , mScanresult ) ; 

7 initBookingLayout ( ) ; 

8 } 

9 e l s e Log . e ( " scan_error " , " scanning error " ) ; 

10 } 

Dabei werden durch die ZXing Activity die Integer-Werte requestCode und result- 

Code sowie ein Intent zurückgegeben, welche durch die statische Methode parseActivityResult 

aus der IntentIntegrator Klasse geparst werden. Diese überprüft den requestCode 

(ein beliebig festgelegter Integer-Wert) auf den durch die IntentIntegrator 

Klasse zuvor übergebenen ” REQUEST CODE“ und den resultCode auf den Wert 

” RESULT OK“ und gibt eine Instanz der Klasse IntentResult 13 zurück. Durch Anwendung 

der Funktion getContents() auf das IntentResult-Objekt wird im String 

mScanresult das Ergebnis des Scanvorgangs (in textueller Form) gespeichert. Folglich 

erzeugt Zeile 6 das DataAccess-Objekt da und übergibt dem DataAccess-Konstruktor 

den Activity-Context sowie den String mScanresult. Eine Instanziierung führt gleichzeitig 

zum Parsen der Scan-Ergebnisse durch die DataAccess-Methode parseScanresult(...) 

(siehe Abschnitt 4.3.3.1). 

Ab dieser Stelle der Anwendung greift die Main-Activity auf das da-Objekt zu, um 

die gescannten Daten abzufragen. Durch Abschluss des Scanvorgangs wird zuletzt noch 

das BookingLayout zur Anzeige der Dienstleistung initialisiert. 

4.3.4.3 Methode initBookingLayout(): Anzeige der Dienstleistung 

Immer dann, wenn in der Anwendung die Methode initBookingLayout(...) aufgerufen 

wird, soll das BookingLayout, wie in Abb. 4.7 gezeigt, dargestellt werden. Um 

13 diese Klasse wurde neben IntentIntegrator ebenfalls ins CodeScanner Projekt importiert 



je nach Status der Dienstabfrage einen entsprechenden Inhalt darstellen zu können, 

greift die CodeScanner Activity auf die Feldvariable mStatus des Enumerationstyp 

Status aus der DataAccess-Klasse zu. Die mStatus-Variable kann die folgenden Werte 

annehmen: ” VALID“, ” INVALID“, VALID PROCESSING und ” VALID INET“. Die 

initBookingLayout()-Methode prüft mStatus auf die Werte von Status und reagiert 

anhand einer switch(da.mStatus)-Anweisung entsprechend: 

INVALID : Der gescannte QR Code ist ungültig. Die Buttons Dienst buchen“ und 

” 

” über Telefon buchen“ werden deaktiviert und es wird eine Meldung angezeigt, 

einen gültigen Code erneut zu scannen. 

VALID NO INET : Das Smartphone ist nicht mit dem Internet verbunden. Der Button 

” Dienst buchen“ wird deaktiviert. Basierend auf dem Inhalt der im QR Code 

codierten Informationen wird die Titel-TextView mit dem Kurztitel befüllt und 

der Button ” über Telefon buchen“ mit einem onClick Listener aktiviert. 

VALID PROCESSING : Solange wie Dienst angefordert wird (innerhalb einiger hundert 

Millisekunden) nimmt das mStatus-Feld diesen Wert an. Für einen kurzen 

Moment werden die UI-Elemente mit dem Kurztitel und der Telefonnummer aus 

dem QR Code, wie beim VALID NO INET -Wert, aktiviert. 

VALID INET Dies ist der Normalfall. Der QR Code ist gültig, es besteht eine Internetverbindung, 

alle Daten zur Dienstleistung wurden abgefragt und liegen im 

Feld mService vor. Die vier TextViews werden mit den Daten Titel, Beschreibung, 

Zeitangabe und Kosten des Dienstes befüllt. Die Buttons ” Dienst buchen“ 

und ” über Telefon buchen“ wurden mit einem onClick Listener versehen. 

In allen Fällen ist die Möglichkeit gegeben, den Dienst erneut zu scannen. Der Button 

” Erneut scannen“ ist bei jedem Status aktiv und mit einem onClick Listener aktiviert, 

um die initiateScan(...) aufzurufen und einen neuen Scanvorgang zu initiieren. 

Den Wert VALID“ kann mStatus zur switch-Anweisung nicht besitzen, denn vor 

” 

Ausführung der switch-Anweisung wird in der initBookingLayout()-Methode der 

Status durch den Aufruf von setStatus() aus der DataAccess-Klasse neu gesetzt: 

Listing 4.18: Methode setStatus(): Steuerung des Ablaufs der Dienstabfrage 

1 p u b l i c void s e t S t a t u s ( ) { 

2 switch ( mStatus ) { 

3 c a s e INVALID : 

4 break ; 

5 c a s e VALID : 

6 i f ( c h e c k I n e t ( mContext ) ) mStatus=Status . VALID PROCESSING ; 

7 e l s e mStatus=Status . VALID NO INET ; 

8 s e t S t a t u s ( ) ; 

9 break ; 

10 c a s e VALID PROCESSING : 

11 r e q u e s t S e r v i c e T h r e a d ( ) ; 

12 break ; 

13 c a s e VALID INET : 

14 break ; 

15 c a s e VALID NO INET : 

16 s e t O f f l i n e S e r v i c e ( ) ; 

17 break ; 



18 } 

19 } 

Initiiert wird mStatus in der Methode parseScanresult() mit den Werten ” VALID“ 

(für einen gültigen und geparsten QR Code) oder ” INVALID“ für einen ungültigen QR 

Code (siehe Codeabschnitt 4.10, Zeile 15 bzw. 16). Im Falle von ” VALID“ wird mStatus 

nach Prüfung einer vorhandenen Internetverbindung durch checkInet() entsprechend 

auf ” VALID NO INET“ oder ” VALID PROCESSING“ gesetzt. Anschließend ruft sich 

setStatus() rekursiv erneut auf. Ist mStatus nach fehlgeschlagenem Internetverbindungscheck 

” VALID NO INET“, werden die Dienstinformationen in mService bis auf 

Titel und Telefonnummer (aus dem QR Code) durch die Funktion setOfflineService() 

mit leeren Strings befüllt. 

Wurde mStatus nach einem positiven Internetverbindungscheck auf ” VALID PRO- 

CESSING“ gesetzt, werden die Dienstinformationen durch Aufruf von requestServiceThread() 

über einen separaten Worker-Thread angefragt. Durch Auslagerung in 

einen separaten Worker-Thread arbeitet die Laufzeitumgebung den Code weiter ab 

und befüllt währenddessen durch die initBookingLayout()-Methode das Layout mit 

den im QR Code befindlichen Daten. Ist die Dienstabfrage beendet, so setzt die Runnable 

mUpdateBookingLayout aus der DataAccess-Klasse (siehe 4.3.3.2) den Wert von 

mStatus auf ” VALID INET“ und ruft initBookingLayout() erneut auf. Damit wird 

das Layout mit den nun in mService gespeicherten Dienstinformationen befüllt. 

Letztendlich setzt sich die initBookingLayout()-Methode wie folgt zusammen: 

Listing 4.19: Methode initBookingLayout() 

1 p u b l i c void initBookingLayout ( ) { 

2 l a y o u t s c a n n i n g . s e t V i s i b i l i t y ( View . INVISIBLE ) ; 

3 l a y o u t b o o k i n g . s e t V i s i b i l i t y ( View . VISIBLE ) ; 

4 

5 // to r e a c t whether scanned code i s v a l i d , i n e t i s a v a i l a b l e e t c . invoke 

s e t S t a t u s ( ) being a b l e to r e a c t to i t 

6 da . s e t S t a t u s ( ) ; 

7 

8 switch ( da . mStatus ) { 



11 t x t t i t l e . setText ( da . mService . get ( 0 ) ) ; 

12 t x t d e s c . setText ( da . mService . get ( 1 ) ) ; 

13 t x t d a t e . setText ( da . mService . get ( 2 ) ) ; 

14 t x t c o s t s . setText ( da . mService . get ( 3 )+" EUR " ) ; 

15 i f ( da . mStatus==Status . VALID NO INET) { 

16 t x t c o s t s . setText ( "" ) ; 

17 b t n b o o k s e r v i c e . setEnabled ( f a l s e ) ; 

18 } 

19 b t n b o o k s e r v i c e . setEnabled ( t r u e ) ; 

20 b t n b o o k s e r v i c e . s e t O n C l i c k L i s t e n e r ( new View . O n C l i c k L i s t e n e r ( ) { 

21 @Override 


23 da . loginAndSend ( ) ; 

24 } 

25 }) ; 

26 btn makecall . setEnabled ( t r u e ) ; 

27 btn makecall . s e t O n C l i c k L i s t e n e r ( new View . O n C l i c k L i s t e n e r ( ) { 

28 @Override 


30 makeCall ( ) ; 

31 } 

32 }) ; 



33 b t n r e s c a n . s e t O n C l i c k L i s t e n e r ( new View . O n C l i c k L i s t e n e r ( ) { 

34 @Override 


36 S t r i n g [ ] d l g s c a n n e r d l = g e t R e s o u r c e s ( ) . g e t S t r i n g A r r a y 

(R. array . d l g s c a n n e r d l ) ; 

37 I n t e n t I n t e g r a t o r . i n i t i a t e S c a n ( CodeScanner . t h i s , 

d l g s c a n n e r d l [ 0 ] , d l g s c a n n e r d l [ 1 ] , d l g s c a n n e r d l 

[ 2 ] , d l g s c a n n e r d l [ 3 ] , " QR_CODE " ) ; 

38 } 

39 }) ; 

40 break ; 


42 

43 [ . . . ] 

Um auf die in der codescanner.xml (unter Codeabschnitt 4.7) definierten UI- 

Elemente vom Programmcode aus zugreifen zu können, ist es nötig diese vorher im 

Code zu intialisieren und durch findViewById(id) einem UI-Element der angegebenen 

Resource ID zuzuweisen. Beispielhaft zeigt dies folgende Codezeile für das Scan- 

Button-Element: 

Button btn scan = (Button) findViewById(R.id.btn scan); 

Als Konventionen für die Benennung der UI-Objekte im Programmcode wurden die 

Präfixe layout “ für ein Layout, btn “ für einen Button, txt “ für eine TextView und 

” ” ” 

” img “ für ein Image festgelegt. 

Nach Ausblenden des ScanningLayouts und Einblenden des BookingLayouts erfolgt 

in Zeile 6 die Steuerung der Dienstabfrage und das Setzen des Status durch die setStatus()-Methode. 

Die switch-Anweisung wurde für den Fall eines korrekt eingescannten 

und bereits abgefragten Dienstes betrachtet. mStatus hat in diesem Fall den Wert 

” VALID INET“. In Zeile 11-14 werden die TextViews durch setText(...) mit den 

entsprechenden Inhalten aus der Variablen mService befüllt. Zeile 19-39 aktiviert die 

drei Buttons jeweils mit einem onClick Listener, der entsprechende Aktionen ausführt: 

Button ” Dienst buchen“ : Es wird die Methode loginAndSend() aus der DataAccess- 

Klasse aufgerufen. Diese prüft, ob für die Anwendung bereits ein Login gespeichert 

wurde. Falls nicht, öffnet sich ein Logindialog, zu dem der Nutzer einen 

vorher vom Dienstanbieter zugewiesenen Benutzernamen und ein Passwort (User- 

Login) eingeben muss. Ist dies geschehen, wird die vorher beschriebene sendMessage()-Methode 

aufgerufen und die über formatMessage() erstellte Nachricht 

an den openMQ Server gesendet. 

Button ” über Telefon buchen“ : Die onClick-Funktion ruft die Methode makeCall() 

auf, die einen Anruf an die in der optischen Marke bzw. im Datensatz des Dienstes 

gespeicherte Telefonnummer initiiert. Die Funktionsweise der makeCall()- 

Funktion wird im nächsten Abschnitt beschrieben. 

Button ” Erneut scannen“ : Dieser Button ist in jeder case-Anweisung aktiviert. Der 

Nutzer hat unabhängig vom mStatus-Wert die Möglichkeit erneut einen QR Code 

zu scannen. 



4.3.4.4 Methode makeCall(): Verbindung mit einem Ansprechpartner 

Falls der Nutzer noch Fragen zum angezeigten Dienst hat oder lieber mit einem Ansprechpartner 

persönlich sprechen möchte anstatt den Dienst direkt zu buchen, hat er 

die Möglichkeit, sich mit einer auf den angezeigten Dienst angepassten Telefonnummer 

verbinden zu lassen. Da die Nummer in den QR Code direkt codiert ist, kann der 

Nutzer auch bei nicht vorhandener Internetverbindung die codierte Nummer anrufen. 

Der Anruf wird durch die Methode makeCall() initiiert: 

Listing 4.20: Methode makeCall() 

1 p r i v a t e void makeCall ( ) { 

2 Uri u r i = Uri . p a r s e ( da . mService . get ( 4 ) ) ; 

3 I n t e n t i n t e n t = new I n t e n t ( I n t e n t .ACTION CALL, u r i ) ; 

4 s t a r t A c t i v i t y ( i n t e n t ) ; 

5 } 

In Zeile 2 wird zunächst ein URI (Uniform Resource Identifier) mit der zuvor formatierten 

Telefonnummer (siehe 4.3.3.1) erstellt. Anschließend wird ein impliziter Intent 

mit den Parametern ” ACTION CALL“ (um einen Anruf zu initiieren) und dem URI 

erzeugt. Da durch den Intent kein Ergebnis erwartet wird, wird dieser zuletzt noch mit 

startActivity(intent) abgeschickt, um die Activity der Phone App zu starten und 

den Anruf zu initiieren. Ist der Anruf beendet, schließt sich die Phone Activity wieder 

und die zuletzt auf dem ” Back Stack“ des Activity Managers gespeicherte CodeScanner 

Activity wird reaktiviert. 

4.4 WEITBLICK QR Code-Generator 

Der Nutzer hat gemäß des Usecases aus der Aufgabenstellung aus Kapitel 2 die Möglichkeit 

den Dienst durch Scannen eines in einer Fernsehsendung eingeblendeten Barcodes 

mit seinem Smartphone zu buchen. Für das Produktionsstudio des Fernsehsenders 

sollte es möglichst einfach sein, einen solchen QR Code komfortabel in das Fernsehbild 

einblenden zu können. Demnach besteht Bedarf an einer einfachen Möglichkeit den 

QR Code mit einem entsprechenden Inhalt zu erzeugen. Die ZXing Bildverarbeitungsbibliothek 

stellt dazu unter [ZXi11c] einen QR Code Generator mit einem RESTful 

Interface (siehe 4.2.2) bereit, womit QR Codes dynamisch erzeugt werden können. 

Durch Senden einer HTTP GET Nachricht mit einem API Befehl wird ein QR Code 

generiert und eine jpg-Bilddatei zurückgeliefert. 

Zur einfachen Erzeugung eines QR Codes mit dem Inhalt ” WEITBLICK“ muss das 

REST Interface wie folgt aufgerufen werden: 

http://chart.apis.google.com/chart?cht=qr&chs=545x545&chl=WEITBLICK 

Damit ist für ein System, das den QR Code in das Fernsehbild einblendet, eine leichte 

Implementierungsmöglichkeit geschaffen. Als Hilfsmittel wird dabei ein zusätzliches 

Programm namens wget verwendet. Dies ist ein plattformunabhängiger HTTP-Client, 

mit welchem HTTP Nachrichten verschickt werden können. 



Eine vereinfachte Generierung des QR Codes wird durch Aufruf einer Batchdatei 

gencode.bat in der Kommandozeile erreicht: 

gencode WEITBLICK qrcode.jpg 

Dem Batchskript werden zwei Parameter übergeben. Der erste Parameter steht für 

den Inhalt des Codes, welcher innerhalb der Batchdatei in die oben genannte URL 

als Variable eingesetzt wird. Für das WEITBLICK-Projekt müsste hier der unter Abschnitt 

4.2.1.1 diskutierte Inhalt eingegeben werden. Der zweite Parameter bezeichnet 

die Zieldatei, in der das JPG-Bild (die Antwort des ZXing REST Interface) gespeichert 

wird. Die damit erzeugte Bilddatei kann das Compositingsystem in der Fernseh- 

Postproduktion weiter verarbeiten und in den Videostream einbetten. 



5 Zusammenfassung und Ausblick 

Die Aufgabe der Arbeit bestand darin, mittels eines Smartphones einen Rückkanal für 

den herkömmlichen Fernsehrundfunk zu bilden. Ausgehend vom WEITBLICK-Projekt 

sollen dabei, im Hinblick auf ein Assistenzsystem für Senioren, Dienstleistungen (Pflege, 

soziale Kontakte, Hobby, Wellness) vermittelt werden. Gemäß der Aufgabenstellung 

ergaben sich folgende Teilaufgaben: 

1. Recherche möglicher Darstellungsformen für die optische Marke 

2. Codierung von Informationen mittels der optischen Marke 


Marke 



In Kapitel 3 wurden die allgemeinen Merkmale einer optischen Marke erläutert und 

darauf basierend eine Anforderungsanalyse an den zu wählenden Code gestellt. Nach 

einer Erläuterung der nach den Anforderungen in Frage kommenden Typen an Codes, 

wurden diese am Ende des Kapitels praktisch miteinander verglichen. Dabei wurde ein 

Usecase-nahes Szenario erstellt und der bestgeeignetste Code in einer Testreihe unter 

realen Bedingungen ermittelt. Die Wahl fiel letztendlich auf den QR Code. 

Im zweiten Teil wurde die praktische Umsetzung der Aufgabenstellung behandelt. 

Dazu war es nötig die an das Dienstbuchungssystem gestellten Anforderungen zu formulieren, 

um anschließend dessen Struktur sowohl auf der Seite des Clients als auch 

auf der des Servers, zu erläutern. Der Android Client fotografiert den auf dem Fernsehgerät 

abgebildeten QR Code ab und fordert die vollständigen Dienstinformationen 

anhand einer in den Code codierten ID von einem SQL Server über das Internet an. 

Ist keine Internetverbindung vorhanden, so verwendet das Smartphone nur die direkt 

in den QR Code codierten Informationen. Dies betrifft die Anzeige des Diensttitels sowie 

die Möglichkeit sich über die codierte Telefonnummer mit einem Ansprechpartner 

verbinden zu lassen. 

Des Weiteren wurde im zweiten Teil auf die Entwicklung der Android CodeScanner 

App eingegangen. Diese beschreibt zunächst die zum Verständnis der Programmstruktur 

notwendigen Grundlagen des Android Betriebssystems im Allgemeinen und geht 

darauf folgend auf die CodeScanner App ein. Beschrieben wird sowohl das User Interface 

sowie die zur Erfüllung der Aufgaben nötigen Methoden. Zur vollständigen 

Einsicht des Quellcodes sei hierbei auf den Anhang verwiesen. Zuletzt wird noch die 



Möglichkeit erläutert, einen QR Code möglichst einfach und plattformunabhängig erstellen 

und in eine Anwendung implementieren zu können. 

Zum Ausblick dieser Technologie lässt sich Folgendes sagen: Vor ein paar Jahren waren 

Smartphones noch kaum verbreitet. Das Marktforschungsunternehmens IDC prognostiziert 

für die nächsten Jahre einen anhaltenden Smartphone-Boom. Der Smartphone-Marktwachstum 

soll demnach im Jahre 2011 50% betragen [hei11]. Laut einer 

Studie des Martkforschungsunternehmens comScore besitzen Smartphones in Deutschland 

bereits einen Marktanteil von über 23% [com11]. 

Bezüglich des WEITBLICK-Projekts ist allerdings zu gestehen, dass die Zielgruppe 

der Senioren noch weniger vom Smartphone-Boom betroffen ist. Eine repräsentative 

Umfrage des Forsa-Instituts im Auftrag des Bundesverband Informationswirtschaft, 

Telekommunikation und neue Medien e.V. (BITKOM) im Oktober 2010 zeigt, dass der 

Anteil der Smartphone-Besitzer mit zunehmenden Alter rapide abnimmt. Die Quote 

bei den über 60-Jährigen (entsprechend der Zielgruppe des WEITBLICK-Projekts) beträgt 

nur 7% [Bun11]. Es ist aber gleichzeitig davon auszugehen, dass dieser Rückstand 

an den verwendeten Smartphones in dieser Zielgruppe generationsbedingt schwinden 

wird. Bei den 30- bis 44-Jährigen hat immerhin schon jeder vierte ein Smartphone 

[Bun11]. Diese Generation wird im Laufe der Zeit in die Zielgruppe des WEITBLICK- 

Projekts hineinwachsen. Zudem wäre es vorstellbar den Einsatzzweck und die Möglichkeiten 

des Assistenzsystems in der Zielgruppe zu bewerben, um so die Senioren zum 

Kauf eines Smartphones zu bewegen. Abgesehen vom WEITBLICK-Projekt könnte 

das Dienstbuchungssystem auch problemlos auf andere Zielgruppen erweitert werden. 

Eine Umsetzung des Dienstbuchungssystem wäre bei einer Markteinführung technisch 

sehr schnell implementierbar. Nachdem die Serverstruktur geschaffen wurde, 

könnte die CodeScanner App in den Android Market Store gestellt werden. Technisch 

gesehen wäre das Dienstbuchungssystem damit einsatzbereit. Der SQL Dienstserver 

würde durch die Dienstanbieter verwaltet werden und die auf der SQL Dienstdatenbank 

basierenden QR Codes könnten in Fernsehsendungen ausgestrahlt werden. 

Letztlich gilt es noch zu erwähnen, dass dieses Dienstbuchungssystem, das auf einer 

CodeScanner App beruht, in Konkurrenz mit einem Dienstbuchungssystem, das 

eine Technologie wie bspw. das Hybrid Broadcast Broadband TV (HbbTV) verwendet, 

steht. HbbTV ist eine moderne Basistechnologie für Unterhaltungselektronik, welche 

Fernsehangebote mit Mehrwertdiensten aus dem Internet verbindet. Über eine Internetverbindung 

kann der Nutzer während einer Fernsehsendung Informationen abrufen, 

die er in einem speziell angepassten HTML, dem sogenannten CE-HTML (Consumer- 

Electronics-HTML), auf dem Fernsehgerät angezeigt bekommt. Voraussetzung hierfür 

ist allerdings, dass der Nutzer auch einen Fernseher besitzt, der für die HbbTV- 

Technologie ausgelegt ist. Fraglich ist zudem, wie groß der technische Aufwand beim 

HbbTV wäre, um ein solches Dienstbuchungssystem zu entwickeln. Ein weiterer Vorteil 

der WEITBLICK Lösung ist die Nutzungsmöglichkeit bei analogem Fernsehen, die bei 

hybriden Fernsehtechnologien wie dem HbbTV nicht gegeben wäre. 


Anhang 

Nutzung eines Smartphones als Rückkanal für digitalen Rundfunk Bachelorarbeit Florian Schlembach 

56


A Quellcodes 

A.1 mySQL-Server und PHP-Server als Dienstserver 

Listing A.1: weitblick services.php 

1 

A.2 Android Manifest 

Listing A.2: /AndroidManifest.xml 

1 

2 

6 

7 

8 

9 

10 

11 

13 

14 

15 

16 

17 

18 

19 

A.3 Layout 



Listing A.3: /res/layout/codescanner.xml 

1 

2 

7 

8 

14 

19 

23 

24 

25 

31 

32 

33 

34 

35 

41 

46 

51 

55 

56 

63 

71 

77 

83 

89 

90 



91 

Listing A.4: /res/layout/userpw dialog.xml 

1 

7 

11 

17 

22 

23 

27 

33 

39 

40 

45 

Listing A.5: /res/menu/optionsmenu.xml 

1 

2 

3 

6 

9 

A.4 Strings 

Listing A.6: /res/values/strings.xml 

1 

2 

3 t r u e 

4 h t t p : //www. k r e a t i v f l o w . de / w e i t b l i c k s e r v i c e s . php 

5 h t t p s : // g a g a r i n . e−t e c h n i k . tu−ilmenau . d e : 8 4 4 3 

6 l o g i n s t o r e . pw 

7 WEITBLICK − CodeScanner ! 

8 Keine I n t e r n e t v e r b i n d u n g vorhanden ! \ n D i e n s t kann nur mit b e s t e h e n d e r 

I n t e r n e t v e r b i n d u n g d i r e k t gebucht werden . Es b e s t e h t d i e M ö g l i c h k e i t s i c h über den Button \ 

" ü b e r T e l e f o n b u c h e n \ " d i r e k t mit einem A n s p r e c h p a r t n e r v e r b i n d e n zu l a s s e n . \ nZur d i r e k t e n 

Buchung b i t t e I n t e r n e t v e r b i n d u n g ü b e r p r ü f e n ! 

9 Die g e s p e i c h e r t e n Login−Daten wurden g e l ö s c h t ! 

10 



11 

12 Kein g ü l t i g e r Code 

13 Es wurde e i n u n g ü l t i g e r Code g e s c a n n t . F a l l s e s s i c h um e i n e n g ü l t i g e n Code g e h a n d e l t 

hat , scannen S i e d i e s e n b i t t e e r n e u t . 

14 

15 

16 WEITBLICK − CodeScanner APP 

17 e i n e B a c h e l o r a r b e i t von F l o r i a n Schlembach am F a c h g e b i e t Kommunikationsnetze an der 

TU Ilmenau f ü r das P r o j e k t WEITBLICK . 

18 OK 

19 

20 I n f o zur APP 

21 Login l ö s c h e n 

22 

23 Barcode Scanner APP 

24 Um d i e Scan−Funktion der WEITBLICK APP zu nutzen i s t d i e e x t e r n e Barcode 

Scanner APP notwendig . Möchten S i e d i e s e j e t z t a u t o m a t i s c h i n s t a l l i e r e n ? 

25 I n s t a l l i e r e n 

26 Abbrechen 

27 

28 

29 D i e n s t buchen 

30 B i t t e Logindaten e i n g e b e n : 

31 Buchen 

32 Abbrechen 

33 

34 

35 D i e n s t gebucht 

36 Termin e i n t r a g e n 

37 Nicht e i n t r a g e n 

38 FEHLER b e i Buchung des D i e n s t e s ! B i t t e e r n e u t v e r s u c h e n ! 

39 

40 

41 Lade D i e n s t 

42 B i t t e warten . . . 

43 

44 

45 Buche D i e n s t 

46 B i t t e warten . . . 

47 

48 

A.5 Datenzugriffsklasse DataAccess() 

Listing A.7: /src/com.weitblick.codescanner/DataAccess.java 

1 package com . w e i t b l i c k . c o d e s c a n n e r ; 

2 

3 import j a v a . i o . B u f f e r e d R e a d e r ; 

4 import j a v a . i o . DataInputStream ; 

5 import j a v a . i o . F i l e I n p u t S t r e a m ; 

6 import j a v a . i o . FileNotFoundException ; 

7 import j a v a . i o . FileOutputStream ; 

8 import j a v a . i o . IOException ; 

9 import j a v a . i o . InputStream ; 

10 import j a v a . i o . InputStreamReader ; 

11 import j a v a . s e c u r i t y . KeyStore ; 

12 import j a v a . u t i l . A r r a y L i s t ; 

13 import j a v a . u t i l . L i s t ; 

14 import j a v a . u t i l . S t r i n g T o k e n i z e r ; 

15 

16 import org . apache . http . Header ; 

17 import org . apache . http . HttpEntity ; 

18 import org . apache . http . HttpResponse ; 

19 import org . apache . http . NameValuePair ; 

20 import org . apache . http . S t a t u s L i n e ; 

21 import org . apache . http . c l i e n t . H t t p C l i e n t ; 

22 import org . apache . http . c l i e n t . e n t i t y . UrlEncodedFormEntity ; 

23 import org . apache . http . c l i e n t . methods . HttpPost ; 

24 import org . apache . http . conn . scheme . Scheme ; 

25 import org . apache . http . conn . s s l . SSLSocketFactory ; 

26 import org . apache . http . e n t i t y . S t r i n g E n t i t y ; 

27 import org . apache . http . impl . c l i e n t . D e f a u l t H t t p C l i e n t ; 

28 import org . apache . http . message . BasicNameValuePair ; 

29 import org . j s o n . JSONArray ; 

30 import org . j s o n . JSONException ; 

31 import org . j s o n . JSONObject ; 

32 

33 import a n d r o i d . c o n t e n t . Context ; 

34 import a n d r o i d . net . ConnectivityManager ; 

35 import a n d r o i d . net . NetworkInfo ; 

36 import a n d r o i d . os . Handler ; 

37 import a n d r o i d . u t i l . Log ; 

38 import a n d r o i d . widget . Toast ; 



39 

40 p u b l i c c l a s s DataAccess { 

41 //member v a r i a b l e s 

42 I n t e g e r mId ; 

43 S t r i n g mTitle ; 

44 S t r i n g mPhonenr ; 

45 

46 p r i v a t e Context mContext ; 

47 S t a t u s mStatus ; 

48 

49 A r r a y L i s t mService = new A r r a y L i s t (6) ; 

50 A r r a y L i s t mLogin = new A r r a y L i s t (2) ; 

51 

52 // Handler manages the i n v o c a t i o n o f the r u n n a b l e s a f t e r f i n i s h i n g worker−t h r e a d s 

53 f i n a l Handler mHandler = new Handler ( ) ; 

54 

55 //STATUS VARIABLES 

56 b o o l e a n s e n t ; 

57 

58 // S t a t u s o f r e q u e s t e d s e r v i c e 

59 p u b l i c enum S t a t u s { 

60 INVALID , 

61 VALID, 

62 VALID PROCESSING , 

63 VALID INET , 

64 VALID NO INET , 

65 } 

66 // Message type f o r showBookedDialog method 

67 p u b l i c s t a t i c enum showProgressDlgMsg { 

68 OFF, 

69 LOADSERVICE, 

70 BOOKSERVICE 

71 } 

72 

73 /∗∗ 

74 ∗ S e t s c o n t e x t o f CodeScanner A c t i v i t y t o the c l a s s ’ c o n t e x t v a r i a b l e and p a r s e s 

s c a n r e s u l t s 

75 ∗ 

76 ∗ @param c o n t e x t a Context which i s p a s s e d by the CodeScanner A c t i v i t y 

77 ∗ @param s c a n r e s u l t a S t r i n g o f the p a r s e d s c a n r e s u l t s 

78 ∗/ 

79 DataAccess ( Context c o n t e x t , S t r i n g s c a n r e s u l t ) { 

80 mContext = c o n t e x t ; 

81 p a r s e S c a n r e s u l t ( s c a n r e s u l t ) ; 

82 } 

83 

84 //PUBLIC METHODS 

85 /∗∗ 

86 ∗ S e t s and c o n t r o l s the s t a t u s o f the r e q u e s t e d s e r v i c e 

87 ∗ This Method i s invoked by the i n i t B o o k i n g L a y o u t ( )−method o f the CodeScanner A c t i v i t y − 

c l a s s 

88 ∗ 1 . A f t e r having s c a n r e s u l t s parsed , s t a t u s o f mStatus i s e i t h e r VALID or INVALID 

89 ∗ 2 . I f VALID i n t e r n e t c o n n e c t i o n s i s checked , an a p p r o p r i a t e S t a t u s i s s e t 

90 ∗ 3 . I f i n t e r n e t c o n n e c t i o n i s a v a i l a b l e , s t a r t r e q u e s t i n g s e r v i c e i n a s e p a r a t e worker− 

t h r e a d 

91 ∗ 4 . I f no i n t e r n e t c o n n e c t i o n i s a v a i l a b l e , f i l l mService with empty data 

92 ∗/ 

93 p u b l i c v o i d s e t S t a t u s ( ) { 

94 s w i t c h ( mStatus ) { 


96 break ; 

97 c a s e VALID : 

98 i f ( c h e c k I n e t ( mContext ) ) mStatus=S t a t u s . VALID PROCESSING ; 

99 e l s e mStatus=S t a t u s . VALID NO INET ; 

100 s e t S t a t u s ( ) ; 

101 break ; 


103 r e q u e s t S e r v i c e T h r e a d ( ) ; 

104 break ; 


106 break ; 


108 s e t O f f l i n e S e r v i c e ( ) ; 

109 break ; 

110 } 

111 } 

112 

113 /∗∗ 

114 ∗ F e t c h e s UserPw D i a l o g 

115 ∗ 1 . Reads l o g i n d a t a from f i l e t o mLogin 

116 ∗ 2 . I f t h e r e i s no l o g i n −f i l e , mLogin i s empty and LoginDlg pops up 

117 ∗ 3 . I f l o g i n d a t a i s saved , s t a r t s s e n d i n g the f o r m a t t e d message ( which c o n s i s t s o f data 

o f shown s e r v i c e ) 

118 ∗/ 

119 p u b l i c v o i d loginAndSend ( ) { 

120 mLogin = readLoginFromFile ( ) ; 

121 // i f t h e r e i s no l o g i n saved y e t 

122 i f ( mLogin . isEmpty ( ) ) ( ( CodeScanner ) mContext ) . showLoginDlg ( ) ; 

123 e l s e sendMessageThread ( formatMessage ( ) ) ; 

124 } 

125 

126 /∗∗ 



127 ∗ Sends HTTPPost−Message to UMS S e r v e r 

128 ∗ 1 . Obtains UMSServer URL from s t r i n g r e s o u r c e 

129 ∗ 2 . C r e a t e s K e y s t o r e out o f raw r e s o u r c e f i l e w e i t b l i c k . bks ( Bouncy C a s t l e k e y s t o r e f i l e ) 

130 ∗ 3 . C r e a t e s Apache H t t p C l i e n t and HttpPost 

131 ∗ 4 . Sends and r e c e i v e s p o s t 

132 ∗ 5 . Reads h e a d e r s and c h e c k s whether message was s e n t s u c c e s s f u l l y 

133 ∗ 

134 ∗ @param message a S t r i n g o f the message to send to the UMS S e r v e r 

135 ∗/ 

136 p u b l i c v o i d sendMessage ( S t r i n g message ) { 

137 s e n t = f a l s e ; 

138 f i n a l S t r i n g UMSSERVER = mContext . g e t R e s o u r c e s ( ) . g e t S t r i n g (R. s t r i n g .UMSSERVER) ; 

139 

140 t r y { 

141 // C r e a t e s k e y s t o r e 

142 InputStream i s = mContext . g e t R e s o u r c e s ( ) . openRawResource (R. raw . w e i t b l i c k ) ; 

143 KeyStore k e y s t o r e = KeyStore . g e t I n s t a n c e ( " B K S " ) ; 

144 k e y s t o r e . l o a d ( i s , " w 3 1 t b l 1 c k " . toCharArray ( ) ) ; 

145 

146 // C r e a t e s SSL c o n n e c t i o n 

147 SSLSocketFactory s o c k e t F a c t o r y = new org . apache . http . conn . s s l . 

SSLSocketFactory ( k e y s t o r e ) ; 

148 s o c k e t F a c t o r y . s e t H o s t n a m e V e r i f i e r ( org . apache . http . conn . s s l . SSLSocketFactory 

. STRICT HOSTNAME VERIFIER) ; 

149 

150 f i n a l Scheme h t t p s = new Scheme ( " h t t p s " , s o c k e t F a c t o r y , 8443) ; 

151 

152 H t t p C l i e n t c l i e n t = new D e f a u l t H t t p C l i e n t ( ) ; 

153 c l i e n t . getConnectionManager ( ) . g e t S c h e m e R e g i s t r y ( ) . r e g i s t e r ( h t t p s ) ; 

154 HttpPost p o s t = new HttpPost (UMSSERVER+" / i m q u m s / s i m p l e ? s e r v i c e = s e n d & d e s t i n a t i o n = 

D V B _ R u e c k k a n a l & u s e r = "+mLogin . g e t ( 0 )+" & p a s s w o r d = "+mLogin . g e t ( 1 ) ) ; 

155 p o s t . addHeader ( " C o n t e n t - T y p e " , " t e x t / h t m l ; c h a r s e t = utf - 8 " ) ; 

156 HttpEntity e n t i t y = new S t r i n g E n t i t y ( message , " UTF - 8 " ) ; 

157 p o s t . s e t E n t i t y ( e n t i t y ) ; 

158 HttpResponse r e s p o n s e = c l i e n t . e x e c u t e ( p o s t ) ; 

159 

160 S t a t u s L i n e s t a t u s = r e s p o n s e . g e t S t a t u s L i n e ( ) ; 

161 Header u m s s e r v i c e = r e s p o n s e . g e t F i r s t H e a d e r ( " u m s . s e r v i c e " ) ; 

162 Header umsstatus = r e s p o n s e . g e t F i r s t H e a d e r ( " u m s . s t a t u s " ) ; 

163 b o o l e a n i s s t a t u s o k = s t a t u s . t o S t r i n g ( ) . c o n t a i n s ( " 2 0 0 " ) ; 

164 b o o l e a n i s r e p l y o k = u m s s e r v i c e . g e t V a l u e ( ) . t o S t r i n g ( ) . e q u a l s ( " s e n d _ r e p l y " ) ; 

165 b o o l e a n i s u m s s t a t u s o k = umsstatus . g e t V a l u e ( ) . t o S t r i n g ( ) . e q u a l s ( " 2 0 0 " ) ; 

166 

167 

168 i f ( i s s t a t u s o k && i s r e p l y o k && i s u m s s t a t u s o k ) s e n t = t r u e ; 

169 } c a t c h ( Exception e ) { 

170 Log . e ( " h t t p p o s t " , " E r r o r i n h t t p s c o n n e c t i o n : "+e . t o S t r i n g ( ) ) ; 

171 } 

172 } 

173 

174 /∗∗ 

175 ∗ S t a r t s s e p a r a t e worker t h r e a d to p r e s e r v e hanging UI 

176 ∗ 1 . Shows P r o g r e s s D i a l o g 

177 ∗ 2 . S t a r t s worker−t h r e a d 

178 ∗ 3 . Sends the f o r m a t t e d message 

179 ∗ 4 . Shows booking−c o n f i r m a t i o n −d i a l o g 

180 ∗ 


182 ∗/ 

183 p u b l i c v o i d sendMessageThread ( S t r i n g message ) { 

184 ( ( CodeScanner ) mContext ) . s h o w P r o g r e s s D i a l o g ( showProgressDlgMsg .BOOKSERVICE) ; 

185 // s t a r t a−worker−t h r e a d w 


187 p u b l i c v o i d run ( ) { 

188 sendMessage ( formatMessage ( ) ) ; 

189 mHandler . p o s t ( mShowBookedDialog ) ; 

190 } 

191 } ; 

192 t . s t a r t ( ) ; 

193 } 

194 

195 /∗∗ 

196 ∗ Executing r u n n a b l e f o r c a l l b a c k method which i n v o k e s the updating−method o f Booking− 

Layout 

197 ∗ 1 . S w i t c h e s o f f P r o g r e s s D i a l o g 

198 ∗ 2 . Shows s u c c e s s f u l booking−c o n f i r m a t i o n −d i a l o g 

199 ∗/ 

200 p u b l i c f i n a l Runnable mShowBookedDialog = new Runnable ( ) { 


202 ( ( CodeScanner ) mContext ) . s h o w P r o g r e s s D i a l o g ( showProgressDlgMsg .OFF) ; 

203 ( ( CodeScanner ) mContext ) . showBookedDlg ( s e n t ) ; 

204 } 

205 } ; 

206 

207 /∗∗ 

208 ∗ Formats the message based on the shown s e r v i c e . 

209 ∗ Contains data : Username , S e r v i c e I D , S e r v i c e T i t l e , S e r v i c e D a t e , SendConfMail ( b o o l e a n s e t 

i n s t r i n g r e s o u r c e ) 

210 ∗ 

211 ∗ @return the f o r m a t t e d message 

212 ∗/ 

213 p u b l i c S t r i n g formatMessage ( ) { 



214 // i f c o n f i r m m a i l i s s e t to true , a booking c o n f i r m a t i o n i s s e n t by mail through 

email−gateway 

215 S t r i n g c o n f i r m m a i l = mContext . g e t R e s o u r c e s ( ) . g e t S t r i n g (R. s t r i n g . c o n f i r m M a i l ) . 

t o S t r i n g ( ) ; 

216 S t r i n g B u f f e r m = new S t r i n g B u f f e r ( ) ; 

217 m. append ( " U s e r : "+mLogin . g e t ( 0 )+" ; " ) ; 

218 m. append ( " S e r v i c e I D : "+mId+" ; " ) ; 

219 m. append ( " S e r v i c e T i t l e : "+mService . g e t ( 0 )+" ; " ) ; 

220 m. append ( " S e r v i c e D a t e : "+mService . g e t ( 2 )+" ; " ) ; 

221 m. append ( " S e n d C o n f M a i l : "+c o n f i r m m a i l ) ; 

222 r e t u r n m. t o S t r i n g ( ) ; 

223 } 

224 

225 /∗∗ 

226 ∗ Checks whether t h e r e i s l o g i n d a t a saved 

227 ∗ 

228 ∗ @return the b o o l e a n v a l u e i f t h e r e i s l o g i n d a t a saved 

229 ∗/ 

230 p u b l i c b o o l e a n i s L o g i n S a v e d ( ) { 

231 i f ( ! readLoginFromFile ( ) . isEmpty ( ) ) r e t u r n t r u e ; 

232 e l s e r e t u r n f a l s e ; 

233 } 

234 

235 /∗∗ 

236 ∗ Writes l o g i n d a t a to f i l e on I n t e r n a l S t o r a g e 

237 ∗ 

238 ∗ @return the r e s u l t o f the f i l e w r i t i n g o p e r a t i o n 

239 ∗/ 

240 p u b l i c b o o l e a n w r i t e L o g i n T o F i l e ( ) { 

241 b o o l e a n w r i t t e n = t r u e ; 

242 t r y { 

243 S t r i n g userpw=mLogin . g e t ( 0 )+" : "+mLogin . g e t ( 1 ) ; 

244 S t r i n g LOGINSTORE=mContext . g e t R e s o u r c e s ( ) . g e t S t r i n g (R. s t r i n g .LOGINSTORE) ; 

245 FileOutputStream f o s = mContext . openFileOutput (LOGINSTORE, 0 ) ; 

246 f o s . w r i t e ( userpw . g e t B y t e s ( ) ) ; 

247 f o s . c l o s e ( ) ; 

248 } 

249 c a t c h ( FileNotFoundException e ) { 

250 Log . e ( " l o g i n s t o r e " , " e r r o r w r i t i n g l o g i n s t o r e f i l e : "+e . t o S t r i n g ( ) ) ; 

251 w r i t t e n = f a l s e ; 

252 } 

253 c a t c h ( IOException e ) { 

254 Log . e ( " l o g i n s t o r e " , " e r r o r w r i t i n g l o g i n s t o r e f i l e : "+e . t o S t r i n g ( ) ) ; 

255 w r i t t e n = f a l s e ; 

256 } 

257 r e t u r n w r i t t e n ; 

258 } 

259 

260 /∗∗ 

261 ∗ D e l e t e s the l o g i n d a t a f i l e on I n t e r n a l S t o r a g e 

262 ∗/ 

263 p u b l i c v o i d d e l e t e L o g i n F i l e ( ) { 

264 f i n a l S t r i n g LOGINSTORE = mContext . g e t R e s o u r c e s ( ) . g e t S t r i n g (R. s t r i n g .LOGINSTORE) ; 

265 S t r i n g m s g l o g i n d e l e t e d = mContext . g e t R e s o u r c e s ( ) . g e t S t r i n g (R. s t r i n g . l o g i n d e l e t e d ) ; 

266 

267 mLogin . c l e a r ( ) ; 

268 mContext . d e l e t e F i l e (LOGINSTORE) ; 

269 // Shows d e l e t e message t o a s t even i f t h e r e i s no l o g i n saved 

270 Toast . makeText ( mContext , m s g l o g i n d e l e t e d , 3000) . show ( ) ; 

271 } 

272 

273 //PRIVATE METHODS 

274 /∗∗ 

275 ∗ P a r s e s s c a n r e s u l t 

276 ∗ 1 . S p l i t s s c a n r e s u l t S t r i n g i n t h r e e p a r t s 

277 ∗ 2 . Third Part i s s p l i t a g a i n i n t o t h r e e p a r t s 

278 ∗ 3 . I f f i r s t two p o i n t s succeeded , the QR Code i s v a l i d 

279 ∗ 4 . S e t s mStatus i n dependence o f p o i n t 3 to VALID o r INVALID 

280 ∗ 

281 ∗ @param s c a n r e s u l t a S t r i n g o f the s c a n r e s u l t o f the e x t e r n a l Barcode Scanner App 

g i v e n by the CodeScanner A c t i v i t y 

282 ∗/ 

283 p r i v a t e v o i d p a r s e S c a n r e s u l t ( S t r i n g s c a n r e s u l t ) { 

284 b o o l e a n r e s u l t = t r u e ; 

285 S t r i n g [ ] s p l i t p h o n e n r = n u l l ; 

286 

287 S t r i n g [ ] s p l i t r e s u l t = s c a n r e s u l t . s p l i t ( " # # " ) ; 

288 i f ( s p l i t r e s u l t . l e n g t h ==3) s p l i t p h o n e n r = s p l i t r e s u l t [ 2 ] . s p l i t ( " - " ) ; 

289 

290 i f ( s p l i t r e s u l t . l e n g t h==3 && s p l i t p h o n e n r . l e n g t h ==3) { 

291 mId=new I n t e g e r ( s p l i t r e s u l t [ 0 ] ) ; 

292 mTitle=s p l i t r e s u l t [ 1 ] ; 

293 mPhonenr=" t e l : ( "+s p l i t p h o n e n r [ 0 ] + " ) "+s p l i t p h o n e n r [ 1 ] + " "+s p l i t p h o n e n r [ 2 ] ; 

294 } 

295 e l s e r e s u l t = f a l s e ; 

296 

297 i f ( r e s u l t ) mStatus=S t a t u s . VALID ; 

298 e l s e mStatus=S t a t u s . INVALID ; 

299 } 

300 

301 /∗∗ 



302 ∗ Formats the g i v e n phonenumber i n t o the format s p e c i f i e d i n RFC 3966 ( IETF ) : t e l : ( xx ) xxxx 

xxxx 

303 ∗ 

304 ∗ @param nr a S t r i n g with the phonenumber 

305 ∗ @return the f o r m a t t e d phonenumber 

306 ∗/ 

307 p r i v a t e S t r i n g formatNumber ( S t r i n g nr ) { 

308 S t r i n g T o k e n i z e r s t = new S t r i n g T o k e n i z e r ( nr , " - " ) ; 

309 nr = " t e l : ( "+s t . nextToken ( )+" ) "+s t . nextToken ( )+" "+s t . nextToken ( ) ; 

310 r e t u r n nr ; 

311 } 

312 

313 /∗∗ 

314 ∗ Checks whether i n t e r n e t c o n n e c t i o n i s a v a i l a b l e 

315 ∗ 

316 ∗ @param c o n t e x t a Context from the CodeScanner A c t i v i t y to check the i n t e r n e t c o n n e c t i o n 

from t h e r e 

317 ∗ @return the s t a t e o f the i n t e r n e t c o n n e c t i o n 

318 ∗/ 

319 p r i v a t e b o o l e a n c h e c k I n e t ( Context c o n t e x t ) { 

320 ConnectivityManager connectmgr = ( ConnectivityManager ) c o n t e x t . g e t S y s t e m S e r v i c e ( Context . 

CONNECTIVITY SERVICE) ; 

321 NetworkInfo a c t i v e N e t w o r k I n f o = connectmgr . g e t A c t i v e N e t w o r k I n f o ( ) ; 

322 r e t u r n a c t i v e N e t w o r k I n f o != n u l l ; 

323 } 

324 

325 /∗∗ 

326 ∗ Executing Runnable f o r c a l l b a c k method which i n v o k e s the updating−method o f 

BookingLayout 

327 ∗ 1 . S w i t c h e s o f f P r o g r e s s D i a l o g 

328 ∗ 2 . I n i t i a l i z e s updating−method o f BookingLayout 

329 ∗/ 

330 f i n a l Runnable mUpdateBookingLayout = new Runnable ( ) { 


332 mStatus=S t a t u s . VALID INET ; 

333 ( ( CodeScanner ) mContext ) . s h o w P r o g r e s s D i a l o g ( showProgressDlgMsg .OFF) ; 

334 ( ( CodeScanner ) mContext ) . i n i t B o o k i n g L a y o u t ( ) ; 

335 } 

336 } ; 

337 

338 /∗∗ 

339 ∗ S t a r t s s e p a r a t e worker t h r e a d to p r e s e r v e hanging UI 

340 ∗ 1 . Shows P r o g r e s s D i a l o g 

341 ∗ 2 . S t a r t s worker−t h r e a d 

342 ∗ 3 . Requests s e r v i c e 

343 ∗ 4 . Updates BookingLayout with r e q u e s t e d i n f o r m a t i o n 

344 ∗ 


346 ∗/ 

347 p r i v a t e v o i d r e q u e s t S e r v i c e T h r e a d ( ) { 

348 ( ( CodeScanner ) mContext ) . s h o w P r o g r e s s D i a l o g ( showProgressDlgMsg .LOADSERVICE) ; 

349 // s t a r t a−worker−t h r e a d 



352 r e q u e s t S e r v i c e ( ) ; 

353 mHandler . p o s t ( mUpdateBookingLayout ) ; 

354 } 

355 } ; 

356 t . s t a r t ( ) ; 

357 } 

358 

359 /∗∗ 

360 ∗ Requests SQL DB o f e x t e r n a l s e r v e r f o r s e r v i c e i n f o r m a t i o n 

361 ∗ 1 . Obtains SQL S e r v e r URI 

362 ∗ 2 . C r e a t e s Apache H t t p C l i e n t and HttpPost 

363 ∗ 3 . Puts NameValuePair i n t o POST 

364 ∗ 4 . P r o c e s s e s HTTP r e s p o n s e 

365 ∗ 5 . P a r s e s the r e c e i v e d JSON−data 

366 ∗/ 

367 p r i v a t e v o i d r e q u e s t S e r v i c e ( ) { 

368 S t r i n g r e s u l t = n u l l ; 

369 InputStream i s = n u l l ; 

370 f i n a l S t r i n g SQLHOST = mContext . g e t R e s o u r c e s ( ) . g e t S t r i n g (R. s t r i n g .SQLHOST) ; 

371 

372 t r y { 

373 H t t p C l i e n t c l i e n t = new D e f a u l t H t t p C l i e n t ( ) ; 

374 HttpPost p o s t = new HttpPost (SQLHOST) ; 

375 L i s t nameValuePair = new A r r a y L i s t () ; 

376 nameValuePair . add ( new BasicNameValuePair ( " i d " , mId . t o S t r i n g ( ) ) ) ; 

377 p o s t . s e t E n t i t y ( new UrlEncodedFormEntity ( nameValuePair ) ) ; 

378 HttpResponse r e s p o n s e = c l i e n t . e x e c u t e ( p o s t ) ; 

379 

380 HttpEntity e n t i t y = r e s p o n s e . g e t E n t i t y ( ) ; 

381 i s = e n t i t y . getContent ( ) ; 

382 

383 B u f f e r e d R e a d e r s e r v i c e r e a d e r = new B u f f e r e d R e a d e r ( new InputStreamReader ( i s , 

" UTF - 8 " ) , 8 ) ; 

384 r e s u l t=s e r v i c e r e a d e r . r e a d L i n e ( ) ; 

385 i s . c l o s e ( ) ; 


387 Log . e ( " l o g _ t a g " , " E r r o r i n h t t p c o n n e c t i o n : "+e . t o S t r i n g ( ) ) ; 

388 } 



389 // P a r s e s JSON−data 

390 t r y { 

391 JSONArray j A r r a y = new JSONArray ( r e s u l t ) ; 

392 JSONObject s e r v i c e j s o n = j A r r a y . getJSONObject ( 0 ) ; 

393 mService . c l e a r ( ) ; 

394 mService . add ( s e r v i c e j s o n . g e t S t r i n g ( " t i t l e " ) ) ; 

395 mService . add ( s e r v i c e j s o n . g e t S t r i n g ( " d e s c r " ) ) ; 

396 mService . add ( s e r v i c e j s o n . g e t S t r i n g ( " f d a t e " ) ) ; 

397 mService . add ( s e r v i c e j s o n . g e t S t r i n g ( " c o s t s " ) ) ; 

398 mService . add ( formatNumber ( s e r v i c e j s o n . g e t S t r i n g ( " p h o n e n r " ) ) ) ; 

399 mService . add ( s e r v i c e j s o n . g e t S t r i n g ( " d u r a t i o n " ) ) ; 

400 } 

401 c a t c h ( JSONException e ) { 

402 Log . e ( " l o g _ t a g " , " E r r o r p a r s i n g d a t a "+e . t o S t r i n g ( ) ) ; 

403 } 

404 } 

405 

406 /∗∗ 

407 ∗ S e t s o f f l i n e s e r v i c e i n f o r m a t i o n which i s c o n t a i n e d i n scanned QR Code , o t h e r f i e l d s a r e 

s e t to empty v a l u e s 

408 ∗/ 

409 p r i v a t e v o i d s e t O f f l i n e S e r v i c e ( ) { 

410 mService . c l e a r ( ) ; 

411 mService . add ( mTitle ) ; 

412 mService . add ( mContext . g e t R e s o u r c e s ( ) . g e t S t r i n g (R. s t r i n g . n o i n e t ) ) ; 

413 mService . add ( " " ) ; // date 

414 mService . add ( " " ) ; // c o s t s 

415 mService . add ( mPhonenr ) ; 

416 mService . add ( " " ) ; // d u r a t i o n 

417 } 

418 

419 /∗∗ 

420 ∗ Reads l o g i n d a t a from l o g i n f i l e on I n t e r n a l S t o r a g e 

421 ∗ 1 . Obtains l o g i n − f i l e name from s t r i n g r e s o u r c e 

422 ∗ 2 . Reads c o n t e n t o f f i l e 

423 ∗ 3 . S p l i t s c o n t e n t ( u s e r : pw) i n t o two p a r t s and s t o r e s them to mLogin 

424 ∗ 4 . I f l o g i n − f i l e e x i s t s mLogin i s empty 

425 ∗ 

426 ∗ @return the read l o g i n d a t a 

427 ∗/ 

428 p r i v a t e A r r a y L i s t readLoginFromFile ( ) { 

429 f i n a l S t r i n g LOGINSTORE = mContext . g e t R e s o u r c e s ( ) . g e t S t r i n g (R. s t r i n g .LOGINSTORE) ; 

430 S t r i n g userpw = n u l l ; 

431 mLogin . c l e a r ( ) ; 

432 

433 t r y { 

434 S t r i n g f i l e =LOGINSTORE; 

435 F i l e I n p u t S t r e a m f i s = mContext . o p e n F i l e I n p u t ( f i l e ) ; 

436 DataInputStream d i s = new DataInputStream ( f i s ) ; 

437 userpw = d i s . r e a d L i n e ( ) ; 

438 f i s . c l o s e ( ) ; 

439 

440 // S p l i t s u s e r : pw 

441 S t r i n g T o k e n i z e r s t = new S t r i n g T o k e n i z e r ( userpw , " : " ) ; 

442 w h i l e ( s t . hasMoreTokens ( ) ) { 

443 mLogin . add ( s t . nextToken ( ) ) ; 

444 } 

445 } 

446 c a t c h ( FileNotFoundException e ) { 

447 Log . e ( " l o g i n s t o r e " , " e r r o r r e a d i n g l o g i n s t o r e f i l e : "+e . t o S t r i n g ( ) ) ; 

448 } 

449 c a t c h ( IOException e ) { 

450 Log . e ( " l o g i n s t o r e " , " e r r o r r e a d i n g l o g i n s t o r e f i l e : "+e . t o S t r i n g ( ) ) ; 

451 } 

452 

453 r e t u r n mLogin ; 

454 } 

455 

456 } 

A.6 CodeScanner Activity-Klasse 

Listing A.8: /src/com.weitblick.codescanner/CodeScanner.java 

1 package com . w e i t b l i c k . c o d e s c a n n e r ; 

2 

3 import j a v a . t e x t . SimpleDateFormat ; 

4 import j a v a . u t i l . Date ; 

5 

6 import a n d r o i d . app . A c t i v i t y ; 

7 import a n d r o i d . app . A l e r t D i a l o g ; 

8 import a n d r o i d . app . P r o g r e s s D i a l o g ; 

9 import a n d r o i d . c o n t e n t . Context ; 

10 import a n d r o i d . c o n t e n t . D i a l o g I n t e r f a c e ; 



11 import a n d r o i d . c o n t e n t . I n t e n t ; 

12 import a n d r o i d . net . Uri ; 

13 import a n d r o i d . os . Bundle ; 

14 import a n d r o i d . u t i l . Log ; 

15 import a n d r o i d . view . L a y o u t I n f l a t e r ; 

16 import a n d r o i d . view . Menu ; 

17 import a n d r o i d . view . M e n u I n f l a t e r ; 

18 import a n d r o i d . view . MenuItem ; 

19 import a n d r o i d . view . View ; 

20 import a n d r o i d . view . ViewGroup ; 

21 import a n d r o i d . widget . Button ; 

22 import a n d r o i d . widget . CheckBox ; 

23 import a n d r o i d . widget . EditText ; 

24 import a n d r o i d . widget . ImageView ; 

25 import a n d r o i d . widget . R e l a t i v e L a y o u t ; 

26 import a n d r o i d . widget . TextView ; 

27 import a n d r o i d . widget . Toast ; 

28 

29 import com . w e i t b l i c k . c o d e s c a n n e r . DataAccess . S t a t u s ; 

30 

31 p u b l i c c l a s s CodeScanner e x t e n d s A c t i v i t y { 

32 // DataAccess−Object , used to handle r e q u e s t e d s e r v i c e data 

33 DataAccess da ; 

34 

35 // I n i t i a l i z e s UI Elements 

36 R e l a t i v e L a y o u t l a y o u t s c a n n i n g ; 

37 R e l a t i v e L a y o u t l a y o u t b o o k i n g ; 

38 ImageView i m g q r ; 

39 Button b t n s c a n ; 

40 Button b t n r e s c a n ; 

41 Button b t n b o o k s e r v i c e ; 

42 Button b t n m a k e c a l l ; 

43 TextView t x t t i t l e ; 

44 TextView t x t d e s c ; 

45 TextView t x t d a t e ; 

46 TextView t x t c o s t s ; 

47 

48 P r o g r e s s D i a l o g d i a l o g ; 

49 

50 //OVERRIDEN ACTIVITY−METHODS 

51 /∗∗ 

52 ∗ I n i t i a l i z e s A c t i v i t y method : 

53 ∗ 1 . S e t s view to xml−l a y o u t d e f i n e d i n / r e s / l a y o u t / c o d e s c a n n e r . xml 

54 ∗ 2 . I n v o k e s UI−I n i t i a l i z i n g method i n i t U I ( ) 

55 ∗ 3 . I f t h e r e i s no DataAccess o b j e c t , i n i t i a l i z e ScanningLayout 

56 ∗ 4 . e l s e ( e . g . a f t e r a s c r e e n o r i e n t a t i o n change ) i n i t i a l i z e BookingLayout 

57 ∗ 

58 ∗ @param s a v e d I n s t a n c e S t a t e a Bundle o b j e c t which r e c o v e r s saved i n f o r m a t i o n 

59 ∗ 

60 ∗ @see a n d r o i d . app . A c t i v i t y#onCreate ( a n d r o i d . os . Bundle ) 

61 ∗/ 

62 @Override 

63 p u b l i c v o i d onCreate ( Bundle s a v e d I n s t a n c e S t a t e ) { 

64 s u p e r . onCreate ( s a v e d I n s t a n c e S t a t e ) ; 

65 setContentView (R. l a y o u t . c o d e s c a n n e r ) ; 

66 

67 i n i t U I ( ) ; 

68 

69 // c h e c k s whether t h e r e i s a l r e a d y a DataAccess−Object , i f y e s i n i t i a l i z e Booking−Layout 

70 da = ( DataAccess ) g e t L a s t N o n C o n f i g u r a t i o n I n s t a n c e ( ) ; 

71 i f ( da==n u l l ) { 

72 i n i t S c a n n i n g L a y o u t ( ) ; 

73 } 

74 e l s e i n i t B o o k i n g L a y o u t ( ) ; 

75 } 

76 

77 /∗∗ 

78 ∗ R e t a i n s DataAccess o b j e c t b e f o r e s c r e e n o r i e n t a t i o n change 

79 ∗ 

80 ∗ @see a n d r o i d . app . A c t i v i t y#o n R e t a i n N o n C o n f i g u r a t i o n I n s t a n c e ( ) 

81 ∗/ 

82 @Override 

83 p u b l i c Object o n R e t a i n N o n C o n f i g u r a t i o n I n s t a n c e ( ) { 

84 f i n a l DataAccess data = da ; 

85 r e t u r n data ; 

86 } 

87 

88 /∗∗ 

89 ∗ Obtain scanned r e s u l t s from Barcode Scanner App 

90 ∗ 1 . I n v o k e s s t a t i c p a r s e A c t i v i t y R e s u l t −method o f I n t e n t I n t e g r a t o r c l a s s to p a r s e s c a n r e s u l t 

91 ∗ 2 . C r e a t e s DataAccess−o b j e c t 

92 ∗ 3 . I n i t i a t e s BookingLayout 

93 ∗ params d e s c r i p t i o n o f the Android API R e f e r e n c e : 

94 ∗ 

95 ∗ @param requestCode The i n t e g e r r e q u e s t code o r i g i n a l l y s u p p l i e d to 

s t a r t A c t i v i t y F o r R e s u l t ( ) , a l l o w i n g you t o i d e n t i f y who t h i s r e s u l t came from 

96 ∗ @param r e s u l t C o d e The i n t e g e r r e s u l t code r e t u r n e d by the c h i l d a c t i v i t y through i t s 

s e t R e s u l t ( ) 

97 ∗ @param i n t e n t An I n t e n t , which can r e t u r n r e s u l t data t o the c a l l e r ( v a r i o u s data can be 

a t t a c h e d to I n t e n t ” e x t r a s ”) 

98 ∗ 

99 ∗ @see a n d r o i d . app . A c t i v i t y#o n A c t i v i t y R e s u l t ( i n t , i n t , a n d r o i d . c o n t e n t . I n t e n t ) 



100 ∗/ 

101 @Override 

102 p u b l i c v o i d o n A c t i v i t y R e s u l t ( i n t requestCode , i n t r e s u l t C o d e , I n t e n t i n t e n t ) { 

103 I n t e n t R e s u l t s c a n R e s u l t = I n t e n t I n t e g r a t o r . p a r s e A c t i v i t y R e s u l t ( requestCode , r e s u l t C o d e , 

i n t e n t ) ; 

104 i f ( s c a n R e s u l t != n u l l ) { 

105 S t r i n g m S c a n r e s u l t=s c a n R e s u l t . g e t C o n t e n t s ( ) ; 

106 da = new DataAccess ( t h i s , m S c a n r e s u l t ) ; 

107 i n i t B o o k i n g L a y o u t ( ) ; 

108 } 

109 e l s e Log . e ( " s c a n _ e r r o r " , " s c a n n i n g e r r o r " ) ; 

110 } 

111 

112 /∗∗ 

113 ∗ C r e a t e s o p t i o n s menu which pops up a f t e r menu button o f smartphone i s p r e s s e d . I n f l a t e s menu 

g i v e n i n / r e s /menu/ optionsmenu . xml 

114 ∗ params d e s c r i p t i o n out o f Android API R e f e r e n c e : 

115 ∗ 

116 ∗ @param menu The o p t i o n s menu i n which you p l a c e your i t e m s 

117 ∗ 

118 ∗ @see a n d r o i d . app . A c t i v i t y#onCreateOptionsMenu ( a n d r o i d . view . Menu) 

119 ∗/ 

120 @Override 

121 p u b l i c b o o l e a n onCreateOptionsMenu (Menu menu ) { 

122 M e n u I n f l a t e r i n f l a t e r = g e t M e n u I n f l a t e r ( ) ; 

123 i n f l a t e r . i n f l a t e (R. menu . optionsmenu , menu ) ; 

124 r e t u r n t r u e ; 

125 } 

126 

127 /∗∗ 

128 ∗ Enables or d i s a b l e s d e l e t e l o g i n item whether DataAccess o b j e c t e x i s t s o r not 

129 ∗ params d e s c r i p t i o n out o f Android API R e f e r e n c e : 

130 ∗ 

131 ∗ @param menu The o p t i o n s menu as l a s t shown o r f i r s t i n i t i a l i z e d by onCreateOptionsMenu ( ) 

132 ∗ 

133 ∗ @see a n d r o i d . app . A c t i v i t y#onPrepareOptionsMenu ( a n d r o i d . view . Menu) 

134 ∗/ 

135 @Override 

136 p u b l i c b o o l e a n onPrepareOptionsMenu (Menu menu ) { 

137 i f ( da==n u l l | | ! da . i s L o g i n S a v e d ( ) ) menu . g e t I t e m ( 0 ) . s e t E n a b l e d ( f a l s e ) ; 

138 e l s e menu . g e t I t e m ( 0 ) . s e t E n a b l e d ( t r u e ) ; 

139 r e t u r n t r u e ; 

140 } 

141 

142 /∗∗ 

143 ∗ Handles optionsmenu 

144 ∗ 1 . i t m d e l l o g i n : d e l e t e s on ” I n t e r n a l S t o r a g e ” saved l o g i n d a t a 

145 ∗ 2 . i t m c r e d i t s : pops up c r e d i t s d i a l o g 

146 ∗ 

147 ∗ @param item The menu item t h a t was s e l e c t e d 

148 ∗ 

149 ∗ @see a n d r o i d . app . A c t i v i t y#o n O p t i o n s I t e m S e l e c t e d ( a n d r o i d . view . MenuItem ) 

150 ∗/ 

151 @Override 

152 p u b l i c b o o l e a n o n O p t i o n s I t e m S e l e c t e d ( MenuItem item ) { 

153 // Handle item s e l e c t i o n 

154 s w i t c h ( item . g e t I t e m I d ( ) ) { 

155 c a s e R. i d . i t m d e l l o g i n : 

156 da . d e l e t e L o g i n F i l e ( ) ; 

157 r e t u r n t r u e ; 

158 c a s e R. i d . i t m c r e d i t s : 

159 s h o w C r e d i t s ( ) ; 

160 r e t u r n t r u e ; 

161 d e f a u l t : 

162 r e t u r n s u p e r . o n O p t i o n s I t e m S e l e c t e d ( item ) ; 

163 } 

164 } 

165 

166 //PUBLIC METHODS 

167 /∗∗ 

168 ∗ I n i t i a l i z e s Booking−Layout 

169 ∗ 1 . Shows and h i d e s l a y o u t s 

170 ∗ 2 . S e t s S t a t u s 

171 ∗ 3 . F i l l s l a y o u t e l e m e n t s dependent on s e r v i c e r e q u e s t s t a t e 

172 ∗/ 

173 p u b l i c v o i d i n i t B o o k i n g L a y o u t ( ) { 

174 l a y o u t s c a n n i n g . s e t V i s i b i l i t y ( View . INVISIBLE ) ; 

175 l a y o u t b o o k i n g . s e t V i s i b i l i t y ( View . VISIBLE ) ; 

176 

177 // to r e a c t whether scanned code i s v a l i d , i n e t i s a v a i l a b l e e t c . i n v o k e s e t S t a t u s ( ) b e i n g 

a b l e to r e a c t to i t 

178 da . s e t S t a t u s ( ) ; 

179 

180 s w i t c h ( da . mStatus ) { 



183 t x t t i t l e . s e t T e x t ( da . mService . g e t ( 0 ) ) ; 

184 t x t d e s c . s e t T e x t ( da . mService . g e t ( 1 ) ) ; 

185 t x t d a t e . s e t T e x t ( da . mService . g e t ( 2 ) ) ; 

186 t x t c o s t s . s e t T e x t ( da . mService . g e t ( 3 )+" E U R " ) ; 

187 i f ( da . mStatus==S t a t u s . VALID NO INET) { 

188 t x t c o s t s . s e t T e x t ( " " ) ; 



189 b t n b o o k s e r v i c e . s e t E n a b l e d ( f a l s e ) ; 

190 } 

191 b t n b o o k s e r v i c e . s e t E n a b l e d ( t r u e ) ; 

192 b t n b o o k s e r v i c e . s e t O n C l i c k L i s t e n e r ( new View . O n C l i c k L i s t e n e r ( ) { 

193 @Override 

194 p u b l i c v o i d o n C l i c k ( View v ) { 

195 da . loginAndSend ( ) ; 

196 } 

197 }) ; 

198 b t n m a k e c a l l . s e t E n a b l e d ( t r u e ) ; 

199 b t n m a k e c a l l . s e t O n C l i c k L i s t e n e r ( new View . O n C l i c k L i s t e n e r ( ) { 

200 @Override 



203 } 

204 }) ; 


206 @Override 


208 S t r i n g [ ] d l g s c a n n e r d l = g e t R e s o u r c e s ( ) . g e t S t r i n g A r r a y (R. 

a r r a y . d l g s c a n n e r d l ) ; 


d l g s c a n n e r d l [ 0 ] , d l g s c a n n e r d l [ 1 ] , d l g s c a n n e r d l [ 2 ] , 

d l g s c a n n e r d l [ 3 ] , " Q R _ C O D E " ) ; 

210 } 

211 }) ; 

212 break ; 


214 t x t t i t l e . s e t T e x t ( da . mTitle ) ; 

215 t x t d e s c . s e t T e x t ( " " ) ; 

216 t x t d a t e . s e t T e x t ( " " ) ; 



219 b t n m a k e c a l l . s e t E n a b l e d ( t r u e ) ; 

220 b t n m a k e c a l l . s e t O n C l i c k L i s t e n e r ( new View . O n C l i c k L i s t e n e r ( ) { 

221 @Override 



224 } 

225 }) ; 


227 @Override 







231 } 

232 }) ; 

233 break ; 


235 S t r i n g [ ] i n v a l i d c o d e = g e t R e s o u r c e s ( ) . g e t S t r i n g A r r a y (R. a r r a y . i n v a l i d c o d e ) ; 

236 t x t t i t l e . s e t T e x t ( i n v a l i d c o d e [ 0 ] ) ; 

237 t x t d e s c . s e t T e x t ( i n v a l i d c o d e [ 1 ] ) ; 

238 t x t d a t e . s e t T e x t ( " " ) ; 



241 b t n m a k e c a l l . s e t E n a b l e d ( f a l s e ) ; 


243 @Override 







247 } 

248 }) ; 

249 break ; 

250 } 

251 } 

252 

253 /∗∗ 

254 ∗ Shows l o g i n ( a l e r t ) d i a l o g and s e t s l o g i n d a t a to mLogin i n DataAccess−Object 

255 ∗/ 

256 p u b l i c v o i d showLoginDlg ( ) { 

257 f i n a l L a y o u t I n f l a t e r i n f l a t e r = ( L a y o u t I n f l a t e r ) g e t S y s t e m S e r v i c e ( 

LAYOUT INFLATER SERVICE) ; 

258 f i n a l View inputView = i n f l a t e r . i n f l a t e (R. l a y o u t . u s e r p w d i a l o g , ( ViewGroup ) 

findViewById (R. i d . u s e r p w l a y o u t ) ) ; 

259 f i n a l EditText t x t u s e r = ( EditText ) inputView . findViewById (R. i d . t x t u s e r ) ; 

260 f i n a l EditText txt pw = ( EditText ) inputView . findViewById (R. i d . txt pw ) ; 

261 f i n a l CheckBox c b s a v e l o g i n = ( CheckBox ) inputView . findViewById (R. i d . c b s a v e l o g i n ) ; 

262 S t r i n g [ ] d l g l o g i n = g e t R e s o u r c e s ( ) . g e t S t r i n g A r r a y (R. a r r a y . d l g l o g i n ) ; 

263 

264 A l e r t D i a l o g . B u i l d e r b u i l d e r = new A l e r t D i a l o g . B u i l d e r ( CodeScanner . t h i s ) ; 

265 b u i l d e r . s e t T i t l e ( d l g l o g i n [ 0 ] ) ; 

266 b u i l d e r . s e t M e s s a g e ( d l g l o g i n [ 1 ] ) ; 

267 b u i l d e r . setView ( inputView ) ; 

268 b u i l d e r . s e t P o s i t i v e B u t t o n ( d l g l o g i n [ 2 ] , new D i a l o g I n t e r f a c e . O n C l i c k L i s t e n e r ( ) { 

269 p u b l i c v o i d o n C l i c k ( D i a l o g I n t e r f a c e d i a l o g , i n t whichButton ) { 



270 S t r i n g u s e r = t x t u s e r . getText ( ) . t o S t r i n g ( ) ; 

271 S t r i n g pw = txt pw . getText ( ) . t o S t r i n g ( ) ; 

272 da . mLogin . add ( u s e r ) ; 

273 da . mLogin . add (pw) ; 

274 

275 // i f checkbox i s checked , s a v e l o g i n 

276 i f ( c b s a v e l o g i n . isChecked ( ) ) da . w r i t e L o g i n T o F i l e ( ) ; 

277 

278 // format and send message based on r e q u e s t e d s e r v i c e 

279 da . sendMessageThread ( da . formatMessage ( ) ) ; 

280 r e t u r n ; 

281 } 

282 }) ; 

283 b u i l d e r . s e t N e g a t i v e B u t t o n ( d l g l o g i n [ 3 ] , new D i a l o g I n t e r f a c e . O n C l i c k L i s t e n e r ( ) { 

284 p u b l i c v o i d o n C l i c k ( D i a l o g I n t e r f a c e d i a l o g , i n t whichButton ) { 

285 r e t u r n ; 

286 } 

287 }) ; 

288 A l e r t D i a l o g a l e r t = b u i l d e r . c r e a t e ( ) ; 

289 a l e r t . show ( ) ; 

290 } 

291 

292 /∗∗ 

293 ∗ Pops up P r o g r e s s D i a l o g which i s d i s p l a y e d w h i l e l o n g e r o p e r a t i o n s a r e pending 

294 ∗ 

295 ∗ @param type the type o f P r o g r e s s D i a l o g message which s h o u l d be shown 

296 ∗/ 

297 p u b l i c v o i d s h o w P r o g r e s s D i a l o g ( DataAccess . showProgressDlgMsg type ) { 

298 s w i t c h ( type ) { 

299 c a s e OFF: 

300 d i a l o g . d i s m i s s ( ) ; 

301 break ; 

302 c a s e LOADSERVICE: 

303 S t r i n g [ ] d l g l o a d s e r v i c e = g e t R e s o u r c e s ( ) . g e t S t r i n g A r r a y (R. a r r a y . 

d l g l o a d s e r v i c e ) ; 

304 d i a l o g = P r o g r e s s D i a l o g . show ( CodeScanner . t h i s , d l g l o a d s e r v i c e [ 0 ] , 

d l g l o a d s e r v i c e [ 1 ] ) ; 

305 break ; 

306 c a s e BOOKSERVICE: 

307 S t r i n g [ ] d l g b o o k s e r v i c e = g e t R e s o u r c e s ( ) . g e t S t r i n g A r r a y (R. a r r a y . 

d l g b o o k s e r v i c e ) ; 

308 d i a l o g = P r o g r e s s D i a l o g . show ( CodeScanner . t h i s , d l g b o o k s e r v i c e [ 0 ] , 

d l g b o o k s e r v i c e [ 1 ] ) ; 

309 } 

310 } 

311 

312 /∗∗ 

313 ∗ Shows d i a l o g with booking c o n f i r m a t i o n 

314 ∗ I f s e n d i n g o p e r a t i o n was s u c c e s s f u l : 

315 ∗ A l e r t D i a l o g . B u i l d e r −o b j e c t i s c r e a t e d what i s s e t with d i f f e r e n t p r o p e r t i e s ( t i t l e , 

message , p o s i t i v e / n e g a t i v e button ) 

316 ∗ I f not : 

317 ∗ A t o a s t ( a s h o r t d i a l o g message ) pops up with s e n d i n g r e q u e s t e r r o r 

318 ∗ 

319 ∗ @param s e n t the b o o l e a n v a l u e which i n d i c a t e s s t a t e o f s e n d i n g r e q u e s t 

320 ∗/ 

321 p u b l i c v o i d showBookedDlg ( b o o l e a n s e n t ) { 

322 S t r i n g [ ] d l g b o o k e d = g e t R e s o u r c e s ( ) . g e t S t r i n g A r r a y (R. a r r a y . d l g b o o k e d ) ; 

323 

324 i f ( s e n t ) { 

325 A l e r t D i a l o g . B u i l d e r b u i l d e r = new A l e r t D i a l o g . B u i l d e r ( t h i s ) ; 

326 b u i l d e r . s e t T i t l e ( d l g b o o k e d [ 0 ] ) ; 

327 b u i l d e r . s e t M e s s a g e ( " D e r D i e n s t \ " "+da . mService . g e t ( 0 )+" \ " w u r d e e r f o l g r e i c h g e b u c h t 

. M ö c h t e n S i e d e n T e r m i n i n I h r e n K a l e n d e r e i n t r a g e n ? " ) ; 

328 b u i l d e r . s e t P o s i t i v e B u t t o n ( d l g b o o k e d [ 1 ] , new D i a l o g I n t e r f a c e . O n C l i c k L i s t e n e r ( ) { 

329 @Override 

330 p u b l i c v o i d o n C l i c k ( D i a l o g I n t e r f a c e d i a l o g , i n t which ) { 

331 addEvent ( ) ; 

332 r e t u r n ; 

333 } 

334 }) ; 

335 b u i l d e r . s e t N e g a t i v e B u t t o n ( d l g b o o k e d [ 2 ] , new D i a l o g I n t e r f a c e . O n C l i c k L i s t e n e r ( ) { 

336 @Override 


338 r e t u r n ; 

339 } 

340 }) ; 


342 a l e r t . show ( ) ; 

343 } 

344 e l s e Toast . makeText ( t h i s , d l g b o o k e d [ 3 ] , Toast .LENGTH LONG) . show ( ) ; 

345 } 

346 

347 /∗∗ 

348 ∗ Pops up c r e d i t s d i a l o g 

349 ∗ 1 . Obtains d i a l o g messages from s t r i n g r e s o u r c e s 

350 ∗ 2 . C r e a t e s A l e r t D i a l o g −B u i l d e r −o b j e c t 

351 ∗ 3 . S e t s d i a l o g p r o p e r t i e s t i t l e , message and an OK−button 

352 ∗ 4 . Shows d i a l o g 

353 ∗ 

354 ∗/ 

355 p u b l i c v o i d s h o w C r e d i t s ( ) { 



356 S t r i n g [ ] d l g c r e d i t s = t h i s . g e t R e s o u r c e s ( ) . g e t S t r i n g A r r a y (R. a r r a y . d l g c r e d i t s ) ; 

357 

358 A l e r t D i a l o g . B u i l d e r b u i l d e r = new A l e r t D i a l o g . B u i l d e r ( t h i s ) ; 

359 b u i l d e r . s e t T i t l e ( d l g c r e d i t s [ 0 ] ) ; 

360 b u i l d e r . s e t M e s s a g e ( d l g c r e d i t s [ 1 ] ) ; 

361 b u i l d e r . s e t N e u t r a l B u t t o n ( d l g c r e d i t s [ 2 ] , new D i a l o g I n t e r f a c e . O n C l i c k L i s t e n e r ( ) { 

362 @Override 


364 r e t u r n ; 

365 } 

366 }) ; 


368 a l e r t . show ( ) ; 

369 } 

370 

371 //PRIVATE METHODS 

372 /∗∗ 

373 ∗ I n i t i a l i z e s UI Elements by r e f e r r i n g to ID r e s o u r c e s p r o v i d e d by the xml−l a y o u t f i l e s 

374 ∗/ 

375 p r i v a t e v o i d i n i t U I ( ) { 

376 l a y o u t s c a n n i n g = ( R e l a t i v e L a y o u t ) findViewById (R. i d . l a y o u t s c a n n i n g ) ; 

377 l a y o u t b o o k i n g = ( R e l a t i v e L a y o u t ) findViewById (R. i d . l a y o u t b o o k i n g ) ; 

378 i m g q r = ( ImageView ) findViewById (R. i d . i m g q r ) ; 

379 b t n s c a n = ( Button ) findViewById (R. i d . b t n s c a n ) ; 

380 b t n r e s c a n = ( Button ) findViewById (R. i d . b t n r e s c a n ) ; 

381 b t n b o o k s e r v i c e = ( Button ) findViewById (R. i d . b t n b o o k s e r v i c e ) ; 

382 b t n m a k e c a l l = ( Button ) findViewById (R. i d . b t n m a k e c a l l ) ; 

383 t x t t i t l e = ( TextView ) findViewById (R. i d . t x t t i t l e ) ; 

384 t x t d e s c = ( TextView ) findViewById (R. i d . t x t d e s c ) ; 

385 t x t d a t e = ( TextView ) findViewById (R. i d . t x t d a t e ) ; 

386 t x t c o s t s = ( TextView ) findViewById (R. i d . t x t c o s t s ) ; 

387 } 

388 

389 /∗∗ 

390 ∗ I n i t i a l i z e s Scanning−Layout 

391 ∗ 1 . Shows Scanning−Layout 

392 ∗ 2 . S e t s two OnClick l i s t e n e r to shown image and button 

393 ∗/ 

394 p r i v a t e v o i d i n i t S c a n n i n g L a y o u t ( ) { 

395 l a y o u t s c a n n i n g . s e t V i s i b i l i t y ( View . VISIBLE ) ; 

396 b t n s c a n . s e t O n C l i c k L i s t e n e r ( new View . O n C l i c k L i s t e n e r ( ) { 

397 @Override 


399 S t r i n g [ ] d l g s c a n n e r d l = g e t R e s o u r c e s ( ) . g e t S t r i n g A r r a y (R. a r r a y . 

d l g s c a n n e r d l ) ; 

400 I n t e n t I n t e g r a t o r . i n i t i a t e S c a n ( CodeScanner . t h i s , d l g s c a n n e r d l [ 0 ] , 

d l g s c a n n e r d l [ 1 ] , d l g s c a n n e r d l [ 2 ] , d l g s c a n n e r d l [ 3 ] , " Q R _ C O D E " ) ; 

401 } 

402 }) ; 

403 i m g q r . s e t O n C l i c k L i s t e n e r ( new View . O n C l i c k L i s t e n e r ( ) { 

404 @Override 


406 S t r i n g [ ] d l g s c a n n e r d l = g e t R e s o u r c e s ( ) . g e t S t r i n g A r r a y (R. a r r a y . 

d l g s c a n n e r d l ) ; 

407 I n t e n t I n t e g r a t o r . i n i t i a t e S c a n ( CodeScanner . t h i s , d l g s c a n n e r d l [ 0 ] , 

d l g s c a n n e r d l [ 1 ] , d l g s c a n n e r d l [ 2 ] , d l g s c a n n e r d l [ 3 ] , " Q R _ C O D E " ) ; 

408 } 

409 }) ; 

410 } 

411 

412 /∗∗ 

413 ∗ I n i t i a t e s p h o n e c a l l to phonenr saved i n mService o f DataAccess−o b j e c t 

414 ∗ 1 . C r e a t e s URI from phonenr 

415 ∗ 2 . C r e a t e s an i m p l i c i t i n t e n t with ACTION CALL 

416 ∗ 3 . Sends i n t e n t 

417 ∗/ 

418 p r i v a t e v o i d makeCall ( ) { 

419 Uri u r i = Uri . p a r s e ( da . mService . g e t ( 4 ) ) ; 

420 I n t e n t i n t e n t = new I n t e n t ( I n t e n t . ACTION CALL, u r i ) ; 


422 } 

423 

424 /∗∗ 

425 ∗ Adds an e v e n t to the c a l e n d a r 

426 ∗ 1 . C r e a t e s i n t e n t 

427 ∗ 2 . Puts e v e n t i n f o r m a t i o n t o i n t e n t 

428 ∗ 3 . Formats p r e v i o u s l y f o r m a t t e d date t o s t a n d a r d Date−format 

429 ∗ 4 . Sends i n t e n t 

430 ∗/ 

431 p r i v a t e v o i d addEvent ( ) { 

432 I n t e n t i n t e n t = new I n t e n t ( I n t e n t . ACTION EDIT) ; 

433 i n t e n t . setType ( " v n d . a n d r o i d . c u r s o r . i t e m / e v e n t " ) ; 

434 i n t e n t . putExtra ( " t i t l e " , da . mService . g e t ( 0 ) ) ; 

435 i n t e n t . putExtra ( " d e s c r i p t i o n " , da . mService . g e t ( 1 ) ) ; 

436 

437 Date date = n u l l ; 

438 t r y { 

439 S t r i n g p a t t e r n = " d d . M M . y y ’ u m ’ H H : m m ’ U h r ’ " ; 

440 SimpleDateFormat s d f = new SimpleDateFormat ( p a t t e r n ) ; 

441 date = s d f . p a r s e ( da . mService . g e t ( 2 ) ) ; 


443 Log . e ( " d a t e p a r s e _ e r r o r " , e . t o S t r i n g ( ) ) ; 



444 } 

445 

446 Double d u r a t i o n = new Double ( da . mService . g e t ( 5 ) ) ; 

447 l o n g durationms = ( l o n g ) ( d u r a t i o n ∗3600∗1000) ; 

448 

449 i n t e n t . putExtra ( " b e g i n T i m e " , date . getTime ( ) ) ; 

450 i n t e n t . putExtra ( " e n d T i m e " , date . getTime ( )+durationms ) ; 

451 i n t e n t . putExtra ( " a l l D a y " , f a l s e ) ; 


453 } 

454 } 



Literaturverzeichnis 

[BP09] Becker, A. ; Pant, M.: Android: Grundlagen und Programmierung. 

dpunkt.verlag GmbH, 2009 

[Bun11] Bundesverband Informationswirtschaft, Telekommunikation 

und neue Medien e.V. (BITKOM): Jeder fünfte Handynutzer besitzt 

ein Smartphone. http://www.bitkom.org/65510_65506.aspx, zuletzt abgerufen 

am 31.03.2011 

[Can11] Canalys: Google’s Android becomes the world’s leading smart phone platform. 

http://www.canalys.com/pr/2011/r2011013.html, zuletzt abgerufen 

am 23.03.2011 

[com11] comScore, Inc.: Smartphones gewinnen an Fahrtwind in Deutschland. 

http://www.comscore.com/ger/Press_Events/Press_Releases/2011/1/ 

Google_Android_Shows_Fastest_Growth_Among_Smartphone_Platforms_ 

in_Germany, zuletzt abgerufen am 31.03.2011 

[Goo11] Google: Android Developers. http://developer.android.com, zuletzt 

abgerufen am 23.03.2011 

[HBF07] Hompel, M. ; Büchter, H. ; Franzke, U.: Identifikationssysteme und 

Automatisierung. Springer, 2007 

[Heg10] Hegen, M.: Mobile Tagging: Potenziale von QR-Codes im Mobile Business. 

Diplomica Verlag, 2010 

[hei11] heise online: IDC-Prognose: Smartphones boomen weiter, Microsoft überholt 

Apple. http://heise.de/-1217792, zuletzt abgerufen am 31.03.2011 

[Int11a] Internet Engineering Task Force (IETF): RFC 2818 - HTTP 

over TLS. http://tools.ietf.org/html/rfc2818, zuletzt abgerufen am 

25.03.2011 

[Int11b] Internet Engineering Task Force (IETF): RFC3966 - The tel URI 

for Telephone Numbers. http://tools.ietf.org/html/rfc3966, zuletzt 

abgerufen am 29.03.2011 

[Len00] Lenk, B.I.: Handbuch der automatischen Identifikation: ID-Techniken, 1D- 

Codes, 2D-Codes, 3D-Codes. Monika Lenk Fachbuchverlag, 2000 

[Len02] Lenk, B.: 2D-Codes, Matrixcodes, Stapelcodes, Composite Codes, Dotcodes. 

Lenk Monika Fachbuchverlag, 2002 



[Len04] Lenk, B.: Handbuch der Automatischen Identifikation 3. Strichcode-Praxis: 

Projektierung, Codeauswahl, Drucktechnik, Codeprüfung, Etikettierung, Lesegeräte. 

Monika Lenk Fachbuchverlag, 2004 

[Len05] Lenk, B.: Optische Identifikation. Monika Lenk Fachbuchverlag, 2005 

[LT07] Langlotz Tobias, Bimber O.: Unsynchronized 4D Barcodes - Coding and 

Decoding Time-Multiplexed 2D Colorcodes / Bauhaus-University Weimar. 

2007. – Forschungsbericht 

[Ora11a] Oracle Corporation (Hrsg.): Open Message Queue 4.5 Technical Overview. 

Redwood City, CA 94065, U.S.A.: Oracle Corporation, 2011 

[Ora11b] Oracle Corporation: Universal Message Service (UMS). http: 

//mq.java.net/4.3-content/ums/umsIntro.html, zuletzt abgerufen am 

24.03.2011 

[PDK03] Pötzsch ; Decker ; Kühnen: Private Haushalte in der Informationsgesellschaft. 

http://www.destatis.de/jetspeed/ 

portal/cms/Sites/destatis/Internet/DE/Content/Publikationen/ 

Querschnittsveroeffentlichungen/WirtschaftStatistik/ 

Informationsgesellschaft/Privhaushalte,property=file.pdf, 2/2003 

[Pro11] Projekt WEITBLICK: WEITBLICK - Wissenbasierte Technologien 

und bedarfsgerechte Leistungen für Senioren durch individualisierte 

Care-Konzepte. http://www.weitblick-aal.de/, zuletzt abgerufen am 

20.03.2011 

[Rod08] Rodriguez, Alex ; IBM (Hrsg.): RESTful Web services: The basics. : 

IBM, 2008 

[Sch06] Schwenkler, T.: Sicheres Netzwerkmanagement: Konzepte, Protokolle, 

Tools. Springer, 2006 

[Son10] Soni, H.: Proceedings of the 2009 International Conference on Signals, Systems 

and Automation (ICSSA 2009). Universal-Publishers, 2010 

[Soy11] Soyatec: eUML2. http://www.soyatec.com/euml2/, zuletzt abgerufen 

am 28.03.2011 

[TCK10] Tan, K.T. ; Chai, D. ; Kato, H.: Barcodes for Mobile Devices. Cambridge 

University Press, 2010 

[TEC11] TEC-IT Datenverarbeitung GmbH: Online Barcode Generator. http: 

//barcode.tec-it.com/barcode-generator.aspx, zuletzt abgerufen am 

20.03.2011 

[The11] The Apache Software Foundation: Apache Tomcat 7 Documentation. 

http://tomcat.apache.org/tomcat-7.0-doc/index.html, zuletzt abgerufen 

am 24.03.2011 



[Wan11] Wanninger, B.: Mobile Tagging- Grundlagen, Einsatzmöglichkeiten und 

Akzeptanz. GRIN Verlag GmbH, 2011 

[Wik11] Wikipedia: Smartphone (Wikipedia). http://de.wikipedia.org/wiki/ 

Smartphone, zuletzt abgerufen am 20.04.2011 

[ZXi11a] ZXing Project (Google): zxing - Multi-format 1D/2D barcode image 

processing library with clients for Android, Java. http://code.google.com/ 

p/zxing/, zuletzt abgerufen am 20.03.2011 

[ZXi11b] ZXing Project (Google): Barcode Contents. http://code.google. 

com/p/zxing/wiki/BarcodeContents, zuletzt abgerufen am 20.04.2011 

[ZXi11c] ZXing Project (Google): QR Code Generator. http://zxing. 

appspot.com/generator/, zuletzt abgerufen am 23.03.2011 


Abbildungsverzeichnis 75 

Abbildungsverzeichnis 

2.1 Veranschaulichter Ablauf des gebildeten Rückkanals . . . . . . . . . . . 2 

3.1 Modulbreite/Zellgröße einer optischen Marke (entnommen aus [Len02]) 6 

3.2 Codeaufbau Code-128 . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 

3.3 

” Projekt WEITBLICK“ codiert mit dem Stapelcode PDF417 (erstellt 

mit [TEC11]) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 

3.4 Data Matrix und QR Code: Suchmuster mit Taktzellen (entnommen aus 

[Len05, S. 140 und 150]) . . . . . . . . . . . . . . . . . . . . . . . . . . 14 

3.5 

” Projekt WEITBLICK“ codiert in Data Matrix und QR Code, Vergleich 

der Platzeffizienz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 

3.6 Anschaulich dargestellte Testreihe (aus Tab. 3.2) des praktischen Vergleichs 

von Code-128, Data Matrix und QR Code . . . . . . . . . . . . 19 

4.1 Struktur des Dienstbuchungssystems . . . . . . . . . . . . . . . . . . . 22 

4.2 Erweiterte Struktur des Dienstbuchungssystems . . . . . . . . . . . . . 25 

4.3 Architektur eines Universal Message Service (UMS) (entnommen aus 

[Ora11b]) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 

4.4 JMS Nachrichten Domänen (entnommen aus [Ora11a, S. 27]) . . . . . . 27 

4.5 Android Systemarchitektur (entnommen aus [Goo11]) . . . . . . . . . . 31 

4.6 Verschachtelung von UI-Elementen (entnommen aus [Goo11]) . . . . . 36 

4.7 Scanning- und BookingLayout des User Interface . . . . . . . . . . . . 36 

4.8 Klassendiagramm der CodeScanner App . . . . . . . . . . . . . . . . . 40 


Tabellenverzeichnis 76 

Tabellenverzeichnis 

3.1 Anzahl der zu codierenden Zeichen . . . . . . . . . . . . . . . . . . . . 9 

3.2 Vergleich des maximalen Leseabstands (in cm) der Codes Code-128, Data 

Matrix, QR Code in Abhängigkeit vom horizontalen Betrachtungswinkel 

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 

4.1 SQL-Tabelle des mySQL-Servers als Dienstserver . . . . . . . . . . . . 30 



Abkürzungsverzeichnis 

aapt . . . . . . . . . . . . . . . . Android Asset Packaging Tool 

AI . . . . . . . . . . . . . . . . . Application Identifier 

API . . . . . . . . . . . . . . . . Application Program Interface 

ASCII . . . . . . . . . . . . . . American Standard Code for Information Interchange 

CA . . . . . . . . . . . . . . . . . Certification Authority 

CCD . . . . . . . . . . . . . . . Charge-coupled Device 

CE-HTML . . . . . . . . . Consumer-Electronics HyperText Markup Language 

CRC . . . . . . . . . . . . . . . Cyclic Redundancy Check 

DEX . . . . . . . . . . . . . . . dalvik executables 

dip . . . . . . . . . . . . . . . . . density independent pixels 

DVB-RCS . . . . . . . . . . Digital Video Broadcast - Return Channel Satellite 

DVM . . . . . . . . . . . . . . . Dalvik Virtual Machine 

EAN . . . . . . . . . . . . . . . European Article Number 

GTIN . . . . . . . . . . . . . . Global Trade Item Number 

GUI . . . . . . . . . . . . . . . . Graphical User Interface 

HbbTV . . . . . . . . . . . . Hybrid Broadcast Broadband TV 

HCCB . . . . . . . . . . . . . High Capacity Color Barcode 

HTTP . . . . . . . . . . . . . HyperText Transfer Protocol 

HTTPS . . . . . . . . . . . . HyperText Transfer Protocol Secure 

ID . . . . . . . . . . . . . . . . . Identifikationsnummer 

IETF . . . . . . . . . . . . . . . Internet Engineering Taskforce 

IP . . . . . . . . . . . . . . . . . . Internet Protocol 

JDK . . . . . . . . . . . . . . . Java Development Kit 

JMS . . . . . . . . . . . . . . . Java Message Service 

JVM . . . . . . . . . . . . . . . Java Virtual Machine 

MOM . . . . . . . . . . . . . . Message Oriented Middleware 

MP . . . . . . . . . . . . . . . . Mega Pixel 

OCR . . . . . . . . . . . . . . . Optical Character Recognition 

openMQ . . . . . . . . . . . open Message Queue 

OS . . . . . . . . . . . . . . . . . Operating System 

QR Code . . . . . . . . . . . Quick Response Code 

REST . . . . . . . . . . . . . . REpresentational State Transfer 

SDK . . . . . . . . . . . . . . . Standard Development Kit 

SQL . . . . . . . . . . . . . . . . Structured Query Language 

SSL . . . . . . . . . . . . . . . . Secure Sockets Layer 

TLS . . . . . . . . . . . . . . . . Transport Layer Security 

UMS . . . . . . . . . . . . . . . Universal Message Service 

UMTS . . . . . . . . . . . . . Universal Mobile Telecommunications System 



UPC . . . . . . . . . . . . . . . Universal Product Code 

URI . . . . . . . . . . . . . . . . Uniform Resource Identifier 

WLAN . . . . . . . . . . . . . Wireless Local Area Network 

XML . . . . . . . . . . . . . . . eXtensible Markup Language 



Quellcodeverzeichnis 

4.1 Buchung des Dienstes als HTTP Request . . . . . . . . . . . . . . . . . 27 

4.2 HTTP Bestätigungsantwort vom UMS an den Android Client . . . . . 28 

4.3 SQL Anfrage im PHP-Skript . . . . . . . . . . . . . . . . . . . . . . . . 30 

4.4 Das Android Manifest der CodeScanner App . . . . . . . . . . . . . . . 32 

4.5 Übergabe eines Objekts bei Stoppen einer Activity . . . . . . . . . . . 34 

4.6 Einstiegspunkt einer Anwendung: die onCreate(...)-Methode . . . . . . 34 

4.7 Auszug aus codescanner.xml . . . . . . . . . . . . . . . . . . . . . . . . 37 

4.8 Zugriff auf UI-Elemente aus einer Layout-XML-Datei . . . . . . . . . . 38 

4.9 Konstruktor der DataAccess-Klasse . . . . . . . . . . . . . . . . . . . . 40 

4.10 Methode parseScanresult(...) . . . . . . . . . . . . . . . . . . . . . . . . 41 

4.11 HTTP POST zur Anfrage der Dienstinformation über das PHP-Skript 42 

4.12 Auszug aus Methode requestService() . . . . . . . . . . . . . . . . . . . 42 

4.13 Methode requestServiceThread() . . . . . . . . . . . . . . . . . . . . . 43 

4.14 Methode formatMessage() . . . . . . . . . . . . . . . . . . . . . . . . . 43 

4.15 Methode sendMessage(String message) . . . . . . . . . . . . . . . . . . 45 

4.16 onClick Listener und Initiierung des Scanvorgangs . . . . . . . . . . . . 47 

4.17 Überschriebene Methode onActivityResult(...): Abfangen der Scan-Ergebnisse 

und Erstellen eines DataAccess-Objekts . . . . . . . . . . . . . . . . . . 48 

4.18 Methode setStatus(): Steuerung des Ablaufs der Dienstabfrage . . . . . 49 

4.19 Methode initBookingLayout() . . . . . . . . . . . . . . . . . . . . . . . 50 

4.20 Methode makeCall() . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 

A.1 weitblick services.php . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 

A.2 /AndroidManifest.xml . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 

A.3 /res/layout/codescanner.xml . . . . . . . . . . . . . . . . . . . . . . . . 58 

A.4 /res/layout/userpw dialog.xml . . . . . . . . . . . . . . . . . . . . . . . 59 

A.5 /res/menu/optionsmenu.xml . . . . . . . . . . . . . . . . . . . . . . . . 59 

A.6 /res/values/strings.xml . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 

A.7 /src/com.weitblick.codescanner/DataAccess.java . . . . . . . . . . . . . 60 

A.8 /src/com.weitblick.codescanner/CodeScanner.java . . . . . . . . . . . . 65 


Thesen zur Bachelorarbeit 80 

Thesen zur Bachelorarbeit 

1. Der QR Code ist für den Usecase der Aufgabenstellung die bestgeeignetste optische 

Marke. 

2. Bei der Anzeige der Dienstleistung muss auf Authentizität und Integrität geachtet 

werden. 

3. Das Dienstbuchungssystem verlangt Anpassungen sowohl auf der Client- als auch 

auf der Serverseite. 

4. Die Erzeugung eines QR Codes lässt sich sehr einfach implementieren. 

Ilmenau, den 02. 05. 2011 Florian Schlembach 


Erklärung 81 

Erklärung 

Die vorliegende Arbeit habe ich selbstständig ohne Benutzung anderer als der angegebenen 

Quellen angefertigt. Alle Stellen, die wörtlich oder sinngemäß aus veröffentlichten 

Quellen entnommen wurden, sind als solche kenntlich gemacht. Die Arbeit ist 

in gleicher oder ähnlicher Form oder auszugsweise im Rahmen einer oder anderer Prüfungen 

noch nicht vorgelegt worden. 

Ilmenau, den 02. 05. 2011 Florian Schlembach

Technische Universität Ilmenau Fakultät für ... - TU Ilmenau

Erfolgreiche ePaper selbst erstellen

Template löschen?

Als Template speichern?