Zusammenfassung Mobilgeräte wie z.B. Smartphones werden heutzutage nicht mehr ausschließlich zur Sprachkommunkation eingesetzt. Sie ermöglichen es, zeitnah Informationen an mobile Nutzer zu übertragen. Hierbei spielt der Aufenthaltsort der Nutzer weitestgehend keine Rolle, er/sie ist quasi jederzeit und allerorts erreichbar. Im Gegensatz zu der Einfachheit der Informationskonsumtion ist das Entwickeln von Apps nicht trivial. Hierzu ist Expertenwissen notwendig. Zahlreiche potentielle Informationsanbieter verfügen nicht über die notwendigen Kenntnisse, wenngleich ihre Informationen für zahlreiche Konsumenten interessant wären und es starke strukturelle Ähnlichkeiten zwischen mobil verfügbar gemachten Informationen gibt. Ein weiteres Problem ist, dass unterschiedliche SmartphoneHersteller dediziert unterschiedliche Programmiersprachen benutzen. In diesem Papier präsentieren wir unseren Ansatz zur anbieterzentrierten Generierung von Apps, wobei ein Hauptaugenmerk auf der Unterstützung heterogener Zielplattformen liegt. Somit ermöglichen wir es technisch nicht versierten Informationsanbietern, ihre eigenen Apps zu erzeugen.
In diesem Papier präsentieren wir unseren Ansatz, die genannten Probleme durch ein Framework zur Erzeugung von Informationssystem-Apps zu beheben. Durch die Analyse verschiedener existierender Apps haben wir herausgefunden, dass die angebotenen Informationen klassifiziert werden können. Basierend auf dieser Klassifikation haben wir eine modulare Struktur entwickelt, die als Code-Skelett für verschiedene Plattformen realisiert wurde. Mithilfe dieser Code-Skelette kann dann eine App wie folgt erzeugt werden: Zuerst wird die App mithilfe eines domänen-spezifischen, Web-basierten Konfigurationswerkzeugs parametrisiert. Die dabei spezifizierten statischen Informationen werden dem Quelltext hinzugefügt. Dynamische Informationen werden auf der Webseite des Anbieters hinterlegt, wo sie auch gewartet werden können. Anschließend wird die App automatisch kompiliert und zum Download angeboten. Neben dem Vorteil, dass auf diese Weise technisch nicht versierte Anwender wie Musiker, Politiker, etc. ohne Kenntnis einer Programmiersprache Apps erstellen können, vermeidet unser Verfahren die potentielle Verletzung von Urheber- und Verwertungsrechten. Alle Informationen, die durch die App angeboten werden, werden auch direkt vom Anbieter bereitgestellt und befinden sich unter dessen Kontrolle1.
Der Rest des Papieres ist wie folgt strukturiert: Abschnitt 2 beschreibt verwandte Arbeiten. Abschnitt 3 analysiert die Eigenschaften der Informationen, welche üblicherweise durch Informationssystem-Apps angeboten werden. Abschnitt 4 beinhaltet eine kurzen Einblick in unseren Evaluationsprototyp und präsentiert die Architektur unseres App-Erzeugungssystems. Abschnitt 5 fasst das Papier zusammen und gibt einen Ausblick auf Folgearbeiten.
Die in diesem Beitrag vorgestellten Forschungsergebnisse können
den Forschungsgebieten Code-Generierung (engl. code
generation), mobile Informationssysteme und
Mensch-Maschine-Interaktion (engl. human-computer interaction) zugeordnet werden.
Code-Generierung wird oft als Teilgebiet der modellgetriebenen
Softwareentwicklung [
Mobile Informationssysteme machen es möglich, Informationen auf
mobilen Endgeräten anzubieten. Die größte Herausforderung
besteht dabei in der Reduktion des übertragenen Datenvolumens zum
und vom Gerät. Die drahtlose Datenübertragung ist unverzichtbar,
aber auch sehr energieintensiv [
Smartphones bieten meist nur sehr kleine Bildschirme und im
Vergleich zu normalen Desktop-Computern grundverschiedene
Möglichkeiten der Benutzerinteraktion. Entsprechend gilt es, bei
Aspekten der Mensch-Maschine-Interaktion auf diese Unterschiede
ein1Wir nehmen an, dass der Anbieter die entsprechenden Rechte
besitzt bzw. entsprechende Verträge hierfür selbst abgeschlossen hat.
zugehen [
Durch die Analyse verschiedener Informationssystem-Apps haben wir zwei Klassen von präsentierten Informationen ableiten können: Statische Informationen sind Informationen, die explizit in den Binärcode von Apps hinein kompiliert werden. Nahezu alle Apps enthalten statische Informationen wie den Namen der App, statisch verknüpfte Bilder, Informationsdialog, usw. Aktualisierungen dieser Informationen sind nur durch Neukompilierung der App möglich. Dafür ist es möglich, statische Informationen auch ohne Netzverbindung zu verwenden.
Dynamische Informationen sind Informationen, die zur Laufzeit heruntergeladen werden. Dies sind beispielsweise Nachrichten-Streams, ortsabhängige Informationen oder Informationen über Ereignisse. Zur Aktualisierung von dynamischen Informationen wird eine bestehende Netzverbindung benötigt. Durch Caching, Hoarding oder Replikation kann jedoch auch eine Offline-Nutzung zuvor heruntergeladener dynamischer Informationen ermöglicht werden. Es gibt zwei Subklassen dynamischer Informationen: (1) Interne Informationen sind Informationen, die zumeist vom Anbieter der App bereitgestellt werden. So werden in Zeitungs-Apps zum Beispiel aktuelle Nachrichten der zugehörigen Zeitung heruntergeladen und präsentiert. (2) Externe Informationen sind verknüpfte Informationen, die von Dritten bereitgestellt werden. Dies können zum Beispiel in Ereignisinformationen verknüpfte Videos bei Youtube sein, die nicht direkt vom Anbieter des Ereignisses zur Verfügung gestellt werden.
Bei der Konzeption einer App spielen auch Fragestellungen des Urheberrechts eine Rolle. In unserem Ansatz gehen wir davon aus, dass der Anbieter der App die nötigen Urheberrechte an den in einer App verwendeten statischen und internen Informationen besitzt. Ferner gehen wir davon aus, dass der Anbieter einer App bei der Verwendung von externen Informationen die Nutzungsbedingungen des jeweiligen Informationsanbieters berücksichtigt. Generell ist davon auszugehen, dass Benutzer auf statische und dynamische Informationen nur lesenden Zugriff besitzen. Einige Apps unterstützen jedoch interaktive (dynamische) Informationen. So kann zum Beispiel eine App, die Informationen über Ereignisse bereitstellt, das Kommentieren von Ereignissen durch soziale Netzwerke wie Facebook, Twitter oder MySpace ermöglichen.
Aufgrund der besseren Verständlichkeit verzichten wir in diesem Papier auf die Trennung zwischen der Beschreibung unseres Ansatzes und der Implementierung des Proof-of-Concept-Systems namens MyBand-App. Dieses System ermöglicht es Musikern, ihre eigenen Apps für Android- und iOS-basierte Smartphones zu erstellen. Uns ist bekannt, dass es mit FansMagnet2 bereits einen Anbieter eines vergleichbaren Services für Musiker gibt. Jedoch werden dabei auch die Inhalte der Apps durch FansMagnet verwaltet. Aufgrund rechtlicher Bedenken, obliegt es in unserem Ansatz tatsächlich dem Informationsanbieter, dem Musiker oder dessen Beauftragten, sicherzustellen, dass alle Urheber- und Verwertungsrechtsfragen geklärt werden.
Der Proof-of-Concept stellt ein Anwendungsszenario von Bands bzw. Musikern dar, die Informationen an Ihre Fans über ein mobiles Informationssystem weitergeben möchten. Dieses Beispiel dient allerdings nur der Verdeutlichung unseres Ansatzes. Der hier beschriebene Ansatz lässt sich auf beliebige andere Informationsanbieter übertragen.
Um diese Übertragbarkeit zu gewährleisten, muss das System anpassbar und leicht erweiterbar sein. Aus diesem Grund ist unser System ist als Framework aufgebaut. Für die App-Erzeugung sind drei Komponenten verantwortlich: (1) ein Web-basiertes Konfigurationswerkzeug (MyBandServlet), (2) die Code-Skelette für die Apps und (3) die eigentliche App-Erzeugung. Der Arbeitsablauf beim Erstellen einer App ist wie folgt: Zuerst wählt der Nutzer die Zielplattform(en) und die Module, welche er/sie in die App integrieren will (vgl. Abbildung 1). Anschließend werden die App und die ausgewählten Module konfiguriert und der Erzeugungsprozess angestoßen. Nach dessen Beendigung (nach dem Kompilieren der App) kann der Nutzer seine App herunterladen.
Aus einem technischeren Blickwinkel betrachtet, funktioniert unser Ansatz wie folgt: Wie Abbildung 1 verdeutlicht, sind Module die kleinsten Bausteine in unserem Erzeugungsprozess. Es gibt intern zwei Arten von Modulen: BuilderModule sind für die Erstellung des plattformabhängigen Binärcodes zuständig. AppModule kapseln die Funktionalität der App. Jedes AppModule umfasst das entsprechende Code-Skelett und eine XML-Datei, mit der die
durch den Web-basierten Konfigurator festgelegte Modulkonfiguration (bestehend aus statischen und dynamischen Informationen) verarbeitet wird (vgl. Abbildung 2). Dies umfasst im verwendeten Anwendungsszenario unter anderem den Namen und das Bild der Band bzw. Musiker, sowie die Liste der Band-Mitglieder. Für die Diskographie werden z.B. die Datei DiscographyModule.xml und zwei AppModule IPhoneDiscographyModule.jar und AndroidDiscographyModule.jar genutzt. Bevor der eigentliche Erzeugungsprozess gestartet wird, analysiert das MyBandServlet die verfügbaren XML-Dateien, erzeugt aus den Meta-Informationen zu statischen Informationen die Formulare für den Konfigurator und generiert aus den Meta-Informationen zu dynamischen Informationen eine RSS-Vorlage3, die zur späteren Bereitstellung der dynamischen Informationen dient. Nachdem das Konfigurationsformular durch den Nutzer abgeschickt wurde, wird pro AppModul die configure-Methode, welche jedes AppModul implementiert, aufgerufen. Diese Methode modifiziert das Code-Skelett des entsprechenden AppModuls entweder direkt oder, wie in Abbildung 4 dargestellt, durch Ändern der XML-Datei basierend auf der durch den Nutzer angegebenen Konfiguration. Anschließend werden die konfigurierten AppModule an das BuilderModule übergeben, welches für das Kompilieren der App verantwortlich ist.
Die Abbildungen 5 und 6 zeigen eine iOS-App, welche beispielhaft mit dem beschriebenen MyBand-App-Ansatz erzeugt wurde.
Sicherlich ist die dargestellte Oberfläche noch nicht „fancy“, die Abbildungen verdeutlichen aber, dass ein Java-basiertes Framework genutzt werden kann, um Programme in Objective-C zu erzeugen.
Abbildung 3 verdeutlicht, dass der vorgestellte Ansatz zum Ziel hat, so generisch wie möglich zu sein. Zur Unterstützungen von Apps abseits der Musiker-Domäne müssen lediglich andere AppModule und XML-Dateien bereitgestellt werden. 3Im Prototyp werden die RSS-Dateien händisch editiert. Ein Editor zum formularbasierten Eingeben der dynamischen Daten ist indes in Vorbereitung.
MyBandServlet +settingsManager: SettingsManager = new SettingsManager() +doPost(request:HttpServletRequest, response:HttpServletResponse): void +doGet(request:HttpServletRequest, response:HttpServletResponse): void
SettingsManager +formatModuleSettings(settings: List<ModuleSetting>, formatter:SettingFormatter): String +handleSettings(settings:List<ModuleSetting>, request:HttpServletRequest): boolean
ModuleManager +getInstance(): ModuleManager +loadModules(): void +getDefaultModuleSettings(): List<ModuleSetting> +registerModule(module:Module): void +setModuleState(module:Module, state:State): void +getModules(): List<Module>
ModuleLoader +loadModules(directory:File): void –loadModule(jarFile:File): Module
Module +getState(): State +setState(state:State): void
Builder +createBuilder(settings:List<ModuleSetting>): Builder +getBuildStatus(buildID:String): int +getBuild(buildID:String): URL +getBuildID(): String +build(): void for(File jarFile:directory.listFiles()) {
Module module = this.loadModule(jarFile);
ModuleManager.registerModule(module); }
AppModule +configure(setting:ModuleSetting) +getDepends(): List<Module> +addFiles(): Map<String, File> +replaceInFile(): List<FileReplace>
BuilderModule +preBuild(): void +build(outDir:File,modules:List<AppModule>,settings:List<ModuleSetting>): void +postBuild(outDir:File,outFile:File) iPhoneCoreModule
AndroidCoreModule iPhoneBuilder
AndroidBuilder +configure(setting:ModuleSetting) +getDepends(): List<Module> +addFiles(): Map<String, File> +replaceInFile(): List<FileReplace> +configure(setting:ModuleSetting) +getDepends(): List<Module> +addFiles(): Map<String, File> +replaceInFile(): List<FileReplace> +preBuild(): void +build(outDir:File,modules:List<AppModule>,
settings:List<ModuleSetting>): void +postBuild(outDir:File,outFile:File) +preBuild(): void +build(outDir:File,modules:List<AppModule>,
settings:List<ModuleSetting>): void +postBuild(outDir:File,outFile:File) Abbildung 3: Klassendiagramm des Framework-Servlets für die MyBand-App-Konfiguration und -Erzeugung
AndroidCoreModule +configure(setting:ModuleSetting) +getDepends(): List<Module> +addFiles(): Map<String, File> +replaceInFile(): List<FileReplace> public void configure(ModuleSetting settings) { ...
String content = Util.readFile("res/values/strings.xml"); } util.writeFile("res/values/strings.xml"; ... <resources> <string name="bandname">Die Apokalyptischen Reiter</string> <string name="updateurl">http://reitermania.de/feed.rss</string> </resources>
5.
In diesem Beitrag haben wir erste Ideen präsentiert, die es Endbenutzern ohne technische Kenntnisse ermöglichen, Informationssystem-Apps für Smartphones verschiedener Betriebssysteme zu erstellen. Wir haben die generellen Eigenschaften von Informationen, die in solchen Apps angeboten werden, klassifiziert und diese Klassifikation für den Entwurf von Code-Skeletten verwendet. Mit Hilfe eines Web-Interfaces können Benutzer ihre App parametrisieren. Anschließend wird die App über die nativen Entwicklungswerkzeuge kompiliert und kann heruntergeladen werden. Weitere Vorzüge unseres Systems sind die native Benutzeroberfläche und die Berücksichtigung des Urheberrechts der angebotenen Informationen. Neben diesen allgemeinen Ansätzen haben wir unseren Prototypen „MyBand-App“ vorgestellt, den wir zudem einer breiten Öffentlichkeit auf der CeBIT-Messe im März 2011 in Hannover zeigen konnten.
Wir stehen erst am Anfang unserer Forschung und sehen nun verschiedene Forschungsrichtungen, die sich in Zukunft eröffnen. Zunächst werden wir interaktive Informationen berücksichtigen. Zudem werden wir die in unserem Evaluationssystem umgesetzten Ideen generalisieren, um die Erstellung von sehr unterschiedlichen mobilen Informationssystem-Apps zu unterstützen. Ferner werden wir somit die Formalisierung unseres Ansatzes beginnen, um die dem Ansatz bislang noch fehlende fundierte formale Basis zu erhalten.