Codefest.at: Xamarin.Forms, oder: Knapp 100% Code-Reuse auf mobilen Plattformen

Xamarin.Forms, einfach genial. Vielen lieben Dank an das CodeFest.atTeam für die Veröffentlichung!

us gegebenem Anlass möchte ich euch gerne den Einstieg in die mobile Entwicklung mit Xamarin und speziell Xamarin.Forms näherbringen. Ihr fragt euch möglicherweise, was denn dieser „Anlass“ sein könnte?

Nun, zum Ersten ist es so, dass die Visual Studio 2015 Preview den Android Emulator mitliefert, was die Entwicklung vereinfacht und die Developer-Experience merklich erhöht, mehr dazu findet ihr hier.

Zum Zweiten ist es so, dass ich nächste Woche wieder einen Xamarin Kurs abhalte und ich gerade wieder einmal meine Unterlagen überarbeite und ich dabei meine treuen Blog-Leser auch teilhaben lassen möchte.

Drittens, und das ist für euch bestimmt noch interessanter, ist die Draft-Version des Xamarin.Forms Buches von Charles Petzold in der Microsoft Virtual Academy als Gratis-Download verfügbar. Und zwar genau hier.

Alles gute Gründe, sich Xamarin und Xamarin.Forms genauer anzusehen, aber zuvor sollten wir die Frage klären:

 

Was ist Xamarin und was kann es für mich tun?

Nun, jeder Entwickler, der mobile Applikationen mit

· C# und
· nativer Performance und
· nativem Look & Feel

für Windows Phone UND iOS UND Android erstellen möchte, sollte sich Xamarin genauer ansehen. Xamarin stellt 100% der nativen APIs für iOS, Android und Windows zur Verfügung.

Als Entwicklungsumgebung liefert Xamarin zwar auch das Xamarin Studio zur Entwicklung mit, aber es ist auch möglich, den gesamten Code in Visual Studio zu erstellen, allerdings benötigt ihr dann auch zumindest die Business-Lizenz. Der Vorteil ist, dass eure gewohnten Tools, wie z. B. Resharper, weiterhin verwendet werden können, ihr aber eben mit dem Xamarin SDK die mobile Plattform eurer Wahl anprogrammiert.

Es werden immer native und keine interpretierten Applikationen für die gewählte Zielplattform erstellt.

Dies wurde dadurch ermöglicht, dass 100% des Android SDKs und 100% des iOS SDKs auf C# gemappt wurden. Kurz gesagt: wenn man es in Java für Android programmieren kann, klappt das auch mit Visual Studio, C# und Xamarin.Android. Das Gleiche gilt eben genauso für XCode mit Objective-C und Visual Studio, C# und Xamarin.iOS.

 

Was benötige ich, um mit Xamarin zu entwickeln?

Das kommt jetzt ein klein wenig darauf an, auf welche mobile Plattform ihr mit eurer Entwicklung abzielt:

· Android: das Android SDK, optional eine Google Developer Subscription (einmalig $25), mehr dazu findet ihr hier – falls ihr die App veröffentlichen wollt, dann ist diese natürlich zwingend notwendig.

· iOS: einen MAC, der als sogenannter Build-Host dient, auf diesem muss XCode installiert sein und ihr benötigt ZWINGEND eine Apple Developer Subscription (jährlich €83), mehr dazu hier. Der Grund ist, dass die Erstellung nativer iOS Applikationen zwingend auf dem MAC mit den Tools von Apple erfolgen muss.

Dann natürlich noch Xamarin selbst, eine der 4 Editionen, oder die Trial Lizenz - diese ist 30 Tage ohne Einschränkungen lauffähig und findet ihr hier zum Download.

 

Was kostet Xamarin?

Es gibt 4 verschiedene Lizenzen:

· Starter (kostenlos, aber bez. Funktionen in sehr eingeschränkter Form)
· Indie ($25/Monat)
· Business ($83/Monat)
· Enterprise ($158/Monat)

Für Studenten gibt es die Indie-Version gratis, mehr dazu findet ihr hier. Für MSDN-Abonnenten gibt es ebenfallsspezielle Rabatte, momentan kostet die Business Edition $799/Jahr und pro Plattform.

Den genauen Unterschied in den Funktionen könnt ihr hier nachlesen, ich empfehle euch zumindest die Indie-Version zu verwenden, ich persönlich habe die Xamarin Business Edition für iOS und Android.

 

Wie funktioniert die Entwicklung mit Xamarin?

Es gibt zwei Möglichkeiten, um mit Xamarin eine native, mobile Applikation zu erstellen:

1. Die GUI wird für die jeweilige Plattform extra erstellt, die Applikations-Logik kann wiederverwendet werden
2. Die GUI wird mit Xamarin.Forms erstellt, damit kann im Idealfall auch die GUI nahezu zu 100% auf jeder der mobilen Plattformen wiederverwendet werden.

Ersteres wird auch der sogenannte Silo-Approach genannt: Drei Säulen – für jede Plattform eine unterschiedliche Implementierung der grafischen Oberfläche.

 

Was ist Xamarin.Forms?

Mit Xamarin.Forms ist es – im Gegensatz zum Silo-Approach – möglich, eine Applikation 1x zu entwickeln, auch die GUI, und zwar mit nahezu 100% gleichem Code. Das heißt, kaum extra Code-Zeilen für eine der drei führenden mobilen Plattformen (Android, iOS und Windows Phone). Möglich wird das, indem Xamarin.Forms die nativen Controls durch eine Zwischenschicht abstrahiert. So gibt es z. B. einen Xamarin.Forms.Button, dieser wird letztendlich ein UIButton, wenn es sich um eine iOS App handelt, zu einem Android Button bei einer Android App und zu einem Windows Phone Button bei einer Windows Phone App (aber dazu später noch genaueres).

Zusätzlich werden von Xamarin.Forms gewisse Unterschiede der mobilen Plattformen per Default eingebaut. So ist eine iOS-Applikation per Default weiß, eine Android App aber eher in schwarz gehalten. Das bedeutet, dass es eben z. B. per Default ein anderes Farbschema für Schriften und Texte verwendet werden muss. Das kann man zu Beginn getrost links liegen lassen, Xamarin.Forms kümmert sich darum.

Um Xamarin.Forms auch für Windows Phone einsetzen zu können, benötigt ihr zumindest eine Xamarin Lizenz für eine der beiden anderen Plattformen.

 

Wie wird eine Xamarin.Forms App erstellt?

Xamarin liefert in der Business-Edition Visual Studio Templates mit, wenn ein neues Projekt angelegt wird. Da eine Xamarin.Forms Applikation erstellt werden soll, sind 3 Templates von Interesse:

· Eine „Blank App (Xamarin.Forms.Portable)“,
· eine „Blank App (Xamarin.Forms.Shared)”,
· eine „Class Library (Xamarin.Forms.Shared)”

Also prinzipiell entscheidet man sich, ob man das Projekt als „Shared Project“, oder als „Portable Class Library“ aufsetzen möchte.

Eine Shared Application kompiliert die Klassen in jede einzelne App. Sollten Unterscheidungen für eine spezielle Plattform notwendig sein, wird häufig eine Kompiler-Direktive verwendet. Der Vorteil ist hier, dass nur eine einzige Quelldatei für alle drei Plattformen existiert.

Quelle: Xamarin docs

Die Portable-Class Library vereint den kleinsten gemeinsamen Nenner aller verwendeten Plattformen, es ist also im Prinzip keine Unterscheidung für eine der drei mobilen Plattformen von Nöten, da diese PCL für alle drei Apps die Gleiche ist.

Quelle: Xamarin docs

Aber warum eine Entscheidung treffen? Ich erstelle üblicherweise eine „Blank App (Xamarin.Forms.Shared)“ und füge danach eine „Class Library (Xamarin.Forms.Portable)“ hinzu. Damit kann ich alle Vorteile aus beiden Lösungen verwenden. Das sieht dann im Endeffekt so aus:

Es ist das Shared Project zu finden, die Android, sowie die iOS App, danach die PCL und am Ende die Windows Phone App. Die PCL wurde als Referenz zu den drei App-Projekten hinzugefügt.

Es lohnt sich, nach dem Anlegen der finalen Projektstruktur das Xamarin.Forms-Package auf die aktuelle Version zu aktualisieren.

 

XAML-Layout und Datenbindung?

Unter iOS und Android gibt es an und für sich keine MVVM-Unterstützung, wie sie in WPF existiert, aber Xamarin.Forms macht das nun für eben diese beiden Plattformen möglich. Inklusive XAML.

Um das in der Praxis zu testen, habe ich mir eine bestehendes MVVM Beispiel geholt, nämlich die „Simple MVVM and Windows Phone 7“-Applikation von hier und diese mit Xamarin.Forms umgesetzt.

Dieses ursprüngliche Beispiel zeigt die Verwendung von MVVM anhand einer Länderliste. Wenn ein einzelnes Land angewählt wird, so gelangt man zu den Details, bzw. erhält weitere Informationen über dieses Land. Da es sich um ein MVVM-Einführungsbeispiel handelt, verwendet es natürlich Models, ViewModels und Views und verwendet die zugehörige Datenbindung. Außerdem beinhaltet die Applikationen ein Verzeichnis mit Bilder, wo die zu jedem Land zugehörige Flagge enthalten ist.

Das Endresultat der Konvrtierung der Windows Phone 7 App mittels Xamarin.Forms sieht auf den drei Plattformen (Android, iOS; Windows Phone 8) so aus:

Das ist jetzt noch ganz ohne „Tweaks“ für eine bestimmte Plattform, d. h. eine Code-Basis für alle 3 mobilen Clients. Das gilt sowohl für die Business Logik, ALSO AUCH für das Frontend.

Ich möchte hier nur einige der Anpassungen aufgreifen, die gegenüber der originalen Windows Phone 7 App durchzuführen waren:

Generell gilt: WPF, bzw. Silverlight XAML != Xamarin XAML, das ist am deutlichsten an den Controls zu erkennen. Nachfolgend ein Beispiel:

Windows Phone 7 XAML:

Xamarin.Forms XAML

Auffallend, dass wir statt dem StackPanel ein StackLayout sehen, statt dem TextBlock ein Label und ich die Styles einfach entfernt habe. Erstens gibt es diese nicht mehr und zweitens haben wir hier es nicht nur mit einer Plattform zu tun, sondern mit drei verschiedenen – und da ist es erst einmal schwierig mit einem bestimmten Style „ins Rennen zu gehen“. Xamarin.Forms nimmt uns per Default schon einiges ab, wie es in den Screenshots zu sehen ist, konkret spiele ich auf die Hintergrundfarbe und die Vordergrundfarbe der Controls an.

Generell würde ich empfehlen, wenn es sich um eine Applikation, die mit Xamarin-für mehrere mobilen Plattformen entwickelt wird, eine Plattform als „führende“ zu definieren. Sobald diese einen Stand hat, der für den Test frei gegeben werden kann, kann man die zweite und danach die dritte Plattform anpassen, bzw. feintunen. Damit ist sichergestellt, dass zumindest eine Plattform quasi fertig ist und funktioniert. Die anderen beiden folgen in sehr kurzem Abstand. In dem oberen – zugegeben relativ einfachem - Beispiel wurde wie erwähnt absolut NICHTS angepasst.

Grund für diese eigenen Controls ist die Funktionsweise von Xamarin.Forms. Durch die Plattform-abhängigen Bibliotheken verwandeln sich die Xamarin.Forms-Controls in die jeweils passenden der jeweiligen Zielplattform, wie das nachfolgende Bild anschaulich zeigt.

So wird also aus einem Xamarin.Forms.Button ein UIButton, bzw. ein Android.Widget.Button unter Android und ein System.Windows.Controls Button unter Windows Phone.

Die Datenanbindung wurde von Xamarin gleich umgesetzt, wie wir das schon von WPF, oder der Windows Phone Entwicklung gewohnt sind. Das ViewModel und das Model habe ich nahezu ohne Änderungen übernommen, ich habe nur mit dem Bild getrickst und ein weiteres Property, um den Applikations-Titel nur unter Windows Phone darzustellen eingefügt.

Als Beispiel hier die Liste der Flaggen in der Windows Phone 7 App (der Trigger aus dem Originalcode wurde hier entfernt, da Trigger in Xamarin.Forms noch nicht offiziell unterstützt sind):

Und hier die Xamarin.Forms App:

Wichtig zu erwähnen ist noch, dass XAML mit Xamarin.Forms nur in einer Portable Class Library funktioniert und nicht in einem Shared Asset Project. Des Weiteren gibt es noch keinen XAML Designer, das könnte euch das Einarbeiten in Xamarin.Forms etwas erschweren, wenn ihr bisher eure XAML-GUI mit Blend, oder in Visual Studio mit dem Designer gebaut habt.

 

Zusammenfassung

Generell kann man sagen, dass Xamarin mit den Xamarin.Forms ein großer Wurf gelungen ist. Es ist zwar erst die erste Version, es lassen sich aber bereits hervorragend Business-Applikationen damit entwickeln. Wir dürfen gespannt sein, was das Xamarin-Team in den nächsten Monaten noch für Überraschungen für uns bereithält.