Mobile Computing I. Tickapp Projekt. Dustin Augstein, Thomas Filbry, Eric Jahn Sommersemester Prof. Dr. Jörg Sahm

Transkript

1 Mobile Computing I Tickapp Projekt Dustin Augstein, Thomas Filbry, Eric Jahn Sommersemester 2011 Prof. Dr. Jörg Sahm

2 Inhaltsverzeichnis Abbildungsverzeichniss Beschreibung der Anwendung Konzept Applikations Architektur Webservice Architektur PayPal

3 Abbildungsverzeichnis Abbildung 1.1 Screenkonzept 5 Abbildung 2.1 Datenflow-Diagramm 6 Abbildung 3.1 Webservice Architektur 8 3

4 1. Beschreibung der Anwendung Tickapp ist eine Anwendung, die es ermöglicht, Fußalltickets mobil und überall mit seinem Smartphone zu kaufen. Das erworbene Ticket wird auf das Handy geladen und kann am Stadioneingang vorgezeigt werden. Zum Verifizieren der Echtheit wird ein Barcode genutzt. Innerhalb der Veranstaltung Mobile Computing I soll ein Prototyp dieser Anwendung entwickelt werden. 1.1 Konzept Abbildung 1.1 zeigt das Screenkonzept der Anwendung. Der erste Screen, von links aus zu sehen, stellt den Splashscreen dar, welcher beim Öffnen des Apps angezeigt wird. Von diesem wird man automatisch zum Starbildschirm weitergeleitet, bei welchem zwischen Ticket-Shop, Favoriten und bereits gekauften Tickets ausgewählt werden kann. Mit dem Betreten des Ticketshops werden die drei höchsten Fußballligen Deutschlands angezeigt. Durch die Auswahl einer Liga gelangt man auf den nächsten Screen, der alle Vereine der ausgewählten Liga anzeigt, für die Tickets verfügbar sind. Hat man ein Verein ausgewählt, gelangt man zum nächsten Screen, der alle Heimspiele aufzeigt. Diese werden mit Gegner, Datum und Spielort angezeigt. Ebenfalls kann man im unteren Bereich des Bildschirms den Verein zu seinen Favoriten hinzufügen, um diesen später schneller zu erreichen. Durch Auswahl eines Spiels gelangt man zu den verschiedenen Kategorien des Stadions, für welche Tickets über das Handy-App verfügbar sind. Hier gibt es Zusatz Informationen wie Preis und Ermäßigungen der Kategorie sowie ob es sich um ein Stehplatz oder Sitzplatz handelt. Nach der Auswahl einer Kategorie erhält man die Möglichkeit, wenn es sich um einen Sitzplatz handelt, sich einen verfügbaren Platz auszusuchen. Nach Auswahl eines Platzes gelangt man auf den Screen mit den Zahlungsmöglichkeiten. Bei erfolgreicher Bezahlung eines Tickets wird das Ticket in Bereits gekaufte Tickets übertragen und ein entsprechender Barcode vom Server abgefragt. Da es sich um einen Prototypen handelt, werden nicht alle Screens implementiert, da diese überflüssig, anders implementiert sind oder werden. 4

5 Abbildung 1.1 Screenkonzept 5

6 2. Applikations Architektur Abbildung 2.1 Datenflow-Diagramm Abbildung 2 zeigt den Datenfluss unseres Prototyps. Zugleich erschließt sich daraus die Grundarchitektur der Anwendung, welche aus zwei Teilen besteht, die Server- Komponente sowie die Handy-App. Für die Kommunikation zwischen Server und Handy ist die Klasse BusinessLogic zuständig. In jeder Funktion wird überprüft, ob die angeforderten Daten schon auf dem Handy vorhanden sind, ist dies nicht der Fall, werden sie vom Server mithilfe eines Http- Post-Requests ermittelt. Als einheitliches Datenformat kommt JSON zum Einsatz. Damit der User immer die aktuellen Daten zu sehen bekommt, werden die Screens über den DataListener über Änderungen informiert und die Daten daraufhin neu geladen. Jeder Request wird in einem eigenen Thread ausgeführt und enthält ein JSON-Objekt namens action, das mit einer Konstanten des Enums DataAction, definiert in der Datei Http.java, belegt wird. Die Werte des Enums repräsentieren die verfügbaren Funktionen auf dem Server, so können diese dynamisch aufgerufen werden. Am Ende jedes Requests wird ein JSON-Objekt an die Handy-Applikation zurückgegeben. Die Verwaltung des internen Datenflusses übernimmt die Klasse DataStore. Diese erstellt bei der erstmaligen Ausführung der App die Datenbank und enthält alle Funktionen zum Auswählen, Manipulieren und Löschen der Daten. Der 6

7 DatabaseHelper bildet dabei die unterste Schnittstelle und führt alle SQL-Statements aus. Der Einstiegspunkt der Anwendung bildet die Klasse Main. Dort wird zunächst die Device-Nummer des Mobiltelefons ausgelesen (diese dient zum Identifizieren des Nutzers), eine Instanz der Datenbank-Klasse angelegt und die Android-spezifischen Initialisierungsfunktionen aufgerufen. Der erste für den User sichtbare Screen ist der SplashScreen, welcher für drei Sekunden erscheint. In dieser Zeit wird die erste Anfrage an den Server getätigt, falls die Anwendung zum ersten Mal gestartet wurde, wird der User in die Server-Datenbank eingetragen und vorhandene Daten wie Ligen und Teams an das Handy übermittelt. Andernfalls wird überprüft, ob sich Daten auf dem Server geändert haben, ist dies der Fall, werden auch die Daten in der internen Datenbank aktualisiert. Im Laufe der Entwicklung stellte sich heraus, dass Teile der Architektur nicht optimal sind. So musste beispielsweise der ChangeActivityOnItemClickListener angepasst werden. Dieser ist für die Speicherung der Auswahl in einem Screen und das Wechseln von einem zum anderen Screen zuständig. Das Problem war, dass die Auswahl nur für den darauffolgenden Screen sichtbar war, wir für die Weiterverarbeitung der Daten aber teilweise auch auf die Auswahl der vorvorletzten Screens angewiesen sind. Auch das Wechseln zwischen Screens über ein Intent stellte sich als Problem heraus, da immer eine Instanz von den Screens vorhanden sein muss, sofern es wichtig ist, zu welchem Screen zurückgesprungen werden soll. 7

8 3. Webservice Architektur Mithilfe eines PHP Soap-Webservices wurde beispielhaft eine Anbindung an die Datenbank eines Vereins implementiert. Abbildung 3 zeigt die genaue Architektur. Abbildung 3.1 Webservice Architektur Werden von der Applikation Tickets zu einem bestimmten Spiel angefordert, wird vom Controller Tickapp (definiert in tickapp.php) die entsprechende Transformationsklasse geladen. Dafür wird der Vereinsname verwendet, welcher von der Applikation in einem JSON-Objekt gesendet wird, um dynamisch die Klasse zu laden (Funktion getclassinstance() in tickapp.php). Jede Transformationsklasse muss die abstrakte Klasse Club erweitern, um eine einheitliche Schnittstelle zu gewähren. Diese besitzt folgende Methoden: gettickets($matchid) o öffentliche Funktion, bildet die Schnittstelle zum Tickapp-Controller, in dieser Funktion wird transformatetickets() aufgerufen, sie gibt ein Array mit allen verfügbaren Tickets an den Haupt-Controller zurück transformatetickets($matchid) o Hauptfunktion, um Tickets vom jeweiligen Club anzufordern und in unser Format zu transformieren 8

9 getcategories($stadiumid) o mithilfe dieser Funktion werden die Stadionkategorien des jeweiligen Clubs ausgelesen und an unsere Anwendung zurückgeliefert, diese werden daraufhin in unserer Datenbank gespeichert addticket($categoryid, $matchid, $barcode, $seat, $seatrow) o diese Funktion stellt sicher, dass unser Ticket-Format eingehalten wird, der übergebene Barcode (2/5 Interleaved Barcode) setzt sich dabei wie folgt zusammen: 4 Prüfziffern Spieldatum (yyyymmdd) Platzkategorie (xx) Sitz(xx) Reihe (xx) Spieltag (xx) 9

10 4. PayPal Im Prototyp wurde ein PayPal-Service zum Kaufen von Tickets implementiert. Mit den folgenden Daten kann der Testaccount genutzt werden: Password: tickapptest Für einen Produktiveinsatz sind auch andere Bezahlverfahren denkbar, beispielsweise per Kreditkarte. 10