Technische Universität Ilmenau Fakultät für Elektrotechnik und Informationstechnik. Bachelorarbeit

Transkript

1 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: geboren am: Studiengang: Medientechnologie Studienrichtung: Informations- und Kommunikationstechnik Matrikelnummer: Anfertigung im Fachgebiet: Verantwortlicher Professor: Wissenschaftlicher Betreuer: Kommunikationsnetze Fakultät für Elektrotechnik und Informationstechnik Prof. Dr. rer. nat. habil. Jochen Seitz Dipl.-Ing. Karsten Renhak

2 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.

3 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.

4 Inhaltsverzeichnis i Inhaltsverzeichnis 1 Einführung 1 2 Aufgabenstellung 2 3 Diskussion der optischen Marke Merkmale einer optischen Marke Zeichensätze Informationsdichte und zu codierende Nutzdatenmenge Datensicherheit Flexibilität Standardisierung Anforderungsanalyse für den WEITBLICK Code Standardisierung Datenmenge Flexibilität Fazit aus den gegebenen Anforderungen Arten von optischen Marken Strichcodes Stapelcodes Matrixcodes Praktischer Vergleich der Codes Vergleich der Codes in einer Testreihe Auswertung der Testreihe und Auswahl der optischen Marke Praktische Umsetzung Anforderungen an das Dienstbuchungssystem Struktur des Dienstbuchungssystems Client des Dienstbuchungssystems Konventionen zur Generierung des QR Codes Android als mobiles Betriebssystem Fehlende Java-Bibliotheken Server des Dienstbuchungssystems UMS- und openmq-server als eigentliches Dienstbuchungssystem SQL Server als Dienstserver Die WEITBLICK CodeScanner App Android Grundlagen

5 Inhaltsverzeichnis ii Android Manifest Activities Application Resources Aufbau der CodeScanner App Datenzugriffsklasse DataAccess Methode parsescanresult(...): Parsen der Scan-Ergebnisse Methode requestservice(): Anforderung der Dienstinformationen Methode sendmessage(...): Buchen des Dienstes Main-Activity CodeScanner Methode initscanninglayout(): Aufruf der externen ZXing Barcode Scanner App Verarbeiten der Scan-Ergebnisse und Erstellen eines DataAccess-Objekts Methode initbookinglayout(): Anzeige der Dienstleistung Methode makecall(): Verbindung mit einem Ansprechpartner WEITBLICK QR Code-Generator Zusammenfassung und Ausblick 54 A Quellcodes 57 A.1 mysql-server und PHP-Server als Dienstserver A.2 Android Manifest A.3 Layout A.4 Strings A.5 Datenzugriffsklasse DataAccess() A.6 CodeScanner Activity-Klasse Literaturverzeichnis 72 Abbildungsverzeichnis 75 Tabellenverzeichnis 76 Abkürzungsverzeichnis 77 Quellcodeverzeichnis 79 Thesen zur Bachelorarbeit 80 Erklärung 81

6 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.

7 2 Aufgabenstellung 2 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 einlesen interpretieren senden TV (mit integriertem Receiver) Smartphone (z.b. iphone, Android-Phone) Dienstleistung mit bestimmter ID anrufen Server des Dienstanbieters persönl. Telefongespräch für entspr. Dienstleistung Abbildung 2.1: Veranschaulichter Ablauf des gebildeten Rückkanals 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]

8 2 Aufgabenstellung 3 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.

9 3 Diskussion der optischen Marke 4 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-

10 3 Diskussion der optischen Marke 5 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 drei- bzw. 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 Zeichensätze Der Informationsgehalt einer optischen Marke teilt sich in mehrere einzelne Zeichen auf. Nach DIN 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] 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

11 3 Diskussion der optischen Marke 6 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.] 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.

12 3 Diskussion der optischen Marke 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] 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 ( ) 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

13 3 Diskussion der optischen Marke 8 sich an den vorliegenden Usecase aus der Aufgabenstellung unter Kapitel 2 zu halten und diesen entsprechend der gegebenen Randbedingungen anzupassen 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 Datenmenge Nach [Len04, S ] 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

14 3 Diskussion der optischen Marke 9 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 Kurztitel Kurzbeschreibung Telefonnummer Zeichensatz numerisch ASCII ASCII Gesamt 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.

15 3 Diskussion der optischen Marke 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 eine Testreihe durchgeführt in der die Barcodes im Anwendungsfall verglichen werden 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 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.

16 3 Diskussion der optischen Marke 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) 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-

17 3 Diskussion der optischen Marke 12 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 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, 5N c + 11N ab + 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 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 N c,n ab : Anzahl der Zeichen aus den Zeichensätzen C und A/B, X: Modulbreite, R: Ruhezone (10X)

18 3 Diskussion der optischen Marke 13 Abbildung 3.3: Projekt WEITBLICK codiert mit dem Stapelcode PDF417 (erstellt mit [TEC11]) 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 vom ZXing Barcode Scanner nicht erfolgreich eingescannt werden. Es wird an dieser Stelle daher auf eine nähere Erläuterung des Codes verzichtet 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 mit dem ZXing Barcode 2 numerisch: max 2710 Ziffern, alphanumerisch: 1850 Zeichen, ASCII: 1400 Zeichen, ISO: 1108 Bytes [Len05, S. 120] 3 abhängig von Codeart, bspw. bei Maxicode auch in hexagonaler Form

19 3 Diskussion der optischen Marke 14 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

20 3 Diskussion der optischen Marke 15 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

21 3 Diskussion der optischen Marke 16 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 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-

22 3 Diskussion der optischen Marke 17 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

23 3 Diskussion der optischen Marke Vergleich der Codes in einer Testreihe Die Lesbarkeit von optischen Marken ist stark davon abhängig, wie viele Zeichen darin codiert sind. In Abschnitt 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 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 )

24 3 Diskussion der optischen Marke 19 Winkel Code Code Data Matrix QR Code 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 Auswertung der Testreihe und Auswahl der optischen Marke Werden die Ergebnisse aus 3.2 bildlich dargestellt, ergibt sich die Abb 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. TV QR Code Data Matrix Code 128 Messpunkt 115 cm 135 cm 90 cm Abbildung 3.6: Anschaulich dargestellte Testreihe (aus Tab. 3.2) des praktischen Vergleichs von Code-128, Data Matrix und QR Code

25 3 Diskussion der optischen Marke 20 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.

26 4 Praktische Umsetzung 21 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: 3. Realisierung einer Anwendung auf dem Smartphone zur Erkennung der optischen Marke 4. Übermittlung der Buchungsinformation an einen Server 5. Anruf einer mitcodierten Telefonnummer 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

27 4 Praktische Umsetzung 22 gemeinsame Kommunikationsschnittstelle geschaffen, die Telefondienste sowie auch Internetdienste miteinander vereint und kommunizieren la 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 wu rde nicht ausreichen, um die Authentizita t des Nutzer zu gewa hrleisten. Das System wa re im Falle der Beschaffung einer fremden ID anfa llig fu r missbra 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 ko nnen. Eine Nutzerauthentifizierung erfordert sowohl eine client- als auch eine serverseitige Anpassung. Ebenso muss die Dienstbuchung u ber eine gesicherte, verschlu sselte Verbindung erfolgen, um missbra uchliche Nutzung zu verhindern. Zusammenfassend werden als Anforderungen an das Dienstbuchungssystem folgende Punkte festgelegt: Buchung des Dienstes u ber eine vom WEITBLICK-Projekt entwickelte Kommunikations-Middleware Sicherstellung der Authentizita t und Integrita t der zu buchenden Dienste Authentifizierung des Nutzers Gesicherte U 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. gagarin.e-technik.tu-ilmenau.de chricht JMS Na ServiceID rlogin+ mit Use chricht JMS Na ätigung st e mit B openmq Server Queue: DVB_Rueckkanal SQL QR Code 1##Kaffeefahrt## Smartphone Android OS Internet über WLAN,UMTS Anfr ag mit ID e SQL Antw ort mit D ienst Client Internet mysql Server Dienstserver Server Abbildung 4.1: Struktur des Dienstbuchungssystems Nutzung eines Smartphones als Ru ckkanal fu r digitalen Rundfunk

28 4 Praktische Umsetzung 23 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 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 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 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## (Dienst mit ID=1, Kurztitel= Kaffeefahrt und Telefonnummer ) 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

29 4 Praktische Umsetzung 24 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 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 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

30 4 Praktische Umsetzung 25 bereit. Eine Dienstanforderung u ber eine externe Datenbank wurde nichtsdestotrotz u ber einen Web-Service in Form eines PHP-Skripts3, wie in erla utert, realisiert Server des Dienstbuchungssystems Aus dem Schluss des letzten Abschnitts sind aufgrund fehlender Java-Bibliotheken im Android System Anpassungen an die Serverstruktur des Dienstbuchungssystem no tig, damit der Android Client sowohl fu r die Abfrage als auch fu 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: gagarin.e-technik.tu-ilmenau.de e (SSL) Anfrag ID HTTPS Service + in g o rl ) mit Use rt (SSL o tw n A HTTPS ng u g ti ä mit Best HTTP QR Code 1##Kaffeefahrt## Smartphone Android OS Internet über WLAN,UMTS Client JMS Nachricht mit UserLogin+ServiceID JMS Nachricht mit Bestätigung openmq Server Queue: DVB_Rueckkanal UMS Server Tomcat Webserver Anfra ge m HTTPit ID Antw or t mit D ienst SQL Anfrage mit ID SQL Antwort mit Dienst mysql Server Dienstserver PHP-Skript HTTP Webserver Internet Server Abbildung 4.2: Erweiterte Struktur des Dienstbuchungssystems Die Erweiterung liegt einem sogenannten RESTful Interface zu Grunde. REST steht fu r Representational State Transfer und beschreibt ein Softwarearchitektur-Prinzip, durch das Web-Anwendungen auf mo glichst einfache Weise miteinander kommunizieren ko nnen. Dabei sollen die Anwendungen mittels einfacher HTTP-Verbindungen Ressourcen (im Begriff einer Informationsressource) austauschen ko nnen. Es ist daher ressourcenorientiert und benutzt, je nachdem welche Aktion mit der entsprechenden Ressource durchgefu hrt werden soll, die HTTP Methoden POST, GET, PUT oder DELETE. Folglich kann eine große Anzahl an unterschiedlicher Clients mit dem auf dem REST-basierten Web-Service kommunizieren. Mittlerweile verwenden zahlreiche WebServices eine solche Schnittstelle. Bspw. stellt die Suchmaschine Google bzw. Google Maps eine RESTful Interface API zur Verfu gung. Suchanfragen ko 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 Nutzung eines Smartphones als Ru ckkanal fu r digitalen Rundfunk

31 4 Praktische Umsetzung 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 )

32 4 Praktische Umsetzung 27 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/ 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 :

33 4 Praktische Umsetzung 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/ OK 2 S e r v e r : Apache Coyote / 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 : 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 : 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

34 4 Praktische Umsetzung 29 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 SQL Server als Dienstserver Die bereits in Abschnitt 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 ) 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

35 4 Praktische Umsetzung 30 weitblick services Feld ID title shorttitle descr date duration costs phonenr Typ int(5) varchar(100) varchar(30) varchar(5000) datetime double int(5) 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 (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 einzuschleusen

36 4 Praktische Umsetzung 31 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 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 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

37 4 Praktische Umsetzung 32 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 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 <?xml v e r s i o n=" 1.0 " encoding="utf -8"?> 2 <m a n i f e s t xmlns:android=" http: // schemas. android. com / apk / res / android " 3 package=" com. weitblick. codescanner " 4 a n d r o i d : v e r s i o n C o d e="1" 5 android: versionname=" 1.0 "> 6 <uses p e r m i s s i o n android:name=" android. permission. INTERNET " /> 7 <uses p e r m i s s i o n android:name=" android. permission. CALL_PHONE " /> 8 <uses p e r m i s s i o n android:name=" android. permission. ACCESS_NETWORK_STATE " /> 9 <uses p e r m i s s i o n android:name=" android. permission. READ_PHONE_STATE " /> 10 <a p p l i c a t i o n a n d r o i d : i c o / ic_launcher_codescanner " a n d r o i d : l a b e / app_name "> 11 <a c t i v i t y android:name=". CodeScanner " 12 a n d r o i d : l a b e / app_name "> 13 <i n t e n t f i l t e r> 14 <a c t i o n android:name=" android. intent. action. MAIN " /> 15 <c a t e g o r y android:name=" android. intent. category. LAUNCHER " /> 16 </ i n t e n t f i l t e r> 17 </ a c t i v i t y> 18 </ a p p l i c a t i o n> 19 </ m a n i f e s t> Aus den XML-Tags ist ersichtlich, dass die CodeScanner App als Komponente nur eine einzige Activity (siehe ) besitzt. Die Anwendung trägt den im Attribut android:label gespeicherten Wert CodeScanner. android:icon zeigt auf eine Ressource (im Abschnitt 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 <intent-filter> aufgeführt.

38 4 Praktische Umsetzung 33 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. <intent-filter>. 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 <intent-filter> 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 android.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 <manifest>-tag wird das Android Manifest selbst definiert. xmlns:android legt den Namespace der XML-Datei fest, der die verwendbaren <Tags> beschreibt. Zudem stehen im <manifest> 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 <manifest> 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 Netzwerkstatus 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 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

39 4 Praktische Umsetzung 34 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 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 ü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 <intentfilter> 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 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

40 4 Praktische Umsetzung 35 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 ) ist in der XML-Datei codescanner.xml definiert und befindet sich im Projektverzeichnis im Unterverzeichnis /res/layout 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 name zugegriffen. 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

41 4 Praktische Umsetzung 36 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