Zur Erlangung des akademischen Grades Diplom-Medieninformatiker. Prof. Dr. rer. nat. habil. Dr. h. c. Alexander Schill

Größe: px
Ab Seite anzeigen:

Download "Zur Erlangung des akademischen Grades Diplom-Medieninformatiker. Prof. Dr. rer. nat. habil. Dr. h. c. Alexander Schill"

Transkript

1 Fakultät Informatik Institut für Systemarchitektur, Lehrstuhl Rechnernetze DIPLOMARBEIT Zur Erlangung des akademischen Grades Diplom-Medieninformatiker Untersuchung hybrider Ansätze zur plattformübergreifenden App-Entwicklung Vorgelegt von: Martin Dobrev Matrikelnummer: Hochschullehrer: Betreuer: Prof. Dr. rer. nat. habil. Dr. h. c. Alexander Schill Dr.-Ing. Thomas Springer (TU Dresden) Dipl.-Inf. Marcel Heckel (Fraunhofer IVI) Abgabedatum: Dresden, den

2

3

4

5 Eigenständigkeitserklärung Hiermit erkläre ich, dass ich die vorliegende Diplomarbeit zum Thema Untersuchung hybrider Ansätze zur plattformübergreifenden App-Entwicklung selbstständig und unter ausschließlicher Verwendung der angegebenen Literaturquellen und Hilfsmittel verfasst habe. Dresden, den Unterschrift: (Martin Dobrev)

6

7 Danksagung An dieser Stelle möchte ich allen danken, die mir bei der Realisierung dieser Diplomarbeit geholfen haben. Zunächst danke ich meinen Betreuern Dr. Thomas Springer der TU Dresden und Marcel Heckel des Fraunhofer-Instituts für Verkehrs- und Infrastruktursysteme. Mein Dank geht auch an Prof. Dr. Alexander Schill und den gesamten Lehrstuhl Rechnernetze der TU Dresden für die Ermöglichung der Diplomarbeit. Ein besonderer Dank richtet sich auch an Ralf Udtke, der mir beim Korrekturlesen der vorliegenden wissenschaftlichen Arbeit sehr behilflich war. Schließlich danke ich meiner ganzen Familie und meinen Freunden, die mich immer unterstützt und aufgemuntert haben. 7

8

9 Inhaltsverzeichnis 1 Einführung MobiKat Motivation und Problemstellung Zielstellung Aufbau der Arbeit Grundlagen & Stand der Technik Klassifikation der Entwicklungsansätze Modellgetriebener Ansatz Webbasierter Ansatz Hybrider Ansatz PhoneGap Icenium Trigger.io Interpretationsansatz Rhodes & RhoMobile Adobe AIR Appcelerator Titanium Kony Tabris Übersetzungsansatz Embarcadero Xamarin MoSync Qt Mobile Edition Zusammenfassung Vergleich und Auswahl des Frameworks MobiKat Funktionen HTML5 als Basis für MobiKat Mobile Vergleichskriterien Vergleich der Frameworks Auswahl der Entwicklungsmethodik Zusammenfassung Konzept und Implementierung Xamarins Entwicklungsansatz Xamarin Studio Code-sharing-relevante Funktionen in C# Konditionale Kompilierung Partielle Klassen und Methoden Events und Delegates Portable Class Libraries Allgemeine Code-Sharing Strategien Globale Code-Sharing Mechanismen Cross-Plattform Anwedungsstruktur Implementierung und Integration der Anwendungsfunktionen MobiKat SOAP-Dienste

10 4.5.2 REST-basierte Kommunikaton Kartenintegration Geolocation Datenbank Lokale Dateizugriffe Benutzung der Kamera Benutzung des Mikrofons Detaillierte Entwicklungsmethodik Prototypische Implementierung Zusammenfassung Evaluation Entwicklungsgeräte- und Tools Entwicklungsumgebungen Allgemeine Bewertung Buildzeiten Probleme Code-Sharing-Analyse Entwicklungsaufwand Gesamteinschätzung und Empfehlung Zusammenfassung 59 A Gesamtliste der Tools und Frameworks 65 B Xamarin Studio 67 C MobiKat Mobile Prototyp 71 10

11 1 Einführung Mobile Geräte gehören zu den am schnellsten wachsenden technologischen Innovationen der Gegenwart. Laut [1] verbreiten sich Smartphones zehn mal schneller als PCs in den 80er Jahren, zwei mal schneller als die Zunahme der Internetzugänge in den 90er Jahren und drei mal schneller als das vor kurzer Zeit statt gefundene Wachstum der sozialen Netzwerke. In nur zwei Jahren überschritten Smartphoneverkäufe die Verkäufe von klassischen Personalcomputern und schon Anfang 2012 wurden zwei mal mehr Smartphones als PCs verkauft. Der Tabletmarkt wächst sogar noch schneller - von dem dreifach größeren Wachstum der ipad-verkäufe im Vergleich zu den iphone-verkäufen (Abbilung 1) ist es klar, dass Tablets als nächste technologische Explosion bezeichnet werden können. Abbildung 1: ipad und iphone Verkäufe nach dem Start des jeweiligen Produkts, Quelle [2] Diese neue mobile Klasse von Geräten, die viele unterschiedliche Sensoren beinhaltet, ermöglicht die Entwicklung einer neuen Generation von umgebungsbewusster Software, die früher nicht realisierbar war. Auf diese Weise lassen sich Businessprozesse und Kundenverhältnisse weiter entwickeln. Mit Hilfe von neuen, einzigartigen, mobilen Programmen lassen sich Produktivität und Zeiteffizienz existierender Dienste deutlich verbessern. Unternehmen, die schnell mobile Anwendungen und die Nutzung von Smartphones und Tablets in ihre Arbeitsweise integrieren, haben dadurch die Möglichkeit den Erfolg ihres Geschäftes zu vergrößern. Die sich langsam anpassenden Unternehmen riskieren dagegen, ihren Einfluss und Bedeutung am Markt zu verlieren. 11

12 1.1 MobiKat Das am Fraunhofer-Institut für Verkehrs- und Infrastruktursysteme IVI entwickelte System MobiKat dient der Vorsorge und Bewältigung von Großschadenslagen sowie der alltäglichen Gefahrenabwehr im Landkreis Sächsische Schweiz-Osterzgebirge [5]. Die System-Komponenten und Konzepte stellen eine Unterstützung für Stäbe, Einsatzleitungen und Einsatzkräfte vor Ort dar und bieten eine wertvolle Entscheidungsgrundlage für die effektive Planung und Durchführung von Schutz- und Rettungsmaßnahmen. Ein Schwerpunkt liegt dabei auf der Gewährleistung der Mobilität aller Beteiligten. Dies sichert eine schnelle Hilfeleistung im Rahmen der gesetzlichen Verpflichtungen und ermöglicht die Reduzierung von Sach- und Personenschäden. Daten aus amtlichen, geografischen Informationssystemen sind in ihrer ursprünglichen Form meist nur sehr eingeschränkt für praktische Anwendungen in den Bereichen Katastrophenschutz und Verkehr geeignet. MobiKat stellt eine integrierte Datenbasis für Krisen- und Verkehrsmanagement sowie effektive Werkzeuge zur Entscheidungsunterstützung und Gewinnung von Live-Informationen zur Verfügung. Zurzeit können die Funktionen des Systems nur von Personalcomputern benutzt werden. Um eine mobile Nutzung und damit den dynamischen Zugriff auf Systemkomponenten während eines Einsatzes zu ermöglichen, ist die Erstellung einer App für Smartphones und Tablets geplant. 1.2 Motivation und Problemstellung Die neuen Smartphone- und Tabletmärkte zeichnen sich durch eine hohe Heterogenität und schnell ändernde Trends aus. Beispielsweise hat die Plattform Android von 2009 bis 2013 ihren Verkaufsanteil von 4% auf 80% erhöht (Abbildung 2). Symbian, auf der Grafik unter Andere, und Blackberry haben dagegen einen Großteil ihrer Nutzer verloren. Apple mit ios war zwar nie auf der ersten Position bezüglich der Anzahl an verkauften Geräten, hat aber relativ kostante Verkaufsanteile und damit eine sichere Kundenbasis. Abbildung 2: Anteile der Smartphoneverkäufe in den letzten Jahren [3] 12

13 Die mobilen Plattformen von Windows waren bis jetzt nicht richtig populär. Mit der Veröffentlichung von Windows Phone 8 fängt aber die Firma an, langsam Marktanteile zu gewinnen. Dieser Trend ist besonders in Europa erkennbar, wo mehr als 10% aller verkauften Smartphones im Jahr 2013 mit dem neuesten mobilen Betriebssystem von Windows ausgerüstet waren (Abbildung 3). Um den Markt effektiv auszunutzen und eine gewisse Sicherheit bezüglich sich ständig ändernden Trends zu erreichen, ist es sinnvoll, mehrere Plattformen zu unterstützen. Native Anwendungen für jedes mobile Betriebssystem zu entwickeln, ist sehr aufwendig und kostenintensiv. Aus diesem Grund sind verschiedene alternative Ansätze entstanden, die plattformübergreifende Anwendungsentwicklung ermöglichen. Diese erhöhen zwar den Aufwand, haben aber den Vorteil, dass mehr Nutzer erreicht werden können. In den Grafiken 2 und 3 ist zu erkennen, dass Abbildung 3: Smartphoneverkäufe in Europa für 2013 [4] mit einer App sowohl für Android als auch für ios mehr als 80% des Markts erreicht werden können. Wenn man aber hauptsächlich in Europa tätig ist, wie im Fall von Fraunhofer IVI, ist die Unterstützung von Windows-Geräten sehr wünschenswert. Mit diesen 3 Plattformen können mehr als 95% des Markts abgedeckt werden. 1.3 Zielstellung Der Erfolg einer Anwendung hängt von vielen verschiedenen Faktoren ab. Das sind z.b. Design, Bedienbarkeit, Lade-und Reaktionszeiten. In diesen Kategorien weisen native Komponenten erhebliche Vorteile gegenüber anderen Lösungen auf. Aufgrund der Integration in das Betriebssystem, sind die meisten Benutzer in der Lage, ohne zusätzliche Kenntnisse diese Elemente zu benutzen. Außerdem sind sie den gerätespezifischen Eigenschaften angepasst. Genau aus diesen Gründen haben die populären sozialen Netzwerke Facebook und LinkedIn ihre Apps komplett neu aufgebaut und alle HTML-basierten mit nativen Komponenten ersetzt. Eine praktikable Lösung für die Erstellung mobiler Cross-Plattform-Anwendungen könnte deshalb ein hybrider Ansatz sein. Unter dem Begriff hybrid sind hier nicht die sogenannten hybriden Apps gemeint, die im Kapitel 2.4 vorgestellt werden, sondern alle Lösungen, die eine Kombination verschiedener Technologien benutzen, um plattformübergreifende Entwicklung zu ermöglichen. Existierende Werkzeuge könnten eine effiziente Lösung für Teilaspekte mobiler Anwendungen, etwa die Datenmodellierung, Nutzung verschiedener Dienste über standartisierte Protokolle wie HTTP oder die Anwendungslogik bieten. Für diese Teilaspekte soll möglichst kein nativer Code nachimplementiert werden müssen, während andere Aspekte wie die Benutzeroberfläche vollständig in Form von separaten Projekten für alle Plattformen umgesetzt werden können. Ebenso ist eine Kombination mehrerer Werkzeuge denkbar. Ziel der Diplomarbeit ist es deshalb, existierende Werkzeuge hinsichtlich ihrer Eignung für eine hybride Lösung zu untersuchen und ein bzw. mehrere Werkzeuge auszuwählen, die zu einer Gesamtlösung integriert werden können. Dafür ist eine flexible und erweiterbare Methodik zu entwickeln, die die Integration aller MobiKat-relevanten Funktionen unterstützt. 13

14 1.4 Aufbau der Arbeit Im nächsten Kapitel wird die reiche Auswahl und Heterogenität verschiedener Entwicklungsansätze vorgestellt. Nach einer Definition und einer Übersicht verschiedener Ansatzklassen werden existierende Frameworks diesen Klassen zugeordnet und detailliert beschrieben. Kapitel 3 befasst sich mit dem Vergleich der beschriebenen Werkzeuge. Basierend auf diesem Vergleich wird ein Framework für die zu entwickelnde MobiKat-App ausgewählt. Im Kapitel 4 wird die zu entwickelnde Anwendung konzipiert. Dabei werden verschiedene Umsetzungsmöglichkeiten der einzelnen Funktionen beschrieben und verglichen. Schließlich wird der auf Basis des Konzepts erstellte Prototyp vorgestellt. Im Kapitel 5 wird eine Evaluation der Entwicklungsmethodik und des Prototyps durchgeführt. Zum Schluss wird diese Arbeit mit einer Zusammenfassung der Ergebnisse und einem Ausblick im Kapitel 6 beendet. 14

15 2 Grundlagen & Stand der Technik Um verschiedene Ansätze zur plattformübergreifenden Entwicklung zu untersuchen, ist zuerst eine allgemeine Klassifikation der Methoden als Basis für den Vergleich notwendig. Dieses Kapitel stellt verschiedene Klassen von Cross-Plattform-Entwicklungsmethoden für mobile Geräte mit ihren charakteristischen Merkmalen vor. Zu jeder Klasse werden auch die aktuellsten Frameworks und ihre Eigenschaften vorgestellt. Schließlich wird das Kapitel mit einem Vergleich der Ansätze beendet. 2.1 Klassifikation der Entwicklungsansätze Allgemein können folgende Ansätze zur Entwicklung plattformübergreifender, mobiler Anwendungen definiert werden: Modellgetriebener Ansatz Webbasierter Ansatz Hybrider Ansatz Interpretationsansatz Übersetzungsansatz Es sei auf die Klassifikation von [7] verwiesen, wo alle plattformübergreifende Entwicklungsansätze sehr detailliert und strukturiert beschrieben sind. 2.2 Modellgetriebener Ansatz Abbildung 4: Funktionsweise der Modellgetriebenen Softwareentwicklung Bei diesem Ansatz sind Modelle die zentrale Komponente im Entwicklungsprozess. Mit deren Hilfe werden sowohl Logik als auch Softwarestruktur spezifiziert. Normalerweise werden sie mit Hilfe einer Markup-Sprache wie XML beschrieben. Mit Hilfe verschiedener Transformationen lassen sich dann beliebige andere Komponenten generieren. Dass können weitere Modelle, Programmcode (Java, C++ usw.) oder direkt ausführbarer Maschinencode sein (siehe Abbildung 4). Eine andere Möglichkeit ist, die Modelle mittels eines Interpreters direkt zur Laufzeit zu benutzen. 15

16 Trotz großer Beachtung in der Forschung haben sich in der Praxis die modellgetriebenen Ansätze nicht durchsetzen können. Es existieren keine Frameworks, die eine modellgetriebene Entwicklung für mehrere mobile Plattformen unterstützen. Der Grund dafür liegt darin, dass die Entwicklung von Anwendungen solcher Art von der Existenz verschiedener Generatoren abhängt. Der Erstellung und das Anpassen dieser Komponenten an die sich schnell ändernden mobilen Plattformen ist sehr aufwendig und bis jetzt nicht realisiert worden. 2.3 Webbasierter Ansatz Bei diesem Ansatz werden die Möglichkeiten der in den mobilen Geräten eingebauten Browser eingesetzt. Die Anwendungen selbst werden als HTML Webseiten angeboten (Abbildung 5), die vom Browser geöffnet werden können. Mit dem Einsatz von Technologien wie JavaScript und CSS lassen sich sowohl interaktive Elemente als auch verschiedene visuelle Effekte realisieren. Aufgrund der Möglichkeit aller neueren mobilen Plattformen, Webseiten darzustellen, können in der Regel mit einer webbasierten Anwendung gleichzeitig alle Plattformen unterstützt werden. Abbildung 5: Struktur von webbasierten Apps Web Apps sind somit die schnellste Methode, eine Cross-Plattform Anwendung zu erstellen. Es ist weder eine Installation noch Packaging jeglicher Art notwendig. Jedes Gerät, das über einen Browser und Internetverbindung verfügt, ist in der Lage, die Anwendung zu benutzen. Aufgrund der verschiedenen Dislplaygrößen ist normalerweise eine zusätzliche Anpassung der Benutzeroberfläche für verschiedene Geräteklassen notwending, was sich aber auf die Anteile des gemeinsam benutzten Codes für die Anwendungslogik kaum auswirkt. Aus Sicherheitsgründen haben mobile Browser einen limitierten Zugriff zu spezifischen Gerätefunktionen wie das lokale Dateisystem und die verschiedenen Sensoren im Gerät. Diese Grenzen gelten dann entsprechend für alle Web Apps, was auch ihr größter Nachteil ist. Web Apps können auch nicht über die populären Plattformanwendungsmärkte - GooglePlay, AppStore und Windows Phone Store verbreitet werden. Trotz wesentlicher Verbesserungen der Performanz von mobilen Browsern in den letzten Jahren sind Web Apps deutlich langsamer als ihre nativen Alternativen. Zum Erstellen von Web Apps bietet sich die Benutzung von verschiedenen JavaScript und CSS Frameworks an. In dieser Arbeit werden die einzelnen Frameworks nicht detailiert betrachtet, sondern ein grober Überblick über die populärsten gegeben. Detaillierte Beschreibungen können auf den Webseiten des jeweiligen Produkts gefunden werden (siehe Anhang A). jquery Mobile - ein Web Framework, das sowohl aus CSS als auch aus JavaScript Dateien besteht. Somit bietet es sowohl eine für mobile Geräte mit Touchscreens optimierte Version der bekannten jquery Bibliothek als auch verschiedene Benutzeroberflächenelemente, die auf der verbreiteten jquery 16

17 UI basieren. Sencha Touch - basierend auf den neuesten HTML5 und CSS3 Standards, bietet dieses Framework verschiedene UI Komponenten, die sich über spezielle Themen unterschiedlich für jede Plattform darstellen lassen. Auf diese Weise kann man eine WebApp, die wie eine native Anwendung aussieht, erstellen. Dabei gibt es Themen für ios, Android, Windows Phone und Blackberry. Dojo - ist auf einem kleinen, optimierten Kernmodul aufgebaut, das nur 3,8 kb groß ist. Basierend darauf kann man verschiedene Widgets und Styles benutzen. Speziell für mobile Geräte wurden neue Formularkomponenten wie Listen, Slider und verschiedene Schalter erstellt. Mit Hilfe von CSS3 ist es möglich, natives Look & Feel von ios, Android und Blackberry zu simulieren. Kendo UI - bietet mit Hilfe von verschiedenen jquery-basierten Widgets nicht nur natives Look & Feel wie Sencha Touch und Dojo sondern auch diverse Datenvisialisierungskomponenten, die zusammen mit weiteren Produkten der Firma integriert werden können. Im Gegensatz zu den vorher vorgestellten Frameworks ist Kendo UI nicht kostenlos. Die Lizenzkosten des Frameworks variieren von 199$ bis 699$ pro Jahr und pro Entwickler in Abhängigkeit von den gewünschten Eigenschaften. Bootstrap - ist ein CSS Framework, das die Entwicklung von flexiblen Benutzeroberflächen ermöglicht. In Abhängigkeit vom aktuellen Gerät werden Bootstrap-basierte Webseiten unterschiedlich dargestellt. Dabei werden sowohl Personalcomputer als auch mobile Geräte wie Tablets und Smartphones unterstützt. 2.4 Hybrider Ansatz Das Ziel dieses Ansatzes ist, den Komfort von Entwicklung mit HTML, JavaScript und CSS mit der Mächtigkeit nativer Apps zu verbinden. Mit dieser Technik können mobile Anwendungen wie Browser Apps entwickelt werden, aber die resultierende Anwendung ist am Ende mit Hilfe einer nativen Hülle in eine native Anwendung gepackt. Diese Hülle ermöglicht den Zugriff zu den gerätespezifischen APIs und Sensoren, die normalerweise vom Browser nicht benutzt werden können. In Abbildung 6 ist der Aufbau einer hybrider Anwendung dargestellt. Abbildung 6: Struktur hybrider Apps Normalerweise bestehen die hybriden Apps aus lokalen HTML-, CSS- und JavaScript-Dateien. Diese werden mit Hilfe eines WebView-Widgets angezeigt. WebView Widgets sind native Plattform- 17

18 komponenten, die das Anzeigen von webbasierten Dokumenten ermöglichen. Alle modernen, mobilen Plattformen verfügen über WebView Widgets. Der Zugriff auf die plattformspezifische Komponenten wird mit Hilfe eines JavaScript-to-Native Bridges realisiert. Das ist eine Cross-Plattform Bibliothek, die die nativen APIs auf JavaScript abbildet. In diese Bibliothek lassen sich auch native Komponenten integrieren, die dann bei der Bildung von Benutzeroberflächen verwendet werden können. Beispielsweise besteht die Möglichkeit native Widgets wie Tabs, Karten und Listen in die Anwendung zu integrieren. Mit der Bündelung von Web Apps als native Anwendungen kann nicht nur die Distribution über App Stores, sondern auch eine hohe Flexibilität bei der Entwicklung und Zugriff auf spezifische Gerätefunktionen erreicht werden. Aufgrund der Benutzung der Browser-Engine für die Hauptkomponenten der hybriden Anwendungen ist ihre Performanz mit der Performanz von Web Applikationen vergleichbar. Allgemein steigt die Komplexität der plattformübergreifenden Bibliothek mit der Anzahl der integrierten Plattformen und mit der Anzahl der angebotenen Funktionen, was für alle Arten von plattformübergreifenden Bibliotheken gilt. Aus diesem Grund können hybride Apps nicht alle mobilen Betriebssysteme unterstützen wie die Web Apps PhoneGap Das Open Source Framework PhoneGap (Anhang A) bietet ios-, Android-, BlackBerry- und WindowsPhone- Unterstützung. Dabei werden als JavaScript-to-Native Bridge die Apache Cordova (Anhang A) APIs benutzt. Für jede Plattform wird eine eigene Bibliothek zur Verfügung gestellt, mit derer Hilfe sich die entsprechenden Plattformprojekte erstellen lassen. Dabei können HTML-, CSS- und JavaScript- Dateien in verschiedene Projekte integriert werden, was eine gemeinsame Codenutzung ermöglicht. PhoneGap ist eine Applikation, die nur für die Bündelung der Projekte zuständig ist. Sie hat keine Benutzeroberfläche und muss von der Konsole ausgeführt werden. Es werden keine Debugging-Tools mitgeliefert, was die Entwicklung von Applikationen deutlich erschwert. Obwohl Emulatoren zum Testen von PhoneGap Anwendungen existieren (Ripple Emulator für Chrome - Anhang A), sind diese immer noch nicht produktionsreif, was die Entwickler dazu zwingt, eigene Logging- und Debugging- Lösungen zusätzlich herzustellen Icenium Icenium ist ein kommerzielles Framework (Anhang A), das nur Android und ios Plattformen unterstützt. Hier wird wie bei PhoneGap, Cordova für Zugriff auf die native Gerätefunktionen benutzt. Dabei wird eine eigene Entwicklungsumgebung angeboten, die sowohl einen realistischen Simulator als auch Debugging- und Bündelungstools beinhaltet. Die Umgebung ist in drei Varianten erhältlich - als Windows Anwendung, als App für Chrome und als Plugin für Visual Studio. Die Bündelung der Anwendungen wurde komplett in die Cloud ausgelagert, was eine Entwicklung am beliebigen Computern mit Internetzugang ermöglicht. Zusätzlich wird das Kendo UI Javascript und CSS Framework für Gestaltung der Benutzeroberfläche angeboten Trigger.io Trigger.io unterscheidet sich von PhoneGap und Icenium dadurch, dass das Framework zusätzlich native UI-Komponenten unterstützt. Somit ist es möglich, sowohl Tab-Widgets als auch verschiedene Picker-Widgets von Android oder ios zu benutzen. Zusätzlich können native Module erstellt und veröffentlicht werden. Unter anderem existieren beispielsweise Module für Zugriff auf verschiedene Sensoren, Facebookdaten, Kameradaten und Kalenderdaten. Trigger.io bietet keine eigene Entwicklungsumgebung. Zum Debugging kann man den Trigger.io Catalyst benutzen, der das Web-Kit ähnliche Debugging ermöglicht. Dabei kann man vom lokalen Computer aus in Echtzeit HTML-, CSS- 18

19 oder JavaScript-Elemente analysieren, hinzufügen und editieren. Es werden sowohl das Debugging an verschiedenen Emulatoren als auch an realen Geräten unterstützt. 2.5 Interpretationsansatz Bei dem Interpretationsansatz wird die plattformübergreifende Anwendung in einer Programmiersprache entwickelt. Die Programmanweisungen werden dann von einem Interpreter oder einer virtuellen Maschine zur Laufzeit nacheinander ausgeführt und in Maschinencode transformiert, der dann auf die Funktionen der Plattform vollständig zugreifen kann. Die allgemeine Struktur aller interpretierten Anwendungen ist in Abbildung 7 dargestellt. Interpretierte Anwendungen enthalten den Quellcode und normalerweise verschiedene Ressourcen. Der Interpreter oder die virtuelle Maschine zusammen mit einer plattformübergreifenden Bibliothek können somit als eine Art Adapter für verschiedene Plattformen angesehen werden. Es gibt zwei verschiedene Möglichkeiten, den Interpreter in die mobilen Plattformen zu integrieren. Er kann sowohl zusammen mit der gesamten Anwendung gepackt werden als auch getrennt als eigenständige Anwendung installiert werden. Eine spezielle Variante ist der JavaScript Interpreter, der standardmäßig in allen mobilen Betriebssystemen vorinstalliert ist. In den folgenden Abschnitten werden die am häufigsten benutzten Frameworks vorstellt, die nach dem Interpretationsansatz aufgebaut sind. Abbildung 7: Struktur interpretierter Anwendungen Rhodes & RhoMobile Rhodes ist ein Open-Source-Framework für schnelle, plattformübergreifende Entwicklung in der Skriptsprache Ruby zusammen mit den Web-Technologien HTML, CSS und JavaScript. Das Framework wird nach dem MVC-Entwurfsmuster (Model-View-Controller) aufgebaut. Dabei werden die Programmlogik und das Datenmodell mit Ruby-Dateien beschrieben. Die View-Komponente wird durch Embedded-Ruby- Templates (ERB) realisiert. Mit Hilfe eines Webservers, der mit der Anwendung gebündelt wird, werden Ruby Dateien interpretiert und HTML Dateien generiert. Der Entwicklungsprozess ist fast identisch mit der Entwicklung einer dynamischen Webseite mit Ruby. Für das Anzeigen der generierten Webdateien wird die Browser-Engine des entsprechenden Geräts verwendet. Das Framework bietet viele Benutzeroberflächenkomponenten, die mit Hilfe einer modifizierten Version des JQTouch-JavaScript-Frameworks ein natives Look & Feel verschiedener Plattformen simulieren Adobe AIR Adobe AIR ist ein Produkt der Firma Adobe Systems Incorporated. Mit Hilfe von Adobe AIR lassen sich Adobe Flash Anwendungen erstellen, die als eigenständige native Programme ausführbar sind. Unterstützte Plattformen sind Mac OS X, Windows, ios, Android und Blackberry. Adobe AIR basiert auf dem Flex-Framework, das eine Reihe von Entwicklungstools und Bibliotheken zur Entwicklung von Rich Internet Applications (RIA) anbietet. Spezielle AIR-Schnittstellen ermöglichen den Zugriff zu spezifischen Plattformfunktionen. Seit der Version 3.2 bietet Adobe AIR eine Schnittstelle 19

20 zur Grafikkarte, was die Performanz der Anwendungen deutlich verbessert. Die AIR-SDK ist wie die Flex-SDK kostenlos. Somit ist es möglich, AIR Anwendungen mit beliebigen Text-Editoren zu erstellen. Wenn man aber die umfangreichen Benutzeroberflächenelemente von Adobe nutzen will, muss man unbedingt das speziell dafür entwickelte Programm Flash Professional verwenden. GUI Elemente können sowohl deklarativ mit Hilfe von MXML (eine XML-basierte Sprache) als auch programmatisch mit ActionScript 3 erstellt werden. Um Plattformunabhängigkeit zu gewährleisten, werden zuerst alle deklarativ beschriebene Elemente in ActionScript-Code umgewandelt. Zusammen mit der Anwendungslogik werden schließlich alle ActionScript-Dateien mit einem Compiler in ActionScript-Bytecode (SWF-Format) kompiliert. Die Plattformen Windows, Mac OS X und Android können diesen Bytecode mittels der separat zu installierenden AIR-Laufzeitumgebung interpretieren. Im Blackberry ist diese direkt in die Plattform integriert. Bei ios muss der Bytecode zuerst in Maschinencode transformiert werden, weil Apple die Benutzung von anderen Laufzeitumgebungen verbietet. Dafür wird der LLVM-Compiler benutzt. Als Ergebnis bekommt man eine native ios-anwendung Appcelerator Titanium Titanium von Appcelerator ist ein Framework für plattformübergreifende Entwicklung, bei dem JavaScript als Programmiersprache benutzt wird. Mit Titanium können sowohl native als auch web-basierte Anwendungen erstellt werden. Native Anwendungen werden zurzeit für Android, ios und Blackberry angeboten. Eine Cross-Plattform-Bibliothek sorgt für die Abstraktion der verschiedenen plattformspezifischen Komponenten. Mit Hilfe des Alloy Frameworks kann man Titanium Apps nach der Modell- View-Controller-Architektur erstellen. Views lassen sich deklarativ mit Hilfe von XML erstellen. Mit einer JSON-basierten Sprache - TSS (Titanium StyleSheets) - können die Views mit CSS-ähnlichen Attributen gestaltet werden. Es ist auch möglich, Themen zu benutzen, um unterschiedliche Anwendungsstyles zu erstellen. Datenmodelle basieren auf dem Backbone.js Framework und sind direkt in die XML-deklarierten Views integrierbar. Titanium kommt mit einer eigenen Entwicklungsumgebung - Titanium Studio, die Eclipse-basiert ist. Um native Anwendungen zu produzieren, werden zuerst alle XML-Views zusammen mit den benutzten Styles in JavaScript transformiert. Der JavaScript-Code wird mittels eines Compilers in die sogenannten Titanium-Symbole transformiert. Diese Symbole werden dann für jede Zielplattform auf die entsprechenden nativen Elementen abgebildet. Anwendungslogik wird mittels eines JavaScript interpreters ausgeführt. Im Fall von Blackberry ist das der native Browser-Engine. Android- und ios-anwendungen benutzen gebündelte Engines - Mozilla Rhino und JavaScriptCore Kony Das Framework Kony (Anhang A) bietet eine plattformübergreifende Entwicklung für Smartphones, Tablets, Desktopcomputer und auch ältere mobile Geräte. Außer ios, Android, Windows Phone und Blackberry werden auch Plattformen wie Symbian und Java ME unterstützt. Ursprünglich wurde die Skriptsprache Lua als einzige Entwicklungssprache benutzt. Seit Juni 2012 wird zusätzlich JavaScript angeboten. Quellcode wird mittels einer virtuellen Maschine und separater Bibliotheken auf verschiedenen Geräte zur Laufzeit interpretiert. Native Komponenten werden mit Hilfe von diesen Bibliotheken gekapselt und ermöglichen somit die Erstellung von sowohl nativen als auch hybriden und webbasierten Anwendungen. Die einzelnen Komponenten des Frameworks sind in der Abbildung 8 dargestellt. Das Kony Studio - die eigene IDE, bietet plattformübergreifende Entwicklung mit gemeinsamer Codebasis. Das Studio basiert auf Eclipse und bietet einen speziellen JavaScript-Editor, Auto-Preview und Deployment für Emulatoren und reellen Geräten. Zusätzlich werden als Cloud-Dienste erweiterte Funktionen wie z.b. Versand von Nachrichten, ios Passbook Integration, Datensynchronisation zwischen beliebigen Geräten, Berichte und Analysen von Daten und Onlinezahlung angeboten. In der 20

21 Abbildung 8: Kony Komponente [10] plattformübergreifenden Bibliothek sind auch verschiedene Bindungen für den Zugriff auf verschiedene Datentypen zu finden. Einige davon sind ERP/CRM (SAP, Oracle, PSFT, JDEdwards, Sharept, SFDC), MQ Series, SOAP, REST, JSON, XML Tabris Tabris ist ein Java-Framework, das standartisierte Java Enterprise Edition Technologien benutzt, um Applikationen auf einen Server zu erstellen. Native Klienten sind eigentlich entfrente Terminals, die auf die Server-Applikation zugreifen. Datenaustausch wird mittels JSON-Nachrichten realisiert. Die Struktur einer Tabris- Anwendung ist in der Abbildung 9 dargestellt. Die serverorientierte Architektur ermöglicht hohe Datensicherheit und zentrales Deployment. Auf dem Server wird die Open Source Eclipse RAP Technologie benutzt. Eclipse RAP (Remote Application Platform) [16] bietet eine große Vielfalt an Widgets und kann mit Technologien wie OSGi und JEE integriert werden. In RAP haben UI-Komponenten zwei Zustände - einen auf dem Server und einen auf dem Klient. Die Serverseite wird mittels Plain-Data-Objects repräsentiert. Klientseite besteht aus nativen Komponenten, die alle Benutzerinteraktionen zum Server verschicken. Unterstützte Plattformen sind nur Android und ios. JEE RAP Server JSON JSON JSON Browser Application Abbildung 9: Tabris Plattform [15] 21

22 Als UI-Komponenten steht eine begrenzte Auswahl zur Verfügung. Die wichtigsten wie z.b. Buttons, Lists und verschiedene Inputfelder können plattformübergreifend benutzt werden. Viele plattformspezifischen Widgets werden aber überhaupt nicht unterstützt. 2.6 Übersetzungsansatz Ein Übersetzer ist ein Programm, das Text einer bestimmten Quellsprache in einen semantisch äquivalenten Text einer Zielsprache transformiert [8]. Übersetzer, die Programme höherer Programmiersprachen in eine meist maschinenorientierte Sprache umwandeln, werden als Compiler bezeichnet. Mit Hilfe eines Compilers und spezieller Cross-Plattform-Bibliotheken ist es dann möglich, eine Anwendung in einer Quellprogrammiersprache zu entwickeln und dabei auf mehreren Plattformen einzusetzen. Der Unterschied zu dem interpretierten Ansatz ist, dass bei der Kompilierung Maschinencode erzeugt wird, der dann direkt von der Plattform ausgeführt werden kann. In den folgenden Abschnitten wird einen Überblick über die populärsten Methoden und ihre Eigenschaften gegeben Embarcadero Der Cross-Plattform Entwicklungsansatz der Firma Embarcadero Technologies basiert auf der neuesten Version der Programmiersprache Delphi - Delphi XE5, die speziell für mobile Geräte optimiert wurde. Zurzeit wird die Entwicklung für Windows, Mac OS X, Android und ios unterstützt. Um alle diese Plattformen zu erreichen, wurden verschiedene Compiler entwickelt, die auf dem bekannten Compiler LLVM basieren. Der Aufbau der Compiler und alle plattformspezifischen Details werden detailiert in [9] beschrieben. Aufgrund des anderen Ziels dieser Arbeit, werden weitere Übersetzungsdetails nicht weiter diskutiert. Es ist vielleicht nur zu erwähnen, dass Android-Anwendungen mit Hilfe von der Android-NDK erstellt werden. Auf diese Weise wird der Weg über die virtuelle Maschine Dalvik umganden und direkt der Linux-basierte Kern von Android angesprochen. Abbildung 10: Funktionsweise des Embarcadero Frameworks Die Abbildung 10 stellt den Aufbauprozess von Embarcadero Anwendungen dar. Von der eigenen Entwicklungsumgebung RAD STUIDIO XE5 ist es möglich, Anwendungen in Delphi und C++ zu schreiben, wobei sich die C++ Entwicklung für Android noch in der Entwicklung befindet. Die Cross-Plattform-Kompabilität wird mittels FireMonkey sichergestellt. FireMonkey ist ein mächtiges Framework, mit dessen Hilfe sowohl 2D als auch 3D Anwendungen erstellt werden können. Dabei wird direkt auf die Hardware zugegriffen, was für die schnelle Ausführung der Programmkomponenten sorgt und in der Regel ein gutes Benutzererlebnis liefert. Embarcadero-Anwendungen sind auf eigenen UI-Widgets aufgebaut. Diese können direkt im RAD STUDIO XE5 Designer visuell erstellt und zu verschiedenen Datenquellen gebunden werden. Das ermöglicht laut der Firma die schnellste Cross-Plattform-Anwendungsentwicklung. Native Systemkomponenten von Android und ios werden teilweise in die eigenen Widgets integriert, um bequeme Dateneingabe für den Benutzer zu realisieren. Dabei werden folgende native Komponenten integriert: 22

23 Message Alerts Custom Picker Date Picker Tastatur Bearbeiten vom Text (Kopieren, Ausschneiden, Selektieren usw.) Web View Hier ist zu beachten, dass die nativen Karten von Android und ios nicht in das System integriert und auf diese Weise auch nicht benutzbar sind. Man kann nur mit Hilfe eines WebViews interaktive geographische Karten mit Embarcadero darstellen. FireMonkey bietet nicht nur UI Komponenten. Das Framework ist sehr mächtig und enthält viele zusätzliche Funktionen wie APIs für verschiene Datenbanksysteme, Zugriff auf das lokale Dateisystem und Funktionen für Kommunikation mit entfernten Servern und Web-Services Xamarin Die Firma Xamarin bietet eine Reihe von attraktiven Entwicklungstools, die eine effektive, gemeinsame Quellcode-Benutzung für Mac OS X, ios und Android ermöglichen. Als Programmiersprache benutzt Xamarin das von Microsoft entwickelte C#. Da C# als Hauptprogrammiersprache für alle Windowsbasierten Systeme benutzt wird, lässt sich Xamarin Programmcode auch in Windows und Windows Phone Anwendungen verwenden. Abbildung 11: Xamarin Plattform, Quelle [13] Xamarin Apps benutzen native Komponenten aller Plattformen. Durch eine innovative Bindungstechnologie, sind Entwickler in der Lage, mit C# alle einzelnen Plattform-APIs und UI-Komponenten zuzugreifen. Plattformupdates werden in der Regel [1] auch innerhalb eines Tages aktualisiert. 23

24 Die Abbildung 11 gibt einen Überblick über die Struktur der Plattform. Als Basis dafür dient das Mono Framework. Mono ist eine Cross-Plattform-Implementierung des.net-frameworks. Darauf aufbauend bieten Xamarin.iOS und Xamarin.Android native SDK-Bindungen für die einzelnen Plattformen Android, ios und Mac OS X. Dabei werden native APIs 1:1 in C# abgebildet. Das stellt den Entwicklern sowohl alle Plattformfunktionen als auch zusätzliche Funktionen des.net Frameworks wie LINQ, Delegates, Events und andere Merkmale der Programmiersprache C# zur Verfügung. Für das Kompilieren der Anwendungen werden 2 verschiedene Techniken benutzt (rechter Teil der Abbildung 11). ios und Mac Anwendungen benutzen ein AOT-Kompilieren (Ahead of Time), was als Ergebnis nativen ARM-Maschinencode für ios liefert. Bei diesem Prozess wird der LLVM-Compiler benutzt, der auch von Apple in der offiziellen SDK verwendet wird. Der Kern des Mono Frameworks und alle zusätzlichen C# Bibliotheken, die für die App notwendig sind, werden statisch zu dem Maschinencode hinzugefügt. Android hat seine eigene Laufzeitumgebing - Dalvik. Viele plattformspezifische Funktionen werden durch Java-APIs zugänglich gemacht. Diese können meistens nur über Dalvik zugegriffen werden. Aus diesem Grund benutzt Xamarin.Android die beiden Laufzeitumgebungen - Mono und Dalvik gleichzeitig. So sind Entwickler in der Lage sowohl C# als auch alle Android-APIs zu benutzen MoSync Das MoSync Framework bietet eine Cross-Plattform-Entwicklung für ios, Android, WindowsPhone, WindowsMobile, Blackberry, Symbian, Java ME und Moblin. Dabei kann man Anwendungen in C/C++ oder HTML/CSS/JavaScript schreiben, die dann mit Hilfe eines eigenen GCC-Backend zuerst in die MoSync Intermediate Language (MoSync IL) kompiliert werden. Um diese breite Palette an Systemen zu unterstützen, werden unterschiedliche Aktionen für die verschiedenen Plattformen gebraucht. Für Java ME und Blackberry wird der MoSync IL in MoSync Bytecode transformiert, der dann zusammen mit einer virtuellen Maschine gepackt und auf dem entsprechenden Gerät installiert wird. Beim Start der Anwendung wird der Code in den Speicher geladen und mit Hilfe der virtuellen Maschine interpretiert. Für Android, Symbian und Windows Plattformen wird ein ähnlicher Prozess genutzt. Der Unterschied liegt nur darin, dass anstatt den Code zur Laufzeit zu interpretieren, er im Voraus komplett in ARM-Maschinencode übersetzt und dann direkt ausgeführt wird. Bei ios wird ein zusätzlicher Transformationsschritt benötigt. Nachdem der MoSync IL zur Verfügung steht, wird der in C-Quellcode transformiert und als Xcode-Projekt generiert. Das ist notwendig, weil Apple sowohl die dynamische Generation von ARM-Maschinencode als auch das dynamische Laden von Code verbietet. Vom Xcode kann dann das generierte Projekt als native Anwendung erstellt werden, die dann auch erfolgreich über den AppleStore veröffentlicht werden kann. MoSync bietet Entwicklern sowohl eigene als auch native Komponenten, wobei die letzen nur für Android, ios und Windows Phone 7 unterstützt werden. Aufgrund des breiten Spektrums der angebotenen Plattformen, werden native Komponente nicht vollständig unterstützt. Beispielsweise stehen native Karten nur für Windows Phone und ios zur Verfügung Qt Mobile Edition Qt ist ein bekanntes, plattformübergreifendes Framework, das Cross-Plattform Entwicklung hauptsächlich für Desktopanwendungen anbietet. Ende 2013 wird zusammen mit der neuen Version 5.2 wird auch die Qt Mobile Edition veröffentlicht, die eine mobile Version des Frameworks für Android und ios liefern wird. Obwohl sich Qt Mobile Edition sich noch in Entwicklung befindet, ist es sinnvoll sie zu dieser Arbeit hinzuzufügen, da Qt zu den populärsten Cross-Plattform-Frameworks zählt. 24

25 Qt bietet eigene GUI-Widgets, die durch spezielles Styling in jeder Plattform als native Komponente erscheinen. Dabei werden die Widgets normalerweise mittels QML definiert. QML ist eine JavaScript-ähnliche Sprache, die das Erstellen von UI Komponenten ermöglicht. Anwendungslogik wird mit Hilfe von C++ definiert. 2.7 Zusammenfassung Mit Hilfe der plattformübergreifenden Entwicklung ist es möglich, mehrere mobile Plattformen mit einer einzigen App zu erreichen oder Teile des Quellcodes innerhalb verschiedenen Plattformen gemeinsam zu benutzen. Das verringert sowohl die Entwicklungszeit und Kosten als auch den Wartungsaufwand in der Zukunft. Um diese Vorteile zu erreichen, grenzen verschiedene Entwicklungsansätze bestimmte plattformspezifische Funktionen aus. Die Abbildung 12 gibt einen Überblick über die Eigenschaften der verschiedenen Ansätze. Übersetzte Apps Web Apps Plattformunterstützung hoch mittel gering bis mittel gering Distribution über App-Stores nein ja ja ja Installation notwendig nein ja ja ja Lokale Speicherung der App möglich nein ja ja ja Performanz gering gering bis mittel hoch maximal Benutzeroberfläche HTML HTML HTML, Native, Custom HTML, Native, Custom Abhängigkeit von bestimmten Komponenten Browser Browser-Engine Interpreter virtuelle Maschine (nur in bestimmten Fällen) Zugriff auf Plattformfunktionen gering hoch vollständig vollständig mittel groß gering gering bis mittel (Cross-Plattform APIs) Programmieraufwand Hybride Apps Interpretierte Apps Vergleichsmerkmal (Cross-Plattform APIs, (Cross-Plattform API oder Abbildungen auf eventuell neue native APIs, eventuell Skriptsprache neue Programmiersprache) zu lernen) Abbildung 12: Gegenüberstellung der plattformübergreifenden Entwicklungsansätze Web Apps zeichnen sich durch Unterstützung von mehreren Plattformen aus. Dafür haben sie einen sehr eingeschränkten Zugriff auf gerätespezifische Funktionen. Web Apps können auch nicht in native Anwendungen gepackt werden, was die Distribution über die App Stores verschiedener Plattformen verbietet. Im Gegensatz dazu werden mit Hilfe anderer Entwicklungsansätze installierbare, plattformspezifische Programme erstellt. In diesem Fall ist die lokale Speicherung der Apps notwendig. Aufgrund der Abhängigkeit vom Browser und der Notwendigkeit, Anwendungsteile dynamisch von entfernten Servern zu laden, bieten die Web Apps eine geringere Performanz im Vergleich zu 25

26 den anderen Entwicklungsansätzen. Hybride Apps können die benötigten Inhalte lokal speichern, was sich positiv auf die Geschwindigkeit des Ladens verschiedener Daten auswirkt. Das Abspielen von verschiedenen Animationen mit JavaScript oder CSS ist deutlich langsamer im Vergleich zur Ausführung natives Codes. Interpretierte und übersetzte Apps sind in der Lage alle Plattformfunktionen zu benutzen. Wenn Anwendungen direkt in Maschinencode übersetzt werden, ist ihre Performanz gleich der der komplett nativen Apps. Der Interpretationsansatz weist fast identische Eigenschaften. Bei dem ist eine zusätzliche Verzögerung bei der Ausführung des Codes zu erwarten, die an der zur Laufzeit durchgeführten Interpretation des Quellcodes liegt. Plattformspezifische Funktionen lassen sich nur mit den Web Apps nicht nutzen. Mit allen anderen Ansätzen können theoretisch alle Plattformfunktionen verwendet werden. Der Zugriff wird mit Hilfe der Cross-Plattform-Bibliotheken gewährleistet. Aufgrund der mit der Anzahl der unterstützten Plattformen und angebotenen Funktionen steigenden Komplexität dieser Komponenten beschränken die meisten Werkzeuge entweder das Plattformangebot oder die unterstützen Funktionen. Aus der Tabelle ist auch zu entnehmen, dass verschiedene Möglichkeiten existieren, Benutzeroberflächen zu realisieren. Im Gegensatz zu den Web Apps und hybriden Apps können mit den interpretierten und übersetzten Apps außer HTML-basierten Ansichten auch native oder eigene Komponenten verwendet werden. Kombinationen der verschiedenen Arten von GUIs sind auch denkbar. Beispielsweise können mit nativen Widgets auch HTML Elemente mit Hilfe eines WebView Widgets dargestellt werden. Für die Erstellung von plattformübergreifenden Web Apps werden keine zusätzlichen Kenntnisse außer Wissen über Webtechnologien (HTML, CSS und JavaScript) gebraucht. Aus diesem Grund wird der Programmieraufwand für diesen Ansatz als gering eingeschätzt. Obwohl die hybriden Apps auch auf Webentwicklungstechnologien basieren, wird der Aufwand durch die Cross-Plattform-Bibliotheken erhöht. Dazu kommt auch die Notwendigkeit, Programmversionen für verschiedene Plattformen zu verwalten. Bei den interpretierten und den übersetzten Apps kann zusätzlich die Einarbeitung in eine neue Skript- oder Programmiersprache erforderlich sein. Somit haben alle Ansätze ihre Vor-und Nachteile. Ein Vergleich ist aus diesem Grund nur in Bezug auf definierte Kriterien möglich. Beispielsweise bietet es sich für eine Anwendung, die auf einer Webseite basiert, auf diese als Web App umzusetzen. Dafür müssen in der Regel nur die Seitenansichten für kleinere Displaygrößen angepasst werden. Wenn plattformspezifische Funktionen gebraucht werden, kann die Web App mit Hilfe des hybriden Ansatzes schnell in eine native Anwendung transformiert werden. Ist die Performanz entscheidend, bietet sich die Verwendung des Interpretationsoder Übersetzungsansatzes. 26

27 3 Vergleich und Auswahl des Frameworks In diesem Kapitel werden die im letzten Kapitel vorgestellten Werkzeuge miteinander verglichen mit dem Ziel, eine passende Grundlage für die Entwicklungsmethodik der mobilen Version von MobiKat auszuwählen. Um das zu erreichen, werden zuerst die von MobiKat benötigten Funktionen betrachtet. Auf Basis dieser Funktionen werden Vergleichskriterien für die zu untersuchenden Frameworks definiert. Mit Hilfe dieser Vergleichskriterien werden die Entwicklungstools auf ihre Eignung bezüglich der benötigten Funktionen untersucht. Zum Schluss wird das am besten geeignete Werkzeug ausgewählt, das als Basis für die Konzeption der Methodik dienen wird. 3.1 MobiKat Funktionen Die mobile Version von MobiKat soll möglichst vollständig die verfügbaren Funktionen der existierenden Anwendung umsetzen. Dabei soll der Fokus auf der Präsentation der Daten liegen. Die komplexen Berechnungen und die Anwendungslogik werden von einem Server übernommen. Zugriff zu den Systemfunktionen wird mit Hilfe eines SOAP-basierten Dienstes ermöglicht. Der Hauptgrund für eine serverorientierte Architektur ist die Sicherheit des Systems. MobiKat wird hauptsächlich in Bereichen wie Einsatzplanung und -optimierung von Feuerwehr, Polizei und Rettungsdienst eingesetzt. In diesen Fällen soll die Benutzung sensibler Informationen unbedingt durch einen hohen Grad an IT-Sicherheit geschützt werden. Der MobiKat Server kontrolliert alle Informationsflüsse und stellt sicher, dass Teilnehmer nur Information bekommen, die ihren Zugriffsberechtigungen entsprechen. Die Durchführung der gesamten Berechnungen auf dem Server wirkt sich auch positiv auf die Akkuleistung der mobilen Geräte aus. Während ein einziger Server in der Lage ist, tausende Kommunikationseinheiten gleichzeitig zu unterstützen, nehmen bei einem typischen Einsatz viel weniger Mitarbeiter teil. Das schließt die potentielle Gefahr der Überlastung aus. Die zentrale Darstellungskomponente des Programms sind die Karten. Obwohl Systeminformationen auch unabhängig dargestellt werden können, ist es meistens sinnvoll, diese auf einer Landkarte zu zeichnen. Typischerweise handelt es sich um Informationen über strategisch-relevante Orte, optimale Routen und wichtige Regionen, die in Katastrophenfällen als Lösungen für komplexe Problemstellungen angesehen werden können. In der mobilen Version des Systems sollen aus diesem Grund Karten effizient und interaktiv gestaltet sein. Verzögerungen bei Benutzeraktionen sollen minimiert werden. Die Steuerung der Komponente soll vorwiegend durch verschiedene Gesten erfolgen, die keinen zusätzlichen Platz des Displays wegnehmen. Als Teil des Systems können auch die Ergebnisse der Belegarbeit Analyse, Konzept und prototypische Implementierung einer Applikation zur Unterstützung von mobilen Einsatzkräften [6] betrachtet werden. Die Ergebnisse dieser Arbeit ermöglichen die Integration von Ortung und Kommunikation zwischen Einsatzkräften im Rahmen des Systems. In der Arbeit wurden eine Android Anwendung und ein Java-Servlet entwickelt. Mit Hilfe der mobilen Anwendung lassen sich sowohl einfache Textnachrichten, als auch multimediale Nachrichten in Form von Videos, Audiodateien oder Bildern verschicken und empfangen. Das Java-Servlet dient nur zur Koordination und bietet Zugriff auf den aktuellen Stand der verbundenen Klienten und der Nachrichten. Die Kommunikation zwischen dem Server und den Klienten wird mit Hilfe einer REST-basierten Schnittstelle über das Protokoll HTTP realisiert. Es wird gefordert, die Ergebnisse dieser Arbeit möglichst komplett in das zu entwickelnde Methodik zu integrieren und auf diese Weise nach Möglichkeit plattformübergreifende Lösungen für Geolocation, Kamera-und Mikrofonzugriffe, lokale Filesystemzugriffe, HTTP Anfragen und integrierte Datenbank zu entwickeln. 27

28 3.2 HTML5 als Basis für MobiKat Mobile Die neuen HTML5 Technologien und Standards bilden eine stabile Grundlage für die Entwicklung sowohl von Web- als auch für Smartphone-Anwendungen. Die schnelle Evolution und Adaption dieser Technologien sorgt dafür, dass neu erfundene Funktionen schnell integriert und damit für Entwickler zugänglich gemacht werden. Die breite Plattformunterstützung und die gleichzeitige Möglichkeit, Web-Apps mit der gleichen Quellcodebasis herzustellen, ist ein bequemer Ansatz, neue Nutzer mit relativ niedrigen zusätzlichen Kosten zu gewinnen. Obwohl manche mobile Plattformen wie Firefox OS sogar komplett auf HTML5 basieren, weisen webbasierte Anwendungen in den populärsten mobilen Betriebssystemen Android, ios, Windows Phone und Blackberry eine viel schlechtere Performanz als ihre nativen Alternativen auf. Wie in den Kapiteln 2.3, 2.4 beschrieben, ist der Grund dafür ihre Abhängigkeit von dem integrierten Browser bzw. Browser-Engine. Obwohl man mit den neuen Animationen im CSS3 verschiedene Elemente dynamisch mit Hilfe der eingebauten Grafikkarte manipulieren kann, realisiert man in der Regel alle Interaktionen mit Hilfe von JavaScript. Als eine vom Browser-Engine interpretierte Sprache ist JavaScript viel langsamer. Während das kein Problem für Anwendungen ist, die hauptsächlich Informationen darstellen und keine dynamische Interaktionen beinhalten, ist schlechtes und langsames Nutzererlebnis für Apps mit intensiven, sich schnell ändernden grafischen Inhalten völlig inakzeptabel. Um die Eignung von HTML-basierten Anwendungen oder Komponenten für die mobile Version von MobiKat zu testen, muss die zentrale Darstellungskomponente der Anwendung betrachtet werden. Da der Fokus der MobiKat Anwendung auf der Gebrauchstauglichkeit der Karten liegt, sollten die vom mobilen Browser dargestellten Karten auf Usability geprüft werden. Dabei sollen die Karten vernünftig verschiedene Information des MobiKat Systems anzeigen und verschiedene Benutzerinteraktionen wie z.b. Skrollen und Zoomen unterstützen. Diese Interaktionen sollen möglichst flüssig ablaufen, damit eine komfortable und bequeme Anwendungsnutzung gewährleistet wird. MobiKat Informationen lassen sich hauptsächlich als bestimmte Orte und Routen auf der Karte anzeigen. Dafür werden entsprechend Marker und einfache Linien benutzt. Aus diesem Grund wurde eine Android Testanwendung erstellt, mit deren Hilfe der Benutzer eine bestimmte Anzahl an Markern bzw. Linien zu den zwei verschiedenen Kartentypen (native und im Web Widget eingebettete HTML Karten) hinzufügen kann [17]. Mit der gleichen Anzahl an Überlagerungselementen kann man die Unterschiede bei den Interaktionen zweier Kartentypen entsprechend analysieren. Idealerweise sollte die Anwendung automatisch alle diese Aktionen durchtesten und schließlich die Ergebnisse ausgeben. Die Interaktionen in den Karten lassen sich aber aufgrund von fehlenden Schnittstellen sowohl in den nativen APIs als auch in den JavaScript Bibliotheken nicht simulieren. Im Fall von JavaScript lassen sich auch die Zeiten für das Anzeigen von verschiedenen Elementen nicht programmatisch messen, da die Elemente zusätzlich vom eingebauten Browser-Engine bearbeitet werden. Das hat dazu geführt, dass die Tests manuell durchgeführt wurden. Eine Demonstration kann auf YouTube [18] angesehen werden. Als Eingaben dafür wurden 50 Marker und 100 Linien benuzt. Als Testgerät wurde ein HTC Evo 3D mit einer Dual-core 1.2 GHz CPU und einen Arbeitsspeicher von 1GB verwendet. Bei der Demonstration wird klar, dass native Karten wesentlich schneller sind. Bei den webbasierten Karten merkt man sogar ohne zusätzliche Elemente große Verzögerungen beim Skrollen und Zoomen. Während die überlagerten Elemente fast keinen Einfluss auf die native Karten haben, bewirken sie deutliche Verzögerung bei den HTML Karten. Manche Touchgesten reagieren erst nach Zeitintervalen von mehr als eine Sekunde, was die Interaktionen mit der Komponenten deutlich erschwert. Aus diesem Grund wurde beschlossen, dass HTML-basierte Anwendungen sich nicht für die mobile Version von MobiKat eignen. 28

29 3.3 Vergleichskriterien Frameworks lassen sich miteinander nur in Bezug auf spezifizierte Kriterien vergleichen. In diesem Abschnitt werden zuerst für die zu entwickelnde Methodik relevante Kriterien aus den Frameworkeigenschaften und aus der Beschreibung des MobiKat Systems extrahiert. Basierend auf diesen Kriterien wird eine tabellarische Gegenüberstellung der Frameworks präsentiert. Als allgemeine Kriterien lassen sich folgende Eigenschaften vergleichen: Unterstützte Plattformen Es werden alle Plattformen aufgelistet, welche von dem jeweiligen Framework unterstützt werden. Wie im Abschnitt 1.2 erwähnt ist es wünschenswert, dass die Entwicklungsmethodik die Plattformen Android, ios und Windows Phone unterstützt. Aus diesem Grund werden Werkzeuge, die alle drei unterstützen mit der Farbe Grün gekennzeichnet. Gelb-markierte Frameworks, bieten zwar eine plattformübergreifende Entwicklung, aber nicht für alle oben beschriebenen Plattformen. Die Farbe Rot bedeutet eine begrenzte Cross-Plattform-Unterstützung (meistens nur Android und ios). Entwicklungssprache Gibt Auskunft über alle Programmiersprachen, die als Eingabe des Quellcodes benutzt werden können. Es ist zu beachten, dass manche Frameworks mehrere Sprachen unterstützen. Art der Benutzeroberfläche - nativ / html / custom Hier werden alle Möglichkeiten zur Erstellung von Benutzeroberflächen aufgeführt. Das können browserbasierte Anwendungen - html, native UI Widgets - nativ oder eigene Lösungen - custom sein. Um die Plattformunabhängigkeit und gute Performanz zu erreichen, basieren fast alle eigenen Lösungen auf OpenGL. Entwicklungsansätze Alle unterstützen Entwicklungsmethoden (nach 2.1) werden angegeben. Manche Frameworks unterstützen mehrere Methoden gleichzeitig. Unterstützung von gerätespezifischen Funktionen - gering / mittel / hoch / komplett Dieses Kriterium gibt Auskunft darüber, inwiefern das Framework gerätespezifische Funktionen unterstützt. Als solche werden Funktionen bezeichnet, die den Zugriff auf die Hardware (Sensoren, lokaler Spreicher, Speicherkarten usw.) ermöglichen. Mit diesem Kriterium werden alle MobiKat-relevanten Funktionen zusammengefasst. Eine detaillierte Betrachtung der spezifischen Plattformeigenschaften wird in der nächsten Gruppe von Vergleichskriterien vorgestellt. Unterstützung von nativen Karten - ja / nein / teilweise Aufgrund der besonders schlechten Performanz von HTML-basierten Karten im Vergleich zu den nativen Karten auf mobilen Geräten (siehe Kapitel 3.2) ist es notwendig die Unterstützung von nativen Kartenwidgets zusätzlich als getrenntes Merkmal in Betracht zu nehmen, um die Auswahl des Frameworks zu erleichtern. Aktualität der unterstützten Funktionen - gering / mittel / hoch Ist ein Maß dafür, wie schnell Frameworks Unterstützung von Plattformupdates berücksichtigen. Darunter wird nicht nur Kompatibilität der benutzten Funktionen mit der neuesten Plattformversion, sondern auch die Verfügbarkeit von neuen Plattformtools verstanden. Lizenzen - kommerziell / frei / Open Source Hier werden alle Lizenzen des Frameworks aufgelistet. 29

30 In Bezug auf die von MobiKat benutzten Funktionen können folgende Merkmale für den Vergleich benutzt werden: Unterstützung von SOAP-basierten Diensten Dieses Kriterium informiert darüber, ob sich SOAP-basierte Dienste in das Werkzeug integrieren lassen. Mit Integration ist dabei die Verfügbarkeit von speziellen Mechanismen, die von der WSDL Beschreibung der Dienste in der Lage sind, die vorhandenen Datentypen und - Operationen zu extrahieren und diese dem Entwickler in Form von generierten Klassen oder Bibliotheken anzubieten. Datenbankintegration (SQLite) Gibt Auskunft darüber, ob das Framework über eine integrierte Datenbank verfügt. Zugriff zum lokalen Dateisystem Der Zugang zu den lokalen Daten wird von den verschiedenen Plattformen unterschiedlich verwaltet. Aus diesem Grund ist eine einheitliche Lösung für Lese- oder Schreibzugriffe eine wichtige Eigenschaft jedes plattformübergreifenden Frameworks. Zugriff auf die Kamera Damit ist das Aufnehmen sowohl von Videos als auch von Bildern gemeint. Zugriff auf das Mikrofon Die reine Aufnahme von Audiosignalen wird nicht so oft in Apps verwendet. Als existierende Funktion im MobiKat System soll die Verfügbarkeit dieser Funktion auch betrachtet werden. Zugriff auf Geolocation-Daten Dieses Kriterium zeigt, ob das Framework das Abrufen von Ortungsdaten vom GPS-Sensor des Geräts unterstützt. Zugriff auf die Accelometer-Daten Informiert darüber, ob die Daten des Beschleunigungssensors mit Hilfe des Werkzeugs ausgelesen werden können. Zugriff auf den Bluetooth-Sensor Nicht alle Frameworks bieten die Nutzung des Bluetooth Standards für Datenübertragung zwischen Geräten über kurze Distanz an. Obwohl dieses Kriterium nicht direkt mit den Funktionen von MobiKat verbunden ist, wird es vollständigkeitshalber hinzugefügt. Zugriff auf den NFC-Sensor Die NFC-Kommunikation (Near Field Communication) ist ein neuer Übertragungsstandard zum konktaktlosen Austausch von Daten per Funktechnik über kurze Strecken von wenigen Zentimetern [30]. Aufgrund der relativ neuen Integration in mobilen Geräten verfügt nur ein kleiner Anteil der Smartphones und Tables über einen NFC-Sensor. Manche Plattformen wie z.b. ios bieten überhaupt keine Unterstützung von NFC. Wie im Fall von Bluetooth wird dieses Kriterium vollständigkeitshalber hinzugefügt. Die Abbildungen 13 und 14 stellen den tabellarischen Vergleich der Frameworks dar. Die erste Tabelle konzertiert sich auf den Vergleich allgemeiner Eigenschaften. Die zweite erweitert die Gegenüberstellung mit der Unterstützung von MobiKat-relevanten Funktionen. 30

31 Framework Unterstützte Plattformen Entwicklungssprachen Art der Benutzeroberfläche Entwicklungsansätze Unterstützung Gerätespezifischer Funktionen Unterstützung von nativen Karten Aktualität der unterstützten Plattformfunktionen Lizenzen Web app Frameworks alle HTML, CSS, JavaScript HTML Web App gering nein gering - Phonegap ios, WP, Android, BB, bada HTML, CSS, JavaScript HTML Hybrid hoch nein gering Open Source Icenium ios Android HTML, CSS, JavaScript HTML Hybrid hoch nein mittel komm. Trigger.io ios Android HTML, CSS, JavaScript HTML, native Hybrid mittel nein mittel komm. Rhodes & Rhomobile ios, WP, Android HTML, CSS, JavaScript, Ruby HTML Hybrid hoch nein mittel Open Source ios, BB, Titanium Android, JavaScript native interpret. hoch ja mittel frei Tizen ios, BB, Adobe Air JavaScript custom interpret. hoch nein mittel frei Android Kony Tabris Embarcadero ios, BB, Android, WP, Java ME Symbian ios, Android ios, Android Lua, JavaScript Java Delphi, C++ HTML, native HTML, custom interpret. hoch teilweise mittel komm. interpret. mittel nein mittel komm. custom übersetzt hoch nein mittel komm. ios, WP, Xamarin C# native übersetzt komplett ja hoch komm. Android MoSync ios, WP Android, BB, Moblin, Symbian, Java ME C++, JavaScript HTML, native übersetzt, hybrid hoch teilweise mittel frei QT mobile edition ios Android C++ custom übersetzt komm. Abbildung 13: Tabellarischer Vergleich von mobilen Frameworks 31

32 Framework Web app Frameworks Unterstützung von SOAP-basierten Diensten nein Datenbankintegration (SQLite) teilweise (WebSQL) Zugriff zum lokalen Dateisystem teilweise (nicht alle Browser) Zugriff auf die Kamera teilweise (input Felder vom Typ File) Zugriff auf das integrierten Mikrofon Zugriff auf Geolocation-Daten Zugriff auf die Accelometer-Daten Zugriff auf den Bluetooth-Sensor Zugriff auf den NFC-Sensor teilweise nein (nicht alle nein nein nein Browser) Phonegap nein teilweise (WP nicht unterstützt) ja ja nein ja ja nein nein Icenium nein ja ja ja nein ja ja nein nein Trigger.io nein teilweise (WebSQL) teilweise (nicht alle Browser) ja nein ja ja nein nein Rhodes & Rhomobile ja ja ja ja teilweise (ios und WP nicht unterstützt) ja ja teilweise ja Titanium nein ja ja teilweise (nur Bilder) teilweise (nur ios) ja ja nein ja Adobe Air ja ja ja ja ja ja ja nein nein Kony ja ja ja ja ja ja ja - - Tabris Embarcadero Xamarin ja ja nein nein nein ja nein nein nein ja ja ja ja nein ja ja nein nein ja ja ja ja ja ja ja ja ja MoSync ja ja ja ja nein ja ja nein ja QT mobile edition Abbildung 14: Tabellarischer Vergleich von mobilen Frameworks (Fortsetzung) 32

33 3.4 Vergleich der Frameworks In der ersten Tabelle ist zu sehen, dass alle Werkzeuge die populärsten Plattformen ios und Android unterstützten. Windows Phone wird dagegen von etwa der Hälfte der betrachteten Tools angeboten. Das liegt an der Tatsache, dass bis Ende 2012 die Plattform von Microsoft nicht verbreitet war. Mit der Veröffentlichung von Windows Phone 8 fängt aber Microsoft an, Marktanteile im Smartphonebereich zu gewinnen. Aus diesem Grund haben viele Frameworks wie z.b. Embarcadero, Titanium und Icenium auf ihren Webseiten Informationen über eine zukünftige Unterstützung der Plattform veröffentlicht. Für die Umsetzung der Benutzeroberfläche werden verschiedene Methoden benutzt. Während die Web und die hybriden Apps der weborientierten Dartestellung an HTML gebunden sind, benutzen interpretierte und übersetzte Tools zusätzlich native als auch eigene Komponenten für ihre GUIs. Aufgrund der bequemen plattformübergreifenden Integration von HTML-basierten Karten, werden Kartenkomponenten meistens in dieser Form angeboten. Nur Xamarin und Titanium bieten eine komplette Unterstützung von nativen Karten. Aufgrund der ständigen Updates ist es schwierig, die neuesten Funktionen schnell in die Cross- Plattform Bibliothek zu übernehmen. Aus diesem Grund benutzen die meisten Tools stabile, aber ältere Versionen der unterstützten Plattformen, beispielsweise von Titanium die praktisch von allen Android-Geräten unterstützte Version Gingerbread (2.3.3). Auf diese Weise wird eine umfangreiche Geräteunterstützung und Unabhängigkeit von den Updates erreicht. Das einzige Werkzeug, das sich den Plattformupdates anpasst, ist Xamarin. Mit den innovativen 1:1-Bindungen zu den nativen APIs ist es möglich, Plattformupdates in kurzer Zeit zu realisieren. Mit Hilfe der zweiten Tabelle lassen sich Frameworks bezüglich der Unterstützung von spezifischen Plattformfunktionen vergleichen. Web Apps bieten einen ziemlich limitierten Zugriff zur Hardware. Alle anderen Frameworks decken den größten Teil der Funktionen ab. Der Aufbau auf HTTP ermöglicht die Nutzung von SOAP-basierten Diensten innerhalb aller Ansätze. In der Tabelle wird dieser Fall nicht betrachtet. Hier werden, wie in der Beschreibung dieses Kriteriums erläutert, nur solche Lösungen betrachtet, die eine Generierung der entsprechenden Datentypen und Methoden anbieten. Es ist nicht wunderlich, dass nur die JavaScript-basierten Ansätze diese Unterstützung nicht anbieten. Es existieren zwar viele Bibliotheken, die den Aufruf solcher Diensten erleichtern. Die sind aber nicht standardisiert und wurden nur von einer begrenzten Anzahl der Browser unterstützt. Was von der Tabelle gleich auffällt ist die geringe Unterstützung der Audioaufnahme mit Hilfe des Mikrofons. Diese Funktion kommt nicht so oft in mobilen Anwendungen und wird aus diesem Grund von den meisten Werkzeugen ignoriert. Ähnlich ist die Situation mit Bluetooth und NFC. Während sich der NFC-Sensor sowohl von Rhomobile, Titanium, Xamarin und MoSync manipulieren lässt, können nur Xamarin Anwendungen die kompletten Bluetooth-APIs der Plattformen benutzen. 3.5 Auswahl der Entwicklungsmethodik Wie im vorherigen Abschnitt gezeigt sind alle Frameworks, die HTML-basierten Karten benutzen, nicht passend für die mobile Version von MobiKat. In der Vergleichstabelle der Abbildung 13 ist zu sehen, dass das alle Web-und Hybrid-Frameworks, Adobe Air, Tabris, Rhodes und Embarcadero sind. Mit Titanium ist es möglich, native Karten zu benutzen. Das Framework bietet aber keine Windows Phone Unterstützung. Eine andere interpretierte Alternative ist Kony. Anhand der detaillierten Dokumentation des Produkts wurde aber festgestellt, dass Karten APIs nur sehr eingeschränkt implementiert werden können. Funktionen, wie Erstellung von einfachen Linien stehen nicht zur Verfügung. Somit bleiben nur zwei Möglichkeiten - MoSync und Xamarin. MoSync bietet einen kompletten Zugriff auf die nativen Karten von ios und Windows Phone, schließt aber Google Maps in Android aus. Xamarin ist das einzige Framework, das alle gestellten Anforderungen erfüllt. 33

34 3.6 Zusammenfassung Obwohl die webbasierte plattformübergreifende Entwicklung ein guter Ansatz für die Erstellung von mobilen Apps ist, passt sie für MobiKat aufgrund der hohen Anforderungen an die Kartenperformanz nicht. HTML-basierte Karten sind einfach in beliebige Ansätze zu integrieren. Sie haben den Vorteil, dass ein einziger Kartentyp in alle Plattformen integriert werden kann, was den Aufwand für die Implementierung der plattformunabhängigen Bibliotheken wesentlich verringert. Die Vielfalt der nativen Kartentypen (Google Maps auf Android, Apple Maps auf ios und Bing Maps auf Windows) und ihre ständige Änderungen sorgen dafür, dass native Karten in ganz wenige Produkte integriert werden können. Die Windows Phone Plattform ist relativ neu und wird im Gegensatz zu Android und ios von einer begrenzten Anzahl von Frameworks unterstützt. Zur Zeit des Erstellens dieser Arbeit erfüllt nur Xamarin alle gestellten Anforderungen. Die folgenden Kapitel werden den Xamarin Entwicklungsprozess und die Evaluation der mit Xamarin erstellten Entwicklungsmethodik detailliert vorstellen. 34

35 4 Konzept und Implementierung Im vorherigen Kapitel wurde Xamarin als grundlegendes Framework für die Entwicklung der mobilen Version von MobiKat ausgewählt. Dieses Kapitel hat das Ziel, ein detailliertes Anwendungskonzept für die App vorzustellen. Dafür wird zuerst der von dem Werkzeug benutzte Entwicklungsansatz betrachtet. Es werden auch Entwicklungstools und Merkmale der Programmiersprache C# vorgestellt, die für einen plattformübergreifenden Applikationsaufbau benutzt werden können. Nach der Vorstellung der Grundlagen wird ein grobes Konzept der MobiKat-App präsentiert. Um alle relevanten Funktionen in das Programm zu integrieren und damit eine genaue Anwendungsstruktur spezifizieren zu können, werden verschiedene Umsetzungsmöglichkeiten jeder einzelnen Funktion untersucht. Dabei werden die einzelnen Funktionen teilweise implementiert mit dem Ziel, ihre Einbindung zu testen. Basierend auf diesen Ergebnissen wird eine ausführliche Methodik für die Entwicklung der MobiKat-App vorgestellt. Schließlich wird die prototypische Implementierung präsentiert. 4.1 Xamarins Entwicklungsansatz Wie im Kapitel erwähnt, ermöglicht Xamarin eine vollständige Benutzung aller nativen Gerätefunktionen der unterstützten Plattformen. Das Produkt basiert auf dem Mono-Framework, das eine plattformunabhängige Portierung des.net Frameworks darstellt. Mono ist ein reifes Projekt, das fast so alt wie.net ist. Es entspricht allen ECMA Standards und unterstützt viele Desktopbetriebssysteme. Einige davon sind Linux, Unix, FreeBSD und Mac OSX. Als Entwicklungssprache wird C# verwendet, was automatisch die Kompatibilität zu allen Arten von windowsbasierten Geräten gewährleistet. Für die Unterstützung der Plattformen Android und ios wurden zwei kommerzielle Produkte entwickelt - Xamarin.Android und Xamarin.iOS. Mit deren Hilfe lassen sich alle nativen API-Funktionen mit C# aufrufen. Zusätzlich wird noch die Komponente Xamarin.Mac angeboten, die die Erstellung von Mac-Desktop-Anwendungen und ihre Veröffentlichung im AppStore ermöglicht. Alle Xamarin-Anwendungen benutzen eine umfassende Kollektion vorhandener Basisklassen, die üblicherweise mit dem Begriff Base Class Library (BCL) bezeichnet wird. Mit Hilfe dieser.net- Klassen lassen sich zahlreiche Funktionen, wie z.b. Bearbeitung von XML-Dokumenten, Manipulation von relationalen Datenbanken, Netzwerkkommunikation und Serialisierung realisieren. Zusätzlich werden Mechanismen zur Integration von externen Objective-C- oder Java-Bibliotheken angeboten. Auf diese Weise kann vorhandener Code schnell integriert und benutzt werden. Hier ist zu beachten, dass existierende Bibliotheken nicht plattformübergreifend eingesetzt werden können, d.h. Xamarin.Android unterstützt nur Java und Xamarin.iOS nur Objective-C. Als Entwicklungsumgebung wird das Xamarin Studio angeboten, wobei es sowohl als eigenständiges Programm für Mac und Windows als auch in Form eines Plugins für Visual Studio erhältlich ist. Mit Xamarin Studio können ios- und Android-Anwendungen hergestellt werden. Hier existieren auch einige Restriktionen, die von den Anforderungen der unterschiedlichen Hersteller vorgegeben sind. Das Kompilieren von ios- oder Mac-Projekten benötigt einen Mac mit installiertem ios-sdk und Xcode. Das gleiche gilt auch für die Benutzung des ios-simulators, der nur für Apple-Produkte angeboten wird. Die Entwicklung windows-basierter Anwendungen dagegen ist unter Windows und nur mit Visual Studio möglich. Das macht die plattformübergreifende Entwicklung umständlicher, weil mehrere Rechner gebraucht werden. Um diese Komplikation zu umgehen wird ein zusätzlicher Cloud-Dienst namens Xamarin TestCloud angeboten, der die Plattformunterschiede abstrahiert und das Testen von Anwendungen auf mehreren hundert reellen Geräten ermöglicht. Der Dienst befindet sich zur Zeit der Erstellung dieser Arbeit noch in der Entwicklung und ist nur für registrierte Nutzer teilweise zugänglich. Die eigenständige Version des Xamarin Studios ist kostenlos. Die kommerziellen Produkte sind die plattformspezifischen Bibliotheken - Xamarin.iOS, Xamarin.Android und Xamarin.Mac. Die jährlichen Lizenzkosten pro Plattform und pro Entwickler beginnen ab 299$. Das ist die so genannte 35

36 Kategorie Indie, die nur für selbständige Entwickler und kleine Unternehmen (bis fünf Mitarbeiter) verfügbar ist. Mit dieser Preisoption ist es allerdings nicht möglich das Visual Studio Plugin zu benutzen. Für größere Unternehmen und Organisationen existieren zwei anderen Lizenzen - Business und Enterprise, die jeweils jährlich pro Plattform und pro Entwickler gelten. Die Business-Option bietet für 999$ sowohl die Benutzung von Visual Studio als Entwicklungsumgebung als auch zusätzliche Optionen wie Headless-Builds, WCF-Unterstützung (Windows Communication Foundation) und -Support. Ein Headless-Build ermöglicht das Packaging eines Projekts ohne das Starten der Entwicklungsumgebung. Somit lassen sich Projekte ferngesteuert kompilieren und testen. Die teuerste Lizenz - Enterprise - kostet 1899$. Dabei enthält sie alle davor beschriebenen Funkionen, eine Kick-Off Schulung von einem Xamarin-Experten, 500$ Guthaben für Komponenten im Xamarin-Store und andere Unterstützungsleistungen. 4.2 Xamarin Studio Xamarin Studio ist ein modernes IDE, das auf dem Programm MonoDevelop basiert. MonoDevelop ist eine Entwicklungsumgebung, die die Erstellung von Desktopanwendungen mit Hilfe des Mono- Frameworks ermöglicht. Beide Programme sind sehr ähnlich und enthalten teilweise gleiche Funktionen. Xamarin Studio ist aber speziell für Android und ios angepasst. Ein Bild des Studios kann im Anhang B gefunden werden. Der komplexe Text-Editor entspricht dem neuesten Standard und bietet viele Funktionen an. Quelldaten lassen sich in verschiedenen Tabs öffnen. Es werden sowohl Syntaxhervorhebung als auch Code-Completion angeboten. Für eine bequeme Navigation im Quellcode gibt es Funktionen zum Öffnen der entsprechenden Klasse oder Methode (wie in Eclipse). Mit Hilfe des Breadcrumb-Menus (Abbildung 15) lassen sich alle Methoden einer Klasse übersichtlich darstellen und untersuchen. Abbildung 15: Breadcrumb Menus Verschiedene Tooltips geben zusätzliche Informationen über Codeelemente. Eclipse-ähnliche Refactoring- Funkionen wie das Umbenennen von Variablen und Methoden, die Erstellung von Getter-und Settermethoden der Klassenfelder sind auch integriert. Weitere Features sind die automatische Quellcodeformatierung und die editierbaren Code-Templates. Verschiedene Versionsverwaltungssysteme wie GIT und SVN können in beliebigen Projekten verwendet werden. Integration von ios und Android Plattformen ist im Xamarin Studio vollständig realisiert. Im Fall von Android muss die SDK-Position auf der Festplatte in den Eigenschaften eingegeben werden. Sobald das gemacht wird, werden alle installierten Android-Versionen und alle Emulatoren erkannt. Das Android-Log vom DDMS kann direkt vom dem Programm untersucht werden. Alle mit dem Entwicklungsrechner verbundenen Geräte werden automatisch erkannt und können auch für das Debugging benutzt werden. Xamarin bietet auch einen eigenen Designer für Android-Layouts (Anhang B). Projekteigenschaften lassen sich nicht nur über manuelle Manipulation der XML-basierten Manifest-Datei, sondern auch über eine bequeme formularbasierte Ansicht editieren (Anhang B). ios-entwicklung wird mittels einer Integration mit Xcode realisiert. Xamarin Studio übernimmt automatisch alle Einstellungen vom Xcode und kann eigenständig die verschiedenen ios-simulatoren 36

37 verwenden. Um reelle Geräte zu benutzen, muss zusätzlich das Apple-Developer-Konto eingegeben werden. Die Manipulation der ios-layoutdateien (XIB-Dateien) erfolgt über Xcode. Um das notwendige Umschalten zwischen den beiden Programmen möglichst bequem zu realisieren, kann Xcode automatisch vom Xamarin Studio gestartet und gesteuert werden. Dabei werden die geöffneten Dateien beim Speichern synchronisiert. 4.3 Code-sharing-relevante Funktionen in C# Obwohl die Vorstellung der Funktionen verschiedener Programmiersprachen nicht das Ziel dieser Arbeit ist, werden in diesem Abschnitt einige Informationen über die Entwicklungssprache C# gegeben, weil sie für das Verstehen einiger Code-Sharing-Strategien erforderlich sind Konditionale Kompilierung Mit Hilfe von speziellen Präprozessordirektiven in C# [21] wird dem Entwickler die Möglichkeit gegeben, Anteile des Quellcodes in bestimmten Fällen zum Buildprozess hinzuzufügen oder aus dem Buildprozess auszunehmen. So kann man verschiedene Plattformen im Code unterscheiden und sicherstellten, dass die Kompilierung der plattformabhängigen Aktionen fehlerfrei abläuft. Die Xamarin.Android stellt standardmäßig eine Reihe von Symbolen zur Verfügung, die benutzt werden können. Das globale Symbol für Android ist ANDROID. Die Abbildung 16 stellt ein einfaches Beispiel dar. Man kann auch spezifische Androidversionen gezielt ansprechen - z.b. mit ANDRO- ID_19 wird geprüft, ob es sich um die neueste API Version namens KitKat handelt (KitKat ist zur Zeit des Schreibens dieser Arbeit die aktuellste Version). Windows Phone bietet die Symbole WINDOWS_PHONE und SILVERLIGHT an. Obwohl Xamarin.iOS keine Symbole zur Verfügung stellt, ist es mit if-else Direktiven möglich, die Kompilierung für iphone oder ipad zu erkennen. Abbildung 16: Konditionale Kompilierung in C# Partielle Klassen und Methoden In C# ist es möglich, Klassen- oder Methodendefinitionen in verschiedene Dateien aufzuteilen. So kann beispielsweise eine Klasse A in Dateien A.cs und A.extra.cs definiert werden. Dieser Fall ist in der Abbildung 17 dargestellt. Klassenmethoden können auch als partiell definiert werden (Abbildung 18). Alle partiellen Methoden müssen void als Rückgabewert haben. Sie können innerhalb anderer Methoden benutzt werden. Falls keine Definition innerhalb anderer Dateien gefunden wurde, wird die Methode als eine leere Methode vom Compiler interpretiert. Das kann sehr nützlich in verschiedenen Fällen sein. Beispielsweise während des Entwicklungsprozesses ist es wünschenswert, verschiedene Informationen mit Hilfe eines Loggers speichern zu können, um später den Ablauf zu analysieren und Fehler zu beheben. Diese Funktionen sind aber in der Produktionsumgebung nicht notwendig und sollen rausgenommen werden, da sie zusätzlich die CPU belasten. Mit Hilfe von partiellen Elementen lässt sich das sehr einfach 37

38 Abbildung 17: Partielle Klasse in C# erreichen indem die Datei, in der die Implementierung der partiellen Methode liegt, einfach aus dem Projekt entfernt wird. Abbildung 18: Partielle Methode in C# Events und Delegates Events und Delegates integrieren das bekannte Entwurfsmuster Observer [23] in die C# Programmiersprache. In C# kann jede Klasse eigene Ereignisse definieren und sich für Ereignisse anderer Klassen registrieren. Wenn eine Klasse ein Ereignis erzeugt, werden alle registrierten Klassen darüber informiert. Mit Hilfe dieser Eigenschaft lassen sich Anwendungsteile entkoppeln, was die Wiederverwendbarkeit und Austauschbarkeit der Komponenten ermöglicht. Das Muster wird oft für die Trennung der Komponenten, die Benutzeroberflächenelemente definieren, von der Anwendungslogik benutzt Portable Class Libraries Die wichtigste Eigenschaft der plattformübergreifenden Entwicklungsansätze ist die Möglichkeit, Quellcode für verschiedene plattformspezifische Projekte freizugeben. Mit dem.net-framework ist das nicht immer einfach, weil verschiedene Plattformen oft unterschiedliche Teilmengen der.net-bibliotheken benutzen. Wenn man z.b. ein Projekt oder eine normale Bibliothek erstellt, lässt sich die kompilierte DLL-Datei nur von der selektierten Plattform ausführen. Somit ist es nicht möglich, windowsbasierte Projekte in Xamarin.Android oder Xamarin.iOS zu benutzen. Diese Einschränkungen können mit Hilfe der Portable Class Libraries (PCL) umgangen werden. PCLs sind plattformübergreifende Bibliotheken [24], die nur die Klassen, die innerhalb aller spezifizierten Zielplattformen enthalten sind, benutzen können. Sowohl Xamarin Studio als auch Visual Studio ermöglichen die Erstellung von 38

39 PCLs. Die Plattformunterstützung ist in der Abbildung 19 dargestellt. Dabei ist zu beachten, dass je mehr Plattformen ausgewählt werden, desto weniger.net-klassen in diesem Projekt benutzt werden können. Abbildung 19: Eingenschaften plattformübergreifender Bibliotheken 4.4 Allgemeine Code-Sharing Strategien Nach der Beschreibung der Funktionsweise des Xamarin-Frameworks, der Einführung in das Xamarin Studio und der Vorstellung einiger speziellen C# Features werden in diesem Abschnitt allgemeine Strategien beschrieben, die Code-Sharing zwischen verschiedenen Plattformen ermöglichen. Zuerst werden die globale Mechanismen beschrieben, die das gemeinsame Benutzung von Quellcode zwischen verschiedenen Projekten ermöglichen. Um diese möglichst effektiv anzuwenden, werden danach die Kernpunkte des Architekturdesigns eines Cross-Plattform-Projekts mit Xamarin eingeführt Globale Code-Sharing Mechanismen Grundsätzlich wird Code-Sharing in Xamarin mittels zweier Technologien erreicht: 1. Portable Class Libraries DemoApp.iOS DemoApp.Droid DemoApp.WP8 2. File-Linking Portable Class Libraries wurden im Kapitel beschrieben und werden hier nicht weiter betrachtet. Ihr größter Nachteil - die eingeschränkte Benutzung der.net Klassen lässt sich mittels File Linking umgehen. Mit File- Linking bezeichnet man die symbolische Verlinkung zu externen Dateien innerhalb eines Projekts. Die verlinkten Dateien werden bei der Kompilierung in das Projekt integriert. Auf diese Weise ist es möglich, Anwendungskomponenten auszulagern und diese dann innerhalb verschiedener SQLite-NET ios SQLite-NET Android DemoApp.DB SQLite-NET WP8 Abbildung 20: Beispiel File-Linking 39

40 Projekte zu nutzen. Die dabei entstehenden plattformspezifischen Abhängigkeiten können mittels der Konditionalen Kompilierung und der partiellen Klassen und Methoden aufgelöst werden. Alternativ dazu bietet sich die Benutzung von verschiedenen Entwurfsmustern an, die der Entkopplung von Komponenten dienen. Einige davon sind z.b. Bridge, Observer und Abstract Factory [23]. Diese Methode ist aber aufwendiger, weil dabei mehrere neue Klassen und Schnittstellen entstehen. Das resultiert in höheren Overhead und macht die Struktur der Anwendung komplizierter. Die Abbildung 20 demonstriert ein einfaches Beispiel für File-Linking. Aufgrung der spezifischen Plattformeigenschaften können SQLite-NET Klassen nicht in eine Portable Class Library gepackt werden. Es existieren für jede Plattform eigene Implementierungen, die die gleichen Schnittstellen anbieten. Um Code-Sharing für alle Datenzugriffe zu ermöglichen, werden alle zuständige Klassen in einem externen Ordner (DemoApp.DB) gespeichert und können dann in verschiedenen Projekten verwendet werden Cross-Plattform Anwedungsstruktur Alle Xamarin Projekte benutzen das Format SLN, das mit Visual Studio kompatibel ist. Diese Dateien werden Solutions (Lösungen) genannt und können mehrere sowohl plattformabhängige als auch plattformunabhängige Projekte beinhalten. Es ist z.b. möglich, innerhalb einer Solution, Projekte für Android, ios, Windows Phone und PCLs zu erstellen. Diese können dann getrennt voneinander kompiliert und eingesetzt werden. Es ist auch erlaubt, ganze Projekte als Bibliotheken oder Dateien eines Projekts in anderen Projekten zu verwenden. Um Code-Sharing zwischen plattformspezifischen Projekten zu ermöglichen, ist es nützlich, die unabhängigen Teile der Anwendung in separaten Projekten zu trennen. Auf diese Weise entstehen getrennte Module, die dann beliebig kombiniert werden können. Die Abbildung 21 zeigt die allgemeine Struktur einer plattformübergreifenden Solution für ios, Android und Windows Phone. ios Application Android Application WP8 Application ios UI, platform-specific code Android UI, platform-specific code Windws Phone 8 UI, platform-specific code Core Libraries (File Linking) Portable Class Libraries Abbildung 21: Allgemeine Struktur einer Cross-Plattform Xamarin Solution Jede Plattform braucht ein eigenes Projekt, in dem die spezifischen Benutzeroberflächen definiert werden. Hier müssen auch andere gerätespezifischen Funktionen implementiert werden. Plattformübergreifende Anwendungskomponente lassen sich getrennt davon definieren. Das können einerseits 40

41 verschiedene Portable Class Libraries sein. Andererseits sind das alle Funkionen, die mittels File- Linking realisiert werden. 4.5 Implementierung und Integration der Anwendungsfunktionen In diesem Abschnitt werden alle Funktionen, die für die MobiKat-App relevant sind, auf Cross- Plattform-Kompatibilität untersucht. Die Ergebnisse dieser Untersuchung werden dann für die Spezifikation der detaillierten Struktur der MobiKat-App verwendet MobiKat SOAP-Dienste Abbildung 22: Plattformübergreifende Kommunikation mit dem MobiKat-SOAP-Dienst SOAP-Dienste der Version 1.1 werden sowohl von Xamarin Studio als auch von Visual Studio unterstützt. Beide Entwicklungsumgebungen bieten eine automatische Erstellung eines Proxys, das für Dienstaufrufe benutzt werden kann. Das Proxy besteht aus C#-Klassen, die sowohl die Dienstoperationen, als auch die Dienstdatentypen abbilden. Aufgrund einiger plattformspezifischer Abhängigkeiten, lassen sich SOAP-Service-Proxies nicht in eine Portable Class Library (PCL) integrieren. Um die Dienste innerhalb von Android, ios und Windows Phone benutzen zu können, ist es deswegen notwendig, das Proxy einzeln für jede Plattform zu generieren. Als Ergebnis bekommt man die gleichen Schnittstellen, die plattformübergreifend mittels der File-Linking Methode angesprochen werden können. Um eine gemeinsame Nutzung mit einer verlinkten Datei zu gewährleisten, müssen je 41

42 nach Plattform die unterschiedlichen Proxy-Klassen importiert werden. Diese Fallunterscheidung lässt sich mit einigen konditionalen Kompilierungsbefehlen erreichen. Die Abbildung 22 veranschaulicht die plattformübergreifende Importierung der generierten MobiKat-Zugriffsklassen. Mit der dargestellten Klasse MobiKatServiceWrapper wurden die Routenberechnungsfunktionen von MobiKat in Form von statischen Methoden für alle Plattformen zur Verfügung gestellt. Mit Hilfe dieser Klasse wurde auch die Integration des SOAP-Dienstes getestet. Für die Nutzung der Routeninformationen war eine zusätzliche Transformation der Daten notwendig. Die Koordinaten werden im Format WKT (Well- Known Text) übertragen. WKT ist eine Sprache, die speziell für die Darstellung von geometrischen Daten entwickelt worden ist [31]. Aufgrund der einfachen Struktur des Formats wurde eine zusätzliche Komponente für das Parsen der Routeninformationen erstellt. Diese wurde in eine Portable Class Library - MobikatDemo.Utils gepackt REST-basierte Kommunikaton Im Rahmen der Belegarbeit [6] wurde das MobiKat System mit einem Modul für die Lokalisierung und Koordination von mobilen Einsatzkräften erweitert. Aufgrund der einfacheren Struktur und der Unabhängigkeit vom XML wurde das Modul als ein REST-basierter Dienst realisiert. Die Kommunikation erfolgt über das HTTP Protokoll mittels JSON-formatierter Nachrichten. Um eine plattformübergreifende Verbindung mit dem Dienst zu realisieren, sollte die existierende Java-Implementierung in C# übersetzt werden. Allgemein existieren für die HTTP-Kommunikation in.net folgende Methoden: HttpWebRequest / WebClient - die Grundklassen des.net-frameworks, mit deren Hilfe man Kommunikation über HTTP realisieren kann. Die Klassen bieten keine automatische Verarbeitung von Nachrichten jeglicher Art. RestSharp [25] - eine Bibliothek, die sowohl einfache als auch komplexe HTTP Anfragen unterstützt. Mit Hilfe von RestSharp lassen sich sowohl textbasierte, als auch binäre Daten verarbeiten. Die Komponente unterstützt auch erweiterte Authentifizierungsstandards wie OAuth. Zusätzlich wird eine Transformation aller Kommunikationsnachrichten in C#-Objekte angeboten. Mit Hilfe dieser Funktion können alle XML- oder JSON-Nachrichten als C#-Klassen in der Anwendung benutzt werden. Hammock [26] - RestSharp-ähnliche Bibliothek, die auch komplexe HTTP-Anfragen unterstützt. ServiceStack [27] - ein kommerzielles Produkt, das Anwendungsentwicklung nach dem SOA- Modell (Service Oriented Architecture) anbietet. Das Produkt besteht aus mehreren optimierten Komponenten, die miteinander verbunden werden können. Im Mittelpunkt stehen dabei die Technologien von Microsoft. Die Grundklassen des.net-frameworks sind plattformübergreifend und weisen keine Abhängigkeiten zu anderen Bibliotheken auf. Die Klassen erlauben eine beliebige Modifikation der HTTP- Nachrichten. Die Verarbeitung der Nachrichten soll aber in diesem Fall manuell programmiert werden, was den Umsetzungsaufwand wesentlich erhöht. RestSharp, Hammock und ServiceStack übernehmen die Nachtichtenverarbeitung und sorgen dafür, die Nachrichten in dem gewünschten Format zur Verfügung zu stellen. Um diese Funktionen zu erreichen, sind diese Bibliotheken von einigen plattformspezifischen Eigenschaften abhängig, was ihre Benutzung innerhalb von PCLs verbietet. Für jedes Betriebssystem existierten aber kompatible Versionen, die einheitliche Schnittstellen zur Verfügung stellen. Mit Hilfe dieser Schnittstellen lässt sich eine plattformübergreifende Nutzung mit der File- Linking Methode umsetzen. Die REST-basierten Dienste zur Kommunikation und Lokalisierung sind JSON-formatiert. Aus diesem Grund bietet sich die Nutzung von Bibliotheken, die einen JSON-Parser enthalten und eine 42

43 Abbildung 23: C# Code-Generierung aus einer MobiKat-JSON-Nachricht automatische Umwandlung der Nachrichten in C#-Klassen durchführen, an. Das sind eigentlich alle oben beschriebenen Methoden außer den Basisklassen des.net-frameworks. ServiceStack wird aufgrund der zusätzlichen Nutzungskosten nicht weiter betrachtet. Somit bleiben für die Umsetzung der Kommunikation mit dem Java-Servlet entweder RestSharp oder Hammock. Beide Frameworks bieten die gleichen Funktionen und sind ähnlich aufgebaut. Aufgrund der umfangreicheren Dokumentation und der größeren Anzahl der Nutzer im GitHub wurde für diese Arbeit RestSharp ausgewählt. Mit Hilfe von RestSharp können JSON-Nachrichten automatisch in C#-Klassen umgewandelt werden. Das macht die Berarbeitung der Kommunikation zwischen dem Klient und dem Server viel einfacher. Um diese Funktion zu nutzen, müssen die Klassen, die die einzelnen Nachrichtenobjekte repräsentieren, erstellt werden. Mit Hilfe von Tools wie json2csharp lassen sich anhand der JSON-Nachrichten automatisch die entsprechenden C#-Wrapperklassen generieren [28]. Ein Beispiel wird in Abbildung 22 präsentiert. Dabei wurde eine JSON-basierte Nachricht des MobiKat Lokalisierung- und Nachrichtenverwaltungsdienstes benutzt (linker Teil der Abbildung). Die generierten C#-Strukturen sind auf der rechten Seite der Abbildung zusehen. Dabei werden alle Datentypen korrekt abgebildet. Mit nur wenigen zusätzlichen Bearbeitungsschritten wurden alle Datenstrukturen der Kommunikation erstellt und konnten für die weitere Entwicklung benutzt werden. Wie im Fall der existierenden Android-App, wurde die ganze Logik der Kommunikation in eine Klasse namens MobiKatMessenger integriert. Die Kommunikation mit dem Server wurde in allen Plattformen getestet. Alle Kommunikationsarten wurden plattformunabhängig implementiert. Nur bei einem Dateiversand sind die Pfadunterschiede der Dateien einzelner Plattformen zu beachten. Diese werden detailliert im Kapitel beschrieben Kartenintegration Wie im Kapitel 3.2 gezeigt sind HTML-basierte Karten für die mobile Version von MobiKat nicht geeignet. Aus diesem Grund sollen für die Darstellung aller geographischen Informationen die plattformabhängigen Karten der Plattformen Android, ios und Windows Phone verwendet werden. Dabei können für Android und ios die von Xamarin angebotenen Wrapperklassen benutzt werden. Für Windows Phone lassen sich die nativen Bing Maps benutzen. Alle ermöglichen sowohl die programmatische Änderung der Kartenansicht als auch die Manipulation von verschiedenen Kartenoverlays in Form von Markern, Linien und Flächen. Für ios und Windows Phone werden keine zusätzliche 43

44 Einstellungen für die Benutzung der Kartenkomponenten gebraucht. Im Fall von Android wird ein spezieller Schlüssel benötigt, der mit Hilfe eines Android-Signierungszertifikats erstellt werden kann. Seit der Version 2 haben die Google Maps eine zusätzliche Abhängigkeit von den Google Play Services. Der detaillierte Prozess der Einstellung wird in [29] beschrieben Geolocation Mit Xamarin kann für die Geolocation die Komponente Xamarin.Mobile benutzt werden. Xamarin.Mobile ist eine Bibliothek, die einheitliche Schnittstellen für den Zugriff auf die im Gerät gespeicherten Kontakte, GPS-Daten und die Kamera bietet. Der aktuelle Ort des Geräts kann mit Hilfe der Klasse Geolocator ausgelesen werden. Plattformspezifische Implementierungen der Positionsdaten, Fehlerbehandlung und verschiedener Ereignisse werden von der Bibliothek abstahiert und mittels eigener Klassen für eine plattformübergreifende Nutzung zur Verfügung gestellt. Die Abbildung 24 demonstriert das Verfolgen von Positionsänderungen. Die Methode Setup erstellt eine Instanz der Geolocator-Klasse und registriert eine EventListener-Methode, die Änderungen der Position verarbeitet. Wenn die Methoden direkt die GUI benutzen, können sie als partiell definiert werden, um spezifische Aktionen in ios, Android und WindowsPhone durchzuführen. Abbildung 24: Verarbeitung der Positionsänderung mittels Xamarin.Mobile Datenbank Die mobile Version von MobiKat soll in der Lage sein, verschiedene Anwendungsdaten lokal zu speichern. Beispielsweise können das empfangene oder verschickte Nachrichten, wichtige Orte oder Routen sein. Um diese Daten strukturiert und effektiv darzustellen und zu verarbeiten, bietet sich die Benutzung einer relationalen Datenbank. Die populärste plattformübergreifende relationale mobile Datenbank ist SQLite. SQLite ist eine Open-Source Datenbank-Engine, die speziell für mobile Geräte erstellt wurde. Im Gegensatz zu Datenbanksystemen wie MySQL oder PostgreSQL benötigt SQLite keine weiteren Server-Installationen. SQLite wurde sowohl von Apple als auch von Google in ihren mobilen Plattformen ios und Android integriert. Obwohl sie in den Windows-Plattformen nicht vorhanden ist, existieren kompatible Portierungen, die als externe Bibliotheken benutzt werden können. Eine SQLite-Datenbank kann durch C# auf zwei verschiedenen Arten manipuliert werden. Einerseits existieren Schnittstellen, die ähnlich den ADO.NET-Klassen aufgebaut sind, andererseits können die zusätzlichen Bibliotheken SQLite.NET-ORM benutzt werden. ADO.NET ist in Xamarin.Android und Xamarin.iOS integriert, kann aber unter Windows nicht verwendet werden. Aus diesem Grund 44

45 Abbildung 25: Ausschnitt aus der Klasse Route wurde die Umsetzung der MobiKat Datenbank mit SQLite.NET-ORM getestet. Wie RestSharp ist SQLite.NET-ORM in Form von plattformspezifischen Bibliotheken verfügbar, die einhetliche Schnittstellen anbieten. Die einzige mögliche Integrationsmethode ist File-Linking. Mit SQLite.NET-ORM kann die Datenbank ohne SQL-Befehle kontaktiert werden. Die Dateneinheiten werden von speziellen Klassen mit Hilfe von Attributen spezifiziert. Die Umwandlung wird dann automatisch vom Framework übernommen. Für einfachere Aktionen existieren die folgenden Methoden: Insert - zum Hinzufügen neuer Objekte Get - zum Abruf existierender Objekte Table - zum Abruf aller Objekte einer Tabelle Delete - zum Löschen der Objekte Komplexere Anfragen können mit den Methoden Query und Execute definiert werden. Dabei können beliebige SQL-Befehle durchgeführt werden. Alle Methoden konvertieren die zurückgegebenen Daten in C#-Klassen oder Sammlungen (Collections) von Klassen. Sammlungen lassen sich weiter bequem mit den LINQ-Eigenschaften der Programmiersprache C# filtern oder sortieren. Für das Testen der SQLite.NET-Bibliothek wurde eine einfache Datenbank zum Speichern der Routen erstellt. Hier wurden genau das Routenszenario ausgewählt, damit später die Integration der Datenbank mit der erstellten SOAP-Dienst-Komponente getestet werden kann. Ein Teil der Klasse Route ist in der Abbildung 25 vorgestellt. Wie zu sehen ist, sind die Datenmodelle ganz normale C#- Klassen. Alle SQLite-relevanten Felder können mit Hilfe von Attributen spezifiziert werden. Bei der Nutzung von SQLite.NET ist zu beachten, dass alle Klassenfelder, die als public definiert sind, automatisch als Datenbankfelder interpretiert werden. Mit dem Attribut Ignore kann dieses Verhalten 45

46 Client RouteManager (Facade) +getroutes() : List<Route> +getroutedescription(string id) : List<RouteDescription>... RouteDatabase (SQLite.NET-ORM) ADO.NET Database XMLDatabase +getroutes() : List<Route>... Abbildung 26: Datenbankabstraktion mit dem Entwurfsmuster Facade verhindert werden. Es ist ganz praktisch, alle Operationen, die mit der Verarbeitung der Datenmodelle verbunden sind, in einer Klasse zu definieren. Auf diese Weise können diese Komponenten als eigenständige Module von verschiedenen Plattformen oder Anwendungen benutzt werden. SQLite-Datenbanken benutzen eine einzige Datei zum Speichern aller Tabellen. In Rahmen dieser Arbeit wurde die Datenbank in eine lokale Datei - MobikatDemo.db3 - gespeichert. Die plattformspezifischen Unterschiede in der Arbeitsweise mit den lokalen Dateisystemen sind im Abschnitt beschrieben und werden hier nicht weiter betrachtet. Obwohl für diese Arbeit SQLite.NET-ORM für Zugriff auf die Datenbank ausgewählt wurde, ist es sinnvoll eine zusätzliche Komponente zu erstellen, die den genauen Aufbau der Daten versteckt und nur die benötigten Schnittstellen zum Aufrufen bietet. Dafür kann das bekannte Muster Facade benutzt werden [23]. Die Umsetzung des Musters in dieser Arbeit ist in der Abbildung 26 dargestellt. Die Klasse RouteManager spielt die Rolle einer Fassade und kümmert sich um die Verarbeitung der Anfragen der Klienten. Auf diese Weise können Datenbankimplementierungen flexibel umgetauscht werden Lokale Dateizugriffe Auf lokale Daten können mit den Basisklassen des.net-frameworks unter dem Namensraum System.IO zugegriffen werden. Für die Dateimanipulation kann die Klasse File verwendet werden. Mit deren Hilfe können Dateien erstellt, gelöscht und kopiert werden. Zusätzlich werden Funktionen zum Auslesen der Dateiinhalte angeboten. Die Klasse Directory ist für die Manipulation der Ordnerstruktur zuständig. Mit Hilfe der Subklassen der Klasse Stream können erweiterte Aktionen wie eine Kompression oder Verschlüsselung durchgeführt werden. Obwohl Dateien einheitlich in allen Plattformen verarbeitet werden können, müssen bei einer plattformübergreifenden Nutzung die Zugriffsrestriktionen der einzelnen Plattformen betrachtet werden. Für Android und ios wird dafür die Klasse System.Environment angeboten. Mit dieser Klasse können die internen Ordner einer Android- oder ios-anwendung mit dem gleichen Code zurückgegeben werden. Mit dem genauen Pfad der App können beliebige Aktionen mit den System.IO-Klassen durchgeführt werden. Unter Windows ist die Environment Klasse nicht verfügbar. Die Dateien müssen relativ definiert werden. Das Betriebssystem findet dann diese automatisch im Root-Ordner der Anwendung. Für einen plattformübergreifenden Zugriff auf Anwendungsdateien müssen zwei Fälle unterschieden werden. Einerseits sind das die relativ spezifizierten Windows-Dateien und andererseits die mit Hilfe der Klasse Environment gewonnenen globalen Dateipfade bei Android und ios. Diese Fallunterscheidung ist in 46

47 der Abbildung 27 demonstriert. Abbildung 27: Plattformübergreifender Dateizugriff Hier wird der Position der Datenbankdatei plattformübergreifend ermittelt. Die Fallunterscheidung wird mit Hilfe von Präprozessordirektiven deklariert. Die Datenbank wurde in dieser Arbeit im Root-Ordner der Anwendungen gespeichert. Im Fall von Windows ist nur die Eingabe des Namens notwendig. Unter Android und ios muss der Name der Datei mit der globalen Position des Anwendungsordners konkateniert werden. Dafür kann die Klasse Path benutzt werden, die verschiedene Methoden für Bearbeitung von Dateinamen anbietet Benutzung der Kamera Für eine plattformübergreifende Benutzung der Kamera kann die Bibliothek Xamarin.Mobile benutzt werden. Diese Komponente wurde kurz im Abschnitt vorgestellt. Mit Hilfe der Klasse Media- Picker können Photos und Videos sowohl von der Kamera als auch von den im Gerät gespeicherten Medien erhalten. Bei der Verwendung der Klasse müssen einige plattformspezifische Eigenschaften beachtet werden. Mit Hilfe der Klasse können nur die Aufnahme- oder Zugriffsvorgänge gestartet werden. Die Ergebnisse müssen dann in jeder Plattform unterschiedlich bearbeitet werden. In Android wird ein ActivityResult zurückgegeben, in dem die genaue Position der Datei im Gerät gespeichert ist. In ios werden vom MediaPicker Instanzen der entsprechenden ViewController erstellt, die dann weitere Verarbeitung der Daten ermöglichen. Unter Windows können mittels asynchroner Operationen die zurückgegebenen Dateien verarbeitet werden. Im Fall eines Abbruchs oder Fehlers werden verschiedene Exceptions ausgegeben Benutzung des Mikrofons Für die Benutzung des Mikrofons existieren keine plattformübergreifenden Bibliotheken. Aus diesem Grund müssen für jede Plattform einzelne Lösungen umgesetzt werden. Aufgrund von Restriktionen der ios- und Windows-Emulatoren, die die Simulation des Mikrofons nicht unterstützen, wurde diese Funktion in Rahmen dieser Arbeit nicht getestet. Das zur Verfügung gestellte Windows-Gerät konnte wegen des fehlenden DreamSpark-Kontos nicht verwendet werden. Das ios-testgerät, ein ipad Mini, konnte auch nicht verwendet werden. Obwohl eine akademische Lizenz von der TU Dresden benutzt werden konnte, erlaubt die Trial Version von Xamarin Studio das Testen mit reellen Geräten nur für 24 Stunden. Aufgrund der entstandenen Probleme, die später im Kapitel 5 beschrieben werden, konnte das Gerät daher nicht benutzt werden. 47

48 4.6 Detaillierte Entwicklungsmethodik Durch Auswerung der Ergebnisse der Implementierung der einzelnen Funktionen ist es möglich ihre Integration in das im Abschnitt vorgestellte globale plattformübergreifende Anwendungsstruktur einzuordnen. So entsteht die in der Abbildung 28 dargestellte Architektur. MobiKat.iOS ios UI, platform-specific code ios Mobikat Web Service Bindings ios RestSharp ios Xamarin.Mobile ios SQLite.NET-ORM Mobikat.Android Android UI, platform-specific code Android UI, platform-specific Android Mobikat code Web Service Bindings Adnroid RestSharp Android Xamarin.Mobile Android SQLite.NET-ORM MobiKat.WP8 WP8 UI, platform-specific code WP8 Mobikat Web Service Bindings WP8 RestSharp WP8 Xamarin.Mobile WP8 SQLite.NET-ORM Core Libraries Service Access Layer Data Access Layer Business Logic Layer Data Layer Portable Class Libraries MobiKat Utilities Abbildung 28: Detailliertes Konzept der MobiKat-App Die gerätespezifischen Komponenten sind für jede Plattform in einzelnen Projekten dargestellt. In diesen Projekten müssen alle Elemente der Benutzeroberfläche mit den nativen APIs implementiert werden. Von zentraler Bedeutung sind im MobiKat die Kartenansichten, die nicht plattformübergreifend umgesetzt werden können. Code-Sharing für diese Komponenten lässt sich nur mit Hilfe von Design Patterns erreichen. Beispielsweise können die globalen Funktionen wie z.b. die Darstellung einer Route mit Hilfe von Interfaces definiert werden. Diese Interfaces sind dann in jeder App unterschiedlich zu implementieren. Allgemeine Ereignisse können auch global in Form von Events und Delegates dargestellt werden. Die Behandlung dieser Ereignisse kann dann plattformspezifisch mit partiellen Methoden oder mit Präprozessordirektiven implementiert werden. Plattformunabhängig können alle Datenmodelle, Netzwerkzugriffe und die Business-Logik dargestellt werden. Bei der Testimplementierung der einzelnen Komponenten wurde festgestellt, dass keine der benötigten Hauptfunktionen in Portable Class Libraries integriert werden kann. Aufgrund der Abhängigkeiten von den gerätenspezifischen Funktionen müssen dafür die gerätespezifischen Bibliotheken, die einheitliche Schnittstellen für diese Funktionen zur Verfügung stellen, in jedes App- Projekt importiert werden. Das sind die ios-, Android-, und Windows-Versionen von SQLite.NET- 48

49 ORM, RestSharp, Xamarin.Mobile und die mit Hilfe der Entwicklungsumgebungen generierten SOAP- Dienst-Proxies. Der Code für ihre Benutzung kann mittels File-Linking in einem gemeinsamen Projekt - MobiKat.Core definiert werden. Dabei bietet sich die Aufteilung der Komponenten in verschiedene Schichten, die für verschiedene Funktionen zuständig sind an. Für die MobiKat-App können folgende Layers definiert werden: Data Layer (DL) - zuständig für die persistente Speicherung der Daten. In dieser Arbeit wurde diese als eine SQLite-Datei implementiert. Alternativ kann z.b. die Speicherung mittels XMLoder JSON-Dateien realisiert werden. Data Access Layer (DAL) - Facade um die Datenschicht, die Zugriffsmethoden für die benötigten Funktionen bietet. Diese Schicht entkoppelt die Implementierung der Datenschicht von den anderen Teilen der Anwendung. Business Layer (BL) - beinhaltet Businesslogik und Businessmodelldefinitionen der Anwendung. Hier werden alle Datentypen wie z.b. Route oder RouteDescription und die dafür relevanten Bearbeitungsfunktionen definiert. Service Access Layer (SAL) - diese Schicht enthält alle Klassen, die für Netzwerkkommukation jeglicher Art zuständig sind. In der MobiKat-App sind das einerseits die Klassen, die Aufrufe der SOAP-Dienst-Operationen ermöglichen. Andererseits ist das der MobiKatMessenger, der für die Kommunikation mit dem Java-Servlet verwendet werden kann. In dieser Arbeit konnten nur einige Hilfsfunktionen wie das Parsen von WKT-formatierten Geolocation- Daten in Form einer PCL implementiert werden. Diese ist unter dem Namen MobiKat Utilities in der Abbildung 28 dargestellt. 4.7 Prototypische Implementierung Um eine Evaluation der vorgestellten Entwicklungsmethodik zu ermöglichen und die realistisch erreichbaren Anteile des gemeinsam benutzten Codes einschätzen zu können, wurde in Rahmen dieser Arbeit ein Prototyp nach dem im vorherigen Abschnitt vorgestellten Konzept erstellt. Dabei wurden nicht alle beschriebenen Funktionen implementiert. Die Gründe dafür sind die aufwendige Darstellung von nativen Benutzeroberflächen und die beim Entwicklungsprozess entstandenen Probleme, die im Kapitel 5 beschrieben werden. Die umgesetzten Funktionen beschränken sich auf die Integration zwischen dem MobiKat-SOAP-Dienst, der Geolocation, der persistenen Speicherung der Daten und der Benutzung der nativen Kartenansichten. Als Anwendungsszenario wurde die Suche nach Wegen zwischen zwei Orten ausgewählt. Die zu entwickelnde App soll dem Benutzer Funktionen zur Auswahl des Start- und Zielorts für die gesuchte Route anbieten. Um möglichst schnell die gewünschte Positionen auswählen zu können, sollen Gesteninteraktionen verwendet werden. MobiKat liefert für jede Suchanfrage nicht nur geographische Daten über den Weg, sondern auch genaue Navigationsbeschreibungen. Während die geographischen Daten direkt auf der Karte dargestellt werden können, bietet sich für die zusätzlichen Beschreibungen eine textuelle Anzeige an. Diese kann beispielsweise mit einer Liste realisiert werden. Für einen schnellen Aufruf wichtiger Routen soll es möglich sein, die Routen lokal speichern zu können. Mit diesem Szenario kann sowohl die Integration zwischen den verschiedenen Schichten der Anwendung, als auch ein Hinweis über das erreichbare Code-Sharing bekommen werden. Obwohl die Funktionen nur einen kleinen Teil der Möglichkeiten des Systems testen, sind im beschriebenen Interaktionsprozess alle Applikationsschichten beteiligt. Die Verbindung zum SOAP-Dienst erfolgt über die Service-Access-Layer. Die für die Routensuche benötigten Datenmodelle werden in der Business- Logic-Schicht definiert. Die Data-Layer sorgt dafür, die Routeninformationen persistent im Speicher zu halten. Der Zugriff auf die gespeicherten Daten erfolgt dann über die Data-Access-Layer. Als 49

50 zentrale Komponente der MobiKat-App wird die Karte den größten Teil des plattformspezifischen Codes der Anwendung beeinflussen. Aus diesem Grund ist ihre Integration in den Prototypen für die Gewinnung realistischer Daten über Code-Sharing-Verhältnisse entscheidend. In der Regel wird für jede integrierte MobiKat-Funktion sowohl eine Bearbeitung mit den plattformübergreifenden Core- Libraries, als auch die entsprechende Kartenanzeige mit zusätzlichen UI-Elementen benötigt. Diese Zusammenhänge gelten auch für den ausgewählten Anwendungsfall, wodurch dieser sich für eine spätere Code-Sharing-Analyse eignet. Die Umsetzung der Apps kann allgemein in zwei Phasen aufgeteilt werden. Zuerst muss das plattformübergreifende Backend vorbereitet werden. Für die Präsentation und die Bearbeitung der Daten sollen dann GUIs einzeln für jede Plattform erstellt werden. Implementierung des plattformübergreifenden Backends Die Backend-Funktionen im Konzept entsprechen der sogenannten Core-Library mit ihren Unterschichten. Für ihre Umsetzung wurden die Ergebnisse aus dem Abschnitt 4.5 benutzt. Während des Testens der einzelnen Funktionen wurden die für das Anwendungsszenario passende Aktionen ausgewählt, was eine schnelle Integration der Komponenten ermöglichte. Die von der Klasse Mobikat- ServiceWrapper zurückgegebenen Routendaten wurden mit Hilfe einer einfachen Bearbeitung direkt in die entsprechende SQlite.NET-ORM-Klasse transformiert, was ihre Speicherung ermöglichte. Mit der im Abschnitt 4.5 erstellter Facade-Klasse RouteManager konnten die implementierten CRUD- Funktionen der Datenmodelle direkt verwendet werden. Implementierung der einzelnen Apps Für die Darstellung der Informationen wurden zunächst drei verschiedene Projekte für jede Plattform erstellt. Das Einbinden der Backendfunktionen wurde mittels File-Linking realisiert. Vom Anwendungsszenario können drei Hauptansichten für die Anwendungen definiert werden: Kartenansicht - Ansicht für die Darstellung der geographischen Informationen. Diese Komponente soll auch für die Eingabe des Start- und Zielorts für die gesuchten Wege sorgen. Routendatenansicht - hier sollen die detaillierten Navigationsbeschreibungen der einzelnen Routen dargestellt werden. Ansicht für die gespeicherten Daten - ermöglicht Auswahl und Bearbeitung der gespeicherten Daten. Die Abbildung 29 stellt die Struktur der implementierten Benutzeroberflächen dar. Einige Screenshots der Apps können im Anhang C angesehen werden. Auf ios wurden die drei Hauptansichten als UIViewController-basierte Klassen implementiert. Die Navigation zwischen den Controllern wird von einem UINavigationController gesteuert. Für die Navigation zwischen den Komponenten können sowohl die nativen Buttons der Navigationsleiste als auch zusätzliche Schaltflächen in der ios-werkzeugsleiste benutzt werden. Als Startansicht wurde die Kartenansicht ausgewählt. Für die Karte wird die native Map-Komponente in ios - die Klasse MKMapView benutzt. Die Definition einer Route erfolgt mittels Markern, die sich per Drag-and-Drop positionieren lassen. Um eine Route zwischen zwei Orten vom Server abzufragen kann eine Schaltfläche in der rechten Ecke der Navigationsleiste benutzt werden. Sobald der Server die Anfrage beantwortet, wird die Route mit Hilfe von Polygonlinien auf der Karte angezeigt. Die Schaltfläche ändert sich zu 50

51 ios UI UINavigationController Android UI MainActivity WP8 UI Pivot Control Map Screen Map Fragment Map Screen Route Details Screen Data Fragment Data Screen Data Screen Route Details Screen Abbildung 29: Struktur der Benutzeroberflächen einzelner Apps diesem Zeitpunkt automatisch und ermöglicht die Navigation zu der Routendatenansicht. Die Routendatenansicht ist in der Form einer Liste dargestellt. Diese wurde mit Hilfe der Klasse UITableView realisiert. Zusätzlich zu den einzelnen Navigationsbeschreibungen für die Route werden im oberen Bereich der Ansicht die Länge und die Dauer präsentiert. Hier kann auch die Route gespeichert werden. Dafür muss der dafür zuständige Button in der Navigationsleiste gedrückt werden und zusätzlich eine Bezeichnung eingeben werden. Die Ansicht der gespeicherten Daten kann von der Werkzeugleiste erreicht. Die Einträge werden in einer Liste dargestellt. Bei der Auswahl einer Route wird sie von der Datenbank geladen und auf der Karte angezeigt. Die Struktur der Android-Anwendung unterscheidet sich von der ios-app. Hier wurden nur zwei Hauptansichten benutzt. Die Detailansicht wurde als ein PopupView zugänglich gemacht. Die Hauptansichten sind in Form von Fragments implementiert, die in einzene Tabs von der für die Anwendung zuständige Activity dargestellt werden können. Die Navigation erfolgt über eine Tabanzeige, die in der Navigationsleiste positioniert ist. Das Kartenfragment beinhaltet nur die Kartenansicht. Wie bei ios kann man Routen mit Hilfe von Markern spezifizieren. Zusätzlich zu dem Drag-and-Drop Interaktion, können Positionen mit einem längeren Drücken auf der Karte spezifiziert werden. Dabei erscheint ein Popup, in dem verschiedene Platzierungsoptionen angeboten werden. Mit Hilfe von Menüoptionen in der Navigationsleiste lassen sich alle Funktionen der Anwendung benutzen. Es existieren Buttons für das Starten des Suchvorgangs, für das Speichern der Daten und für die Anzeige der Details. Abhängig von dem Zustand der Anwendung werden nur die möglichen Aktionen dargestellt. Beispielsweise können die Routen nicht mehrmals gespeichert werden. Detaillierte Beschreibungen können nur im Fall einer ausgewählten oder geladenen Route angezeigt werden. Diese werden in einem Popup-Fenster dargestellt. Die gespeicherten Daten werden ähnlich wie bei ios in einer Liste angezeigt, die auch die Auswahl der Einträgen ermöglicht. Im Fall von Windows Phone bietet sich als Hauptelement der Darstellung der sogennante Pivot- Control. Das ist eine Microsoft-Komponente, mit der eine Navigation zwischen den Komponenten durch horizontale Verschiebungsgesten erreicht werden kann. Zusätzlich können die Elemente über ihre Titelanzeige aktiviert werden. Die Kartenansicht und die Ansicht für die gespeicherten Daten wurden als Teilelemente des Pivot-Controls implementiert. Zugang zu den Anwendungsfunktionen wurde mittels Buttons in der Menüleiste ermöglicht. Die Positionierung der Marker konnte nur über einen Long-Click-Ereignis umgesetzt werden. Die Kartenkomponente in Windows Phone 8 bietet keine Schnittstellen für Drag-and-Drop-Interaktionen der Elemente. Aufgrund der Konflikte beim Skrollen 51

52 der Karte, konnte diese Funktion nicht implementiert werden. Für die detaillierte Beschreibung der zusätzlichen Informationen wurde eine separate Ansicht in Form einer Liste benutzt. Diese Trennung war notwendig, weil die Detailanzeige nicht immer angezeigt werden soll. Die getrennte Ansicht kann über einen Button in der Menüleiste erreicht werden. Für den Rückweg wurden keine zusätzlichen Aktionen gebraucht - das kann in Windows Phone standardmäßig mit dem eingebauten Hardware- Zurück-Button erreicht werden. 4.8 Zusammenfassung In diesem Kapitel wurde ein ausführliches Konzept für die mobile Version von MobiKat dargestellt. Als Grundlage dafür wurde das Framework Xamarin verwendet. Für die Erstellung des Konzeptes wurden zuerst die dafür benötigten Technologien und die Methoden der plattformübergreifenden Entwicklung mit Xamarin erläutert. Für die detaillierte Spezifikation des Konzeptes wurden die applikationsrelevanten Funktionen der App einzeln untersucht. Dabei wurden die Funktionen teilweise implementiert, um ihre Integration in das Konzept überprüfen zu können. Unter Berücksichtigung der gewonnenen Ergebnisse wurde schließlich ein Prototyp erstellt, mit dem die Zusammenarbeit der einzelnen Komponenten getestet werden konnte. Im nächsten Kapitel wird mit Hilfe des hier erstellten Prototyps eine Evaluation des Entwicklungsansatzes durchgeführt. 52

53 5 Evaluation Das vorherige Kapitel beinhaltete die Konzeptbeschreibung der MobiKat-App. Dafür wurden zuerst alle MobiKat-relevanten Funktionen einzeln implementiert und getestet. Schließlich wurden einige davon in dem erstellten Prototyp integriert. In diesem Kapitel werden die Ergebnisse des letzten Kapitels evaluiert. Zuerst werden die für die Arbeit benutzte Entwicklungstools- und Technologien bewertet. Danach wird eine Analyse des erreichten Code-Sharing-Grades im Prototyp durchgeführt. Anhand der Ergebnisse dieser Analyse wird eingeschätzt, wie die Verhältnisse zwischen den plattformspezifischen und plattformunabhängigen Codeanteilen in der vollständigen Anwendung aussehen können. Schließlich wird das Kapitel mit einer Empfehlung für den getesteten Ansatz beendet. 5.1 Entwicklungsgeräte- und Tools In diesem Abschnitt werden die für diese Arbeit benutzte Tools und Werkzeuge beschrieben. Die Entwicklung der Android- und ios-apps wurde auf einem MacBook (2,26 GHz Intel Core 2 Duo, 8 GB RAM, Mac OS X , Modell 2009) durchgeführt. Als Testgeräte wurden ein HTC EVO 3D (Android 4.0.3) und ein Nexus 5 (Android 4.2.2) verwendet. Die normalen Android-Emulatoren, die mit dem SDK geliefert werden, konnten für den Testprozess nicht benutzt werden. Der Grund dafür ist die Abhängigkeit der neuen Google Maps (Version 2) von den Google Play Services, die auf den Emulatoren nicht verfügbar sind. Als eine Alternative dazu, wurde der Genymotion-Emulator verwendet. Genymotion ist ein Produkt der Firma Genymobile, die Android-Emulatoren auf der Virtualisierungssoftware VirtualBox anbieten. Diese Emulatoren verhalten sich wie reelle Geräte und bieten die Möglichkeit zur Installation von beliebigen Apps. ios-tests wurden mit dem ios-simulator durchgeführt. Das vorhandene ipad Mini konnte aufgrund der Restriktionen von Xamarin nicht vollständig verwendet werden. Als Entwicklungsumgebung für ios- und Android wurde das Programm Xamarin Studio verwendet. Dabei wurden zwei verschiedene Versionen verwendet und Diese Informationen werden hier erwähnt, weil mit der neuesten Version des Programms Probleme beim Testen mit reellen Geräten entstanden sind. Wie im Abschnitt 4.1 beschrieben, ist die Nutzung von Xamarin.Android und Xamarin.iOS nicht kostenlos. Zum Ausprobieren wird eine 30-tätige Trial Version angeboten, mit der alle Versuche in dieser Arbeit durchgeführt wurden. In dieser Variante des IDEs sind auch ios-tests mit reellen Geräten nur für 24 Stunden erlaubt. Für die Windows Phone 8 Entwicklung wurde vom Fraunhofer-Institut IVI ein Tablet-PC Samsung Slate 7 (Intel Core i5-2467m, 4 GB RAM, Windows 8 Pro) zur Verfügung gestellt. Aufgrund eines fehlenden Dream-Spark-Kontos, das für die Durchführung von Tests mit reellen Geräten notwendig ist, konnte das im Institut vorhandene Nokia Lumia 520 nicht benutzt werden. Die Windows-Version des Prototyps wurde in Visual Studio Express for Windows Phone umgesetzt. 5.2 Entwicklungsumgebungen In diesem Abschnitt werden die Entwicklungsumgebung Xamarin Studio und Visual Studio näher betrachtet. Zuerst wird eine allgemeine Bewertung der Programme vorgestellt. Danach werden die Buildzeiten der Anwendungen präsentiert. Schließlich wird auf die in Rahmen dieser Arbeit entstandenen Probleme eingegangen Allgemeine Bewertung Sowohl Xamarin Studio als auch Visual Studio bieten viele Features und ermöglichen eine bequeme Entwicklung. Die Benutzeroberflächen lassen sich nach Wunsch anpassen, was eine effektive Arbeit 53

54 gewährleistet. Neue Benutzer können sich an die Entwicklungsumgebungen in wenigen Stunden gewöhnen. Alle erweiterte Funktionen wie beispielsweise Code-Completion, Info-Tooltips und die integrierte Designer-Komponente funktionieren schnell und ohne Verzögerungen. Als besonders nützlich hat sich im Rahmen der Arbeit das benutzte Plugin für Visual Studio namens NuGet erwiesen. Mit Hilfe dieser Komponente konnten alle Konflikte, die aufgrund von Abhängigkeiten der benutzten Bibliotheken im Projekt entstanden sind, gelöst werden. Beide Tools bieten sowohl ausführliche Debugging-Möglichkeiten, als auch eine Integration der vorhandenen Emulatoren und Testgeräten Buildzeiten Die Buildzeiten der einzelnen Projekte sind ein wichtiges Kriterium für die Softwareentwicklung. Um eine komfortable Arbeit zu gewährleisten, werden die Zeiten jedes Builds nach Möglichkeit gering gehalten. So sind die Programmierer bei der Umsetzung in der Lage, die durchgeführten Änderungen schnell testen zu können. In diesem Abschnitt werden die gemessenen Zeiten der einzelnen Schritte der Buildvorgänge jeder Plattform vorgestellt. Dabei wurden zehn Messungen pro Prozessschritt durchgeführt. Als Ergebnisse werden die durchschnittliche Werte der Messungen genommen. Zeit (Sekunden) s. 4 s. 45 s. ios Start des Emulators Build des Projekts Installation & Start der Anwendung 4 s. 10 s. 11 s. WP8 Abbildung 30: Buildzeiten des ios- Simulators und WP8-Emulators Aufgrund der spezifischer Anwendungsstruktur, werden bei jeder Plattform unterschiedliche Buildvorgänge verwendet. Bei ios und Windows Phone werden die Anwendungen in nativen ARM-Code kompiliert und auf den Simulator, Emulator oder einem reellen Gerät installiert. Im Fall von ios wird zusätzlich die.net-laufzeitumgebung zusammen mit der Anwendung gebündelt, was aber zu dem Buildprozess zählt. Zusätzlich wurden auch die Zeiten, die notwendig für das Starten des Emulators und für die Installation der Anwendung auf dem Gerät ermittelt. Wie im Abschnitt 5.1 beschrieben, konnten in dieser Arbeit keine Tests mit reellen ios- und Windows-Geräten durchgeführt werden. In der Abbildung 30 sind die gemessenen Werte dargestellt. Beim Testen von ios-apps mit Xamarin Studio muss man ca. 22 Sekunden bis zum Anwendungsstart warten. Der Emulator fährt vergleichsweise langsam hoch, der kann aber während des Entwicklungsprozesses im Hintergrund laufen. Im Fall von Windows lässt sich der Prototyp in 14 Sekunden ausführen. Der Emulator startet auch wesentlich schneller - in nur 11 Sekunden. Bei Android wird ein zusätzlicher Schritt für den Buildvorgang gebraucht - die Installation der.net-laufzeitumgebung. Diese läuft in Android als eigenständige Anwendung. Dabei werden zwei Fälle unterschieden. Falls die.net-runtime auf dem Gerät bzw. Emulator nicht vorhanden ist, muss diese zuerst installiert werden. Bei späteren Installation muss aber trotzdem überprüft werden, ob sie existiert, was von Xamarin als eine Synchronisation bezeichnet wird. Die Abbildung 31 präsentiert die gemessenen Zeiten bei der Android-Plattform. Zur Klarheit und Übersichtlichkeit wurden die Startzeiten des Emulators weggelassen. Der Genymotion-Emulator verhält sich wie ein reelles Gerät und kann von Xamarin Studio nicht kontrolliert werden. Aus diesem Grund muss der manuell gestartet werden, was ungefähr eine Minute dauert. Aus der Grafik ist zu sehen, dass bei Android alle Buildprozesse viel langsamer als bei ios und Windows ablaufen. Bei der Entwicklung des Prototyps war es notwendig, bei jeder Codeänderung ca. eine Minute zu warten, bis die Ergebnisse getestet werden konnten. Dabei spielen weder die Geräte und Emulatoren noch das Vorhandensein einer.net-laufzeitumgebung im Gerät eine Rolle. Die Installationszeiten auf dem SS 54

55 Installation & Start der Anwendung Build des Projekts Installation / Synchronisation der.net-laufzeitumgebung Zeit (Sekunden) s. 13 s. 13 s s. 31 s. 29 s. 21 s s s. Installation ohne.net Emulator 20 s. 20 s. Installation mit.net Emulator Installation ohne.net HTC 20 s. Installation mit.net HTC Abbildung 31: Android-Buildzeiten Emulator sind etwas niedriger als beim getesteten Gerät, diese Unterschiede können aber im Vergleich zu der Dauer anderer Prozesse eher vernachlässigt werden. Die durchgeführte Synchronisation der existierender.net-laufzeitumgebung dauert genau so lange wie das Build der gesamten Applikation. Im Gegensatz zu ios und Windows, wird der Android-Entwicklungsprozess von den beschriebenen Wartezeiten deutlich erschwert, was einen negativen Eindruck hinterlassen hat Probleme Trotz guter allgemeiner Bewertungen der Entwicklungsumgebungen Xamarin Studio und Visual Studio, sind während der Entwicklung einige Probleme entstanden, die einige Aspekte der Tests beeinflusst und die Implementierung deutlich verzögert haben. Xamarin Studio Wie bereits erläutert, war die Arbeit mit Xamarin Studio von höherer Effektivität und geringerer Problemhaftigkeit geprägt. Im Laufe der Arbeit sind folgende Probleme entstanden. 1. Kartenintegration (Google Maps) - Xamarin Studio unterstützt zwar alle Android-APIFunktionen- und Bibliotheken, ihre Benutzung ist aber manchmal aufgrund geringer Dokumentation nicht einfach. Das ist auch der Fall mit der Integration von den neuesten Google Maps (Version 2). Der geforderte Einstellungsprozess ist selbst mit den standardmäßig angebotenen Entwicklungstools von Google nicht trivial. Mit den zusätzlichen Schritten, die für Xamarin notwendig sind, kann die Einstellung mehrere Stunden dauern. Für die Erstellung des MapSchlüssels, der für die Freigabe der Karten notwendig ist, werden zwei Parameter gebraucht. Einerseits muss ist die ID-Nummer des Entwicklungszertifikats, mit dem die App signiert wird, 55

56 eingegeben werden. Andererseits muss der sogenannte Package-Name, der das Projekt identifiziert, vorliegen. Dieser kann z.b. so lauten: de.ivi.fraunhofer.mobikat.android. Dabei muss unbedingt beachtet werden, dass Google nur Kleinbuchstaben für diesen Namen erlaubt. Xamarin Studio benutzt, wie es in C# üblich ist, große Buchstaben für die Bezeichnung der Namensräume, Klassen, Methoden und Parameter. Der Package-Name jeder Anwendung wird auch automatisch mit großen Buchstaben bezeichnet. Wenn man mit diesem Namen einen Kartenschlüssel erstellt, erhält man zwar keine Fehlermeldungen, aber die Karten können trotzdem nicht benutzt werden. In Xamarin.Android kann der Package-Name in der Manifest-Datei manuell geändert werden. Dabei sind beliebige Bezeichnungen erlaubt. Wenn aber diese mit dem Ordnerstruktur des Projekts nicht übereinstimmen, kann die Freigabe der Kartenkomponente nicht erfolgen. Alle diese Details sind in der Dokumentation von Xamarin nicht beschrieben und haben die Entwicklung um einige Tage verzögert. 2. Tests mit reellen ios-geräten - das Testen von Anwendungen auf reellen ios-geräten ist nur mit Hilfe eines kostenpflichtigen Developer-Zertifikats möglich. Für diese Arbeit wurde von der TU Dresden ein akademisches Zertifikat zur Verfügung gestellt. Das vorhandene Testgerät ipad Mini wurde erfolgreich registriert. Mit Hilfe von Xcode konnten erfolgreich Anwendungen auf den Gerät installiert werden. Die neueste Version von Xamarin Studio konnte aber die vorhandenen Zertifikate nicht richtig importieren. Es hat sich herausgestellt, dass das Problem ein Fehler in dieser Version der Entwicklungsumgebung ist. Das Problem konnte nur mittels Installation der älteren Version behoben werden. Visual Studio Bei Visual Studio sind einige Probleme bei der Integration der benutzten Bibliotheken und des SOAP- Dienst-Proxys entstanden. Nach der Importierung der SQLite.NET-ORM-Komponente für Windows Phone 8 konnten die Proxies nicht mehr generiert werden. Diese Abhängigkeite konnte mit der Ausgrenzung der Proxy-Komponente in ein getrenntes Projekt gelöst werden. 5.3 Code-Sharing-Analyse Das Maß der Effektivität jedes plattformübergreifenden Entwicklungsansatzes ist das Verhältnis zwischen dem plattformspezifischen und dem plattformunabhängigen Code. Um eine Analyse der in Kapitel 4.5 vorgestellter Entwicklungsmethodik durchzuführen kann der erstellte Prototyp benutzt werden. Obwohl bei der Implementierung nicht alle Funktionen integriert werden konnten, sind alle Anwendungsschichten vorhanden, was die Erstellung einer realistischen Einschätzung des fertigen Produkts gewährleistet. Die Ergebnisse des geteilten Codes werden in der Abbilding 32 präsentiert. Der plattformübergreifende Code, der sich aus den Core Libraries und den Portable Class Libraries zusammensetzt, beträgt 506 Zeilen. Für die Umsetzung der Benutzeroberflächen in ios, Android und Windows Phone waren entsprechend 679, 701 und 601 Zeilen Code notwendig. Somit ergeben sich Code-Sharing-Anteile zwischen 42% und 45%. Diese relativ geringen Prozentanteile können mit der kleinen Anzahl an umgesetzten Funktionen begründet werden. In der Anwendung wurde von jeder Komponente jeweils eine Funktion implementiert. Auf diese Weise konnte die Integration der Komponenten getestet werden. Mit der Berücksichtigung weiterer MobiKat-Operationen kann der Code-Sharing-Anteil erhöht werden. Es lässt sich absehen, dass durch eine Kapselung ähnlicher Benutzeroberflächenkomponenten und ihre Wiederverwendung, deutlich bessere Ergebnisse erreicht werden können. Auf der offiziellen Webseite von Xamarin gibt es viele Anwendungsbeispiele, bei denen 80% des Quellcodes plattformübergreifend benutzt wird. Diese Anwendungen basieren aber ihre GUIs auf OpenGL, was eine Erstellung von Benutzeroberflächenelementen für alle Plattformen ermöglicht. Als eine Bibliothek für Erstellung von 3D-Objekten, wird OpenGL meistens in Spielen eingesetzt. Auf- 56

57 ios-app Code-Verhätnisse plattformspezifisch: gesamt: Code-Sharing: 679 LOC* 1185 LOC* LO*42,7% Android-App Code-Verhätnisse plattformspezifisch: gesamt: Code-Sharing: 701 LOC* 1207 LOC* 41,9% WP8-App Code-Verhätnisse plattformspezifisch: gesamt: Code-Sharing: 601 LOC* 1107 LOC* 45,7% plattformübergreifender Code LOC (Core Libraries und Portable Class Libraties) *LOC - Lines of Code Abbildung 32: Code-Sharing-Auswertung grund der Fokus auf der Kartenkomponente, kann OpenGL für die mobile Version von MobiKat nicht effektiv angewendet werden. Die beste Option für die Umsetzung bleiben die nativen Widgets. 5.4 Entwicklungsaufwand Die Einarbeitung in die Entwicklung mit Xamarin ist durch eine steile Kurve gekennzeichnet. Zunächst werden Kenntnisse von der Programmiersprache C# gebraucht. Aufgrund fehlender Erfahrungen mit der von Microsoft entwickelten Sprache wurde eine Einarbeitung notwendig. Obwohl die Syntax vergleichbar mit der Syntax von Java ist, bietet C# viele zusätzliche Features. Um sich an diese zu gewöhnen, wird einige Zeit benötigt. In dieser Arbeit wurden besonders intensiv die Events und Delegates, die partiellen Klassen, die Präprozessordirektiven und LINQ verwendet. Die Basisklassen zur Bearbeitung von String-Objekten, Sammlungen von Objekten (Collections) sind auch ähnlich wie ihre Java-Alternativen aufgebaut. Einige Details ihrer Arbeitsweise haben zu schwer auffindbaren Fehlern geführt. Beispielsweise konnte aufgrund der Abhängigkeit des Parsens der Zahlendatentypen von der im System eingestellten Sprachen ein Fehler in der vorgestellten WKTParser-Klasse mehrere Stunden nicht gefunden werden. Im Emulator, auf dem Englisch als Hauptsprache eingestellt wurde, konnten die durch einen Punkt getrennten Double-Werte korrekt von dem entsprechenden String-Objekt extrahiert werden. In dem HTC EVO 3D dagegen wurde Deutsch als Hauptsprache ausgewählt. Der Parser hat eine Dezimalstellentrennung durch Kommas erwartet, was dazu geführt hat, dass die Anwendung falsche Koordinatendaten erhalten hat. Der innovative Ansatz der Xamarin-Entwicklung, bei dem alle native APIs der Plattformen verwendet werden können, bietet zwar viele Vorteile, erfordert aber unbedingt gute Kenntnisse der einzelnen Plattformen. Der Prozess der Einarbeitung in die einzelnen Plattformen war die größte Herausforderung in dieser Arbeit. Die vorhandenen Erfahrungen mit Android konnten schnell angewendet werden. In das Kennenlernen von ios und Windows Phone wurden mehreren Wochen investiert. Die Dokumentation auf der Xamarin-Webseite stellt die Grundlagen der ios-entwicklung vor, was aber für diese Arbeit nicht ausreichend war. Zusätzlich wurden sowohl die ausführliche Apple-Dokumentation als auch mehrere Online-Tutorials benutzt. Alle diese Ressourcen basieren auf der Sprache Objective- C, die für die Entwicklung der Apple-Produkte benutzt wird. Um diese Ressourcen zu verstehen, war es auch notwendig, die Sprache Objective-C kennen zu lernen. Aufgrund der Zusammenarbeit von 57

58 Xamarin Studio mit Xcode, wird für die ios-entwicklung besonders Wissen in des Designprozesses von GUIs mit Xcode notwendig. Als unbekannte Plattform, wurde Windows Phone 8 auch wie ios anhand verschiedener Online- Tutorials kennen gelernt. Dafür sollten neue Microsoft-Technologien wie XAML, die XML-basierte Sprache für die Definition von Oberflächen, in Erfahrung gebracht werden. Dieser Prozess wurde durch das nicht immer vorhandene Tablet-PC zusätzlich erschwert Gesamteinschätzung und Empfehlung Die Produkte der Firma Xamarin bieten die Möglichkeit, plattformübergreifende mobile Anwendungen für Android und ios zu erstellen. Das Framework basiert auf dem Mono-Framework - eine plattformübergreifende Portierung des.net-frameworks von Microsoft. Als Entwicklungssprache wird C# verwendet, was automatisch die Kompatibilität zu allen windows-basierten Betriebssystemen gewährleistet. So kann der Quellcode gemeinsam von verschiedenen Plattformen benutzt werden. Die Besonderheit der Xamarin-Entwicklung ist die Abbildung der nativen APIs der unterstützten Plattformen. Während sich die meisten Frameworks mit einer bestimmten Anzahl der angebotenen nativen Komponenten begrenzen, ermöglicht Xamarin eine vollständige Nutzung der Plattformfunktionen. Aufgrund des direkt in Maschinencode übersetzten Quellcodes, sind die mit Xamarin erstellten Apps durch eine hohe Performanz gekennzeichnet. C# ist eine moderne Programmiersprache, die den Entwickler mehrere hilfreiche Funktionen wie Events & Delegates, LINQ und eine einfache Behandlung asynchroner Operationen ermöglicht. Für die Sprache existieren auch mehrere zusätzlichen Bibliotheken, die auch mobile Versionen für Xamarin.Android und Xamarin.iOS beinhalten. Diese Vorteile bringen aber auch einige Nachteile mit sich. Die nativen Widgets sind plattformspezifisch, was ihre Integration in anderen Plattformen verbietet. Aus diesem Grund ist eine Trennung der plattformspezifischen von den plattformunabhängigen Teilen der Anwendungen notwendig. Das resultiert in eine komplexe Projektstruktur, die mit einer aufwendigen Verwaltung verbunden ist. Für die Entwicklung mit Xamarin werden unbedingt gute Plattformkenntnisse benötigt, was den Einarbeitungsaufwand deutlich erhöht. Insgesamt hat Xamarin einen positiven Eindruck hinterlassen. Xamarin war das einzige Framework, das gesamte Palette der MobiKat-relevanten Funktionen unterstützt. Das angebotene Entwickungsumgebung - Xamarin Studio gewährleistet eine angenehme Arbeit. Wie bei jedem Programm, sind auch in Rahmen dieser Arbeit einige Probleme entstanden. Für die Auswahl des Frameworks ist es ganz wichtig, zuerst eine Auswertung der zu entwickelnden App durchzuführen. Xamarin lässt sich effektiv in Anwendungen verwenden, bei der viele Backend-Operationen ausgeführt werden. Diese können plattformübergreifend implementiert und in verschiedenen Plattformen wiederverwendet werden. Die Apps, die hauptsächlich aus sichtbaren Elementen bestehen, sind für Xamarin eher ungeeignet. Die plattformspezifischen GUIs müssen einzeln für jede Plattform erstellt werden, was fast so aufwendig ist, wie das Erstellen einer komplett nativer App. Eine Ausnahme sind natürlich die OpenGL-basierten Benutzeroberflächen, die aber für Business-Anwendungen sehr selten benutzt werden. Schließlich müssen natürlich noch die hohen Lizenzkosten von Xamarin beachtet werden. 58

59 6 Zusammenfassung Die sich ständig steigenden Verkäufe von Smartphones und Tablets in den letzten Jahren haben die Softwarewelt vollständig verändert. Während früher die Hersteller nur auf die Entwicklung der Desktopversionen ihrer Anwendungen konzentriert waren, müssen sie heutzutage zusätzlich mobile Versionen der Programme anbieten, um ihre Kunden zufriedenzustellen. Mit Hilfe der in den Geräten vorhandener Sensoren lassen sich existierende Anwendungen mit zusätzlichen Funktionen vervollständigen, die die Qualität und die Effizienz der angebotenen Diensten verbessern können. Genau aus diesen Gründen wurde am Fraunhofer-Institut für Verkehrs- und Infrastruktursysteme IVI entschieden, das System MobiKat, das der Vorsorge und Bewältigung von Großschadenslagen sowie der alltäglichen Gefahrenabwehr im Landkreis Sächsische Schweiz- Osterzgebirge dient, auch in Form einer mobilen Anwendung zur Verfügung zu stellen. Auf diese Weise soll die Benutzung der umfangreichen Funktionen während eines Einsatzes ermöglicht werden. Das Ziel dieser Arbeit war, die Entwicklung der MobiKat-App zu planen. Dabei sollte eine plattformübergreifende Lösung, die die Plattformen ios, Android und Windows Phone unterstützt, entwickelt werden. Um das zu erreichen, wurden zuerst die existierenden Cross-Platform-Ansätze identifiziert und klassifiziert. Um ein passendes Framework als Grundlage für die MobiKat-App auswählen zu können, wurden existierende Werkzeuge miteinander bezüglich der MobiKat-relevanten Funktionen verglichen. Da bei MobiKat besonders großer Wert auf die Performanz der Karteninteraktionen gelegt wird, wurde eine kleine Android-App erstellt, die für den Vergleich der verschiedenen Möglichkeiten der Umsetzung von Kartenkomponenten benutzt werden konnte. Mit Hilfe dieser App wurde gezeigt, dass alle HTML-basierte Ansätze nicht passend für MobiKat sind. Das einzige Framework, das vollständig alle benötigten Funktionen unterstützt ist Xamarin. Aus diesem Grund wurde beschlossen, die Entwicklungsmethodik der MobiKat-App auf Xamarin aufzubauen. Im Kapitel 4 wurde die Anwendung ausführlich konzipiert. Dabei wurden die dafür relevanten Funktionen teilweise implementiert, um ihre Integration testen zu können. Basierend auf dem Konzept wurde ein Prototyp der App erstellt, mit dem dann eine Evaluation durchgeführt werden konnte. 59

60

61 Literatur [1] Xamarin Whitepaper, Key Strategies for Mobile Excellence [2] Apple Sales Reports Online, Abruf: URL [3] International Data Corporation (IDC) Online, Abruf: URL [4] Kantar Worldpanel Online, Abruf URL [5] Offizielle MobiKat Webseite Online, Abruf: URL [6] Belegarbeit Martin Dobrev, Analyse, Konzept und prototypische Implementierung einer Applikation zur Unterstützung von mobilen Einsatzkräften TU Dresden, 2012 [7] Diplomarbeit Dirk Hering, Analyse von Methoden und Werkzeugumgebungen zur plattformunabhängigen Entwicklung mobiler Applikationen TU Dresden, 2011 [8] Watt, David A., Programming Language Processors - Compilers and Interpreters Prentice Hall, 1993 [9] Marco Cantu, Whitepaper The Delphi Language for Mobile Development Embarcadero Technologies, April 2013 [10] Kony Inc., Whitepaper Kony Development Cloud Kony Inc [11] SAP, Whitepaper Building Enterprise-Grade HTML5 Mobile Apps, 2013 [12] SAP, Whitepaper Hybrid Mobile Apps, 2013 [13] Xamarin Platform Overview Online, Abruf: URL [14] Tizen SDK Overview Online, Abruf: URL https://developer.tizen.org/documentation/devguide/2.2.1?redirect=https%3a//developer.tizen.org/dev-guide/2.2.1/org.tizen.gettingstarted/html/cover_page.ht [15] Tabris Anatomy Online, Abruf: URL [16] Eclipse Remote Application Platform Offiziele Webseite Online, Abruf: URL [17] Map Benchmark, Andoid Anwendung für Kartentypen Usability Testing Martin Dobrev, Open Source Anwendung - URL https://github.com/martindobrev/mapbenchmark 61

62 [18] Map Benchmark Demo, Youtube Online, Abruf URL [19] Seminar Cross Platform Development, Xamarin 2012 Online, Abruf URL [20] Seminar Sharing Up to 80% code for ios, Android, and Windows Platforms Online, Abruf URL [21] MSDN Dokumentation - C# Preprocessor Directives Online, Abruf URL [22] MSDN Dokumentation - Delegates and Events Online, Abruf URL [23] Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software Addison-Wesley 1994 [24] Xamarin Dokumentation - Introduction to Portable Class Libraries Online, Abruf URL [25] RestSharp GitHub Seite Online, Abruf: URL [26] Hammock GitHub Seite Online, Abruf: URL [27] ServiceStack Offizielle Seite Online, Abruf: URL [28] Online Tool json2csharp Online, Abruf: URL [29] Xamarin Dokumentation, Maps API Online, Abruf: URL /maps_and_location/part_2_-_maps_api/ [30] Wikipedia, Near Field Communication Online, Abruf: URL [31] Wikipedia, Well-Known Text Online, Abruf: URL [32] GenyMotion, Offizielle Webseite Online, Abruf: URL 62

63 Abbildungsverzeichnis 1 ipad und iphone Verkäufe nach dem Start des jeweiligen Produkts, Quelle [2] Anteile der Smartphoneverkäufe in den letzten Jahren [3] Smartphoneverkäufe in Europa für 2013 [4] Funktionsweise der Modellgetriebenen Softwareentwicklung Struktur von webbasierten Apps Struktur hybrider Apps Struktur interpretierter Anwendungen Kony Komponente [10] Tabris Plattform [15] Funktionsweise des Embarcadero Frameworks Xamarin Plattform, Quelle [13] Gegenüberstellung der plattformübergreifenden Entwicklungsansätze Tabellarischer Vergleich von mobilen Frameworks Tabellarischer Vergleich von mobilen Frameworks (Fortsetzung) Breadcrumb Menus Konditionale Kompilierung in C# Partielle Klasse in C# Partielle Methode in C# Eingenschaften plattformübergreifender Bibliotheken Beispiel File-Linking Allgemeine Struktur einer Cross-Plattform Xamarin Solution Plattformübergreifende Kommunikation mit dem MobiKat-SOAP-Dienst C# Code-Generierung aus einer MobiKat-JSON-Nachricht Verarbeitung der Positionsänderung mittels Xamarin.Mobile Ausschnitt aus der Klasse Route Datenbankabstraktion mit dem Entwurfsmuster Facade Plattformübergreifender Dateizugriff Detailliertes Konzept der MobiKat-App Struktur der Benutzeroberflächen einzelner Apps Buildzeiten des ios-simulators und WP8-Emulators Android-Buildzeiten Code-Sharing-Auswertung

64

65 A Gesamtliste der Tools und Frameworks Webseite Bezeichnung Hersteller Abschnitt jquery Mobile jquery Foundation Webbasierter Ansatz Sencha Touch Sencha Inc. Webbasierter Ansatz Dojo Toolkit Dojo Foundation Webbasierter Ansatz Bootstrap Twitter Inc. Webbasierter Ansatz Kendo UI Telerik Webbasierter Ansatz PhoneGap Adobe Systems Inc. Hybrider Ansatz https://build.phonegap.com/ Ripple Emulator Apache Software Foundation Hybrider Ansatz Apache Cordova Apache Software Foundation Hybrider Ansatz Icenium Telerik Hybrider Ansatz Trigger.io Trigger.io Hybrider Ansatz https://trigger.io/ Kony Kony Inc. InterpretationsAnsatz Rhomobile Motorola Solutions Inc. InterpretationsAnsatz Business+Product+and+Services/ Software+and+Applications/RhoMobile+Suite Adobe Air Adobe Systems Inc. InterpretationsAnsatz Titanium Appcelerator Inc. InterpretaionsAnsatz Tabris EclipseSource InterpretationsAnsatz Embarcadero Delphi XE5 Embarcadero Technologies Inc. ÜbersetzungsAnsatz products/delphi Xamarin Xamarin Inc. ÜbersetzungsAnsatz MoSync MoSync AB ÜbersetzungsAnsatz Qt Mobile Digia ÜbersetzungsAnsatz Qt-for-Mobile-Development/Qt-Mobile-Edition/ (Stand Januar 2014) 65

66

67 B Xamarin Studio 67

68 68

69 69

Cross-Platform Apps mit HTML5/JS/CSS/PhoneGap

Cross-Platform Apps mit HTML5/JS/CSS/PhoneGap Cross-Platform Apps mit HTML5/JS/CSS/PhoneGap Proseminar Objektorientiertes Programmieren mit.net und C# Florian Schulz Institut für Informatik Software & Systems Engineering Einführung Was hat Cross-Plattform

Mehr

Eine App, viele Plattformen

Eine App, viele Plattformen Eine App, viele Plattformen Anwendungsentwicklung für Mobile Heiko Lewandowski 23.04.2013 EINLEITUNG Festlegung App-Strategie: Welche Ziele möchte ich erreichen? Die Vielzahl der Plattformen und Geräte(hersteller)

Mehr

App Entwicklung mit Hilfe von Phonegap. Web Advanced II - SS 2012 Jennifer Beckmann

App Entwicklung mit Hilfe von Phonegap. Web Advanced II - SS 2012 Jennifer Beckmann App Entwicklung mit Hilfe von Phonegap Web Advanced II - SS 2012 Jennifer Beckmann http://www.focus.de/digital/internet/netzoekonomie-blog/smartphone-googles-android-laeuft-konkurrenz-in-deutschland-davon_aid_723544.html

Mehr

Mobile Applications. Adrian Nägeli, CTO bitforge AG

Mobile Applications. Adrian Nägeli, CTO bitforge AG Mobile Applications Adrian Nägeli, CTO bitforge AG Inhalt Vorstellung Marktübersicht Entwicklung Adrian Nägeli Dipl. Inf.-Ing FH Seit 2005 bei bitforge bitforge AG Standort Rapperswil-Jona Gründung 2004

Mehr

Architekturen mobiler Multi Plattform Apps

Architekturen mobiler Multi Plattform Apps Architekturen mobiler Multi Plattform Apps Wolfgang Maison & Felix Willnecker 06. Dezember 2011 1 Warum Multi- Plattform- Architekturen? Markt. Apps für Smartphones gehören zum Standardinventar jeder guten

Mehr

Bring Your Own Device in der Industrie

Bring Your Own Device in der Industrie Bring Your Own Device in der Industrie Geht das wirklich? 27.05.2014 Thomas Sorg BERNER & MATTNER Überblick BERNER & MATTNER Systemtechnik GmbH ASSYSTEM Founded: 1979 Employees: 450 Headquarters: Munich,

Mehr

Mit Cloud Power werden Sie zum

Mit Cloud Power werden Sie zum Mit Cloud Power werden Sie zum Herzlich Willkommen! Christian Hassa Managing Partner TechTalk Software AG Agenda Mobile App Development mit Xamarin Pause Azure Mobile Services Q&A 9h00-10h30 10h30-10h50

Mehr

Entwicklung und Integration mobiler Anwendungen. Oracle Deutschland B.V. & Co. KG

Entwicklung und Integration mobiler Anwendungen. <Speaker> Oracle Deutschland B.V. & Co. KG Entwicklung und Integration mobiler Anwendungen Oracle Deutschland B.V. & Co. KG Global Users (Millions) Der Trend ist eindeutig. Trend zu mobilen Endgeräten Wachstum des mobilen Datenverkehrs

Mehr

Vergleichsstudie zur Entwicklung von mobilen Applikationen auf der Basis von Android, ios und HTML5

Vergleichsstudie zur Entwicklung von mobilen Applikationen auf der Basis von Android, ios und HTML5 Vergleichsstudie zur Entwicklung von mobilen Applikationen auf der Basis von Android, ios und HTML5 Impressum Herausgeber: Bader&Jene Software-Ingenieurbüro GmbH Schauenburgerstrasse 116 D-24118 Kiel Tel:

Mehr

JavaScript Frameworks für Mobile

JavaScript Frameworks für Mobile JavaScript Frameworks für Mobile MoBI Expertenrunde Usability, 1. März 2012 doctima GmbH JavaScript Frameworks für Mobile MoBI 1.3.2012 Edgar Hellfritsch Inhalt Native App-Entwicklung Klassische Web-Entwicklung

Mehr

Autorensysteme für mobile Anwendungen - Totgesagte leben länger. Prof. Dr. Michael Bauer 25.10. 2012 Autorensysteme

Autorensysteme für mobile Anwendungen - Totgesagte leben länger. Prof. Dr. Michael Bauer 25.10. 2012 Autorensysteme Autorensysteme für mobile Anwendungen - Totgesagte leben länger Was ist, was will ein Autor? Produzent interaktiver, multimedialer Inhalte geschlossene Einheiten (Apps) keine Grenzen für Kreativität Entwicklungs-

Mehr

Integration mobiler Endgeräte in Medizinprodukte und Medizintechnik-nahe Produkte

Integration mobiler Endgeräte in Medizinprodukte und Medizintechnik-nahe Produkte Integration mobiler Endgeräte in Medizinprodukte und Medizintechnik-nahe Produkte Agenda Problemstellung Medizinprodukt App Grundlagen Szenarien (Problemstellungen und Lösungsansätze) 03.06.2013 2 Innovationen

Mehr

Einführung in Betriebssysteme

Einführung in Betriebssysteme Einführung in Betriebssysteme APPLE ios Entwicklung von ios Entwickelt auf der Basis von MacOS X UNIX Vorgestellt am 9.1.2007 Zusammen mit iphone Markenname von Cisco Internetwork Operating System Für

Mehr

Möglichkeiten, Vorteile und Grenzen der Cross-Plattform-Entwicklung

Möglichkeiten, Vorteile und Grenzen der Cross-Plattform-Entwicklung Möglichkeiten, Vorteile und Grenzen der Cross-Plattform-Entwicklung iks Thementag Mobile Applikationen Es lebe die Vielfalt?! 18.06.2013 Autor: Jan Laußmann Agenda Warum Cross-Plattform entwickeln? Hybrid

Mehr

Präsentation Von Laura Baake und Janina Schwemer

Präsentation Von Laura Baake und Janina Schwemer Präsentation Von Laura Baake und Janina Schwemer Gliederung Einleitung Verschiedene Betriebssysteme Was ist ein Framework? App-Entwicklung App-Arten Möglichkeiten und Einschränkungen der App-Entwicklung

Mehr

1 Entwickeln mit PhoneGap

1 Entwickeln mit PhoneGap 1 1.1 Das Cross-Plattform-Problem Bevor ich mit Ihnen in die praktische Entwicklung einsteige, möchte ich Ihnen von einem kurzen Gespräch berichten, das sich vor einiger Zeit in der IT-Abteilung eines

Mehr

Mobile App development mit Xamarin. Christian Hassa (ch@techtalk.ch) Andreas Willich (awi@techtalk.ch) TechTalk Software AG

Mobile App development mit Xamarin. Christian Hassa (ch@techtalk.ch) Andreas Willich (awi@techtalk.ch) TechTalk Software AG Mobile App development mit Xamarin Christian Hassa (ch@techtalk.ch) Andreas Willich (awi@techtalk.ch) TechTalk Software AG % der Bevölkerung mit Smartphone Smartphone Durchdringung >50% 34% 43% 54% DACH

Mehr

Use Cases, Mockups, Prototyping Von der Idee zur App

Use Cases, Mockups, Prototyping Von der Idee zur App Use Cases, Mockups, Prototyping Von der Idee zur App Dipl.-Päd. Sandro Mengel 08. November 2012 The Beginning: Idee & Fragestellungen Eine App... für welche Zielgruppe? mit welchen Inhalten oder Features?

Mehr

Mobile Application Development

Mobile Application Development Mobile Application Development Android: Einführung Jürg Luthiger University of Applied Sciences Northwestern Switzerland Institute for Mobile and Distributed Systems Lernziele Der/die Kursbesucher/in kann

Mehr

PLATTFORMÜBERGREIFENDE ENTWICKLUNG VON APPS

PLATTFORMÜBERGREIFENDE ENTWICKLUNG VON APPS PLATTFORMÜBERGREIFENDE ENTWICKLUNG VON APPS DIPL.-WIRT.INFORM. HENNING HEITKÖTTER PRAKTISCHE INFORMATIK, UNIVERSITÄT MÜNSTER 1 GEGENÜBERSTELLUNG NATIVE VS. PLATTFORMÜBERGREIFENDE ENTWICKLUNG 2 ENTWICKLUNGSANSÄTZE

Mehr

App-Entwicklung für Android

App-Entwicklung für Android App-Entwicklung für Android Einleitung - Systemarchitektur Hochschule Darmstadt WS15/16 1 Inhalt Historie Systemarchitektur Sandbox 2 Motivation Kontra Pro Limitierte Größe Begrenzte Ressourcen Kein Standardgerät

Mehr

Mobile: Die Königsfrage

Mobile: Die Königsfrage Mobile: Die Königsfrage - Native App,Mobile Website oder doch Responsive Design? - Native App oder Mobile Website? Wer am Boom der mobilen Anwendungen teilhaben möchte, hat im Prinzip zwei Möglichkeiten:

Mehr

SAP Mobile Platform MÜNSTER 10.04.2013. best practice consulting Aktiengesellschaft Raboisen 32 20095 Hamburg T +49 40 303752-0 F +49 40 303752-77

SAP Mobile Platform MÜNSTER 10.04.2013. best practice consulting Aktiengesellschaft Raboisen 32 20095 Hamburg T +49 40 303752-0 F +49 40 303752-77 MÜNSTER 10.04.2013 SAP Mobile Platform best practice consulting Aktiengesellschaft Raboisen 32 20095 Hamburg T +49 40 303752-0 F +49 40 303752-77 E info@bpc.ag W www.bpc.ag Seite 1 18.04.2013 Agenda Einleitung

Mehr

Mobile Apps mit DSLs. und entfernter Codegenerierung. Codierst Du noch oder generierst Du schon? Powered by

Mobile Apps mit DSLs. und entfernter Codegenerierung. Codierst Du noch oder generierst Du schon? Powered by Mobile Apps mit DSLs C1 und entfernter Codegenerierung Codierst Du noch oder generierst Du schon? Generative Software GmbH Freiburg Inhalt Plattformabhängige Entwicklung JavaScript Firefox OS Java Android

Mehr

Mobile Kartenanwendungen im Web oder als App?

Mobile Kartenanwendungen im Web oder als App? Mobile Kartenanwendungen im Web oder als App? Agenda Anforderungen an eine mobile Kartenanwendung Warum mobile Anwendungen? Mobil ist nicht genug! Knackpunkte bei der Entwicklung mobiler Kartenanwendungen

Mehr

Lauter nützliche Apps!? Was sind Apps, und wie werden diese entwickelt?

Lauter nützliche Apps!? Was sind Apps, und wie werden diese entwickelt? Lauter nützliche Apps!? Was sind Apps, und wie werden diese entwickelt? Prof. Dr. Jörg R. Weimar, Fakultät Informatik 1 Smartphones Anwendungen Apps Prof. Dr. Jörg R. Weimar Wolfenbüttel Fakultät Informatik

Mehr

Einführung in die Cross-Plattform Entwicklung Das Intel App Framework

Einführung in die Cross-Plattform Entwicklung Das Intel App Framework Einführung in die Cross-Plattform Entwicklung Das Intel App Framework Einführung Dieses Hands-on-Lab (HOL) macht den Leser mit dem Intel App Framework vom Intel XDK vertraut. Es wird Schritt für Schritt

Mehr

Möglichkeiten, Vorteile und Grenzen der Cross-Plattform-Entwicklung

Möglichkeiten, Vorteile und Grenzen der Cross-Plattform-Entwicklung Möglichkeiten, Vorteile und Grenzen der Cross-Plattform-Entwicklung iks Thementag Mobile Applikationen Es lebe die Vielfalt?! 20.11.2012 Autor: Jan Laußmann Agenda Warum Cross-Plattform entwickeln? Hybrid

Mehr

1. Software-Plattform Android Android. Was ist Android? Bibliotheken, Laufzeitumgebung, Application Framework

1. Software-Plattform Android Android. Was ist Android? Bibliotheken, Laufzeitumgebung, Application Framework 1. Software-Plattform Android Android Was ist Android? Plattform und Betriebssystem für mobile Geräte (Smartphones, Mobiltelefone, Netbooks), Open-Source Linux-Kernel 2.6 Managed Code, Angepasste Java

Mehr

Die fünf häufigsten Fehler Von Entwicklern bei der mobilen Programmierung

Die fünf häufigsten Fehler Von Entwicklern bei der mobilen Programmierung Die fünf häufigsten Fehler Von Entwicklern bei der mobilen Programmierung In 2015 werden mehr Tablet-Computer verkauft werden als Desktopund tragbare Computer zusammen Quelle: IDC, Mai 2013 Aufgrund der

Mehr

AM BeIsPIel Der DAsInvestMent.coM MoBIl WeB APP

AM BeIsPIel Der DAsInvestMent.coM MoBIl WeB APP AM BeIsPIel Der DAsInvestMent.coM MoBIl WeB APP 2 Inhalt Warum ist es sinnvoll eine spezielle Applikation für mobile Geräte zu entwickeln? Seite 5 Welche Möglichkeiten der Umsetzung gibt es? 6 Mobile Applikation

Mehr

TM1 mobile intelligence

TM1 mobile intelligence TM1 mobile intelligence TM1mobile ist eine hochportable, mobile Plattform State of the Art, realisiert als Mobile BI-Plug-In für IBM Cognos TM1 und konzipiert als Framework für die Realisierung anspruchsvoller

Mehr

Datenhaltung für Android. Model First

Datenhaltung für Android. Model First Datenhaltung für Android Model First Frederik Götz, Johannes Tysiak 26.05.2011 Unser Ziel! 26.05.2011 Datenhaltung in Android - Model First» Frederik Götz, Johannes Tysiak 2 Agenda Android Quickstart Datenhaltung

Mehr

C++ und mobile Plattformen

C++ und mobile Plattformen Dieser Artikel stammt aus dem Magazin von C++.de (http://magazin.c-plusplus.de) C++ und mobile Plattformen Mit diesem Artikel möchte ich euch einen kurzen Überblick über die verschiedenen Plattformen für

Mehr

Mobility mit IBM Worklight Erste Schritte zu einer mobilen App. Benjamin Stein, Consultant Stuttgart, 03.04.2014

Mobility mit IBM Worklight Erste Schritte zu einer mobilen App. Benjamin Stein, Consultant Stuttgart, 03.04.2014 Mobility mit IBM Worklight Erste Schritte zu einer mobilen App Benjamin Stein, Consultant Stuttgart, 03.04.2014 Agenda Was ist IBM Worklight eigentlich? Hintergrund und Idee, Architektur und Bestandteile

Mehr

NEXT GENERATION MOBILE PHONE PLATFORMS

NEXT GENERATION MOBILE PHONE PLATFORMS Stephan Zeisberg NEXT GENERATION MOBILE PHONE PLATFORMS Ein Einblick in die Systemarchitekturen aktueller Smartphones 1 Motivation Technologischer Stillstand in der Entwicklung mobiler Betriebssysteme

Mehr

09.06.2003 André Maurer andre@maurer.name www.andre.maurer.name Wirtschaftsinformatik FH 3.5 Fachhochschule Solothurn, Olten

09.06.2003 André Maurer andre@maurer.name www.andre.maurer.name Wirtschaftsinformatik FH 3.5 Fachhochschule Solothurn, Olten Aktuelle Themen der Wirtschaftsinformatik Zusammenfassung 09.06.2003 André Maurer andre@maurer.name www.andre.maurer.name Wirtschaftsinformatik FH 3.5 Fachhochschule Solothurn, Olten 1 Serverseitige Webprogrammierung

Mehr

Programmierung mobiler Geräte

Programmierung mobiler Geräte Programmierung mobiler Geräte SoSe 2015 Hybride Apps Markus Berg Hochschule Wismar Fakultät für Ingenieurwissenschaften Bereich Elektrotechnik und Informatik http://mmberg.net 2 Letzte Woche: Webapps Nativ

Mehr

Apps entwickeln mit HTML und Javascript

Apps entwickeln mit HTML und Javascript Apps entwickeln mit HTML und Javascript Framework "PhoneGap" (Apache Cordova) Apps für diverse Mobil-Plattformen (Android, ios, etc.) Apps als Web-Anwendung Vor- und Nachteile zu nativen Apps. Frank Bartels

Mehr

Appery.io Mobile Apps schnell und einfach entwickeln

Appery.io Mobile Apps schnell und einfach entwickeln Appery.io Mobile Apps schnell und einfach entwickeln Cloud-basierte Entwicklungsumgebung, keine lokale Installation von Entwicklungsumgebung nötig. Technologie: HTML5. JQuery Mobile, Apache Cordova. Plattformen:

Mehr

Erste Erfahrungen mit Android

Erste Erfahrungen mit Android Java User Group München, 22. 9. 2008 Erste Erfahrungen mit Android 1 Was ist Android? Die erste vollständige, offene und freie Plattform für mobile Telefone Entwickelt von der Open Handset Alliance (Telecoms,

Mehr

MOBILE ENTERPRISE APPLICATION PLATFORM (MEAP)

MOBILE ENTERPRISE APPLICATION PLATFORM (MEAP) MOBILE ENTERPRISE APPLICATION PLATFORM (MEAP) Oliver Steinhauer Markus Urban.mobile PROFI Mobile Business Agenda MOBILE ENTERPRISE APPLICATION PLATFORM AGENDA 01 Mobile Enterprise Application Platform

Mehr

Entwicklung von Plattform-übergreifenden Mobilanwendungen

Entwicklung von Plattform-übergreifenden Mobilanwendungen Entwicklung von Plattform-übergreifenden Mobilanwendungen Unter Nutzung von HTML 5 basierten Cross Development Werkzeugen und standardisierten Serviceschnittstellen Clemens Düpmeier, Thorsten Schlachter

Mehr

Geschäftsbereich Mobile Services Was ist Android?

Geschäftsbereich Mobile Services Was ist Android? Geschäftsbereich Mobile Services Was ist Android? Hinter Hoben 149 53129 Bonn www.visionera.de Ansprechpartner: Arno Becker arno.becker@visionera.de +49 228 555 1111 +49 160 98965856 Einleitung Android

Mehr

WEBAPPS MEDIEN ZWISCHEN TECHNOLOGIE UND GESELLSCHAFT PROF. DR. MANFRED THALLER JONAS SCHOPHAUS UNI KÖLN WS 2012

WEBAPPS MEDIEN ZWISCHEN TECHNOLOGIE UND GESELLSCHAFT PROF. DR. MANFRED THALLER JONAS SCHOPHAUS UNI KÖLN WS 2012 WEBAPPS MEDIEN ZWISCHEN TECHNOLOGIE UND GESELLSCHAFT PROF. DR. MANFRED THALLER JONAS SCHOPHAUS UNI KÖLN WS 2012 AGENDA 1. Native versus webbasierte Apps 2. HTML5 & CSS3 1. Media Queries 2. Geolocation

Mehr

Einführung in die Cross-Plattform Entwicklung Das Intel XDK

Einführung in die Cross-Plattform Entwicklung Das Intel XDK Einführung in die Cross-Plattform Entwicklung Das Intel XDK Einführung Dieses Hands-on-Lab (HOL) macht den Leser mit dem Intel XDK vertraut. Es wird Schritt für Schritt die erste eigene Hybrid-App entwickelt

Mehr

User Experience und Cross-Plattform Entwicklung. Spektrum mobiler Funktionen Cross Platform SDK landscape Cross Platform Design Pattern

User Experience und Cross-Plattform Entwicklung. Spektrum mobiler Funktionen Cross Platform SDK landscape Cross Platform Design Pattern User Experience und Cross-Plattform Entwicklung Spektrum mobiler Funktionen Cross Platform SDK landscape Cross Platform Design Pattern 1 Spektrum mobiler Funktionen 1. Spektrum mobiler Funktionen Seite

Mehr

App-Entwicklung mit Titanium

App-Entwicklung mit Titanium Masterstudienarbeit Betreuung Prof. Dr. M. von Schwerin 1 Gliederung 1.Motivation 2.Aufgabenstellung 3.Projektbeschreibung 4.Projektstatusbericht 5.Fazit und Ausblick 2 1.Motivation Verbreitung von Smartphones

Mehr

Fraunhofer FOKUS. Institut für Offene Kommunikationssysteme

Fraunhofer FOKUS. Institut für Offene Kommunikationssysteme Fraunhofer FOKUS Institut für Offene Kommunikationssysteme Öffentliche Informationstechnologien ÖFIT Forschung und Entwicklung in öffentlichen Informationstechnologien Forschung & Entwicklung Zukünftige

Mehr

SMARTPHONES. Möglichkeiten, Gefahren, Sicherheit Best Practice Peter Teufl

SMARTPHONES. Möglichkeiten, Gefahren, Sicherheit Best Practice Peter Teufl SMARTPHONES Möglichkeiten, Gefahren, Sicherheit Best Practice Peter Teufl A-SIT/Smartphones iphone security analysis (Q1 2010) Blackberry security analysis (Q1 2010) Qualifizierte Signaturen und Smartphones

Mehr

Smartphone Entwicklung mit Android und Java

Smartphone Entwicklung mit Android und Java Smartphone Entwicklung mit Android und Java predic8 GmbH Moltkestr. 40 53173 Bonn Tel: (0228)5552576-0 www.predic8.de info@predic8.de Was ist Android Offene Plattform für mobile Geräte Software Kompletter

Mehr

Mobile Anwendungen im SAP-Umfeld

Mobile Anwendungen im SAP-Umfeld Erstes Symposium für neue IT in Leipzig 27. September 2013 Michael Rentzsch Informatik DV GmbH michael.rentzsch@informatik-dv.com +49.341.462586920 IT-Trend: Mobile Mobile might be one of the most interesting

Mehr

Jörg Neumann Acando GmbH

Jörg Neumann Acando GmbH Jörg Neumann Acando GmbH Jörg Neumann Principal Consultant bei der Acando GmbH MVP Windows Platform Development Beratung, Training, Coaching Buchautor, Speaker Mail: Joerg.Neumann@Acando.com Blog: www.headwriteline.blogspot.com

Mehr

Bin ich fit für myconvento?

Bin ich fit für myconvento? Bin ich fit für myconvento? Sie planen den Einsatz unserer innovativen Kommunikationslösung myconvento und fragen sich gerade, ob Ihr Rechner die Anforderungen erfüllt? Hier erfahren Sie mehr. Inhalt Was

Mehr

CouchCommerce Online-Shops für Tablet Besucher optimieren, aber wie?

CouchCommerce Online-Shops für Tablet Besucher optimieren, aber wie? CouchCommerce Online-Shops für Tablet Besucher optimieren, aber wie? Wie Tablets die Post PC Commerce Ära einleiten Sie finden ein Video dieser Präsentation unter http://blog.couchcommerce.com/2012/06/03/couchcommerce-impressions-andvideo-from-the-shopware-community-day-2012/

Mehr

Mobile App Testing. Software Test im mobilen Umfeld ATB Expertentreff, Wien, 2013. Functional Test Automation Tools

Mobile App Testing. Software Test im mobilen Umfeld ATB Expertentreff, Wien, 2013. Functional Test Automation Tools Functional Test Automation Tools Mobile App Testing Software Test im mobilen Umfeld ATB Expertentreff, Wien, 2013 Presenter: Christoph Preschern (cpreschern@ranorex.com) Inhalte» Ranorex Company Overview»

Mehr

Programmieren im Web 2.x

Programmieren im Web 2.x Programmieren im Web 2.x Ein Überblick über die Webentwicklung im Jahre 2011 Johannes Leers 26. März 2012 1 Motivation 2 Web-Frameworks 3 Mobile Computing 4 WebGL 5 Cloud Computing 6 Fazit Native Programme

Mehr

1. Software-Plattform Android Android. Was ist Android? Managed Code, Angepasste Java Virtual Machine

1. Software-Plattform Android Android. Was ist Android? Managed Code, Angepasste Java Virtual Machine 1. Software-Plattform Android Android Was ist Android? Plattform und Betriebssystem für mobile Geräte (Smartphones, Mobiltelefone, Netbooks), Open-Source Linux-Kernel ab 2.6, aktuell 3.8 Managed Code,

Mehr

Christian Immler. Der Crashkurs für Android, und Windows Phone. Mit 309 Abbildungen

Christian Immler. Der Crashkurs für Android, und Windows Phone. Mit 309 Abbildungen Christian Immler Der Crashkurs für Android, und Windows Phone Mit 309 Abbildungen Inhaltsverzeichnis 1 - die Großen Drei 9 1.1 Kultspielzeuge für jedermann 10 1.2 Android: der Herausforderer 11 1.2.1 Die

Mehr

Web 2.0 Architekturen und Frameworks

Web 2.0 Architekturen und Frameworks Web 2.0 Architekturen und Frameworks codecentric GmbH Mirko Novakovic codecentric GmbH Quality Technische Qualitätssicherung in Software-Projekten mit Fokus auf Performance, Verfügbarkeit und Wartbarkeit

Mehr

HFT App. Prof. Dr. Gerhard Wanner Michael Kolb B.Sc. Sonntag, 26. Mai 13

HFT App. Prof. Dr. Gerhard Wanner Michael Kolb B.Sc. Sonntag, 26. Mai 13 HFT App Prof. Dr. Gerhard Wanner Michael Kolb B.Sc. 1 Die Hochschule 2 3 HFT Stuttgart Gegründet 1832 als Winterschule für Bauhandwerker 3.700 Studierende über 100 Professoren über 350 Lehrbeauftragte

Mehr

Value Added Services (VAS) Mobile. Kundenprojekte

Value Added Services (VAS) Mobile. Kundenprojekte Value Added Services (VAS) Mobile Kundenprojekte Live Reply arbeitet bereits seit 10 Jahren an mobilen en. en und Anwendungsfälle reichen von Widgets bis hin zu ausgeklügelten Symbian- oder Android-en

Mehr

Einführung in die Cross-Plattform Entwicklung Zugriff auf Sensoren mit dem Intel XDK

Einführung in die Cross-Plattform Entwicklung Zugriff auf Sensoren mit dem Intel XDK Einführung in die Cross-Plattform Entwicklung Zugriff auf Sensoren mit dem Intel XDK Einführung Dieses Hands-on-Lab (HOL) macht den Leser mit dem Intel XDK und dem Zugriff auf Sensoren vertraut. Es wird

Mehr

Sicherheit in Rich Internet Applications

Sicherheit in Rich Internet Applications Sicherheit in Rich Internet Applications Florian Kelbert 14.02.2008 Seite 2 Sicherheit in Rich Internet Applications Florian Kelbert 14.02.2008 Inhaltsverzeichnis Grundlagen Ajax und Mashups Adobe Flash-Player

Mehr

1. Java Grundbegriffe

1. Java Grundbegriffe 1. Java Grundbegriffe Geschichte von Java Programmieren mit Java Interpretieren vs. Kompilieren Java Byte-Code Jave Virtual Machine Arbeitsmaterialien Allgemeine Informatik 2 SS09 Folie 1.1 Java, eine

Mehr

Moderne Benutzeroberflächen für SAP Anwendungen

Moderne Benutzeroberflächen für SAP Anwendungen Seite 1 objective partner für SAP Erfahrungen mit dem UI-Development Kit für HTML5 (SAPUI5) - 19.06.2012 Seite 2 Quick Facts objective partner AG Die objective partner AG 1995 gegründet mit Hauptsitz in

Mehr

Mobile Lösungen im industriellen Umfeld

Mobile Lösungen im industriellen Umfeld Mobile Lösungen im industriellen Umfeld Jetzt die Chancen nutzen 13.05.2014 Thomas Sorg Inhalt Berner & Mattner Ein Beispiel zu BYOD Vorteile von BYOD Warum mobile Lösungen Industrielle Apps Technologische

Mehr

Programmieren I. Die Programmiersprache Java. www.kit.edu. Institut für Angewandte Informatik

Programmieren I. Die Programmiersprache Java. www.kit.edu. Institut für Angewandte Informatik Programmieren I Die Programmiersprache Java KIT Universität des Landes Baden-Württemberg und nationales Großforschungszentrum in der Helmholtz-Gemeinschaft www.kit.edu Eigenschaften von Java Java ist eine

Mehr

SMARTE WEB-TECHNOLOGIE FÜR HMIS DER GENERATION 4.0

SMARTE WEB-TECHNOLOGIE FÜR HMIS DER GENERATION 4.0 SMARTE WEB-TECHNOLOGIE FÜR HMIS DER GENERATION 4.0 PORTABEL INDIVIDUELL EFFIZIENT www.smart-hmi.de WebIQ Features List Das Framework WebIQ ist die ganzheitliche Lösung für die Erstellung von HMIs der Generation

Mehr

APPS ALS MARKETINGINSTRUMENT NUTZEN

APPS ALS MARKETINGINSTRUMENT NUTZEN APPS ALS MARKETINGINSTRUMENT NUTZEN Die Tendenz, mobile Endgeräte als Marketing- Plattform zu nutzen ist steigend. Laut einer Umfrage des Bundesverbandes Digitale Wirtschaft e.v. (BVDW) erwarten Beschäftigte

Mehr

Lessons Learned: Mobile CRM Integration

Lessons Learned: Mobile CRM Integration 1 Lessons Learned: Mobile CRM Integration 2 Enable Mobile Business Apps in Enterprises Weptun GmbH Vorstellung 3 Gründung 2010 18 Mitarbeiter 50 Apps für internationale Kunden umgesetzt Launch eigener

Mehr

VDLUFA-Schriftenreihe 1

VDLUFA-Schriftenreihe 1 VDLUFA-Schriftenreihe 1 Wie viele Apps sind ein LIMS? J. Flekna Pragmatis GmbH, Neufahrn 1. Einleitung Seitdem mobile Endgeräte massentauglich sind, ist die Bezeichnung App fester Bestandteil unseres zeitgeistigen

Mehr

Web und Mobile Apps Programmieren mit Dart

Web und Mobile Apps Programmieren mit Dart Web und Mobile Apps Programmieren mit Dart Marco Jakob Kalaidos Fachhochschule Schweiz majakob@gmx.ch Abstract: Bisher war es kaum realistisch, im Anfängerunterricht mobile oder webbasierte Applikationen

Mehr

Xamarin Applikationen Showcase aus der Praxis

Xamarin Applikationen Showcase aus der Praxis Xamarin Applikationen Showcase aus der Praxis Mark Allibone @mallibone Noser Engineering AG 2014, Alle Rechte vorbehalten. Erfahrungen Erfahrung ist der beste Lehrmeister. Nur das Schulgeld ist teuer.

Mehr

Die perfekte Online-Hilfe auf Basis von HTML5 und Open-Source- Komponenten. Jochen Marczinzik 11.04.2014, tekom Führjahrstagung

Die perfekte Online-Hilfe auf Basis von HTML5 und Open-Source- Komponenten. Jochen Marczinzik 11.04.2014, tekom Führjahrstagung Die perfekte Online-Hilfe auf Basis von HTML5 und Open-Source- Komponenten Jochen Marczinzik 11.04.2014, tekom Führjahrstagung 1 Zur Person Dipl.-Inf. (Univ.) Jochen Marczinzik 1993 1999 DATEV eg Entwickler

Mehr

Deutschland 8,50 Österreich 9,80 Schweiz 16,80 sfr. www.dotnet-magazin.de 7.2011. Outlook-Kalender in WPF

Deutschland 8,50 Österreich 9,80 Schweiz 16,80 sfr. www.dotnet-magazin.de 7.2011. Outlook-Kalender in WPF z.net MAGAZIN dot Alle Beispiele und Quellcodes zu den Artikeln dieser Ausgabe Bonus-Video von der BASTA! Spring 2011 Architektur für die Cloud Testversionen TeamPulse Ranorex Automation Framework dotpeek

Mehr

Ansätze für die Entwicklung von mobilen Business-Apps

Ansätze für die Entwicklung von mobilen Business-Apps Viele Unternehmen vollziehen derzeit den Schritt von klassischen Desktop-PCs und Notebooks auf mobile Geräte als Ergänzung oder gar als Ersatz für die herkömmliche Arbeitsumgebung. Apps auf mobilen Geräten

Mehr

Dies ist eine seit geraumer Zeit heiß

Dies ist eine seit geraumer Zeit heiß Mobile Anwendungen für mehrere Plattformen Viele Wege ohne König Es ist und bleibt ein Wunschtraum: einmal geschrieben, auf verschiedenen Plattformen lauffähig. Abstriche muss man bei der Performance oder

Mehr

Lieferung 7.2 Werkzeugintegration/- kette mit Konfiguration für automatisiertes Build und Testen

Lieferung 7.2 Werkzeugintegration/- kette mit Konfiguration für automatisiertes Build und Testen Lieferung 7.2 Werkzeugintegration/- kette mit Konfiguration für automatisiertes Build und Testen für das BMBF-Projekt Modellgetriebene agile Entwicklung für mobile Anwendungen (ModAgile Mobile) Arbeitspaket

Mehr

Ihr IT-Dienstleister aus Bonn

Ihr IT-Dienstleister aus Bonn Ihr IT-Dienstleister aus Bonn Wer wir sind Sie sind auf der Suche nach einem Partner, der Sie bei der technischen Umsetzung Ihrer Online-Projekte zuverlässig und kompetent unterstützt? Wer wir sind Die

Mehr

LaVida. Mobile Endgeräte. Andreas Neupert

LaVida. Mobile Endgeräte. Andreas Neupert LaVida Mobile Endgeräte Andreas Neupert Einleitung 1 33 Was? 1) Android a. Hardware b. Entwickeln i. Tools ii. Architektur & Konzepte iii. Google App Inventor c. Benutzen versus 2) WP 7 a. Hardware b.

Mehr

iphone Apps vs. Mobile Web

iphone Apps vs. Mobile Web iphone Apps vs. Mobile Web Smartphone-Anwendungen im Museumsbereich Vortrag iphone App vs. Mobile Web von Ines Dorian Gütt auf der Herbsttagung 2010 Seite 1/27 Inhalt Einführung iphone Apps Apps in itunes

Mehr

MOBILE ENTERPRISE APPLICATION PLATFORM (MEAP)

MOBILE ENTERPRISE APPLICATION PLATFORM (MEAP) MOBILE ENTERPRISE APPLICATION PLATFORM (MEAP) Oliver Steinhauer.mobile PROFI Mobile Business Agenda MOBILE ENTERPRISE APPLICATION PLATFORM AGENDA 01 Mobile Enterprise Application Platform 02 PROFI News

Mehr

Windows 8 die Tablet-Plattform fü r Unternehmen

Windows 8 die Tablet-Plattform fü r Unternehmen Windows 8 die Tablet-Plattform fü r Unternehmen Inhaltsverzeichnis Einleitung... 3 Anforderungen des Fachbereiches... 3 Geschwindigkeit... 3 Einfache Bedienung... 3 Displaygröße... 3 Gesamtgröße und Gewicht...

Mehr

Cross Platform Development Heute Windows, morgen Android, übermorgen Xbox

Cross Platform Development Heute Windows, morgen Android, übermorgen Xbox Cross Platform Development Heute Windows, morgen Android, übermorgen Xbox Daniel Meixner Technical Evangelist Microsoft Deutschland GmbH @DanielMeixner DevelopersDevelopersDevelopersDevelopers.Net Programming

Mehr

Einbindung von Web Services in mobilen Applikationen

Einbindung von Web Services in mobilen Applikationen Einbindung von Web Services in mobilen Applikationen Vorlesung im Sommersemester 2015 1 Aufgabenbeschreibung 2 Aufgabe 1 Entwickeln Sie auf der Basis eines oder mehrerer von Ihnen gewählten Webservices

Mehr

Walkabout: Location Based Services mit Android und dem Google Phone

Walkabout: Location Based Services mit Android und dem Google Phone Walkabout: Location Based Services mit Android und dem Google Phone Teilbereich 1: Die Android Plattform für mobile Geräte (Software) Von: Sebastian Schul Inhalt Einleitung Was ist Android Exkurs: Wie

Mehr

Diese Zahlen belegen recht eindrucksvoll, dass Bibliotheken ihr InformaUonsangebot auch auf mobile Endgeräte ausrichten müssen.

Diese Zahlen belegen recht eindrucksvoll, dass Bibliotheken ihr InformaUonsangebot auch auf mobile Endgeräte ausrichten müssen. 1 Eine Studie von Morgan Stanley aus dem Jahr 2009 sagte voraus, dass die Verkäufe von Smartphones im Jahr 2012 jene von Desktop- und Notebook- PCs überholen würden. Quelle: Meeker, Mary. DeViL, John.

Mehr

App-Entwicklung mit Titanium

App-Entwicklung mit Titanium App-Entwicklung mit Titanium Masterstudienarbeit von Betreuung Prof. Dr. M. von Schwerin App-Entwicklung mit Titanium 1 Gliederung 1.Titanium Eine Einführung 2.Programmierschnittstelle (API) 3.Module 4.App

Mehr

Mit Cloud Power werden Sie zum

Mit Cloud Power werden Sie zum Mit Cloud Power werden Sie zum Windows 8 und Windows Phones Apps Mark Allibone Noser Engineering AG History Channel Computing Technology 1960 Mainframe Computing 1970 Mini Computing 1980 Personal Computing

Mehr

CLR CIL MCS ECMA-335. Linux.Ne t. 2005 Albrecht Liebscher, Erlanger Linux Tage

CLR CIL MCS ECMA-335. Linux.Ne t. 2005 Albrecht Liebscher, Erlanger Linux Tage C# CLR CIL MCS ECMA-335 Linux.Ne t Was ist.net? Microsoft Homepage:.NET is the Microsoft Web services strategy to connect information, people, systems and devices through software. Mono Handbuch:.Net besteht

Mehr

Workshop I. Technische Differenzierung mobiler Kommunikationslösungen am Beispiel NPO/NGO Kommunikation. 7. Juni 2011

Workshop I. Technische Differenzierung mobiler Kommunikationslösungen am Beispiel NPO/NGO Kommunikation. 7. Juni 2011 Workshop I Technische Differenzierung mobiler Kommunikationslösungen am Beispiel NPO/NGO Kommunikation 7. Juni 2011 Übersicht è Native Apps è Web-Apps è Mobile Websites è Responsive Design Mobile Kommunikation

Mehr

eclipse - Entwicklungsumgebung und mehr ETIS SS05

eclipse - Entwicklungsumgebung und mehr ETIS SS05 eclipse - Entwicklungsumgebung und mehr ETIS SS05 Gliederung Motivation Geschichte Architektur Platform Runtime Eclipse Platform Java Development Tools (JDE) Plugin Development Environment (PDE) Zusammenfassung

Mehr

Mobile Enterprise Application Platforms

Mobile Enterprise Application Platforms Mobile Enterprise Application Platforms 17. April 2013 Fachbereich Wirtschaft und Gesundheit Prof. Dr. Volker Wiemann volker.wiemann@fh bielefeld.de +49 (0) 521/106 389 Problem 0. Ausgangslage Blackberry

Mehr

Mobile Application Plattforms

Mobile Application Plattforms Mobile Application Plattforms Trends in der Kommunikationstechnik DI Franz Geischläger Agenda Mobile Applications Allgemeine Betrachtung Mobile Betriebssysteme und Plattformen Die wichtigsten Vertreter

Mehr

inserteffect GmbH Kurzvorstellung und Arbeitsbeispiele

inserteffect GmbH Kurzvorstellung und Arbeitsbeispiele inserteffect GmbH Kurzvorstellung und Arbeitsbeispiele WebApps ios Apps App Konzeption Plattformübergreifend Mobile Usability Android Apps Hybrid Apps Mobile Design Branchenübergreifend Windows (Phone)

Mehr

Systemanforderungen Verlage & Akzidenzdruck

Systemanforderungen Verlage & Akzidenzdruck OneVision Software AG Inhalt Asura 9.5, Asura Pro 9.5, Garda 5.0...2 PlugBALANCEin 6.5, PlugCROPin 6.5, PlugFITin 6.5, PlugRECOMPOSEin 6.5, PlugSPOTin 6.5,...2 PlugTEXTin 6.5, PlugINKSAVEin 6.5, PlugWEBin

Mehr

PC-Schule für Senioren. Windows Phone. für Einsteiger

PC-Schule für Senioren. Windows Phone. für Einsteiger PC-Schule für Senioren Windows Phone für Einsteiger INHALT 7 IHR WINDOWS PHONE 7 Aus grauer Vorzeit: Die Historie 8 Windows Phone und die Konkurrenz 11 Los geht s: Das Microsoft-Konto 15 Ein Gang um das

Mehr

Unterscheidung Tablet PC & Tablet Computer. Tablet PC; ursprüngliche Bezeichnung von Microsoft. Tablets gemeint

Unterscheidung Tablet PC & Tablet Computer. Tablet PC; ursprüngliche Bezeichnung von Microsoft. Tablets gemeint Überblick Unterscheidung Tablet PC & Tablet Computer Tablet PC; ursprüngliche Bezeichnung von Microsoft Mit Tablet Computer sind die heutigen gängigen Mit Tablet Computer sind die heutigen gängigen Tablets

Mehr

Fachhochschule Lübeck Fachbereich Elektrotechnik und Informatik

Fachhochschule Lübeck Fachbereich Elektrotechnik und Informatik Fachhochschule Lübeck Fachbereich Elektrotechnik und Informatik BACHELORARBEIT Evaluierung von Cross Mobile Frameworks von Markus Domin Vorgelegt von: Markus Domin Erstbetreuer: Zweitbetreuer: Prof. Dr.

Mehr