Mobility / Software-Entwicklung

Xamarin – Ein Erfahrungsbericht

Firmen erhalten häufig den Auftrag, ein und dieselbe mobile App für mehrere Plattformen (z.B. Android, iOS, Windows Phone) zu entwickeln. Anstatt die App nun für jede dieser Plattformen einzeln zu entwickeln, werden oft Crossplattform-Lösungen bevorzugt. Ziel ist es dadurch den Aufwand für die Entwicklung und wenn möglich auch Kosten zu sparen. Dies hat meinen Kollegen Anton Kalcik und mich dazu bewegt uns Xamarin als Crossplattform-Lösung etwas genauer anzusehen.

Modern Smartphones

Was ist Xamarin? Was ist Xamarin.Forms?

Xamarin bietet eine Möglichkeit der Crossplattform-Entwicklung und setzt dabei auf „Code-Sharing“ – der gemeinsamen Verwendung von Programmcode für mehrere Plattformen. Als Programmiersprache werden C# oder VB.NET verwendet. Zusätzlich können moderne und gängige .NET Konzepte eingesetzt werden. Im Gegensatz zu Web-Apps soll ein natives Aussehen der Benutzeroberfläche garantiert werden. Der Vorteil von Xamarin ist, dass native Apps (natives Aussehen und native Perfomance) für jede der gewünschten Plattformen erstellt werden und trotzdem der Großteil des Programmcodes nur einmal geschrieben werden muss. Dies verringert den Aufwand – und somit die Kosten –  für die Erstellung einer solchen App erheblich.

Mit Xamarin können nun große Teile des Programmcodes gemeinsam verwendet werden. Im Wesentlichen handelt es sich dabei um die Businesslogik und Datenzugriffe auf Datenbanken, Netzwerk oder sonstige Speicherorte. Um nun für jede Zielplattform ein natives User Interface (mit plattformspezifischen Textfeldern, Buttons, etc.) zu garantieren und auch die unterschiedlichen Design Guidelines zu berücksichtigen, muss für jede Plattform dieses User Interface einzeln zusammengebaut werden.

Da jedoch die Entwicklung des User Interfaces einer mobilen App laut unseren Erfahrungen einen erheblichen Teil des Gesamtentwicklungsaufwandes darstellt, wurde eine Lösung gesucht um auch das User Interface nur einmalig entwickeln zu müssen und auf allen Zielplattformen verwenden zu können. Dafür stellt Xamarin das Xamarin.Forms Framework zur Verfügung. Mit dem Xamarin.Forms Framework wird ein gemeinsames User Interface (UI) erstellt und auf der jeweiligen nativen Plattform dann mit den nativen UI Elementen dargestellt. Einige Teile der App sind dennoch plattformspezifisch zu lösen.

Xamarin mit/ohne Xamarin.Forms

 

Pakete, Lizenzen, Kosten

Xamarin wird dem Entwickler in Form von Paketen zur Verfügung gestellt. Mit dem Paket Xamarin.Android können Apps für Android Smartphones und Tablets sowie Android Wear Apps erstellt werden. Um Apps für iPhone, iPad und WatchKit Apps entwickeln zu können benötigt man das Xamarin.iOS Paket. Mit dem dritten Paket Xamarin.Mac werden Apps für Mac erstellt. Zusätzlich kann man auch für Windows Phone und Windows Store entwickeln. Hierfür benötigt man jedoch keine Pakete, da Apps für diese beiden Plattformen ohnehin schon in C# und .NET erstellt werden.

Für die Pakete Xamarin.Android, Xamarin.iOS und/oder Xamarin.Mac benötigt man nun Lizenzen. Diese werden pro Entwickler und pro Paket erworben. Es gibt für die Xamarin Plattform vier verschiedene Lizenzen. Für den betrieblichen Einsatz kommen aber nur die Business Lizenz um 999$/Jahr und die Enterprise Lizenz um 1899$/Jahr in Frage. Mit beiden können vollwertige Xamarin Apps auch mit Xamarin.Forms sowohl im Xamarin Studio als auch im Visual Studio erstellt werden. Die Enterprise Lizenz beinhaltet noch zusätzliche Supportleistungen (One Business Day SLA, Technical Kick-off Session, uvm.).

 

Was benötige ich um mit Xamarin arbeiten zu können?

Was bzw. welche Tools benötige ich nun zur Entwicklung mit Xamarin? Es gibt 2 Entwicklungsumgebungen für die Entwicklung mit Xamarin und zwar das von Xamarin zur Verfügung gestellte Xamarin Studio oder ein Plugin für Visual Studio. Mit Xamarin Studio für Mac kann man für Android und iOS entwickeln und mit Xamarin Studio für Windows kann man nur für Android Anwendungen erstellen. Da man mit Visual Studio für Android, iOS als auch Windows Phone entwickeln kann und wir Visual Studio ohnehin schon benutzen, haben wir uns für Visual Studio als Entwicklungsumgebung entschieden.

Bei der Entwicklung auf Visual Studio wird ein Mac als Build Host für iOS benötigt. Da ohne Apple Zertifikate und code-signing Tools (also Signatur der Apps) das Ausführen auf einem iPhone nicht funktioniert und da auch der iPhone Simulator nur auf einem Mac läuft, wird unbedingt ein solcher benötigt.

Ausgeführt werden die Apps nun auf einem Emulator oder auf iOS auf einem Simulator. Weiters können die Apps auch auf den Geräten selbst ausgeführt werden. Für iOS und Windows Phone muss dafür jedoch das Gerät als Entwicklergerät registriert werden und eine Developer Lizenz wird benötigt.

Infrastruktur

 

Das Arbeiten mit den Emulatoren/ dem Simulator

Bei der Entwicklung mit Xamarin wird viel mit Emulatoren/Simulatoren gearbeitet. Wir dürfen Sie hier auf einen Blog unseres Kollegen Michael Hofstätter Emulatoren für die Entwicklung mit Android verweisen, wo erklärt wird wie die Emulatoren erheblich beschleunigt werden können, um ein angenehmeres Arbeiten mit Emulatoren zu gewährleisten.

 

Aufbau und Architektur

Wir haben unsere Applikation für Android, iOS und Windows Phone in Layer gegliedert. Die unteren Layer stellen die Repositories, Data Access Layer und Business Layer dar. Diese Layer beinhalten keinen User Interface Code und können vollständig für alle Plattformen verwendet werden. Darüber befindet sich der Applikation Layer, in dem sich der gemeinsame Anteil des User Interface Codes, welcher mit Xamarin.Forms erstellt wird, befindet. Ganz oben finden wir nun die plattformspezifischen Projekte für die einzelnen Plattformen, in denen sich nur rein plattformspezifischer Programmcode befindet.

Layer

 

Bei der Entwicklung von Xamarin Apps muss man sich für eine von zwei möglichen Codesharing-Strategien entscheiden. Diese sind: Shared Projects oder Portable Class Libraries. Bei Shared Projects werden, wie auch bei Portable Class Libraries (PCL) vier (Visual Studio-) Projekte angelegt: ein Projekt für den gemeinsamen Code, sowie je ein Projekt für Android, iOS und Windows Phone.

Shared ProjectPortable Class Library

 

 

Shared Project Portable Class Library
Im gemeinsamen Projekt können mit Hilfe von sogenannten Compiler Direktiven Verzweigungen für einzelne Plattformen (z.B. Android) erstellt werden. Das gemeinsame Projekt (die PCL) bildet eine eigene Output-Assembly.
Das gemeinsame Projekt bildet nach der Übersetzung (Kompilation) keine eigene Output-Assembly, sondern wird in die drei plattformspezifischen Projekte aufgenommen. Die PCL wird von den drei plattformspezifischen Projekten referenziert.
Vorteile:

  • Komplettes .NET Framework verwendbar
Vorteile:

  • Lesbarer Code
  • Output-Assembly kann von anderen Projekten referenziert werden
  • Gemeinsamer Code und plattformspezifischer Code werden sauber voneinander getrennt
Nachteile:

  • Durch Compiler Direktiven Code nicht gut lesbar
  • Keine saubere Trennung von gemeinsamen und plattformspezifischen Code
Nachteile:

  • Nur Subset vom .NET Framework verwendbar
  • Nicht alle NuGet packages für PCLs verfügbar

 

Ziel ist sowohl bei Shared Projects als auch bei Portable Class Libraries möglichst viel Code im gemeinsamen Projekt und möglichst wenig in den drei plattformspezifischen Projekten zu platzieren, da dieser Code sonst drei mal geschrieben werden muss.

 

Die mobile Datenbank SQLite

Als Datenbank bietet sich für Xamarin Apps SQLite an. SQLite wird von mehreren Plattformen, unter anderem von Android, iOS und Windows Phone unterstützt. SQLite ist eine für mobile Geräte optimierte Datenbank d.h. sie ist schlanker aufgebaut und benötigt daher weniger Ressourcen. Dafür ist der Funktionsumfang etwas eingeschränkt. Es stehen auch OR Mapper in Form von NuGet Packages für den Entwickler zur Verfügung.

 

Das Xamarin.Forms Framework

Das User Interface (UI) kann mit Hilfe des Xamarin.Forms Frameworks einmalig geschrieben und für mehrere Plattformen verwendet werden. In diesem Kapitel möchte ich nun auf ein paar Komponenten von Xamarin.Forms eingehen. Xamarin.Forms muss in den Application Lifecycle der jeweiligen Plattform eingebunden werden und besitzt auch einen eigenen Lifecycle. Es kann auf Lebenszyklusereignisse wie auf das Starten der App, das Versetzen in den Sleep Modus sowie das Erwachen aus dem Sleep Modus reagiert werden.

Die Hauptkomponenten von Xamarin.Forms sind natürlich die gemeinsamen UI Elemente, welche einmalig im gemeinsam verwendeten Code erstellt und anschließend in die nativen UI Elemente übergeführt werden. Diese werden in XAML oder programmatisch in C# erstellt. Dabei können auch die üblichen Design Patterns, wie z.B.: MVVM und der Databinding Mechanismus angewendet werden. Weiters besteht das Xamarin.Forms User Interface aus Pages. Eine Page stellt eine Ansicht dar und es kann von einer zur anderen Page navigiert werden. Auf diesen Pages werden nun die gemeinsamen UI Elemente platziert. Es stehen dem Entwickler derzeit leider noch wenige gemeinsame Elemente für die UI Gestaltung zur Verfügung. Die UI Elemente werden dann mit Renderern in die native UI übergeleitet.

Weiters beinhaltet das Xamarin.Forms Framework noch weitere Komponenten. Eine Komponente stellen Custom Renderer dar, mit dem Renderer und somit das native Verhalten und Aussehen auf den einzelnen Plattformen überschrieben, ausgebessert und verändert werden können. Um auf plattformspezifische native Funktionen zugreifen zu können und dann im gemeinsamen Projekt zu verwenden, wird ein sog. Dependency Service von Xamarin.Forms zur Verfügung gestellt.

Des Weiteren kann zu den UI Elementen UI Logik hinzugefügt werden und zwar mit Styles, Behaviors und Trigger. Mit Styles können Farben, Schriftgrößen usw. gruppiert werden und Elementen zugewiesen werden. Mit Behaviors kann Elementen ein Verhalten hinzugefügt werden. Beispiel: Ein Textfeld ist für die Eingabe von Zahlen bestimmt. Gibt man jedoch Buchstaben ein wird es rot umrandet. Mit Trigger kann auf bestimmte Änderungen von Properties der gemeinsamen UI Elemente oder auch auf Events reagiert werden.

Leider werden neben diesen Möglichkeiten auch einige Fehler und Einschränkungen festgestellt. Der DataBinding Mechanismus bei Xamarin.Forms Ansichten funktioniert noch nicht bei allen Elementen reibungslos und allgemein sind die Möglichkeiten zur individuellen Anpassung von User Interface Elementen (ohne Zuhilfenahme von Custom Renderern) doch begrenzt.

Was geht nicht mit Xamarin.Forms? Für unsere Beispielanwendung haben wir auch ein Android Widget und ein Windows Phone Tile erstellt. Diese beiden können nicht mit Xamarin.Forms erstellt werden. Hier muss man auf die plattformspezifischen Funktionen zurückgreifen, aber mit Hilfe von Xamarin. D.h. auch das Android Widget sowie das Windows Phone Tile werden mit Xamarin in C# erstellt.

 

Die Xamarin Test Cloud

Seit kurzem gibt es die Möglichkeit für alle Entwickler, die einen Xamarin Account besitzen, die Xamarin Test Cloud für „60 device minutes“ im Monat gratis zu nutzen. Mit der Xamarin Test Cloud ist es möglich UI Tests auf ca. 1800 physischen (!) iOS und Android Smartphones und Tablets laufen zu lassen. Für Windows Phone gibt es die Möglichkeit derzeit noch nicht. Weiters ist zu erwähnen, dass die iOS UI Tests nur auf einem Mac mit Hilfe von Xamarin Studio (lokal) ausführbar sind. Diese UI Tests können auch für Xamarin.Forms Apps erstellt werden.

Die Xamarin Test Cloud ist online folgendermaßen aufgebaut. Es gibt Organisationen, Teams und Apps. Organisationen fassen mehrere App Entwickler Teams zu einer Einheit zusammen. Für die Verwaltung gibt es ein oder mehrere Admins, die Teams erstellen oder löschen können bzw. User zu den Teams zuweisen. Ein Team besteht aus ein oder mehreren Usern und ein oder mehreren Apps. Jedes Team hat einen eigenen Team API Key. Dieser und die jeweilige E-Mail Adresse des Users werden für den berechtigten Upload der Tests in die Test Cloud herangezogen.

Test Cloud Organisation

 

Für das Erstellen der Testfälle für die Xamarin Test Cloud werden 2 NuGet packages benötigt. Und zwar NUnit und Xamarin.UI Test. Nach dem die NuGet packages installiert sind, kann man den Testfall, den UI Test, erstellen. Die Testfälle können nun lokal am Gerät oder am Emulator ausgeführt werden. Wenn das funktioniert hat, macht es Sinn die Testfälle und die App in die Test Cloud zu laden. Der Upload funktioniert aus der Entwicklungsumgebung heraus. Anschließend wird man auf die Webseite weitergeleitet. Hier werden die weiteren Schritte zum Starten eines Test Runs (Testdurchlauf in der Test Cloud) durchgeführt. Man wählt die Geräte mit den entsprechenden Betriebssystemversionen aus, wählt den Branch für die Durchführung, die Systemsprache und ob man die Tests parallelisiert durchführen möchte, aus. Anschließend wird der Test Run durchgeführt und die Ergebnisse sind online ersichtlich und werden zusätzlich per Mail an die Mitglieder des App Teams versendet.

 

Fazit

Beeindruckend ist, dass sich tatsächlich der Großteil des Programmcodes in den gemeinsam verwendeten Teilen der App befindet und dadurch der Aufwand eine App für mehrere Plattformen zu entwickeln gering gehalten wird. Was Xamarin.Forms betrifft, kann man sagen es ist ein gutes Konzept. Man hat mit Xamarin.Forms viele Möglichkeiten für die UI Erstellung. Jedoch ist es für die betriebliche Verwendung noch nicht so ausgereift wie der Rest von Xamarin und hat unsere Erwartungen nicht ganz erfüllt, da wir oft Umwege über die Zuhilfenahme von Custom Renderern gehen mussten, um das gewünschte Aussehen und Verhalten der Ansichten zu erhalten. Jedoch glauben wir, dass für die Zukunft auch Xamarin.Forms ohne Probleme eingesetzt werden kann, da ja natürlich dieses Framework auch ständig weiterentwickelt und verbessert wird.

Weiters ist noch zu erwähnen, dass bestehende .NET und SDK Kenntnisse der einzelnen Plattformen sowie allgemeines Wissen über den Aufbau und die Funktionsweise der gewünschten Zielplattformen bei der Entwicklung von Xamarin Apps eingesetzt werden können bzw. diese auch benötigt werden. Da die Kosten einen nicht unwesentlichen Faktor darstellen, muss jedes Unternehmen anhand von Kriterien wie Firmengröße, Anzahl und Komplexität der zu entwickelnden Apps, usw. selbst abwägen, wie die Aufwände und Kosten in Relation zur nativen Entwicklung stehen und ob es Sinn macht Xamarin einzusetzen.

Abschließend weisen wir darauf hin, dass sich dieser Blog Artikel auf die aktuellen Versionen und Daten vom September 2015 und auf die Entwicklungsumgebung Visual Studio 2013 mit Xamarin Plugin bezieht. Weiters möchten wir an dieser Stelle Rob Jewett und Andrew Ditmer von Xamarin einen Dank für ihre Unterstützung aussprechen.

Passende Artikel

Antwort schreiben

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*