Implementierung eines Multi- Device Interfaces zur Zeiterfassung fur Microsoft Dynamics NAV

Transkript

1 Leopold-Franzens-University Innsbruck Institute of Computer Science Research Group Quality Engineering B A C H E L O R A R B E I T Implementierung eines Multi- Device Interfaces zur Zeiterfassung fur Microsoft Dynamics NAV Alex Untertrifaller Supervisor: Prof. Dr. Ruth Breu Innsbruck, 28. Januar 2015

2 Abstract: Mobile Cross Platform Development Solutions are becoming increasingly important, therefore it is becoming crucial for suppliers to offer applications that run on all platforms and to appeal as many users as possible. In this thesis the development of a TimeSheet application for the company EOS Solutions AG from Bozen are implemented and described. Xamarin Framework and MVVMCross Framework were used to build this application. Xamarin Framework allows to write the application in C# and MVVMCross Framework allows the implementation of the MVVM Pattern for the application. The TimeSheet application was developed for Android, ios, and WinRT with a common Core Library, which contains the whole logic. The application allows users to insert and see times with the ERP system Microsoft Dynamics NAV on mobile devices. 1

3 Abstract: Mobile Cross Platform Development Lösungen gewinnen stetig an Bedeutung, da es immer wichtiger ist, Apps für alle Plattformen anzubieten, um so viele Nutzer wie möglich anzusprechen. In der vorliegenden Arbeit wird die Entwicklung der TimeSheet App für das Unternehmen Eos Solutions AG aus Bozen implementiert und beschrieben. Für die Erstellung der Applikation wurde das Xamarin Framework und das MVVMCross Framework verwendet. Durch das Xamarin Framework konnte die App in C# erstellt werden und das MVVMCross Framework ermöglicht die Umsetzung des MVVM Patterns für die App. Die TimeSheet App wurde für Android, ios und WinRT erstellt, mit einer gemeinsamen Core Library, welche die gesamte Logik enthält. Die App ermöglicht es Benutzern, Zeiten über mobile Endgeräte in das ERP System Microsoft Dynamics NAV einzutragen und zu betrachten. 1

4

5 Inhaltsverzeichnis Einleitung 7 Cross Platform Development 9 1 Allgemein Native Apps Web Apps Hybrid Apps Cross Platform Native Solutions Mobile Cross Development Möglichkeiten Anforderungen und Ziele 15 Methoden und Technologien 19 3 Frameworks Xamarin MVVMCross SQLite.NET Tools Microsoft Dynamics NAV Visual Studio Xamarin Studio Xcode Android Studio SOAP Web Service Architektur 35 6 Web Service Core Library User Interface Android User Interface ios User Interface WinRT User Interface Language Tool Verteilen der Applikationen Evaluierung 53 3

6 Auswertung 57 Zusammenfassung und Ausblick 59 4

7 Abbildungsverzeichnis 1 Xamarin Architektur Xamarin ios Compiler Xamarin ios Compiler Xamarin Compiler Xamarin Forms MVVM Bindings MVVM Sequenzdiagramm NAV Architektur Xamarin Insights Lifecycle SOAP TimeSheet App Architektur Xamarin Package Struktur Android UI Android App Home Bildschirm Android App Zeitintervalle ios Home Screenshot WinRT Home Language Tool Gemeinsam genutzter Code pro App Codeanteil der verschiedenen Projekte

8 Aus Gründen der Lesbarkeit wird in dieser Arbeit auf die genderspezifische Schreibweise verzichtet. Sämtliche personenbezogene Bezeichnungen sind geschlechtsneutral zu verstehen. 6

9 Einleitung Mobile Endgeräte wurden in den letzten Jahren immer beliebter und werden auch in Zukunft nicht an Popularität verlieren. Somit steigt auch die Anzahl an mobilen Applikationen. Da es mittlerweile viele verschiedene Anbieter für mobile Betriebssysteme gibt, sollten Applikationen für alle und nicht nur für einzelne Betriebssysteme entwickelt werden. Dies erfordert viel Zeit und Kosten und zudem ist eine spezifische Kenntnis in der Entwicklung für verschiedene Betriebssysteme notwendig. Aus diesem Grund werden Cross Platform Development Lösungen immer populärer und ständig weiterentwickelt. Ziel dieser Bachelorarbeit ist die Implementierung einer TimeSheet App für das Unternehmen EOS Solutions AG aus Bozen und dessen Evaluierung. Für die App-Entwicklung wird Xamarin und MVVMCross Framework verwendet. Die TimeSheet App ermöglicht dem Benutzer das Erfassen der Zeit, die z.b. für Projekte, Abwesenheiten oder Serviceleistungen aufgebracht wird. Die erfassten Daten werden im ERP System Microsoft Dynamics NAV eingetragen und weiter verwaltet. Zu Beginn der Arbeit wird allgemein auf das Cross Platform Development eingegangen, es wird erklärt, was man darunter versteht und welche Möglichkeiten es gibt, um mobile Applikationen plattformunabhängig zu erstellen. In Kapitel 2 werden einige Frameworks vorgestellt, die dies ermöglichen. Im Kapitel Anforderungen und Ziele geht es um die Anforderungen, die an die Applikationen gestellt werden und darum, welche Ziele bei der Entwicklung verfolgt werden. Anschließend werden die verwendeten Frameworks vorgestellt und genauer erklärt. Das werden Xamarin, MVVMCross und SQLite.NET sein. Danach werden die Tools vorgestellt, die verwendet werden, um die Apps zu erstellen. Im Kapitel Architektur geht es um den Aufbau der Applikation. Hier werden der Web Service, die Core Library und die verschiedenen Oberflächen der Apps genauer betrachtet. Außerdem wird das Language Tool vorgestellt, welches im Laufe der Arbeit erstellt wird und in zukünftigen Applikationen weiter verwendet werden kann. Am Ende der Arbeit werden die erstellten Programme ausgewertet, es wird ein Ausblick auf die Zukunft gegeben und im Schlussteil wird noch einmal die gesamte Arbeit zusammengefasst. 7

10

11 Cross Platform Development 1 Allgemein Die Inhalte dieses Kapitels wurden aus der Bachelorarbeit Evaluation, Bewertung und Implementierung verschiedener Cross-Platform Development Ansatze fur Mobile Internet Devices auf Basis von Web-Technologien von Michael Jaser entnommen [13]. Mobile Applikationen gewinnen stetig an Bedeutung; es gibt immer mehr mobile Geräte, die das Bedienen von Applikationen verändert haben. Durch Touchscreens erfährt der Benutzer eine neue Möglichkeit der Interaktion mit der App. Es wird also immer wichtiger, plattformspezifische Design Patterns in den Applikationen umzusetzen, damit der User die App intuitiv bedienen kann und sich auskennt. Die Anzahl verschiedener mobiler Endgeräte wächst immer weiter. Durch die verschiedenen Plattformen, die sich im Laufe der Zeit durchgesetzt haben, ist es wichtig, die Apps auf so vielen Plattformen wie möglich anzubieten. Dies erfordert aber viel Zeit und Ressourcen. Durch das Cross Platform Development bietet sich eine neue Möglichkeit, Apps so zu entwickeln, dass diese auf allen Plattformen laufen. Dadurch erspart man sich Entwicklungskosten und auch die Entwicklungszeit wird stark verkürzt. Bei einer Cross Platform Applikation wird ein Code geschrieben, welcher auf mehreren Betriebssystemen laufen kann. Man unterscheidet zwischen folgenden App-Typen: 1.1 Native Apps Native Apps sind auf das jeweilige Betriebssystem angepasste Anwendungen, die durch eine vom Hersteller bereitgestellte API auf die Hardware des Endgerätes zugreifen können. Die Programmierung dieser Apps erfolgt meist durch das vom Hersteller zur Verfügung gestellte Entwicklungstool; die Verteilung der Apps geschieht über eine zentrale Stelle, den Stores der Anbieter. Dieser Ansatz ist der am weitesten verbreitete. Vorteile: Hohe Performance Hardware/ Software APIs (z.b. Kamera, GPS etc.) Vertrieb über App Stores 9

12 Nachteile: Plattformbindung Hohe Entwicklungskosten Kosten für Lizenzen (SDK oder Vertriebskosten) 1.2 Web Apps Web Apps sind mobile Webseiten, welche durch HTML, JavaScript und CSS erstellt werden. Der Begriff wird hauptsächlich im Zusammenhang mit HTML5 genannt. Das Design der Web Apps ist an das der nativen Apps angepasst. Die technische Grundlage ist dieselbe wie bei Webseiten, jedoch wird durch HTML5 eine bessere Plattformintegration erreicht, z.b. durch die Integration von Sensoren. Diese Art der App Entwicklung ist noch relativ jung, da die Browser der Smartphones HTML, JavaScript und CSS erst seit Kurzem unterstützen. Im Gegensatz zu Desktop Web Apps gibt es bei mobilen einen bedeutenden Vorteil: Die bekanntesten Plattformanbieter setzen auf die Browser Engine Web Kit, die zu einer Art Standard geworden ist und somit das Entwickeln erleichtert. Bisher waren Web Apps ziemlich eingeschränkt. Durch die Verwendung von HTML5 sind dem Entwickler neue Möglichkeiten gewährleistet, sodass die App offline verfügbar gemacht oder auf Sensoren zugegriffen werden kann. Es bleiben jedoch einige Einschränkungen bei der Erstellung von Web Apps, so kann z.b. nicht auf alle Hardware und Software APIs zugegriffen werden, was das Entwickeln immer noch einschränkt. Vorteile Geringe Entwicklungskosten Plattformübergreifende Apps Einfache Verteilung Nachteile Eingeschränkter Zugriff auf Plattformfunktionen Kein Zugang zu nativen Apps Teilweise schlechte Performance 10

13 1.3 Hybrid Apps Hybrid Apps sind eine Mischung aus Web Apps und Native Apps. Hybrid Frameworks setzen bei der Erstellung auf Webtechnologien und ermöglichen eine plattformübergreifende Entwicklung. Diese Anwendungen sind kaum von den nativen Apps zu unterscheiden. Einige Anbieter bieten auch Container an, welche auf Funktionen des Betriebssystems und der Hardware zugreifen können. So kann mit einer Hybrid App auf den Kalender zugegriffen werden oder das Telefon zum Vibrieren gebracht werden. Jedoch stehen auch hier noch nicht alle Funktionen der Plattform APIs zur Verfügung. 1.4 Cross Platform Native Solutions Bei dieser Lösung wird der Code in einer Sprache geschrieben und dann in den nativen Code und Features kompiliert. Hier stehen auch gerätespezifische APIs zur Entwicklung der Anwendungen zur Verfügung. Vorteile Geringe Entwicklungskosten Plattformübergreifende Apps Natives Look and Feel Plattform APIs können verwendet werden Nachteile Drittanbieter-Framework liegt zwischen der App und dem Endgerät Cross Platform Development bietet viele Vorteile in der Entwicklung, aber auch einige Nachteile gegenüber nativ entwickelten Applikationen. Native Applikationen laufen direkt auf den von den Herstellern zur Verfügung gestellten APIs und sind dadurch auch schneller als Cross Compiled Applications. Diese verwenden ein weiteres Framework von Drittanbietern, welches zwischen der App und dem Endgerät liegt. Ein Nachteil von nativen Applikationen ist, dass sich der Programmierer in den verschiedenen Entwicklungssprachen und Architekturen einer nativen App auskennen muss. Dadurch dass es mehrere Plattformen gibt, sind spezifische Kenntnisse notwendig. Bei der Cross Plattform Lösung hingegen muss nur eine Sprache erlernt werden. Die Fehleranfälligkeit kann reduziert werden, indem nur ein Code erstellt werden muss, außerdem wird das Testen bei weniger Code erleichtert. 11

14 2 Mobile Cross Development Möglichkeiten In diesem Kapitel werden kurz einige Frameworks zur Erstellung von Cross Platform Mobile Apps vorgestellt. Die nachstehend genannten Frameworks sind einige der bekanntesten und am häufigsten verwendeten im Mobile Cross Plattformbereich. Zur Erstellung der Apps für diese Arbeit wurde das Xamarin Framework verwendet. Xamarin Xamarin ist ein kostenpflichtiges Framework zur Erstellung von Apps in C#. Es basiert auf dem MonoTouch Framework, welches das Entwickeln von Apps in C# ermöglicht. Die Apps werden dabei nativ kompiliert [3]. Xamarin Framework wird im Kapitel 3.1 genauer behandelt. PhoneGap PhoneGap ist ein Framework zur Erstellung von Hybrid Apps. Zur Entwicklung der Apps wird dabei auf die herkömmlichen Webtechnologien wie HTML, CSS und JavaScript gesetzt. PhoneGap ermöglicht außerdem den Zugriff auf die plattformspezifischen APIs und dadurch auf Daten, die sich auf dem Gerät befinden oder z.b. auf das GPS-Signal. [18]. Appcelerator Titanium Titanium ist ein Framework, das von Appcelerator erstellt wurde. Die Apps werden in JavaScript erstellt und nativ kompiliert. Dabei wird kein HTML5 und CSS verwendet, sondern ausschließlich JavaScripts zur Erstellung der Apps. Die App wird in ios und Android nativ kompiliert und läuft am Ende mit einem nativem Code [9]. Sencha Touch Sencha Touch ist ein von Sencha Inc. implementiertes Framework zur Erstellung von Webapplikationen. Die Apps werden mit JavaScript, HTML5 und CSS3 erstellt. Dabei erhalten die Apps ein natives Look and Feel. Sencha Touch ist frei erhältlich unter der GPLv3 Lizenz. Die Apps sind über alle Browser darstellbar oder sie können auch in Native Apps eingepackt werden, über das Sencha eigene Tool oder über PhoneGap, um sie in den verschiedenen Stores zu vertreiben [10]. 12

15 Unterstützte Betriebssysteme: ios Android Windows Windows Mac Blackberry Phone/RT Desktop Desktop Xamarin PhoneGap Appcelerator Sencha Touch Mobile Cross Development Eigenschaften: In den folgenden Tabellen werden die Eigenschaften der verschiedenen Frameworks veranschaulicht und aufgezeigt, worin sie sich unterscheiden. Dabei wurden folgende Eigenschaften verwendet: Programmiersprache: Die Programmiersprache, die beim Entwickeln der App verwendet wird. Natives Look & Feel: Erhalten die Apps bei der Erstellung mit dem Framework ein Natives Look & Feel? Offline: Können die Apps offline verfügbar gemacht werden? Hardware API: Kann bei der Erstellung auf die Hardware API der verschiedenen Plattformen zugegriffen werden? Kosten: Entstehen Kosten beim Verwenden des Frameworks? Code Sharing: Kann der gleiche Code für mehrere Plattformen und somit für verschiedene Apps wieder verwendet werden? Programmiersprace Natives Look & Feel Offline Xamarin C# PhoneGap HTML5, CSS und JavaScript Appcelerator JavaScript Sencha Touch HTML5, CSS und JavaScript Hardware API Kosten Code Sharing Xamarin 30 Tage Testversion kostenlos PhoneGap teils eine App kostenlos Appcelerator teils Comunity Edition kostenlos Sencha Touch teils 10 Apps und 10 Developer kostenlos 13

16

17 Anforderungen und Ziele Die Entwicklung der App TimeSheet wurde in Zusammenarbeit mit der Firma EOS Solutions AG aus Bozen durchgeführt. Das Unternehmen ist spezialisiert auf den Vertrieb und die Anpassung des ERP-Systems Microsoft Dynamics NAV. Die Applikation soll eine Schnittstelle zur erleichterten Eingabe für die Zeiterfassung bieten. Microsoft Dynamics NAV hat bereits selbst eine solche Funktion integriert, jedoch soll nun auch eine für mobile Endgeräte bereitgestellt werden. Die Funktion sollte auf den Betriebssystemen der meist verbreiteten mobilen Geräte laufen: Android, ios und Windows. Aus diesem Grund wurde das Framework Xamarin für die Entwicklung ausgewählt. Der Benutzer muss sich über den im Microsoft Dynamics NAV verwendeten Benutzernamen und das Passwort einloggen. Die Daten der Microsoft Dynamics NAV Datenbank werden einmal am Tag synchronisiert und lokal abgespeichert, dies reicht laut EOS Solutions AG aus. Nun hat der Benutzer die Möglichkeit, seine Arbeitszeiten zu stoppen oder nachträglich einzutragen. Zum Eingeben der Daten muss zunächst der Typ ausgewählt und die erforderlichen Daten eingetragen werden. Durch Klicken auf den Start-Knopf beginnt der Timer, welcher am Bildschirm angezeigt wird. Beim Klicken auf den Stopp-Knopf wird der Timer angehalten und die ermittelten Daten werden, soweit eine Internetverbindung besteht, sofort an den Server gesendet und zudem lokal abgespeichert. Bereits eingetragene Zeiten können nochmals über eine Liste eingesehen, kontrolliert und bestätigt werden. Erst nach der Bestätigung der Daten werden sie vom ERP System übernommen, zuvor werden sie zwischengespeichert. Sollte also eine eingetragene Zeit nicht korrekt sein, so kann diese gelöscht oder bearbeitet werden. Einmal abgesendete Zeiten werden jedoch endgültig im Dynamics NAV eingetragen und können auch nur dort wieder gelöscht bzw. geändert werden. Für die Zeiterfassung kann zwischen folgenden Typen unterschieden werden. Je nach Typ gibt es verschiedene Felder, die noch zusätzlich ausgefüllt werden müssen: Jobs: Hier sind Tasks enthalten und zusätzlich kann noch ein Kommentar eingetragen werden. Services: Ein Service kann ausgewählt werden und zusätzlich kann noch ein Kommentar eingetragen werden. 15

18 Ressources: Hier kann ein Kommentar eingegeben werden. Absences: Es kann eine Abwesenheit mit zusätzlichem Kommentar eingetragen werden. Die Applikationen bieten auch die Möglichkeit, die oben genannten Typen in einer Liste zu betrachten, das wäre also eine Aufzählung aller verfügbaren Jobs, Tasks, Ressourcen, Leistungen und Absenzen. Diese Daten sollen beim Anmelden synchronisiert werden, sodass sie auch offline angezeigt werden können. Anforderungen an die mobilen Applikation Natives Look and Feel: Die Apps sollen eine intuitive Bedienung zulassen. Das bedeutet sie sollten die plattformspezifischen Design Patterns implementieren, sodass der Benutzer die übliche Navigation und die üblichen Eingabebedingungen vorfindet. Offline Modus: Alle Apps sollen auch offline funktionieren, sodass der Benutzer bei fehlender Internetverbindung keinerlei Einschränkungen hat. Sprachunterstützung: Die Apps sollen in Englisch, Deutsch und Italienisch zur Verfügung stehen. Die jeweilige Sprache sollte je nach Gerätesprache automatisch eingestellt werden; sollte eine Sprache eingestellt sein, die die App nicht unterstützt, wird Englisch verwendet. Verbindung zum Web Service: Die Apps sollen sich mit dem Web Service verbinden, um die Daten jederzeit übertragen zu können. Nicht funktionale Anforderungen Netzwerkverbindung: Es wird überwacht, ob eine Internetverbindung besteht. Bei fehlender Verbindung läuft die App offline, bei Wiederherstellung der Verbindung wird das von der App erkannt und sie kann die Daten online aktualisieren. Das Gerät sollte in der Lage sein, sich immer wieder mit dem Internet zu verbinden, ansonsten werden die Daten nicht aktualisiert und es kann zu Inkonsistenzen führen. Lokaler Datenspeicher: Die App soll auch offline funktionieren, deshalb ist das Offline-Speichern von Daten erforderlich. Anforderungen an den Web Service Der Web Service wird in Microsoft Dynamics NAV erstellt und auch von diesem Programm zur Verfügung gestellt. Es soll soviel Logik wie möglich Dynamics NAV seitig gemacht werden, dadurch werden nämlich die mobilen Applikationen besser gekapselt, sodass die Applikationen selbst kaum Rechenleistung in Anspruch nehmen. Das Holen von benötigten Daten aus der NAV Datenbank: Die benötigten Daten können nur vom ERP-System selbst geholt und gegebenenfalls verändert werden. 16

19 Das Einfügen der Daten in die NAV Datenbank: Microsoft Dynamics NAV kann die Daten vor dem Eintragen auf Vollständigkeit überprüfen, anschließend werden sie eingetragen oder eine Fehlermeldung gesendet. 17

20

21 Methoden und Technologien In diesem Kapitel werden die Frameworks zur Erstellung der Applikationen vorgestellt. Es wurden die Frameworks Xamarin und MVVMCross sowie die SQLite.NET Library verwendet. Auch die Tools, die bei der Erstellung der Apps sehr hilfreich waren, werden kurz beschrieben. Programmiert wurde hauptsächlich in Visual Studio 2013, aber auch das Xamarin Studio, Xcode und Android Studio spielten bei der Entwicklung eine bedeutende Rolle. Zum Ausführen, Testen und Debuggen der Applikationen, waren die Simulatoren für Android und ios sowie einige mobile Endgeräte wichtig. 3 Frameworks 3.1 Xamarin Die Inhalte dieses Kapitels werden hauptsächlich aus folgenden zwei Quellen entnommen: MeteoCheck Relaunch mit Xamarin von Patrick Pulfer [16] und Xamarin - Understanding the Xamarin Mobile Platform aus der Xamarin Dokumentation [20]. Xamarin ist ein im Jahre 2011 gegründetes Unternehmen, welches auf das Mono Framework aufbaut. Das Mono Framework ist eine Open Source Implementierung des Microsoft.NET Frameworks basierend auf dem ECMA Standard fur C# und der Common Language Runtime. Xamarin bietet die Möglichkeit, native Applikationen in der gleichen Programmiersprache, nämlich C#, zu schreiben. Die objektorientierte Programmiersprache C# bietet hier einige Vorteile gegenüber den Sprachen Objective C und Java, wie LINQ fur den Zugriff auf Daten, funktionale Konstrukte mit Lambdas oder die Unterstutzung fur eine parallele Programmierung. Bestehende native Implementierungen in Objective C oder Java können durch eine deklarativen Binding-Syntax eingebunden werden. Somit können auch Komponenten von Drittanbietern verwendet werden. Xamarin bietet eine native Plattform API an. Alle Funktionen, die von Android und ios zur Verfügung gestellt werden, sind ebenfalls in C# verfügbar. Die Syntax wurde 19

22 jedoch an die für C# üblichen Konventionen angepasst, so werden z.b. alle Methoden groß geschrieben. Die Architektur für eine App wird wie in der Abbildung 1 dargestellt aussehen. Die App besteht aus vier Projekten: der Core Library, dem ios Projekt, dem Android Projekt und dem WinRT Projekt. Die Core Library spielt hier die bedeutendste Rolle. Dort wird nämlich die gesamte Logik implementiert, wie Web Service Verbindungen und das Speichern von Daten in den SQLite Datenbanken. In den plattformspezifischen Projekten wird die Core Library eingebunden und stellt die Funktionen für die UIs zur Verfügung. Diese bestehen aus zwei Layern: Zum einen dem App Layer, in dem plattformspezifische Funktionen implementiert werden, wie etwa die Sprache des Gerätes zu finden oder die lokale Datenbank anzulegen und den Pfad dazu zu generieren. Zum anderen bestehen die UIs aus dem User Interface Layer, in dem die verschiedenen Views erstellt werden. Hier ist der größte Unterschied zwischen den Projekten zu erkennen. In ios werden die UIs in XIB Dateien geschrieben und die Bindings in C# erstellt. In Android werden die UIs in AXML Dateien samt Bindings erstellt. In WinRT wird die UI in XAML samt den Bindings erstellt. Zur Erstellung der UIs werden plattformspezifische Kenntnisse vorausgesetzt, in der Logik hingegen kann alles in der Sprache C# erstellt werden. Abbildung 1: Architektur einer Xamarin App 20

23 Je nach Plattform wird der Code verschieden in den nativen Code kompiliert. ios - C# wird ahead-of-time (AOT) in ARM Assembler Sprache kompiliert. Das.NET Framework ist enthalten, wobei alle unbenutzten Klassen entfernt werden, um die Größe der Applikation zu verringern. Apple lässt keine Generierung des Laufzeitcodes zu, deshalb werden einige Sprachfunktionen auf ios nicht unterstützt. Siehe dazu Abbildung 2 Abbildung 2: Native Kompilierung einer Xamarin App in ios. [5] Android - C# wird zu IL kompiliert und mit MonoVM und JIT ing eingepackt. Unbenutzte Klassen werden während des Verlinkens entfernt. Die Applikation läuft side-by-side mit Java/Dalvik und interagiert mit den nativen Typen über JNI. Siehe dazu Abbildung 3 Abbildung 3: Native Kompilierung einer Xamarin App in Android. [5] Windows Phone - C# wird zu IL kompiliert und von der eingebauten Laufzeitumgebung ausgeführt, hier wird kein Xamarin benötigt, da C# die native Sprache von Windows Phones ist. Die Abbildung 4 zeigt exakt den Aufbau des Xamarin Compilers und welche Frameworks auf welchen Plattformen verwendet werden. Dadurch wird auch klar, welche bedeutende 21

24 Rolle die Frameworks für die Erstellung der Apps mit Xamarin haben und wie die Plattform APIs verwendet werden können. Abbildung 4: Xamarin Compiler Architektur. [1] Xamarin bietet zwei Möglichkeiten an Entwicklungsumgebungen: Xamarin Studio bietet eine IDE zur Erstellung von MAC, ios und Android Apps an. Enthalten sind auch grafische UI Designer für Android und ios. Xamarin Studio wird weiter entwickelt und erhält durch laufend neue Features, wie Sketches, eine Echtzeit Code Auswertung. Weitere Features können auf der Webseite www. xamarin.com nachgelesen werden. Visual Studio ist eine von Microsoft erstellte Entwicklungsumgebung. Xamarin bietet hierfür ein Plugin an. Ebenfalls enthalten sind hier grafische Designer zur Erstellung von Android und ios UIs. Weitere Details zu den Entwicklungsumgebungen werden in Kapitel 4 genauer erläutert. Xamarin Forms Xamarin Forms ermöglicht das Erstellen einer UI in C#. Die UI wird dann auf die Android, ios und WinRT spezifischen Komponenten kompiliert und erhält ein natives Look and Feel. Wie in Abbildung 5 gut zu erkennen, wird dadurch ein höheres Codesharing erreicht, wobei aber die herkömmliche Implementierung noch deutlich plattformspezifischer programmiert werden muss. Xamarin Forms ist im Moment noch in der Entwicklungsphase und somit noch nicht vollkommen ausgereift. Xamarin arbeitet aber stark an dessen Weiterentwicklung, es ist 22

25 also davon auszugehen, dass Xamarin Forms in Zukunft sicher noch weitere Vorteile mit sich bringen wird. Abbildung 5: Links ist die traditionelle Entwicklungsstrategie von Xamarin abgebildet, rechts die mit Xamarin Forms [6] 3.2 MVVMCross Die Inhalte dieses Kapitels beruhen hauptsächlich auf folgenden Internetseiten: MvvM- Cross GitHub [17] von Stuart Lodge und MVVM von Amit Bahree [2]. MVVMCross ist ein von Stuart Lodge entwickeltes Cross Platform MVVM Development Framework, welches die Umsetzung des MVVM Patterns für mobile Cross Plattform Applikationen ermöglicht. MVVMCross ist ein OpenSource Framework und unterstützt folgende Plattformen: Silverlight für WP7, WP8 Mono für Android (oder Xamarin.Android) MonoTouch für ios (oder Xamarin.iOS) WinRT XAML Framework für Windows 8 Store Apps WPF Mono für Mac (oder Xamarin.Mac) 23

26 MVVM Pattern MVVM ist ein von Microsoft entwickeltes Design Pattern. Es ist eine Spezialisierung des MVC Patterns und wurde von Martin Fowler eingeführt. Dieses Pattern besteht aus drei Rollen: View, Model und ViewModel. View und Model haben denselben Zweck wie im MVC Pattern. Das ViewModel in MVVM ist ein spezieller Controller für die View, es ist dafür zuständig, Daten und Logik für die View zur Verfügung zu stellen, dabei hat das ViewModel aber keinerlei Kenntnisse über die Komponenten der View. Es gibt hier also eine klare Trennung zwischen View und ViewModel, was auch die Hauptcharakteristik des MVVM Patterns ist. Von einer anderen Perspektive aus gesehen, kann man sagen, dass das View Layer wie eine UI Projektion des ViewModels ist. Oberflächen können somit leicht ausgetauscht werden, ohne die Logik der Software zu verändern. Da das ViewModel keinerlei Kenntnisse über UI Komponenten der View besitzt, braucht es eine Möglichkeit, diese zu verbinden, was durch Bindings in der View geschieht. Der Binder ist für die Kommunikation der Komponenten in der View mit der dazugehörigen Logik zuständig. Zur besseren Veranschaulichung siehe Abbildung 6. Abbildung 6: Darstellung des MVVM Pattern Bindings [2] Zur besseren Veranschaulichung wird in der nächsten Abbildung ein Sequenzdiagramm dargestellt. Das Beispiel ist ein simples Hello World Programm, das durch einen Klick auf den Button Show, Hello World! auf dem Bildschirm ausgibt. 1. Der Button Show wird gedrückt, dadurch wird eine Aktion ausgeführt. 2. Ein Event wird im Binder angestoßen. 3. Der Binder findet die richtige Logik im ViewModel und führt sie aus. 4. Daten werden aus der Datenbank gelesen. 5. Der Binder wird über eine Änderung informiert. 24

27 Abbildung 7: Darstellung des MVVM Pattern Bindings mittels eines simplen Hello World Beispiels [2] 6. Der Binder holt sich die Daten aus dem ViewModel. 7. Die View bekommt vom Binder ein Update über die veränderten Daten und kann diese dann anzeigen. Die folgenden Informationen werden aus der GitHub Wiki des MVVM Frameworks übernommen [11]. MVVMCross bietet das MVVM Pattern unter anderem auch für Xamarin an. Dieses Pattern eignet sich hier besonders gut, da es bei der Entwicklung mit Xamarin nur einen Core und mehrere Oberflächen für verschiedenen Plattformen gibt. MVVMCross Binding Typen: In MVVMCross gibt es vier verschiedene Binding Typen: JSON: Wurde in den ersten Versionen von MVVMCross verwendet, wird aber seit der Version 3 nicht mehr unterstützt. Ein Beispiel dazu: { Text { Path : TweetText, Converter : RemainingLength, ConverterParameter :140 } } Swiss: hat JSON abgelöst, da es eine klarere und leichter lesbare Struktur verwendet. Beispiel: Text TweetText, Converter=RemainingLength, ConverterParameter=140 25

28 Fluent: Zusätzlich zu den Bindings in XML bietet MVVMCross auch die Möglichkeit, Bindings im C# Code zu erstellen. Beispiel: this.creatingbinding(label).for(l => l.text).to(vm => vm.tweettext).withconversion("remaininglength", 140); Tibet, Rio: sind Erweiterungen von Swiss und Fluent Bindings. Beispiele für Bindings mit MVVMCross in Xamarin Das folgende Beispiel soll zeigen, wie in den verschiedenen Oberflächen Bindings auf das ViewModel erstellt werden können. Zuerst das ViewModel. Dieses enthält ein Attribut FirstName mit Getter und Setter. RaisePropertyChanged wird beim erneuten Setzen der Variable aufgerufen, um den Binder auf Änderungen im Inhalt zu informieren. private string firstname public string FirstName { get { return firstname ; } s e t { firstname = value ; RaisePropertyChanged ( ( ) => FirstName ) ; } } Die drei nachstehenden Beispiele sollen simple bindings in den verschiedenen Oberflächen zeigen. In Android wird die UI in AXML geschrieben und die Bindings werden dort direkt eingebunden. In WinRT werden sie in XAML Format geschrieben und auch dort eingebunden. In ios wird die UI mittels eines Designers erstellt, weshalb ein Binding nur über den C# Code in der View möglich ist. WinRT Binding: <TextBlock Text="{Binding FirstName}" /> Android Binding: <TextView android:layout_width="fill_parent" android:layout_hight="wrap_content" local:mvxbind="text FirstName" /> ios Binding: 26

29 var label = new UILabel(); Add(label); this.createbinding(label).to<firstviewmodel>(vm => vm.firstname).apply(); MVVMCross bietet vier verschiedene Binding Modes an: One-Way: Transferiert Werte vom ViewModel zur View One-Way-To-Source: Transferiert Werte von der View zum ViewModel Two-Way: Transferiert Werte in beide Richtungen One-Time: Transferiert den Wert einmal beim Setzen in der View vom ViewModel zur View Ein weiteres sehr hilfreiches Tool ist der Value Converter. Value Converter müssen das Interface IValueConverter implementieren, welches zwei Methoden zur Verfügung stellt: Convert ist ein Mechanismus, um Werte zwischen dem ViewModel und der View zu verändern. ConvertBack ist ein Mechanismus, um Werte zwischen der View und dem View- Model zu verändern. In den meisten Fällen wird nur die Convert Methode implementiert, da auch nur diese gebraucht wird. Das folgende Beispiel zeigt einen Converter, der einen String in Integer aufgrund der Länge des Strings konvertiert. public class LengthValueConverter : MvxValueConverter<string, int> { protected override int Converter(string value, Type targettype, object parameter, CultureInfo cultureinfo) { if (value == null) return 0; return value.length; } } 27

30 3.3 SQLite.NET Die Inhalte dieses Abschnitts stammen aus der Xamarin Dokumentation Using SQLite.NET ORM [21] und dem Buch Using SQLite von Jay A. Kreibich [7]. SQLite ist ein RDBMS - Relational Database Management System. Es wird verwendet, um Inhalte auf relationale Datenbanken abzubilden. SQLite besitzt keine wie für Datenbanken übliche Client/Server Struktur. Die SQLite Datenbank Engine kann direkt in die Anwendung integriert werden. Die einzige verteilte Ressource ist die Datenbanken-Datei, die im Speicher liegt. SQLite.NET ist ein ORM - Objekt Relational Mapping. Das ist eine Library, die es ermöglicht, Objekte automatisch in Datenbanken anzulegen, ohne SQL Befehle zu schreiben. Xamarin empfiehlt die Verwendung von SQLite.cs, die unter gefunden werden kann. Verwendung: Folgende Zeile muss in der Datei, die über eine Datenbankverbindung verfügen soll, eingebaut werden. using SQLite; Hiermit wird eine Verbindung mit der Datenbank hergestellt. Sollte es noch keine geben, wird eine neue hergestellt. var db = new SQLiteConnection (dbpath); Daten speichern: db.createtable<stock> (); db.insert (newstock); Daten lesen: var stock = db.get<stock>(id); var stocklist = db.table<stock>(); Daten löschen: var rowcount = db.delete<stock>(somestock.id); Es gibt aber auch die Möglichkeit, SQL Befehle zu schreiben: var stocksstartingwitha = db.query<stock>( "SELECT * FROM Items WHERE Symbol =?", "A"); foreach (var s in stocksstartingwitha) { Console.WriteLine ("a " + s.symbol); } 28

31 4 Tools Zur Erstellung der Apps für Android, ios und WinRT waren die folgenden Tools, die im nächsten Abschnitt genauer erklärt werden und deren Nutzen ausführlicher erläutert wird, sehr hilfreich. 4.1 Microsoft Dynamics NAV Microsoft Dynamics NAV ist ein von Microsoft entwickeltes ERP System. Das System selbst beinhaltet eine beträchtliche Menge an Funktionen, es bietet aber auch die Möglichkeit, die interne Datenstruktur und Logik über eine Entwicklungsumgebung zu ändern und so das Produkt für Kunden zu spezifizieren. Dadurch war es möglich, die bereits implementierte Zeiterfassungsfunktion zu erweitern und einen Web Service einzugliedern. Dieser Schritt war sehr wichtig, um die mobilen Applikationen mit dem System zu verbinden. Abbildung 8: Drei-Schichten-Layout des Microsoft NAV Systems [14] 29

32 Microsoft Dynamics NAV ist in drei Schichten aufgebaut: Microsoft Dynamics NAV Windows Client: Der Client kann auf mehreren PCs gleichzeitig verwendet werden und stellt eine Oberfläche für die Verwendung der Daten zur Verfügung. Microsoft Dynamics NAV Server Computer: Der Server verwaltet die Daten. Er ist für das Speichern, Verarbeiten und Lesen der Daten zuständig. An dieser Stelle wurde der Web Service, der für die Applikationen zuständig ist, eingegliedert. SQL Server Database: Der SQL Server ist für das persistente Speichern der Daten zuständig. 4.2 Visual Studio 2013 Visual Studio ist eine von Microsoft zur Verfügung gestellte Entwicklungsumgebung, um in C# zu programmieren. Es enthält alle für Entwicklungsumgebungen typischen Features, wie Rich Text Editor, Debugger, Error Assistent. Mit Visual Studio können aber nicht nur C# Dateien editiert werden, sondern auch alle für diese Arbeit relevanten Dateiformate, wie XAML oder AXML. Der in Visual Studio eingebaute Debugger war beim Testen sehr hilfreich. Visual Studio unterstützt aber neben C# auch noch andere Sprachen wie Visual Basic oder F#. Team Foundation Server TFS - Ein sehr wichtiger Aspekt beim Entwickeln von Applikationen ist die Art wie Teammitglieder kommunizieren können. Dabei spielt das von Microsoft entwickelte Tool TFS eine große Rolle und stellt einige Funktionen zur Verfügung [4]: Projekt Management Versionskontrolle Testfallmanagement Build Automatisierung Reporting Feedback Management Das Unternehmen Eos Solutions AG stellte einen TFS Server für diese Arbeit zur Verfügung. ReSharper - ist ein von Jetbrains entwickeltes Plugin für Visual Studio. Es unterstützt C#, VB.NET, XAML, JavaScript, TypeScript, XML, HTML, CSS, ASP.NET, ASP.NET 30

33 MVC, NAnt und MSBuild Scripts. ReSharper erleichtert dem Entwickler das Schreiben, Korrigieren und Refactoring des Codes. [8] Xamarin Plugin - Das von Xamarin zur Verfügung gestellte Plugin ermöglicht das Schreiben von Android und ios Apps in Visual Studio. Es sind grafische UI Designer für Android und ios enthalten. Zum Ausführen von Android Apps wird die Android Debug Bridge ADB verwendet. Es kann entweder im Simulator oder auf einem Endgerät ausgeführt und gedebuggt werden. Für ios wird ein Mac OS benötigt, auf dem Xamarin.iOS Build Host laufen muss. Visual Studio kann sich über das Plugin mit dem Build Host verbinden, um den Code zu kompilieren und auszuführen. Auch hier kann ein Simulator auf dem Mac-Pc gestartet oder direkt auf ein Endgerät übertragen werden. 4.3 Xamarin Studio Xamarin Studio Xamarin Studio ist die von Xamarin zur Verfügung gestellte Entwicklungsumgebung zur Erstellung mobiler Applikationen. Dabei enthält sie alle wichtigen Funktionen einer Entwicklungsumgebung, z.b. den Debugger oder die Source Control. Die Entwicklungsumgebung steht für Windows und MAC zur Verfügung. Weitere Details und Features dazu können auf nachgelesen werden. Xamarin Insights Xamarin Insights ist ein Monitoring Tool zur Überwachung von Apps. Durch das einbinden der Library Xamarin.Insights in die Apps und das Angeben eines API-Schlüssels kann die App überwacht werden. Dies funktioniert, auch wenn das Endgerät keine Internetverbindung hat. In diesem Fall werden die Daten zu einem späteren Zeitpunkt übertragen. Auftretende Fehler und Interaktionen der User werden dabei in einer Webansicht dargestellt, so können Fehler, die bei den Benutzern auftreten, angeschaut und deren Auslöser leicht nachvollzogen werden. Xamarin Profiler Xamarin Profiler ist ein Tool zum Überprüfen des Codes und dessen Performance. Es hilft dem Entwickler beim Finden von Speicherlecks, Bottlenecks und Performance Problemen. 31

34 Abbildung 9: Xamarin Insights Lifecycle [19] Xamarin Scans Auf der Website von Xamarin unter scan.xamarin.com können kompilierte DLL und EXE Dateien hochgeladen werden. Dort wird dieser.net Code dann auf die Kompatibilität mit Xamarin überprüft. Es wird ein Report ausgegeben, der zeigt, wie viel Code pro Plattform geteilt werden kann. Außerdem werden weitere wichtige Hinweise gegeben, welche.net Komponenten nicht auf den Mobilgeräten funktionieren. 4.4 Xcode Xcode ist die Entwicklungsumgebung von Apple zum Entwickeln von Applikationen, die auf Apple Endgeräten laufen sollen. In dieser Arbeit wurde vor allem der UI Designer von Xcode verwendet, um die Oberfläche der ios App zu gestalten. Xamarin Studio arbeitet bei der Erstellung der UIs stark mit Xcode zusammen. So öffnet sich z.b. beim Öffnen einer XIB Datei automatisch Xcode zum Editieren der grafischen Oberfläche. Beim Schließen von Xcode synchronisiert Xamarin Studio die in Xcode geänderten Dateien. 32

35 4.5 Android Studio Android Studio ist eine von Google entwickelte Entwicklungsumgebung basierend auf der von Jet Brains entwickelten Entwicklungsumgebung IntelliJ. Sie enthält einen grafischen UI Designer, der während der Entwicklung der Android App eine angenehmere Alternative zu dem von Xamarin zur Verfügung gestellten UI Designer war. 5 SOAP Web Service Die folgenden Informationen entstammen der Bachelorarbeit Mobile Sales von Manuel Bonatti [12]. Microsoft Dynamics NAV stellt einen SOAP Web Service zur Verfügung. Bei SOAP handelt es sich um ein Protokoll zur Übertragung von XML basierten Nachrichten. Damit ist es nicht nur möglich, Daten zu übertragen, sondern auch Funktionen aufzurufen. Um diese Funktionen aufzurufen, müssen die notwendigen Parameter, falls vorhanden, übertragen werden, dann wird die Funktion am Server ausgeführt und anschließend das Ergebnis, falls eines existiert, zurückgegeben. Beim Aufruf einer Serverfunktion werden der Funktionsname und die Parameter zuerst serialisiert, also in XML umgewandelt. Danach erfolgt die Datenübertragung. Sobald die Daten am Server angekommen sind, werden diese wieder deserialisiert und der Server kann die Funktion aufrufen. Sollte die Funktion ein Resultat liefern, wird dieses wieder serialisiert, übertragen und auf dem Endgerät wieder deserialisiert. Die Abbildung 10 stellt den Ablauf grafisch nochmal genauer dar. Vorteile von SOAP: XML ist die einzige verwendete Datenstruktur Umfangreicher Web Service durch eine Vielzahl an möglichen Operationen Zugriff auf Funktionen, welche auf Daten agieren Zugriff durch Name der Operation Stellt eine zusätzliche Sicherheitsstufe für direkte und indirekte, Verbindungen, zusammen mit Datensicherheit und -schutz, zur Verfügung durch dazwischen liegende Knoten. Unterstützt ACID Transaktionen Verfügt über eine automatische Erkennung von nicht oder fehlerhaft übertragenen Nachrichten über dem Web Service 33

36 Abbildung 10: SOAP Abfrage [12] Nachteile von SOAP: Etwas langsamere Übertragung Zustandslosigkeit - Session-Daten können nicht gespeichert werden [15] 34

37 Architektur In diesem Kapitel wird die Architektur des gesamten Systems genauer erklärt. Das System besteht aus dem Web Service, der in Microsoft Dynamics NAV erstellt wurde; aus der Core Library, die aus reinem C# Code besteht und alle wichtigen Funktionen beinhaltet und aus drei UIs, die je nach Plattform spezifisch erstellt wurden. Da die App in mehreren Sprachen angeboten werden soll, musste nach einer geeigneten Lösung für die Umsetzung in den verschiedenen Oberflächen gesucht werden. Ich habe hier ein Tool entwickelt, das mir die Umsetzung in den verschieden Sprachen erleichtert hat. Abbildung 11: TimeSheet App Architektur 35

38 Die Abbildung 11 veranschaulicht die Architektur der gesamten Applikation. Alle Komponenten, die eine Rolle spielen, werden dargestellt. Der Web Service: Bestehend aus dem Microsoft Dynamics NAV und dem Microsoft SQL Server. Die Core Library mit der Verbindung zum Web Server und der SQLite Datenbank. Die drei verschiedenen Oberflächen ios, Android und WinRT. Im Folgenden wird genauer auf die Implementierung der verschiedenen Teile der Applikationen eingegangen. 6 Web Service Es wurde ein SOAP Web Service verwendet, welcher durch Microsoft Dynamics NAV erstellt werden konnte. Aufgrund der Problemstellung wurde dieser Web Service als beste Möglichkeit ausgewählt. Damit die im ERP System zur Verfügung gestellten Funktionen aber in den Apps verwendet werden können, wurde eine WSDL Datei mit den gesamten Spezifikationen bereitgestellt. Diese ermöglicht der App, die genauen Funktionsnamen und Parameter zu wissen. Da diese Spezifikationen in einem XML Format sind, kann die Datei ohne Probleme und in jeder Programmiersprache leicht eingebunden und verwendet werden. Es gibt auch noch andere Technologien, wie REST Web Services, jedoch bietet SOAP eine bessere Sicherheitsverwaltung an. Außerdem ist es durch die SOAP Variante einfacher möglich, in der Applikation Funktionen des Web Services aufzurufen, was in diesem Fall von Vorteil ist, da das ERP System die Daten verwaltet. 7 Core Library In der Abbildung 12 ist die Struktur der Projekte für die Apps zu sehen. Wie dort auch deutlich zu erkennen, ist die Core Library der Kern der Anwendungen und jede App referenziert die Core Library und somit auch ihre gesamte Funktionalität. Im Folgenden wird diese Struktur genauer erklärt: Die Core Library ist der Kern der Anwendung, in der alle wichtigen Funktionen und Daten vorhanden sind. Die Library beinhaltet folgende Pakete, die nachstehend genauer erklärt werden. BusinessLayer Das BusinessLayer beinhaltet alle Objekte, die Daten repräsentieren sollen. Diese Klassen erweitern die BusinessEntityBase Klasse, die Attribute beinhaltet, welche alle Objekte haben sollen: eine ID, eine Nummer und einen Zeitstempel. Die Objekte werden dann mit Hilfe der sich im DataLayer befindenden Klassen persistent in einer SQLite Datenbank geschrieben. Diese Klassen repräsentieren hauptsächlich Daten. 36

39 Abbildung 12: Xamarin Package Struktur DataAccessLayer Dieses Layer beinhaltet den DataManager, der für das Managen der Daten zuständig ist. Es beinhaltet Funktionen, die Daten vom Server holen und in die lokale Datenbank speichern. Er führt Funktionen aus dem DataLayer und dem ServiceAccessLayer zusammen. Im DataAccessLayer wird zusätzlich ein Scheduler implementiert, der beim Fehlen einer Internetverbindung die Daten lokal abspeichert und diese zu einem späteren Zeitpunkt synchronisiert. DataLayer Ist für das persistente Speichern der Daten auf den mobilen Endgeräten zuständig. Es beinhaltet die von Xamarin zur Verfügung gestellte Klasse SQLite.cs, welche im Kapitel 3.3 genauer beschrieben wird. Zusätzlich enthält es die JobTimeDb Klasse. Diese initialisiert die Datenbank, sie erstellt die Tabellen und füllt diese auch. Alle Datenbankabfragen werden asynchron abgearbeitet, damit der weitere Programmfluss nicht unterbrochen wird. An einigen Stellen ist jedoch eine sequentielle Abfrage notwendig, da auf das Ergebnis gewartet werden muss, so z.b. beim Offline Login. Exceptions In diesem Layer wurden einige spezielle Exceptions implementiert. Diese implementieren u.a. ein Errorhandling. 37

40 Helpers Beinhalten folgende Klassen: AsyncHelper: Eine Klasse, die hilft, asynchrone Methoden zu synchronisieren. CommentToStringConverter: Konvertieren das CommentObject in einen String und wird bei den Bindings in der UI verwendet. CryptoHelper: Dient zur Verschlüsselung der Login-Daten beim Speichern in die lokale Datenbank. DateTimeHelper: Enthält einige Methoden, um die Datumsein- und ausgabe zu formatieren und konvertieren. URIHelper: Enthält die URL zum Web Service. XamarinInsigths: Ist eine Hilfsklasse zum Ein- und Ausschalten des Xamarin Monitoring Tools. OptionStringHelper: Der OptionString wird von Microsoft Dynamics NAV übermittelt und enthält die Typen (siehe Kapitel 2). Dieser ist jedoch in einem String und die einzelnen Typen sind mit einem Komma getrennt. Mit dieser Klasse wird der String in ein Array umgewandelt. Language Dieses Layer beinhaltet alle Sprachen, die angeboten werden. Sie werden mit Hilfe des Language Tools erstellt und gefüllt. Das Language Tool wird im Kapitel 9 genauer erklärt. Service References Alle Klassen des ServiceAccessLayers sind für die Kommunikation mit dem Web Service zuständig. Sie wurden mit Hilfe von Visual Studio automatisch generiert und bieten alle Funktionen, die der Web Service beinhaltet. Alle Funktionen sind asynchron. ServiceAccessLayer Enthält Klassen zur Synchronisation der Daten mit dem Web Service. ViewModel Repräsentiert eine View im Code und ist so strukturiert, dass es für jede View ein View- Model besitzt. Die Views greifen über Bindings auf die Daten und Operationen zu, die das ViewModel zur Verfügung stellt. Dieses Layer ist eine sehr wichtige Komponente zur Implementierung des MVVM Patterns. Jede ViewModel Klasse erweitert die BaseViewModel Klasse, die Funktionen und Attribute, welche alle Klassen brauchen, zur Verfügung stellt, wie etwa das Language Objekt. 38

41 8 User Interface Jede Plattform hat ihre eigenen Oberflächen und muss deshalb je nach Plattform spezifisch programmiert werden. Im folgenden Kapitel werden diese genauer erklärt. 8.1 Android User Interface Die Android UIs werden im axml Format geschrieben, welches eine Erweiterung des von Android üblichen XML Formats zur Erstellung von UIs ist. Es gibt bei der Erstellung der UIs keinen Unterschied zwischen XML und AXML, deshalb habe ich den Designer von Android Studio zur Erstellung der UI verwendet. In Android wird üblicherweise das MVC Pattern implementiert. Bei der Erstellung wurden Activities und Fragments verwendet. Zu jeder AXML Datei gibt es auch eine View, die in C# geschrieben wird. Dort werden OnCreate, OnCreate- View usw. implementiert. Da ich das MVVM Pattern verwendet habe, sind diese Klassen aber so gut wie leer und dienen nur zum Binden der UI an das ViewModel. Das nachstehende Beispiel zeigt ein Fragment, welches das JobsFragment Layout anzeigt und das JobViewModel an dieses Layout bindet. [Activity] class JobsFragment : MvxFragment { public override View OnCreateView(LayoutInflater inflater, ViewGroup container, Bundle savedinstancestate) { var ignored = base.oncreateview(inflater, container, savedinstancestate); } return this.bindinginflate(resource.layout.jobsfragment, null); } public new JobViewModel ViewModel { get { return (JobViewModel)base.ViewModel; } set { base.viewmodel = value; } } Um diese View anzuzeigen: ShowViewModel<JobViewModel>(); 39

42 Diese Vorgehensweise ermöglicht es, Views im ViewModel und somit in der Core Library aufzurufen, damit wird auf allen Plattformen die Navigation zwischen den verschiedenen Views gleich gemacht. Das JobsFragment sieht wie folgt aus: <?xml version="1.0" encoding="utf-8"?> <LinearLayout xmlns:android=" xmlns:local=" android:layout_width="match_parent" android:orientation="vertical" <Mvx.MvxListView android:layout_width="match_parent" android:layout_height="wrap_content" android:layout_margintop="4dp" android:layout_gravity="center_vertical" android:layout_weight="1" local:mvxbind="itemssource Joblist" /> </LinearLayout> Das Layout zeigt eine Liste mit den im ViewModel befindlichen Daten. Das ViewModel enthält eine Liste mit den Jobs; diese Joblist wird von der View eingebunden. Es enthält auch ein Attribut CurrentJob, in dem die jeweilige Jobauswahl gespeichert wird. public class JobViewModelCore : BaseViewModel { protected JobLocal _currentjob; private List<JobLocal> _listjobs; public JobViewModelCore() { Reset(); } public List<JobLocal> Joblist { get { return _listjobs?? (_listjobs = DataManager.ReadJobs() 40

43 } } as List<JobLocal>); public JobLocal CurrentJob { get { return _currentjob; } } } set { } _currentjob = value; if (_currentjob!= null) { ShowViewModel<TaskViewModel>(); } RaisePropertyChanged("CurrentJob"); Zum UI Design: Die App fordert zu Beginn eine Anmeldung des jeweiligen Benutzers. Die Daten werden an den Web Service übermittelt, dieser überprüft sie und schickt ein Ergebnis zurück. Wenn die Authentifizierung am Server erfolgreich ist, dann werden die Login-Daten verschlüsselt am Gerät gespeichert, sodass ein Offline Login zu einem späteren Zeitpunkt möglich ist. Der Login wird wie in Abbildung 13a dargestellt. Sobald der Benutzer sich angemeldet hat und über eine Internetverbindung verfügt, werden die Daten synchronisiert und in der lokalen Datenbank abgespeichert. Das Synchronisieren wird einmal pro Tag durchgeführt. Der Benutzer wird nun zum Hauptbildschirm weitergeleitet. Bei der Entwicklung der Android App wurde besonders darauf geachtet, dass das Darstellen der UIs sowohl auf Smartphones als auch auf Tablets gut aussieht. Außerdem sollte sowohl der Landscapeals auch der Portrait-Modus in beiden Apps möglich sein. Die App wurde in einem responsive Design erstellt, sodass sie sich auf alle Größen automatisch anpasst. In Abbildung 14 werden sowohl Tablet- als auch Smartphone-Screenshots zur besseren Veranschaulichung abgebildet. Der Home-Bildschirm besteht aus drei Komponenten: Die erste Komponente dient zum Auswählen eines Jobs, einer Ressource oder eines Services. Sobald einer dieser Typen ausgewählt wird, erscheinen je nach Auswahl verschiedene Felder, die ausgefüllt werden müssen. Sobald alle notwendigen Felder ausgefüllt sind, kann auf den Start-Knopf gedrückt werden und die Stoppuhr 41

44 (a) Android App Login Bildschirm (b) Das Menü ist sowohl für Smartphones als auch für Tablets verfügbar und soll den Benutzer das Navigieren durch die App erleichtern. Abbildung 13: Schreenshots der Android UI beginnt zu zählen. Beim Klick auf den Stopp-Knopf werden die Daten lokal abgespeichert und an den Web Service geschickt. Die zweite Komponente gibt Informationen über das zuletzt eingetragene Zeitintervall. Das Datum und die Dauer werden angezeigt. Die dritte Komponente zeigt Statistiken der letzten Woche an. Es wird die gesamte Dauer an gestoppten Zeiten der jeweiligen Woche angezeigt. Außerdem wird die Anzahl an Jobs, Ressourcen, Services und Absenzen angezeigt. Zum Navigieren in der App wird das für Android typische Slide Menu verwendet, welches in Abbildung 13b zu sehen ist. Durch das Klicken auf die drei Striche im oberen linken Eck der App oder durch Wischen von links nach rechts öffnet sich das Menü. 42

45 Abbildung 14: Home Bildschirm von Android Smartphone und Tablet App Der Benutzer kann nicht nur Zeiten stoppen, sondern diese auch nachträglich eintragen, er kann wieder den Typ auswählen und die dazugehörigen Felder ausfüllen und anschließend ein Start- und Enddatum sowie eine Start- und Endzeit eingeben. Auch diese Daten werden lokal abgespeichert und einmal täglich an den Server gesendet. Im Abschnitt Zeitintervalle, welcher in Abbildung 15 zu sehen ist, kann der Benutzer seine eingetragenen Daten einsehen. Die Bilder der jeweiligen Zeile zeigen an, ob die eingetragenen Zeiten bereits bestätigt oder noch zu bestätigen sind. Daten, die noch nicht bestätigt worden sind, können noch gelöscht oder bearbeitet werden, die bereits bestätigten hingegen sind definitiv eingetragen und können nur noch im Microsoft Dynamics NAV bearbeitet werden. Beim Klicken auf eine Zeile der Liste, die die time sheets anzeigt, öffnet sich ein Popup, welches das Bestätigen oder Löschen eines Zeitintervalls ermöglicht. Im Abschnitt Abwesenheiten, Jobs und Service werden Listen zu den jeweiligen in der Datenbank befindlichen Daten angezeigt. 43

46 (a) Zeitintervalle (b) Popup zum Lo schen und U bertragen von Zeitintervallen Abbildung 15: Ansicht der eingetragenen Zeitintervalle 8.2 ios User Interface In ios wurden verschiedene Oberfla chen fu r die Endgera te iphone und ipad entwickelt, um die gesamte Darstellungsfla che des Endgera tes auszunutzen. Hier musste jedoch fu r beide Typen von Gera ten eine eigene Oberfla che geschrieben werden. In ios wurden die UIs in XIB Files erstellt, welche sich nur u ber Xcode o ffnen und vera ndern lassen. Zu jeder Komponente in der UI wird im Headerfile eine Referenz zu diesem Objekt angelegt, um spa ter dann auf dieses zugreifen zu ko nnen und die Bindings zu erstellen. Zur Veranschaulichung nachstehend das JobsView Beispiel: Es existieren zwei XIB Dateien: JobsView ipad.xib JobsView iphone.xib 44