Mit Xamarin Studio und Xamarin für Visual Studio können Mobile Applications plattformübergreifend mit C# entwickelt werden. Wir haben Xamarin für Visual Studio bereits mehrfach produktiv in Projekten eingesetzt und wollen hier unsere Erfahrungen teilen.Seit 2016 ist Xamarin ein Projekt von Microsoft

Nach nunmehr 10 Jahren Smartphone und Mobile Devices hat sich am Markt einiges getan. So gut wie alle populären Urgesteine der Softwareindustrie haben mittlerweile einen mehr oder weniger erfolgreichen App-Ableger in den bekannten Stores am Start. Doch nicht nur unsere alltägliche IT-Nutzung, sondern auch die dahinterstehenden Entwicklungsprozesse haben sich teilweise radikal verändert. Wegen der schier unglaublich gewachsenen Geräte- und Systemvielfalt waren App-Entwicklung und -Wartung lange Zeit sehr teuer. Verschiedene Framework-Ansätze sollten hier Abhilfe schaffen und etwas Licht in den Code-Dschungel lassen. Der Grundgedanke war dabei immer der gleiche: Ein Code – viele Geräte. Der Teufel hierbei lag jedoch – wie so oft – im Detail. Die lückenhafte Unterstützung aller Hardwarefunktionen, neuartige Metasprachen und Probleme mit der Performance waren an der Tagesordnung, denn die meisten dieser Frameworks setzen auf Webtechnologien, wie HTML, JavaScript und CSS. Doch dann erschien Xamarin auf dem Screen und die lange Suche nach einer plattformübergreifenden Lösung für unsere C#-Entwickler hatte endlich ein Ende. Am Anfang ging es nur darum, das .NET Framework auf Android abzubilden. Doch spätestens seit der Übernahme von Xamarin durch Microsoft Anfang 2016 und der anschließenden Veröffentlichung als Open-Source-Extension für Visual Studio hat sich Xamarin als vollwertiges Entwicklungswerkzeug für die mobile Entwicklung emanzipiert. Die Zielplattformen reichen von der Universal Windows Platform über Android bis hin zur gesamten Apple-Familie (iOS, tvOS, macOS). Nachdem wir bereits mehrere Projekte damit umgesetzt haben, wollen wir hier kurz unsere Erfahrungen teilen und der Frage nachgehen, ob und in welchen Szenarien sich die Entwicklung mit Xamarin lohnt und wo mögliche Showstopper liegen.

 

Das Setup

Bevor wir jedoch über die Vor- und Nachteile sprechen – zunächst noch ein paar allgemeine Infos zum notwendigen Setup. Damit wir loslegen können, brauchen wir nicht nur Xamarin für Visual Studio, sondern noch drei weitere Zutaten. Die Library Xamarin.Forms wird benötigt, um geräteübergreifend UI-Elemente platzieren und anzusteuern zu können. Zwar können auch unterschiedliche plattformspezifische UI-Bibliotheken dafür genutzt werden, der Einsatz von Xamarin.Forms senkt den Entwicklungsaufwand jedoch erheblich. Weiterhin ist der in Visual Studio integrierte Android-Emulator für das Debugging und die Tests mit Googles Betriebssystemen ein Must-have. Und zu guter Letzt brauchen wir natürlich einen Mac. Für alle die glaubten mit Xamarin könne man endgültig auf eine Aluminiumkiste aus dem Hause mit dem angebissenen Obst verzichten – dem ist nicht so. Sowohl beim Build-Prozess als auch dem Debugging ist eine Verbindung zu einem lauffähigen macOS Sierra (oder höher) mit installiertem XCode und dem Xamarin SDK Pflicht.

 

Cross-platform Development mit Xamarin für Visual Studio: Build und Debugging für Apple Devices geht nur mit einem Mac.

Cross-platform Development mit Xamarin für Visual Studio: Build und Debugging für Apple Devices geht nur mit einem Mac.

Szenarien für den Einsatz

Zur Frage, wann man Xamarin am besten einsetzen kann, lautet unsere klare Empfehlung, dass es eher für die Entwicklung datenverarbeitender als performance-kritischer Apps sinnvoll einzusetzen ist. Aufgrund der häufig bremsenden CLR-Schicht (Common Language Runtime Layer), die zwischen .NET und dem jeweiligen Hostsystem vermittelt, sind Xamarin-programmierte Apps eher nicht als Echtzeit-Anwendungen gedacht. Das soll nicht heißen, dass diese Apps besonders viel Last erzeugen – vielmehr ist es nur sehr viel schwerer möglich den tatsächlichen post-build Code so zu optimieren, dass Echtzeit-Anwendungen mit perfekten Nutzererlebnis dabei herauskommen. Auch bei sehr medienlastigen Apps mit exzessiven Audio- und Video-Handling sollte man sich gut überlegen, ob Xamarin die richtige Wahl ist. Für jede Ansteuerung von Medien und Dateien müssen mithilfe sogenannter DependencyServices (geräte- und systemspezifische Code-Verzweigungen) Code-Alternativen für jedes Zielsystem geschrieben werden, was den Entwicklungs- und Testaufwand dann schnell in die Höhe treiben kann. Durch die aktive Xamarin-Community sollte dieser bekannte Missstand jedoch bald behoben sein.

 

Pro und Contra

Der augenscheinlichste Vorteil ist der Punkt Schnelligkeit beim Coding. C#-Entwickler können in ihrer gewohnten IDE mit vertrauter Syntax Apps entwickeln und die Wartung des Codes ist dank zentraler Codebasis sehr effizient. Allerdings gibt es mit Xamarin out-of-the-box nur Standard-UI-Elemente, was für die User die Interaktionsvielfalt mit der GUI auf den Devices etwas einschränkt. Abhilfe schafft hier die Paketverwaltung NuGet, mit der auch UI-Elemente von Drittanbietern einfach eingebunden werden können. Doch auch Xamarin.Forms ist dank guter Dokumentation schnell und einfach erweiterbar. Die bereits erwähnten DependencyServices für die Ansteuerungen der Systemfunktionen sind etwas aufwändiger zu realisieren – besonders bei Android, mit seiner Vielzahl an OS-Versionen und teilweise beträchtlichen Unterschieden. Ein klarer Vorteil aber ist, dass im Gegensatz zu anderen Frameworks (z. B. Cordova) allerdings nie explizit Java- bzw. SWIFT-Code geschrieben, sondern nur entsprechend nachgebaute SDK-Bibliotheken aus dem Mono-Framework angesprochen werden müssen. Generell kann man so auf alle Hardwarefunktionen der Geräte problemlos zugreifen.

 

Handling der Systemfunktionen über DependencyServices

Etwas Schreibarbeit – mit DependencyServices können plattformspezifische Systemfunktionen mit C# angesprochen werden

 

Als etwas nachteilig und ungewohnt hat sich das Thema Debugging herausgestellt. So ist der Code zur Laufzeit nicht veränderbar und die bei uns geschätzte Code-Navigationsfunktion zur manuellen Änderung des Ausführungsablaufs (Move the pointer to change the execution flow) ist leider nicht verfügbar. Hinzu kommen manchmal nichtssagende Exception-Errors, die zunächst nervös machen, jedoch direkt von Problemen in der SDK-Schicht der einzelnen Plattformen herrühren. Alles in Allem sind das aber nur Komfortprobleme. Man merkt hingegen das Xamarin noch ziemlich in den Kinderschuhen steckt und kann mit der Zeit eine recht starke Evolution innerhalb des Frameworks beobachten. So lassen sich im Netz – mit Ausnahme der von Microsoft betriebenen Xamarin-Projektseite selbst – nur schwer aktuelle Tutorials, Informationen und verlässliche Lösungshinweise für spezifische Probleme finden. Auch die Community ist noch recht überschaubar und hilfreiche Forenbeiträge eher rar gesät. Auf der anderen Seite ist gerade diese Lebendigkeit ein großer Benefit, wenn es um die Integration neuer SDK-Features geht. So ließ zum Beispiel die Integration des neuen Siri-Kits Ende 2016 nur einen Monat auf sich warten. Für uns kam das genau zum passenden Zeitpunkt.

 

Fazit

Xamarin ist optimal für die kosten- und zeiteffiziente Entwicklung von Apps durch C#-Entwickler in ihrer gewohnten IDE. Durch die effizient wartungsfähige Codebasis, die für alle Devices zwischen 70 bis 90% überlappt, können wir unseren Kunden optimale Angebote erstellen und die Folgekosten minimal halten. Das Framework eignet sich also hervorragend für alle Arten von Anwendungen bei denen der Faktor Echtzeit nicht die oberste Priorität hat. Die Entwicklung mit Xamarin hat uns bisher viel Freude bereitet und gerade in der Anfangsphase eines Projekts sieht man sehr schnell erste Resultate auf allen Geräten. Natürlich sind dann hier und da noch Anpassungen notwendig und die teils subtilen Unterschiede zwischen den verschiedenen Android-Versionen zu beachten. Alles in allem aber hält Xamarin, was es verspricht, vereinfacht den Prozess der plattformübergreifenden Entwicklung und findet in unserer Entwicklungsabteilung für die Zukunft seinen festen Platz.

 

Quellen/Links