FH JOANNEUM Gesellschaft mbh myfhj Entwicklung einer Apple iphone Applikation für die FH JOANNEUM GmbH Bachelorarbeit zur Erlangung des akademischen Grades Bachelor of Science in Engineering (BSc.) eingereicht am Fachhochschul-Studiengang Software Design Betreuer: Feiner, Johannes eingereicht von: Markus Scheucher Personenkennzahl: 0810418065 September 2011
i Ehrenwörtliche Erklärung Ich versichere an Eides statt durch meine Unterschrift, dass ich die vorliegende Arbeit selbstständig und ohne fremde Hilfe angefertigt und alle Stellen, die ich wörtlich oder annähernd wörtlich aus veröffentlichten oder nicht veröffentlichten Quellen übernommen habe, als solche kenntlich gemacht habe und mich auch keiner anderen als der angegebenen Literatur oder sonstiger Hilfsmittel bedient habe. Die Arbeit ist in gleicher oder ähnlicher Form noch keiner Prüfungsbehörde vorgelegt worden. Kapfenberg, am 02.09. 2011 Markus Scheucher
ii Kurzfassung In dieser Arbeit wird versucht zu ermitteln welche Funktionen eine Applikation für ein mobiles Endgerät haben muss um Studierende (im Besonderen Studierende der FH JOANNEUM) in ihrem akademischen Alltag zu unterstützen. Dazu wird zunächst im Vorfeld eine Umfrage durchgeführt, um den Bedarf an bestimmten Funktionen sowie die Verteilung von Smartphones beziehungsweise deren Betriebssysteme festzustellen. Das Hauptziel dieser Arbeit ist die Umsetzung und Veröffentlichung einer solchen Applikation. Unter dem Namen myfhj wird eine Applikation für das mobile Betriebssystem von Apple ios implementiert und anschließend in die Verkaufsplattform von Apple Computers dem App Store gestellt. Die gesamte Implementierung des Projektes und die einzelnen Einreichungsvorgänge in den App Store werden in dieser Arbeit genauestens dokumentiert Diese App wird kostenlos auf dieser Plattform zu Verfügung gestellt und iterativ erweitert. Darüber hinaus wird auch der gesamte Quellcode dazu unter einer offenen Lizenz veröffentlicht, damit andere interessierte Personen das Projekt erweitern, verbessern und, was noch viel interessanter ist, weitere Ideen einbringen können. Abstract The main goal of this thesis is the implemantation and distribution of an applicaton for mobile devices, that supports students of the FH JOANNEUM. Prior to this work there was a survey of the students conducted to get some clues what kind of functionality they need. This document contains a detailed description of the implementation of the app myfhj for the mobile operating system ios from Apple. Furthermore there will be a complete documentation of the app submitions to Apple s plattform App Store. The application myfhj will be free to download from there. Additionaly the whole project will be made available through a open source license. Anyone, who is interested, can check out the source code, can make his changes, improvements and maybe bring in some new ideas.
Inhaltsverzeichnis 1 Einführung 2 1.1 Motivation............................... 2 1.2 Ziele.................................. 3 1.3 Aufbau der Arbeit.......................... 3 2 Stand der Technik 4 2.1 Definitionen.............................. 4 2.1.1 Der Begriff Smartphone.................. 4 2.1.2 App.............................. 6 2.1.3 Mobile Betriebssysteme.................... 6 2.2 Programmierung für das ios..................... 8 2.2.1 Die Programmiersprache Objective-C............ 8 2.2.2 ios Grundaufbau....................... 8 2.2.3 ios Frameworks........................ 9 2.2.4 Interface Builder....................... 10 2.2.5 Foundation.......................... 11 2.2.6 TouchXML.......................... 12 2.3 Musterlösungen............................ 12 2.3.1 TUGraumplan und TUGsearch............... 12 3 Umfrage 16 3.1 Aufbau................................. 16 3.2 Auswertung der Umfrageergebnisse................. 17 3.2.1 Smartphones der Studierenden................ 18 iii
INHALTSVERZEICHNIS iv 3.2.2 Bewertung von vorgegebenen Features........... 19 3.2.3 Freitext Felder........................ 25 4 Umsetzung 27 4.1 Entwicklungsumgebung........................ 27 4.2 Genereller Designansatz....................... 27 4.3 Provisionierung des Quellcodes................... 28 4.4 Die Applikation............................ 28 4.4.1 Die Funktionen........................ 29 4.5 Veröffentlichung der Applikation................... 37 4.5.1 Provisionierung........................ 37 4.5.2 Einreichungen im App Store................. 38 5 Ergebnisse 42 5.1 Die Umfrage.............................. 42 5.2 Dokumentation der Entwicklung und der Provisionierung..... 43 5.3 iphone App.............................. 44 6 Schlussfolgerung 45 6.1 Zusammenfassung........................... 45 6.2 Ein Ausblick in die Zukunft..................... 45 6.3 Persönliche Meinung......................... 46
Abbildungsverzeichnis 2.1 Schichten des ios........................... 8 2.2 TUGraumplan............................. 12 2.3 TUGsearch.............................. 12 2.4 Vier Screenshots der Applikation TUGraumplan.......... 13 2.5 Vier Screenshots der Applikation TUGsearch............ 14 3.1 Umfrage: Smartphones........................ 18 3.2 Möglichkeit zur Kommunikation unter den Studierenden..... 19 3.3 Möglichkeit zur Kommunikation zwischen Studierende und Lehrende 19 3.4 Möglichkeit zur Kommunikation zwischen Studierenden und Administration.............................. 20 3.5 Hörsaalfinder............................. 21 3.6 Zugriff auf die Bibliothek....................... 21 3.7 Newsletter............................... 22 3.8 Prüfungsplaner............................ 23 3.9 Stundenplan.............................. 23 3.10 Taskplaner............................... 24 4.1 Tab Bar -Navigation der ersten Implementation.......... 28 4.2 myfhj Hauptmenü.......................... 29 4.3 UITableViewCellAccessoryDetailDisclosureButton......... 31 4.4 Beispiel der Table View für News und Events........... 32 4.5 Agenda im Landscape-Modus.................... 33 4.6 Ansicht der überarbeiteten Agenda................. 35 v
ABBILDUNGSVERZEICHNIS 1 4.7 Settings View und Info Alert View Beispiel Kürzel"........ 36 4.8 Toolbar mit Der Schaltfläche Info................. 37 4.9 itunes Connect: App Verwaltung.................. 38 4.10 Submission Note zur zweiten Einreichung.............. 40 5.1 Zusammenfassung der Funktionsbewertungen........... 42 5.2 Vereinfachte Darstellung der Funktionsbewertungen........ 43 5.3 myfhj Icon.............................. 44
Kapitel 1 Einführung Laut einer Umfrage von T-Mobile Austria im Jahre 2009 gab es in Österreich bereits rund 2,2 Millionen Smartphones und die Anzahl steigt weiter. [13] Die Internetzeitschrift Compterwelt.at schrieb am 21.05.2010, dass 85 Prozent der Personen in Österreich, die Smartphones besitzen, mobile Apps nutzen. [14] Gefragt sind vor allem Applikationen mit lokalem Bezug und konkretem Nutzen. Zu Beginn dieser Arbeit wird eine Umfrage durchgeführt, die einen Hinweis auf die tatsächliche Anzahl an Studierenden mit Smartphone an der FH JOANNEUM liefern wird. Was aber noch interessanter ist, sind die Antworten auf die Frage welche Funktionen von einer Applikation erwartet werden, die genau für diese Zielgruppe entwickelt werden soll. 1.1 Motivation Der Zweck dieser Arbeit ist die Erhebung von Anforderungen, die an eine mobile Applikation für Studierende gestellt werden, sowie eine Umsetzung der gewonnenen Daten. Für die Erhebung wird eine Umfrage unter den Studierenden der FH JOANNEUM durchgeführt. Dadurch werden wichtige Daten aus erster Hand gewonnen. Aufbau, Durchführung und Ergebnisse dieser Umfrage sind im Kapitel 3 dieser Arbeit zu finden. Mit den gewonnen Daten lässt sich der wirkliche Bedarf an bestimmten Funktionen ablesen. Dies liefert wichtige Hinweise für den praktischen Teil dieser Arbeit. 2
KAPITEL 1. EINFÜHRUNG 3 1.2 Ziele Das Hauptziel dieser Arbeit ist die Umsetzung einer Applikation für das Apple iphone in der die Ergebnisse der Umfrage einfließen werden. Diese App wird im Anschluss an eine grundlegende Implementation über den Apple App Store kostenlos veröffentlicht und kontinuierlich verbessert werden. Jedoch werden nicht sämtliche Vorschläge der Umfrageergebnisse umgesetzt werden können. Daher wird auch der Quellcode der Applikation frei verfügbar gemacht um interessierten Personen die Möglichkeit zu geben eigene Features einzubauen oder bestehende zu verbessern. 1.3 Aufbau der Arbeit Hier im ersten Kapitel wurden die grundlegenden Fragestellungen und die Ziele, die zu erreichen sind, vorgestellt. Im folgenden Kapitel 2 werden nun Terme und Konzepte, mit den sich diese Arbeit beschäftigt, beleuchtet. Daneben werden noch zwei Musterlösungen der TU (Technische Universität) Graz präsentiert. Das dritte Kapitel beschäftigt sich mit der Umfrage zum Thema mobile Applikation für Studierende, welche im Vorfeld dieser Arbeit unter den Studierenden der FH JOANNEUM durchgeführt wurde. Das Kapitel 4 dokumentiert die Umsetzung des Projektes myfhj in zwei Teilen. Im ersten Teil werden die Implementation und der Aufbau des Prototyps erläutert. Der zweite Teil dokumentiert die Provisionierung sowie die Einreichungen in den Apple App Store. Im sechsten Kapitel werden die Ergebnisse dieser Arbeit zusammengetragen und im letzten Kapitel zusammengefasst. Daneben gibt es im letzten Kapitel einen Ausblick auf die Zukunft des Projektes myfhj sowie eine persönliche Meinung.
Kapitel 2 Stand der Technik Im Verlauf dieser Arbeit werden einige Begriffe genannt, die sich auf bestimmte Konzepte im Zusammenhang mit der Programmierung für mobile Geräte beziehen. In diesem Kapitel werden diese Konzepte vorgestellt. Danach werden zwei Musterlösungen präsentiert. 2.1 Definitionen 2.1.1 Der Begriff Smartphone Eine ausführliche Definition für diese Geräte versuchte bereits 2003 eine Studie der Universität Osnabrück zu liefern. In der Vergangenheit sind sowohl Telefone als auch Computer zunehmend mobiler geworden und bewegen sich in ihren Entwicklungen immer mehr aufeinander zu. Mit Telefon-, SMS und Internetfunktionen, Datenbanken und Text-, Tabellen-, und Präsentationssoftware ist den Smartphones schon heute der Brückenschlag gelungen. Da es den perfekten Mix aus beiden Welten noch nicht gibt, tendieren Smartphones in ihrem Aussehen und ihren Fähigkeiten meist entweder stärker zum Telefon oder zum Computer/PDA. Der Heise-Verlag hat Anfang 2003 das c t Special 2/2003 mit dem Thema Handhelds herausgebracht, in dem die einzelnen Typen definiert werden: 4
KAPITEL 2. STAND DER TECHNIK 5 Unter die Klasse der PDAs (Personal Digital Assistent) fallen handgroße Geräte mit Display, auch manchmal als Handheld bezeichnet. Ein ausgewachsener PDA mit integrierten Mobiltelefonfunktionen heißt Wireless Handheld. Geräte, die vom Design und der Funktion her Handys sind, aber ein für Handy-Verhältnisse großes Display haben, beidseitige PIM-Synchronisation mit dem PC beherrschen und sich nachträglich mit Zusatzapplikationen versehen lassen, heißen Smartphones. Meist wird der Begriff Smartphone auf die Wireless Handhelds ausgedehnt, und auch hier sollen sie unter diesem Begriff zusammengefasst werden. [16] Eine modernere Definition ist im Gabler Wirtschaftslexikon zu finden. Mobiltelefon mit erweitertem Funktionsumfang. Dazu zählen neben der Telefonie und Short Message Service (SMS) üblicherweise Zusatzdienste wie Electronic Mail (E-Mail), World Wide Web (WWW), Terminkalender, Navigation sowie Aufnahme und Wiedergabe audiovisueller Inhalte. Auf Smartphones laufen gegenüber herkömmlichen Mobiltelefonen komplexere Betriebssysteme wie etwa Symbian OS, Blackberry OS oder das iphone OS. Die hierdurch geschaffene Möglichkeit zur Installation weiterer Applikationen durch den Endnutzer verleiht Smartphones einen erweiterbaren und individualisierbaren Funktionsumfang." [17] Zusammengefasst sind Smartphones mobile Computer, die unter anderem auch Anrufe und Kurznachrichten aus dem Mobilfunknetz erhalten können. Interessant ist die Möglichkeit selbst Applikationen für diese Geräte zu entwickeln und über eigene Verkaufsplattformen jeder Besitzerin und jedem Besitzer solcher Geräte diese Apps anbieten zu können.
KAPITEL 2. STAND DER TECHNIK 6 2.1.2 App App steht genau genommen als Abkürzung für den englischen Begriff Application (auf Deutsch Anwendung) im Sinne von Computerprogramm. [3] Im heutigen Sprachgebrauch sind damit aber vor allem Anwendungen speziell für mobile Systeme wie Smartphones und Tablet-PCs gemeint. 2.1.3 Mobile Betriebssysteme Mobile Endgeräte wie Smartphones oder Tablet-PCs benötigen spezielle Betriebssyste, welche die verfügbare Hardware optimal nutzen. Es folgt nun ein kurzer Überblick der gängigsten Betriebssysteme. Google Android Android [11] ist ein komplett offenes Betriebssystem für eine Vielzahl von mobilen Endgeräten 1 wie Smartphones, Tablet-PCs oder auch Netbooks. Es steht unter einer Apache/MIT Lizenz, was bedeutet, dass jede Person es frei erweitern und verwenden kann. Es ist auch möglich einen eigenen proprietären Teil einzubauen ohne, dass dieser Teil unter derselben Lizenz veröffentlicht werden muss [10]. Applikationen werden in Java und XML (extensible Markup Language) geschrieben. Es gibt ähnlich wie bei Apple itunes eine eigene Verkaufsplattform mit dem schlichten Namen Marketplace. Apple ios Das ios war bis Juni 2010 als iphone OS bekannt. Am 07. Juni 2010 gab Cisco auf ihrem Firmenblog [4] bekannt, dass es den eingetragenen Markennamen IOS 2 an Apple lizenziert. Es ist das Betriebssystem von Apple Computers Inc. für ipod, iphone, ipad und Apple TV. Apple bietet eine Vielzahl von Referenzunterlagen und Guidelines um 1 Einige Beispiele sind zu finden auf: Google Phone Gallery http://www.google.com/phone/ (Zuletzt aufgerufen am 05. August 2011) 2 IOS (Internetwork Operating System) ist ein Betriebssystem von Cisco Systems, Inc. für ihre Netzwerkprodukte [2]
KAPITEL 2. STAND DER TECHNIK 7 mit den vorgegebenen Frameworks umgehen zu können. Ziel von Apple ist, dass alle Applikationen demselben Designmodell entsprechen. Ein SDK (Software Development Kit) ist für jede als ios-developer registrierte Person verfügbar. Um eine Applikation offiziell auf ein Endgerät zu installieren, wird eine kostenpflichtige Mitgliedschaft in einem Developer Program vorausgesetzt. Applikationen werden in ObjC (Objective-C), C und XML geschrieben. Mehr dazu im Abschnitt 1.4 Programmierung für das ios. Microsoft Windows Phone 7 Windows Phone 7 ist ein Betriebssystem des amerikanischen Unternehmen Microsoft. Applikationen werden in C# geschrieben und können über den eigenen Marketplace vertrieben werden. Nokia Symbian Symbian [1] ist das weltweit noch am Häufigsten genutzte Betriebssystem für Handys und Smartphones. Aber in den letzten Jahren hat es immer mehr an Bedeutung verloren. Apps werden in Java ME (Mobile Edition), C++/Qt, Flash und Scriptsprachen wie JavaScript geschrieben und können über die Verkaufsplattform von Nokia dem OVI-Store vertrieben werden. BlackBerry OS BlackBerry OS, oder früher auch RIM OS genannt, ist ein urheberrechtlich geschütztes Betriebssystem für die Produkte der kanadischen Firma Research in Motion. Die Unterlagen, die auf der BlackBerry Internetpräsenz [15] zu Verfügung stehen, weisen auf vier unterschiedliche Entwicklungsansätze hin, was auch von den Zielgeräten abhängt. Generell werden Anwendungen mit Web-Sprachen wie HTML, CSS, JavaScript und Adobe Flash oder in Java entwickelt.
KAPITEL 2. STAND DER TECHNIK 8 2.2 Programmierung für das ios Spätestens im Kapitel 4 Umsetzung werden Begriffe fallen, die sich auf Programmier- und Designkonzepte für das Betriebssystem ios von Apple beziehen. Dieser Abschnitt soll einen kleinen Einblick in diese verwendeten Elemente vermitteln. 2.2.1 Die Programmiersprache Objective-C ObjC ist die primäre Programmiersprache von Apple für Cocoa (Mac OS) und Cocoa-Touch (ios). Es handelt sich hierbei um eine Erweiterung der Programmiersprache C um objektorientierte Ansätze. [12] 2.2.2 ios Grundaufbau Das Betriebssystem ios lässt sich in grobe Schichten (Abbildung 2.1) [7, ios Technology Layers] aufteilen. Die untersten Schichten Core OS und Core Ser- Abbildung 2.1: Schichten des ios vice bieten fundamentale Schnittstellen für das ios wie primitive Datentypen, Daten- und Netzwerkservices. Die Media Schicht bietet, wie der Name sagt, Technologien zur Darstellung von Grafiken in 2D und 3D, zum Abspielen von Audio und Video und zur Gestaltung einfacher Animationen. In der obersten Schicht Cocoa Touch finden sich schließlich komplexe Schnittstellen und Datentypen wie zum Beispiel das UIKIT Framework und Container- Datentypen.
KAPITEL 2. STAND DER TECHNIK 9 2.2.3 ios Frameworks Die wichtigste Schicht für einen Programmierer in der ios Umgebung ist Cocoa Touch. Das UIKiT Framework Dieses Framework bietet zahlreiche Elemente, mit denen die Benutzer und Benutzerinnen direkt konfrontiert werden. Diese dienen entweder als Container für Texte und weitere UI (User Interface)-Elemente oder zur direkten Interaktion, wie beispielsweise eine Schaltfläche. Standard UI Elemente 3 UIWindow, UIView Windows und Views sind die Basisklassen für jegliche Art von UI. Ein Window repräsentiert den geometrischen Raum, während eine View als Container für weitere Elemente dient. UITextView Text-Views sind spezialisierte View-Klassen um Text anzuzeigen beziehungsweise zu editieren. Eine Notepad Anwendung wäre ein einfaches Beispiel für so eine View. UINavigationDelegate Die iphone Benutzerschnittstelle behandelt seine verschiedenen Fenster ähnlich wie Seiten in einem Buch. Eine Navigation-Bar bietet üblicherweise per Standard eine Schaltfläche an um zum letzten Fenster zurück zu wechseln. Diese Funktionalität ist in fast allen iphone Applikationen von Apple zu finden. UITransition, UIAnimation Transitions sind die Übergänge zwischen den einzelnen Fenstern. Standardmäßig verhält sich so ein Übergang wie das Umblättern in einem Buch wobei es hierfür sogar noch eine feinere Stufung gibt. 3 Vergleiche [21, Kapitel 3.1 Basic User Intrerface Elementss]
KAPITEL 2. STAND DER TECHNIK 10 UIAlertView, UIActionSheet Alert-Views und Action-Sheets sind modale Fenster, die bei konkreten Ereignissen angezeigt werden. Sie sind vergleichbar mit Pop-ups in Internet-Browser. Sie erweisen sich als sehr nützlich in den Fällen in denen die sofortige Aufmerksamkeit der Benutzer erforderlich ist. UITableView Table-Views sind eigentlich nur einspaltige Listen mit denen üblicherweise Elemente von Collections angezeigt werden. In dieser Liste können dann eine oder mehrere dieser Elemente selektiert werden. Das Ereignis bei Selektion und das Aussehen der einzelnen Elemente der Table View kann der Entwickler frei definieren. UIStatusBar Die Status-Bar ist eine dünne graue Leiste am oberen Bildschirmrand des iphone. Per Standard ist dieser Teil über alle Applikationen des iphone sichtbar. Ein Entwickler kann gewisse Eigenschaften wie Farbe beziehungsweise Deckkraft und diverse Notifikationen anpassen. 2.2.4 Interface Builder Der Interface Builder ist eine grafische Schnittstelle um Oberflächen für Applikationen zu gestalten. Dabei werden die einzelnen Elemente mit Maus und Tastatur angeordnet und über sogenannte Outlets mit den Controller-Klassen verbunden. In der ios-entwicklung werden diese Informationen in XIB(XML Interface Builder)-Dateien gespeichert. Der Interface Builder ist seit Xcode Version 4 fixer Bestandteil der Programmierumgebung. Delegate Ein sehr schönes Praxisbeispiel für ein Decorator Design Pattern liefern uns die sogenannten Delegate. Bei diesem Struktur-Entwurfsmuster kann Funktionalität zu einem vorhandenen Objekt hinzugefügt werden ohne den Code des Objektes selbst zu verändern [18, Seite 40]. Dazu wird im ios bei solchen Objekten eine eigene Delegate -Schnittstelle verwendet. Der wichtigste Vertreter ist die UIApplication Klasse, welche auch ein Singleton Design Pattern implementiert. Mit die-
KAPITEL 2. STAND DER TECHNIK 11 sem Erzeugungsmuster kann das Objekt nur ein einziges Mal instanziiert werden. Der Constructor ist nicht sichtbar (private) und es steht lediglich eine shared- Instance zu Verfügung. Diese Klasse implementiert den UIApplicationDelegate, der es gestattet weitere Funktionalität bei bestimmten Ereignissen hinzuzufügen. Zum Beispiel was geschehen soll, wenn die Applikation in den Hintergrund Modus geschalten wird oder das Gerät (iphone) erhält einen Anruf. [8, UIApplicationDelegate Protocol Reference] Weitere wichtige Delegate sind UITableViewDelegate und UITableViewDatasource. 2.2.5 Foundation Dieses Framework bietet eine Sammlung an elementaren Utility Klassen wie Collections und Strings. Nicht alle Datentypen in diesem Framework sind ObjC Objekte, es finden sich hier auch sehr viele primitive Datentypen sowie C-Strukturen ( struct ) und Aufzählungstypen ( enum ), welche mittels typedef einen ähnlichen Namen erhalten (Siehe Beispiele in Listing 2.1 [5]). 1... 2 typedef unsigned int NSUInteger ; 3... 4 typedef struct _NSRange { 5 NSUInteger l o c a t i o n ; 6 NSUInteger length ; 7 } NSRange 8... 9 enum { 10 NSOrderedAscending = 1, 11 NSOrderedSame, 12 NSOrderedDescending 13 } ; 14 typedef N S In t e g e r NSComparisonResult ; 15... Listing 2.1: Beispiele für C Foundation Datentypen Alle haben das Präfix NS gemein, welches auf den geschichtlichen Ursprung dieser Klassen NeXtStep"hinweist. Es handelt sich dabei um ein frühes Betriebssystem der Firma NeXT. NeXTStep gilt als Urvater von Mac OS, Mac OSX und ios. [6, Cocoa fundamentals Guide]
KAPITEL 2. STAND DER TECHNIK 12 2.2.6 TouchXML TouchXML ist ein Teil des quelloffenen Projectes TouchCode [20] und nicht im ios SDK enthalten. Es handelt sich hierbei um eine Sammlung von Wrapper für Funktionen der ebenfalls quelloffenen C Bibliothek libxml2. Dieser XML-Parser kommt beim Feed-Reader zum Einsatz. 2.3 Musterlösungen Ein guter Anfang eines Projektes ist meist der Blick auf bereits vorhandene Lösungen. Diese sogenannten Musterlösungen liefern nicht nur Hinweise wie Probleme gelöst werden können, sondern auch mit welchen Hindernissen bei bestimmten Lösungsansätzen zu rechnen sind. 2.3.1 TUGraumplan und TUGsearch Abbildung 2.2: TUGraumplan Abbildung 2.3: TUGsearch Die iphone-application TUGraumplan 4 (Abbildung 2.2) der Technischen Universität Graz bietet einen Index aller Räumlichkeiten der Studieneinrichtung. Die Räume sind zunächst nach Verwendung aufgelistet. Wählt der Anwender beispielsweiße Sekretariat aus, folgt eine Liste aller Sekretariatsräume der Universität mit der exakten Bezeichnung, Adresse und Stockwerk. Jeder einzelne Eintrag der Liste führt zu einer Detailansicht in der auch eine GPS Karte sowie ein Grundrissplan mit Hinweis auf den Raum zu finden ist (Siehe Screenshots 2.4). 4 Bilder und Applikation - Quelle: Apple App Store, Zugriff am 30. 07. 2011
KAPITEL 2. STAND DER TECHNIK 13 Abbildung 2.4: Vier Screenshots der Applikation TUGraumplan Diese Funktion würde dem Feature-Vorschlag Hörsaalfinder (Siehe Kapitel 3 Umfrage ) am Ehesten entsprechen, jedoch handelt es sich bei TUGraumplan um eine eigenständige Applikation.
KAPITEL 2. STAND DER TECHNIK 14 Die TU Graz hat im Sommer 2011 eine weitere kostenlose iphone-applikation mit dem Namen TUGsearch (Abbildung 2.3) in den App Store gestellt. Diese Anwendung erweitert TUGraumplan in dem eine Volltextsuche eingebaut wurde. Das Auffinden von Räumlichkeiten ist hier nur mehr ein kleiner Teil. Die Suche dehnt sich auf annähern alle Bereiche aus mit denen die TU Graz zu tun hat. Abbildung 2.5: Vier Screenshots der Applikation TUGsearch
KAPITEL 2. STAND DER TECHNIK 15 In diesem Kapitel werden zunächst die Begriffe Smartphone und App erklärt. Ebenso wird ein Überblick über die geläufigsten mobilen Betriebssysteme wie Google Android, Apple ios, Microsoft Windows Phone 7, Nokia Symbian und BlackBerry OS gegeben. Da die Applikation myfhj begleitend zu dieser Arbeit für das mobile Betriebssystem von Apple ios umgesetzt wird, wird als Nächstes in diesem Kapitel eine kurze Einführung zur Programmierung für dieses System gegeben. Abschließend werden noch zwei Musterlösungen der Technischen Universität Graz präsentiert: TUGraumplan und TUGsearch. Das nächste Kapitel befasst sich mit dem Aufbau und der Auswertung der Umfrage die im Vorfeld dieser Arbeit durchgeführt wurde.
Kapitel 3 Umfrage Um den Bedarf an einer mobilen Applikation für die Studierenden der FH JO- ANNEUM sowie den erforderlichen Funktionsumfang für einen effektiven Nutzen einer solchen Applikation zu ermitteln, wurde eine kurze Umfrage durchgeführt. Die Umfrage bestand aus einem Fragebogen-Formular, welches über das Internet auf einer privaten Seite erreichbar war. Die Teilnahme an dieser Umfrage konnte so online durchgeführt werden. Für die Erstellung der Online-Umfrage wurde ein Joomla CMS (Content Management System) der Version 1.5 eingerichtet. Das für diese Plattform entwickelte quelloffene Plugin JQuarks bot die nötigen Werkzeuge für die Einrichtung und Auswertung dieser Umfrage. 3.1 Aufbau Der Titel der Umfrage lautete Entwicklung einer mobilen Applikation für die Studierenden der FH JOANNEUM. Es gab zwei Bereiche Teilnehmerbezogene Daten und Mobile Applikation für Studierende zu je drei Fragen. Die Fragen wurden bewusst so gestellt, dass sie für alle beziehungsweise die bekanntesten Systeme gelten, um teilnehmende Personen, die kein Apple iphone besitzen, nicht aus diesem Grund eine Teilnahme ablehnen. Es ist voraussehbar, dass mit dem Erfolg der iphone Implementation in Zukunft weitere Umsetzungen dieses Projektes für andere Systeme folgen. 16
KAPITEL 3. UMFRAGE 17 Die erste Frage Welcher Altersgruppe gehören Sie an? ist aufgrund der gewählten Antwortmöglichkeiten nicht besonders aussagekräftig. Für diese Arbeit ist sie ohnehin von geringer Bedeutung. Es wurde der Versuch unternommen die Altersgruppen der Umfrageteilnehmer festzuhalten um dieses Ergebnis anschließend mit dem Besitz bestimmter Smartphones in Relation zu bringen. Das Ergebnis war leider zu ungenau um solche Schlüsse ziehen zu können. Die einzig eindeutige Aussage, die aus dem Ergebnis abzulesen war, ist, dass alle Teilnehmenden volljährig (>18 Jahre) waren. Die zweite Frage Besitzen Sie ein oder mehere Smartphone(s)? Wenn ja, welche Betriebssysteme sind darauf installiert? besaß folgende Antwortmöglichkeiten: ios (iphone) Android (Nexus S als Beispiel) WebOS (Palm Pre) BlackBerry OS Andere Ich besitze kein Smartphone Hierbei konnten auch mehrere Antworten ausgewählt werden. Im Textfeld bei der dritten Frage konnten Teilnehmende ein Gerät beziehungsweise System angeben, welches nicht in der Liste bei der zweiten Frage erwähnt wurde. Die vierte Frage bestand aus einer Gruppe von neun Funktionsvorschlägen, welche teilnehmende Personen mit je einer von fünf Bewertungsstufen (nicht sinnvoll bis sehr sinnvoll) bewerten können. Hier war es auch möglich keine Antwort zu geben. Die fünfte und sechste Frage sollte den Teilnehmerinnenn und Teilnehmern die Möglichkeit geben, die eigenen Vorstellungen und Wünsche welche Funktionen eine Applikation, die speziell für Studierende einer Studieneinrichtung konzipiert wurde, näher zu beschreiben. 3.2 Auswertung der Umfrageergebnisse An der Umfrage hatten zwischen 01.05.2011 und 30.05.2011 139 Personen teilgenommen. Die gezeigten Diagramme sind generierte Grafiken der JQuarks Engine.
KAPITEL 3. UMFRAGE 18 3.2.1 Smartphones der Studierenden Abbildung 3.1: Umfrage: Smartphones In dem Tortendiagramm uf Abbildung 3.1 ist die Verteilung der Antworten für die zweite Frage dargestellt. Wie erwartet besitzt die Mehrheit der teilnehmenden Personen Smartphones mit dem Android 33% oder dem ios 28% Betriebssystem. Blackberry Systeme sind nur sehr schwach mit 4% vertreten. Andere wurde mit 23% doch recht häufig gewählt aber leider wurde nicht immer bei der nächsten Frage ein anderes System angegeben. Im Freitextfeld der Frage 3 wurde am häufigsten das Symbian OS Betriebssystem erwähnt aber auch Windows Phone 7 wurde zwei Mal genannt.
KAPITEL 3. UMFRAGE 19 3.2.2 Bewertung von vorgegebenen Features Abbildung 3.2: Möglichkeit zur Kommunikation unter den Studierenden Abbildung 3.3: Möglichkeit zur Kommunikation zwischen Studierende und Lehrende
KAPITEL 3. UMFRAGE 20 Das Ergebnis, welches im Diagramm Möglichkeit zur Kommunikation unter den Studierenden(Abbildung 3.2) abzulesen ist, sagt aus, dass eine Funktion mit der die Studierenden untereinander kommunizieren können von vielen (29% = 41/139) Teilnehmenden als eher sinnvoll bewertet wurde. Der Funktionsvorschlag einer Möglichkeit zur Kommunikation zwischen Studierende und Lehrende wurde ähnlich bewertet (34% = 47/139) wie im Diagramm (Abbildung 3.3) abzulesen ist. Abbildung 3.4: Möglichkeit zur Kommunikation zwischen Studierenden und Administration Nur ein wenig schwächer (33% = 36/139) jedoch ebenfalls eher sinnvoll fiel die Bewertung des nächsten Funktionvorschlages aus wie im Diagramm Möglichkeit zur Kommunikation zwischen Studierenden und Administration auf Abbildung 3.4 zu sehen ist.
KAPITEL 3. UMFRAGE 21 Abbildung 3.5: Hörsaalfinder Abbildung 3.6: Zugriff auf die Bibliothek
KAPITEL 3. UMFRAGE 22 Eine sehr gute Bewertung hat der Vorschlag einer Funktion um sich auf dem Campusgelände zurecht zu finden, bekommen. Auf der Abbildung 3.5 ist zu sehen, dass 36% der Teilnehmer und Teilnehmerinnen (50/139) diese Funktion als sehr sinnvoll bewertet haben. Nur mäßig sinnvoll wurde die Idee einer Anbindung an die Bibliotheken der einzelnen Standorte von 27% (38/139) der Teilnehmer bewertet. Allerdings ist auf dem Diagramm in Abbildung 3.6 zu erkennen, dass hier die Meinungen der Umfrageteilnehmer auseinander gingen und dies zu einer eher gleichmäßigen Verteilung der Antworten führte. Abbildung 3.7: Newsletter Eindeutiger fielen die Bewertungen um einen Zugriff auf die Newsfeeds der FH JOANNEUM aus. Wie im Diagramm Newsletter auf der Abbildung 3.7 zu sehen, bewerteten 38% (53/139) der teilnehmenden Personen dieses Feature mit mäßig sinnvoll. Weitere 32% der Teilnehmenden stimmten für weniger sinnvoll wodurch die absolute Mehrheit bei den negativen Bewertungen liegt.
KAPITEL 3. UMFRAGE 23 Abbildung 3.8: Prüfungsplaner Abbildung 3.9: Stundenplan
KAPITEL 3. UMFRAGE 24 Ganz im Kontrast dazu sind die Ergebnisse für den Featurevorschlag eines Prüfungsplaners zu sehen. Wie auf der Abbildung 3.8 bewerteten ganze 50% (69/139) der Teilnehmenden mit sehr sinnvoll. Dazu kommen noch 32% der Stimmen eher sinnvoll. Dies reicht aber nur für den zweiten Platz. Ganz klarer Umfragesieger ist jedoch der Stundenplan. Dem Stundenplan nach bewertet 81% (113/139) der Teilnehmenden dieses Feature mit sehr sinnvoll. Abbildung 3.10: Taskplaner Der Feature-Vorschlag zur Selbstorganisation mittels Taskplaner wurde laut dem Diagramm auf Abbildung 3.10 von 33% (46/139) der teilnehmenden Studierenden als eher sinnvoll bewertet. Weitere 25% bewerteten diese Funktion mit sehr sinnvoll was dem Ganzen einen positiven Schub gibt.
KAPITEL 3. UMFRAGE 25 3.2.3 Freitext Felder Zusätzlich zu den Vorschlägen gab es noch zwei Freitextfelder, die für weitere Featurevorschläge und Anregungen in Bezug auf die Applikation vorgesehen waren. Wie vorhergesehen nahmen nicht alle Umfrageteilnehmenden diese Gelegenheit wahr. Nur 67% der Teilnehmerinnen und Teilnehmer nutzten die Gelegenheit um in diesen Feldern ihre Meinung niederzuschreiben. Dafür war dieser Input bis sehr wenige Ausnahmen sehr aufschlussreich. Auf Grund der Ähnlichkeit vieler Angaben wurden diese zusammengefasst. Zugriff auf den Menüplan der Mensa nach Standort. Eine Möglichkeit die E-Learning Plattformen encephalon und Moodle zu nutzen. An online Vorlesungen teilzunehmen mit Bild- und Tonübertragung (VNC und Teamspeak). Ein vereinfachter Webmail-Zugriff. Eine Liste der verfügbaren Bücher in der Bibliothek. Zugriff auf Benotung und Prüfungstermine. Zugriff auf Fahrpläne und Anschlüsse öffentlicher Verkehrsmittel Fahrgemeinschaften organisieren Diese Ideen ergänzen die vorgeschlgenen Funktionen aber schaffen auch weitere Bedingungen, die für eine Umsetzung nötig sind.
KAPITEL 3. UMFRAGE 26 Die in diesem Kapitel beschriebene Umfrage liefert wichtige Hinweise auf die Nutzung von Smartphones unter den Studierenden der FH JOANNEUM. Sie zeigt nicht nur die Verteilung der Endgeräte beziehungsweise der mobilen Betriebssysteme, die auf diesen Geräten laufen. Nein, diese Umfrage zeigt auch die Preferenzen der Studierenden gegenüber vorgeschlagener Funktionen, die in die Applikation myfhj umgesetzt werden können. Es werden auch weitere Ideen geliefert. Im nächsten Kapitel werden diese gewonnen Daten angewandt und die Applikation myfhj umgesetzt. Es wird neben einer detailierten Beschreibung der Implementation dieser Applikation für das ios auch der Prozess der Provisionierung sowie die einzelnen Einreichungen dokumentiert.
Kapitel 4 Umsetzung In diesem Kapitel wird die praktische Umsetzung des Projektes myfhj beschrieben. 4.1 Entwicklungsumgebung Die Applikation, die in diesem Kapitel näher beschrieben wird, wurde entwickelt auf einem Apple Mac Book Pro mit einem 2.2 GHz getakteten Intel Core i7 Prozessor und 8GB 1333MHz getakteten DDR3 Arbeitsspeicher. Als Betriebssystem lief Apple s Mac OS X in der Version 10.6.7 mit einem Update auf die Version 10.6.8 Ende Juni. Entwickelt wurde mit dem ios SDK der Version 4.3 sowie der Entwicklungsoberfläche Xcode der Version 4.0.2. 4.2 Genereller Designansatz Es wurde ein iterativer Implementierungs- und Veröffentlichungsansatz angewandt. Das bedeutet, dass am Beginn der Implementation nur wenige Funktionen umgesetzt wurden und diese minimale Version gleich im App Store eingereicht wurde. Komplexere Funktionen und neue Features wurden danach schrittweise hinzugefügt und als Update im App Store nachgereicht. Eine vollständige Liste der Einreichungen und deren Beschreibung ist im Abschnitt App Store dieses Kapitels zu finden. 27
KAPITEL 4. UMSETZUNG 28 4.3 Provisionierung des Quellcodes Um den Zugang zum Quellcode für andere Personen zu vereinfachen wurde entschieden das Projekt auf einem öffentlich zugänglichen SVN-Server 1 zu stellen. Das Projekt wird fortan vom Google Code Projekt gehostet und ist dort unter der offenen Lizenz GNU GPLv3 [9] veröffentlicht. Die Projekt-Homepage ist im Internet unter http://code.google.com/p/myfhj/ zu finden. 4.4 Die Applikation In diesem Abschnitt ist der gesamte Entwicklungsprozess der iphone Applikation myfhj dokumentiert. Als Ausgangspunkt diente ein Projekt, dass im Herbst 2010 im Rahmen der Vorlesung Mobile Computing entwickelt wurde. Die entstandene Applikation hatte in erster Linie den Zweck den Entwicklungsprozess rund um das Apple ios zu demonstrieren. Für die neue Implementation dieser Applikation waren Veränderungen geplant. So wurde im ersten Schritte von einem Tab Bar Application Template zu einem Navigation-based Application Template gewechselt. Der Unterschied zwischen den beiden Applikationsstrukturen ist die Art und Weise der Navigation. Während mit einer Tab Bar (auf Abbildung 4.1 zu sehen) Zugriff auf mehrere Funktionen der Applikation bestand, navigiert ein Benutzer einer Navigationbased Application auf einem baumartigen Navigationsstack. Dies hat mehrere Abbildung 4.1: Tab Bar -Navigation der ersten Implementation Vorteile. Der Hauptgrund für diese Entscheidung war jedoch der, dass somit bessere Kontrolle über den Applikationsfluss geboten wurde, vor allem bei mehreren Funktionen. Allerdings wird nun ein zentraler Punkt benötigt an dem Anwender 1 Subversion ist eine freie Software zur Versionsverwaltung von Dateien. Vergleiche [19]
KAPITEL 4. UMSETZUNG 29 zwischen den Funktionen wählen können. Dazu wurde ein Hauptmenü (siehe Abbildung 4.2) geschaffen, vergleichbar mit einer Homepage in der Webentwicklung. Abbildung 4.2: myfhj Hauptmenü Sobald eine View des Hauptmenüs voll ist, ist es einfach möglich eine weitere hinzuzufügen. 4.4.1 Die Funktionen News und Events Die erste Funktion, die in myfhj eingebaut wurde, war ein RSS Feedreader. Der Clou dabei ist, dass beide Funktionen News und Events dieselben Klassen verwenden. Anhand des Titels, mit dem das Objekt initialisiert wird, wird jeweils die entsprechende URL zum Feed verwendet. Mit dem Parser aus dem Framework TouchXML werden von einem frei zugänglichen Newsfeed aktuelle Einträge heruntergeladen und geparst.
KAPITEL 4. UMSETZUNG 30 1 <item> 2... 3 </ item> 4 <item> 5 < t i t l e>...</ t i t l e> 6 <l i n k>...</ l i n k> 7 <d e s c r i p t i o n>...</ d e s c r i p t i o n> 8 </ item> Listing 4.1: Beispiel für eine RSS Feed XML Datei Per Standard sind UITableViewCells mit maximal zwei einzeiligen Textfeldern ausgestattet mit einigen wenigen Berechnungen in der UITableViewDataSource Methode heightforrowatindexpath (Siehe Listing 4.2) lassen sich die Textfelder dynamisch vergrößern und mehrzeilig Text darstellen. 1 ( CGFloat ) tableview : ( UITableView ) tableview heightforrowatindexpath : ( NSIndexPath ) 2 { indexpath 3 UITableViewCell c e l l = ( UITableViewCell ) [ s e l f tableview : tableview 4 cellforrowatindexpath : indexpath ] ; 5 6 CGFloat width = tableview. frame. s i z e. width 10 2; 7 8 i f ( c e l l. t e x t L a b e l. f o n t == n i l c e l l. t e x t L a b e l. f o n t. p o i n t S i z e == 0 ) 9 { 10 [ c e l l l a y o u t S u b v i e w s ] ; 11 } 12 13 CGSize d e t a i l T e x t S i z e = [ c e l l. d e t a i l T e x t L a b e l. t e x t sizewithfont : c e l l. d e t a i l T e x t L a b e l. f o n t 14 constrainedtosize : CGSizeMake ( width, 15 CGFLOAT_MAX) 16 linebreakmode : UILineBreakModeTailTruncation ] ; 17 18 CGSize t e x t S i z e = [ c e l l. t e x t L a b e l. t e x t sizewithfont : c e l l. t e x t L a b e l. f o n t 19 constrainedtosize : CGSizeMake ( width, CGFLOAT_MAX) 20 linebreakmode : UILineBreakModeWordWrap ] ; 21 22 return 20 2 + d e t a i l T e x t S i z e. h e i g h t + t e x t S i z e. h e i g h t ; 23 24 } Listing 4.2: Funktion heightforrowatindexpath Zunächst wurden nur die Felder title und description verwendet und dessen Werte in die Textfelder textlabel und detailtextlabel der Zelle geschrieben. Mit der nächsten Version der Applikation wird ein das Feld link aus dem Feed verwendet. In jeder Zelle wurde das Accessory UITableViewCellAccessoryDetail- DisclosureButton (Abbildung 4.3 und Abbildung 4.4) aktiviert. Es handelt sich hierbei um eine spezielle Schaltfläche, die auf eine eigene Methode (Siehe Listing
KAPITEL 4. UMSETZUNG 31 Abbildung 4.3: UITableViewCellAccessoryDetailDisclosureButton 4.3) der UITableViewDelegate Schnittstelle gebunden ist. Die Implementation dieser Methode kann anhand des Zellenindexes feststellen in welcher Zelle sich die Schaltfläche befindet, die gerade aktiviert wurde. 1 ( void ) tableview : ( UITableView ) tableview accessorybuttontappedforrowwithindexpath : ( NSIndexPath ) indexpath 2 { 3 int blogentryindex = [ indexpath indexatposition : [ indexpath length ] 1]; 4 NSDictionary item = [ newsentries objectatindex : blogentryindex ] ; 5 NSString a r t i c l e L i n k = [ item objectforkey :@" l i n k " ] ; 6 7 [ [ U I A p p l i c a t i o n s h a r e d A p p l i c a t i o n ] openurl : [ NSURL URLWithString : a r t i c l e L i n k ] ] ; 8 } Listing 4.3: Funktion accessorybuttontappedforrowwithindexpath Dieser Index entspricht den Indizes der Blog Items worin der Wert vom Tag link der Feed XML-Struktur abgespeichert ist. Damit wird die Applikation in den Hintergrund-Modus des ios gesetzt und der Safari Browser gestartet mit jener URL als Ziel. Agenda Die erste Version der Funktion Agenda öffnet den Stundenplan für Vorlesungen an der Fachhochschule. Hier wird eine Verbindung zum Internet benötigt. Optimalerweise werden aus dem Benutzerkontext bestimmte Daten verwendet um den URL aufzubauen der den korrekten Stundenplan für die aktuelle Woche vom Server abruft. Die Ansicht der Agenda ist im Prinzip ein simples Web-Browser-Fenster. Es wird die Agenda gleich aufgebaut wie zu Hause am Computer des Studenten. Sofern vom Benutzer eingegeben (siehe Unterabschnitt Settings ), werden aus dem Applikationskontext NSUserDefaults die Werte für das Studiengangs Kürzel (zum Beispiel SWD ) und Jahrgang (zum Beispiel 2008 ) ausgelesen (Siehe Liesting 4.4). Andernfalls wird ein Standardwert verwendet.
KAPITEL 4. UMSETZUNG 32 Abbildung 4.4: Beispiel der Table View für News und Events 1 ( NSString ) agendaurlstring 2 { 3 NSString pcode = [ [ [ NSUserDefaults standarduserdefaults ] stringforkey :@" userprogrammecode " ] l o w e r c a s e S t r i n g ] ; 4 NSString year = [ [ NSUserDefaults standarduserdefaults ] stringforkey :@" useryear " ] ; 5 NSString urladdress ; 6 7 i f ( pcode!= n i l && y e a r!= n i l ) { 8 u r l A d d r e s s = [ NSString stringwithformat :@" http : / / s t u n d e n p l a n. fh joanneum. a t /? l o g i n= l o g i n&u s e r=%@&p a s s=%@&new_jg=%@", pcode, pcode, y e a r ] ; 9 10 } e l s e { 11 urladdress = [ [ NSUserDefaults standarduserdefaults ] stringforkey :@" defaultagendaurl " ] ; 12 } 13 14 return urladdress ; 15 } Listing 4.4: Funktion agendaurlstring Der generierte String wird als Ziel-URL für die Agenda verwendet. Die Agenda besitzt momentan als einzige Funktion eine View die Möglichkeit in den Landscape- Modus (Siehe Abbildung 4.5) zu wechseln. Diese Implementierung der Agenda Funktion ist auch im Landscape Modus kaum
KAPITEL 4. UMSETZUNG 33 Abbildung 4.5: Agenda im Landscape-Modus lesbar. Benutzerinnen und Benutzer sind so gezwungen die Zoom Funktionalität in Anspruch zu nehmen um Texte bei den Eintragungen zu lesen. So wurde entschieden, dass die Agenda Funktion mit myfhj Version 1.2.0 völlig neu implementiert wird. Da die Auswertung der HTML-Seite nicht optimal durchführbar wäre, musste für das neue Design eine andere Schnittstelle anprogrammiert werden. Die einzige vorhandene Alternative war das Projekt Stundenplan- Suche 2 von Thomas Radeke (Informationsdesign 2008-2011). Neben einer Darstellung im HTML-Format, wird hier auch ein icalendar 3 -Abonnement angeboten. Die dahinter liegende ics Datei kann über diese URL in entsprechende Programme (Outlook, ical, und viele mehr) eingebunden werden. Mittels des HTTP Protokoll ist die Datei (Siehe Beispiel in Listing 4.5) selbst erreichbar. 1 BEGIN:VCALENDAR 2... 3 BEGIN:VEVENT 4 UID:HEB2009_50594533 5 SUMMARY:PSY4V/ AbgabeTMSeminararbeit \, Rakhi J h a l a \, PR\, SR LL1 ( HEB 2009) 6 DTSTART; TZID=Europe/ Vienna: 20110715T080000 7 DTEND; TZID=Europe/ Vienna: 20110715T090000 8 LOCATION:G/CAA/SR LL1\, Zi.430 4.OG 2 Link: http://almaty.fh-joanneum.at/stundenplan/index.php letzter Zugriff am 15. August 2011 3 icalendar ist ein Dateiformat zum Austausch von Kalenderinhalten. Siehe RFC 5545
KAPITEL 4. UMSETZUNG 34 9 END:VEVENT 10 BEGIN:VEVENT 11... 12 END:VEVENT 13... 14 END:VCALENDAR Listing 4.5: Funktion Beispiel einer icalendar Datei Die für diese Arbeit relevante Information steht jeweils zwischen den BE- GIN:VEVENT und END:VEVENT Feldern. Für jeden Termin gibt es einen solchen Block. Diese Blöcke lassen sich problemlos mit dem NSScanner aus dieser Datei herauslesen (siehe Code in Listing 4.6). Ein NScanner ist eine Art Iterator für Inhalte von String-Objekten. 1 NSScanner veventscanner = 2 [ NSScanner scannerwithstring : calcontent ] ; 3 NSString t e x t ; 4 NSMutableArray events = 5 [ [ NSMutableArray a l l o c ] initwithcapacity : 1 ] ; 6 7 while ( [ veventscanner isatend ] == NO) { 8 9 // f i n d s t a r t o f tag 10 [ veventscanner scanuptostring :@"BEGIN:VEVENT" i n t o S t r i n g :NULL ] ; 11 12 t e x t = n i l ; 13 14 // f i n d end o f tag 15 [ veventscanner scanuptostring :@"END:VEVENT" i n t o S t r i n g :& t e x t ] ; 16 17 i f ( t e x t!= n i l ) { 18 [ events addobject : t e x t ] ; 19 } 20 21 calcontent = [ calcontent stringbyreplacingoccurrencesofstring : 22 [ NSString stringwithformat :@"%@", t e x t ] 23 w i t h S t r i n g :@" " ] ; 24 25 } Listing 4.6: Funktion icalendar Parsing mit NSScanner Die restliche Zerlegung geschieht anschließend in eigenen Event-Objekten. Um Datum und Uhrzeit zu formatieren, wurde eine DateFormatter Helper-Klasse erstellt, die diese Operationen übernimmt. Um die Events am Endgerät darzustellen, wird eine ähnliche Tabellenklasse wie
KAPITEL 4. UMSETZUNG 35 bei News und Events verwendet. In der aktuellen Version werden im Textlabel Begin und Ende der Lehrveranstaltung angezeigt. Die Beschreibung und der Ort des Events werden im Detailtext-Label dargestellt. Im Beispiel auf Abbildung 4.6 ist zu sehen, dass in der aktuellen Version zwei Tage, der aktuelle und der nächste Tag, abgefragt werden. Die Auswertung der zwei ics Dateien werden in separate Tabellensektionen aufgeteilt und mit jeweils einen Header gekennzeichnet. Abbildung 4.6: Ansicht der überarbeiteten Agenda Settings Die Settings sind ein zentraler Punkt der gesamten Applikation. Hier kann ein Nutzer Einstellungen vornehmen und bestimmte Werte eingeben. Diese Werte werden dann von anderen Funktionen der Applikation genutzt. Ein Beispiel: ein Nutzer kann hier seinen Studiengang und Jahrgang eingeben. Die Funktion Agenda nutzt diese Werte, da sie damit die Abfrage-URL zusammenbaut um den richtigen Stundenplan für die entsprechenden Daten zu bekommen. Die Settings-Ansicht enthält eine Sammlung von Schaltflächen, an denen ein An-
KAPITEL 4. UMSETZUNG 36 wender systemweite Einstellungen setzen kann. Bei Betätigung einer Schaltfläche öffnet eine Auswahl an Objekten. Sobald eine Änderung beziehungsweise ein Abschluss dieser Änderung ausgehend vom Anwender wahrgenommen wird, werden die veränderten Werte im Benutzerkontext der Applikation abgespeichert. Folgende Werte können seit der ersten Version gesetzt und verändert werden. Standort Studiengang (Kürzel) Jahrgang Ab der Version 1.1.0 befinden sich kleine Hinweisschaltflächen neben den Wertschaltflächen. Werden diese aktiviert erscheint eine Alert View mit kurzen Hinweisen auf die Art und Verwendung der eingegebenen Werte (Siehe Abbildungen 4.7a und 4.7b). (a) (b) Abbildung 4.7: Settings View und Info Alert View Beispiel Kürzel" In der Version 1.2.0 wurde die Schaltfläche Standort deaktiviert da der Wert, der damit auswählbar ist, in der vorliegenden Version nicht verwendet wird. Sie bleibt aber in der XIB-Datei enthalten und braucht bei Bedarf nur mehr aktiviert und neu positioniert werden.
KAPITEL 4. UMSETZUNG 37 Info Seit der ersten Version befindet sich im Hauptmenü eine Toolbar mit einer zentrierten Schaltfläche mit der Bezeichnung Info wie auf der Abbildung 4.8 zu sehen. Die Ansicht, die bei Betätigung dieser Schaltfläche geladen wurde, besteht Abbildung 4.8: Toolbar mit Der Schaltfläche Info in der Ursprungsversion nur aus einer UITextView in die der Impressumtext der FH JOANNUM kopiert wurde. Mit Version 1.0.1 wurde der Text in eine Textdatei ausgelagert und per Code in die View geladen. Darüber hinaus wurde noch die Erkennung von E-Mail Adressen und URLs aktiviert damit die Nutzer gleich aus der Applikation heraus diese nutzen können. 4.5 Veröffentlichung der Applikation Ein Ziel dieser Arbeit ist die Veröffentlichung der Applikation myfhj im Apple App Store. Dafür ist eine Registrierung als iphone Developer und eine Mitgliedschaft in einem kostenpflichtigen ios Developer Program erforderlich. Diese Mitgliedschaft gestattet Zugriff auf online Werkzeuge von Apple um die so genannten Provisioning Dateien zu erzeugen. Die App myfhj wird mit einem Schlüssel (die myfhj Bundle ID lautet at.fh-joanneum.myfhj ) kompiliert und lässt sich nur auf Geräte installieren, die eine entsprechende Provisioning Datei besitzen. 4.5.1 Provisionierung Die Veröffentlichung der Applikation erfolgt über die online Plattform itunes Connect für die auch eine Mitgliedschaft im entsprechenden Developer Program notwendig ist. Hier können je nach Berechtigung jegliche App Store relevanten Informationen verwaltet werden. Das betrifft zum Beispiel Informationen über die Verkäufe beziehungsweise Downloads, Informationen über den eigenen Auf-
KAPITEL 4. UMSETZUNG 38 tritt im App Store und natürlich Informationen über die Applikationen. In diesem Teil werden Applikationen zwar tatsächlich erstellt, aber sie wird erst weiter verarbeitet, wenn die Binärdaten der Applikation dazu hochgeladen wurden und eine routinemäßige Validierung bestanden haben. Anschließend wird die Einreichung in eine Warteschlange für ein Review gereiht (Siehe Abbildung 4.9. Abbildung 4.9: itunes Connect: App Verwaltung 4.5.2 Einreichungen im App Store Sonntag, 26. Juni 2011 Die erste Einreichung diente in erster Linie dazu den Freigabeprozess seitens Apple anzustoßen. Die Erfahrung mit ähnlichen Prozessen zeigte eine verkürzte Wartezeit bei der Einreichung von Updates. Die eingereichte Applikation besaß lediglich frühe Versionen des Feedreaders, der Agenda, der Settings und eines einfachen Impressums. Die Freigabe im App Store erfolgte am Freitag dem 01. Juli 2011. Die Applikation
KAPITEL 4. UMSETZUNG 39 wurde gleich nach Erhalt der Benachrichtigung auf einem Apple iphone 4 installiert und die einzelnen Features auf ihre Funktion hin überprüft. Es wurden in dieser Version Mängel in Bezug auf Datenspeicherung und Lokalisierung festgestellt, die sofort ausgebessert wurden und mit der nächsten Einreichung behoben werden. Sonntag, 03. Juli 2011 Die zweite Einreichung sollte lediglich einige Fehler der ersten Version beheben. Es wurde in erster Linie die Lokalisierung von Zeichenketten, die in die UI geladen werden, nachgezogen. Am Montag dem 11. Juli 2011 traf dann ein App Submission Feedback ein und der Status der Einreichung wurde auf rejected (abgelehnt) gesetzt. Dies bedeutet, dass diese Einreichung nicht den Vorschriften seitens Apple entspricht und somit abgelehnt wurde. Die erste Version war aber immer noch verfügbar. Der Originaltext diese Nachricht lautete: Hello Markus, Thank you for submitting myfhj to the App Store. We ve completed the review of your app, but cannot post this version to the App Store because it did not comply with the App Store Review Guidelines, as detailed below: 20.2: Official rules for sweepstakes and contests, must be presented in the app and make it clear that Apple is not a sponsor or involved in the activity in any manner To reply to this message or to get more information, visit the Resolution Center in itunes Connect. Do not reply directly to this email. Regards, App Review Converse with fellow developers and Apple engineers on technical topics. Apple Developer Forums http://devforums.apple.com Demnach konnte diese Version nicht akzeptiert werden da sie nicht den Richtlinien von Apple bezüglich Gewinnspiele entsprach. Der E-Mail war Nichts beigefügt, was eine Begründung für diese Entscheidung lieferte. Doch am itunes Connect Portal war diese Grafik 4.10(ohne Pfeil) dieser Konversation angehängt.
KAPITEL 4. UMSETZUNG 40 Abbildung 4.10: Submission Note zur zweiten Einreichung Offenbar wurden zu dieser Zeit Teilnahmeplätze für ein Seminar verlost. Dies wurde leider im Hinblick auf eine App Store Submission ungünstig im Newsfeed erwähnt (siehe Pfeil in Grafik 4.10). Um ein solches Missverständnis in Zukunft zu vermeiden, wurde ein Verzichthinweis eingebaut, der nur beim ersten Start der Applikation eingeblendet wird und die Benutzer (und vor allem Apple) erklärt, dass die FH JOANNEUM GmbH für sämtliche Inhalte der App verantwortlich ist. Sonntag, 17. Juli 2011 Mit der dritten Einreichung sollten in erster Linie die Richtlinen für App Einreichungen erfüllt werden. Am Freitag dem 22. Juli 2011 wurde diese Version von myfhj im App Store freigegeben.
KAPITEL 4. UMSETZUNG 41 Sonntag, 14. August 2011 Die überarbeitete Agenda und die erweiterte Studiegangskürzelauswahl in den Settings sollen mit der vierten Einreichung die bisherigen Funktionen ersetzen beziehungsweise aktualisieren. Die Freigabe für den App Store erfolgte am Donnerstag den 18. August 2011 Dieses Kapitel beschreibt die komplette Implementierung jeder einzelnen Funktion der ios Applikation myfhj. Im zweiten Teil wurde jeder Schritt, der unternommen wurde um diese Applikation für die Studierenden der FH JOANNEUM über den Apple App Store verfügbar zu machen, dokumentiert. Im nächsten Kapitel werden die Ergebnisse dieser Arbeit zusammengetragen und präsentiert.
Kapitel 5 Ergebnisse 5.1 Die Umfrage Die gewonnen Daten aus der Umfrage, die im Vorfeld dieser Arbeit durgeführt wurde, geben Aufschluss über die Nutzung von Smartphones unter den Studierenden der FH JOANNEUM. Die genaue Auswertung der einzelnen Umfrageergebnisse ist im Abschnitt 3.2 des dritten Kapitels zu finden. Die Ergebnisse sind noch einmal im Diagramm auf der Abbildung 5.1 zusammengefasst. Abbildung 5.1: Zusammenfassung der Funktionsbewertungen 42
KAPITEL 5. ERGEBNISSE 43 Abbildung 5.2: Vereinfachte Darstellung der Funktionsbewertungen Die Ansicht lässt sich vereinfachen indem jeder Bewertungsstufe ein Wert zugewiesen wird. So erhält jeder Prozent der Stimmen bei sehr sinnvoll vier Punkte, drei bei eher sinnvoll, zwei bei mäßig sinnvoll und einen Punkt bei weniger sinnvoll. Die Stufe nicht sinnvoll wurde mit keinem Punkt bewertet also nicht mit eingerechnet. Das Ergebnis ist auf Abbildung 5.2 zu sehen. Eindeutiger Sieger bei der Beurteilung von Funktionsvorschlägen ist eine Umsetzung des Stundenplans, welcher nun auch in der verfügbaren App implementiert ist. Der hohe Wert lässt darauf schließen, dass es den Studierenden am Wichtigsten ist ihre Tagesabläufe zu kennen. Die als am wenigsten sinnvoll bewertete Funktion ist der Zugriff auf einen Newsfeed beziehungsweise auf ein Newslettersystem. 5.2 Dokumentation der Entwicklung und der Provisionierung Das vierte Kapitel zusammen mit dem Quellcode auf dem beigelegten Datenträger bietet eine vollständige Anleitung für die Entwicklung einer iphone Applikation
KAPITEL 5. ERGEBNISSE 44 vom Design über die Implementation bis zur Veröffentlichung im Apple App Store. 5.3 iphone App Die, im Zuge diese Arbeit entwickelte, Applikation für das iphone ios ist im Apple App Store kostenlos verfügbar. Jede interessierte Person mit einem Zugang zu dieser Plattform und einem entsprechenden Endgerät (iphone 3GS/4, ipad) kann sich diese Anwendung herunterladen, installieren und anschließend verwenden. Diese Applikation verfügt nur über wenige Funktionen. Es ist jedoch ein solider Anfang gemacht. Mit der Veröffentlichung des Quellcodes ist ein weiterer Schritt getan. Es wird stets neue Anwendungen oder Verbesserungen vorhandener Funktionen geben. Es sind noch sehr viele der Vorschläge aus der Umfrage gar nicht oder nur teilweise umgesetzt. Gut möglich, dass man auch bereits existierende Funktionen besser beziehungsweise anders umsetzen kann. Zu finden ist die App (Abbildung 5.3 - myfhj Icon) unter http://itunes.apple.com/at/app/myfhj/id445190229?mt=8 (Letzter Zugriff erfolgte am 04. August 2011). Abbildung 5.3: myfhj Icon