Xamarin – Cross Platform Mobile Development (3/3)

Nach den Herausforderungen der Native Mobile App Entwicklung der Gegenwart in Teil Eins und der Vorstellung von Xamarin in Teil Zwei dieser Blogserie, abschliessend Einblicke und Learnings aus direkter Projekterfahrung.

visualstudio_xamarinstudio

In den letzten Monaten haben wir verschiedenste Erkenntnisse in der Implementierung eines iOS und Windows 7 Client mit Hilfe von Xamarin sammeln können.

Grundsätzlich lässt sich vorweg nehmen, dass die gesammelten Erfahrungen überwiegend positiv ausgefallen sind. Dennoch gibt es gewisse nicht ganz zu verachtende Makel, die vor Projektstart unbedingt in Betracht gezogen werden sollten.

Vorteile – Allgemein

  • Eine plattformneutrale Code-Basis von 50% bis 70% ist durchaus realistisch.
  • Ausgeprägte Parallelisierung durch UI und Business Logic Trennung analog der Webentwicklung mit Backend und Frontend Entwickler-Teams möglich.
  • Als Xamarin Partner (Premium Status) gibt es die Möglichkeit, dass Leads zugespielt werden.

Vorteile – Technisch

  • Vollwertiges Two-Way Data Binding steht zur Verfügung.
  • Eine klare Trennung zwischen UI und Business Logic wird erzwungen.
  • Mit Hilfe von Xamarin Forms ist der Code-Sharing Anteil theoretisch bis fast 100% ausreizbar.
  • Der verwendete Toolchain ist bekannt und ausgereift. Visual Studio, TFS, Jenkins, Git, etc. (Xamarin Studio ist bewusst nicht aufgeführt und muss auf Mac verwendet werden)
  • Basiert ein verwendetes Backend bereits auf .NET, können bestehende Datenmodelle samt Logik auf den Client übernommen werden.

Neben diesen positiven Eigenschaften sind wir aber leider auch auf eine ganze Menge nicht so angenehme Eigenheiten gestossen.

Nachteile – Allgemein

  • Aus Android und iOS Sicht wird man im Xamarin Ecosystem gefangen. Möchte man zu einem späteren Zeitpunkt zur direkten native iOS oder Android Entwicklung umsteigen, kann die vorhandene Codebase nicht weiter verwendet werden. Eine vollständige Neuentwicklung des Client ist die Folge.
  • Mit Visual Studio als Windows IDE ist man bestens bedient. Xamarin Studio hingegen, welches für die iOS Entwicklung auf Mac OS X erforderlich ist, kann es nicht ansatzweise mit Xcode oder AppCode aufnehmen und sorgt des Öfteren für Frust.
  • Apple’s Instruments – eines der hilfreichsten iOS Entwickler Werkzeuge – ist fast vollständig nutzlos, da die .NET Runtime für diese Applikation eine Blackbox ist. Lediglich minder wichtige Eigenschaften können überwacht werden. Dabei wird jedoch generell auf Assembler-Referenzen referenziert. Dies nimmt den Entwicklern ein entscheidendes Tool zur Optimierung und Fehleranalyse.
  • Auf iOS hatten wir während der Entwicklung einige Male App Crashs, die ich in vier Jahren klassischer iOS Entwicklung im Team nicht ein einziges mal erfahren habe.

Nachteile – Technisch

  • Der Xamarin-„Overhead“ bzw. dessen Footprint vergrössert sich direkt proportional zur Anzahl verlinkter APIs und bremst den initialen App-Start spürbar.
  • Es werden plattformspezifische Architektur-Konzepte mit denen von C#/.NET vermischt, was ein starkes Umdenken bei der Client-spezifischen Implementierung mit sich bringt.
  • Durch einen weiteren Layer im Toolchain werden auch entsprechend Xamarin-spezifische Bugs (bugzilla.xamarin.com/…) eingeführt. Diese können zu nicht nachvollziehbaren App Crashs führen.
  • Das Threading weicht stark von dem bekannten plattformspezifischen Thread Verhalten ab. Der Grand Central Dispatcher zum Beispiel, bekannt von Mac OS X und iOS, steht nicht zur Verfügung.
  • Auf iOS ist der Keychain Zugriff sehr instabil, obwohl dies eigentlich dank KeychainItemWrapper tadellos funktionieren sollte.
  • XIBs müssen weiterhin per Xcode modifiziert werden. Zur Übernahme der Änderungen (IBOutlets etc.) wird per Xamarin Studio eine Synchronisierung mit Xcode angestossen. Diese setzt teilweise aus und muss daraufhin manuell erzwungen werden.

Ausblick

Mit Xamarin Forms wird neu versucht, den aktuell noch plattformspezifischen UI Code in plattformneutralen Code zu überführen. Eine fast vollständige Plattformneutralität wäre theoretisch hiermit bei der Implementierung möglich. Dies gelingt durch eine neue API welche Pages, Layouts und Controls zur Verfügung stellt. Leider eignet sich dies sicherlich nicht für anspruchsvolle GUIs, da hierdurch wiederum ein generisches UI, basierend auf dem grössten gemeinsamen Nenner aller involvierten Plattformen, erstellt wird.

Fazit

Wie doch so oft, ist nicht alles schwarz oder weiss. Daher kann Xamarin weder ausnahmslos empfohlen noch als weiterer erfolgloser Cross Platform Development Ansatz abgetan werden. Abhängig von den projektspezifischen Rahmenbedingungen und den jeweiligen Detailanforderungen muss der Entscheid überlegt getroffen werden. Wir sind nach dem ersten grösseren Projekt der Meinung, dass wir diesen kompetent und guten Gewissens treffen können.

Ein Dankeschön an die Kollegen Tobias Baube und Christoph Bühler, die mit ihren persönlichen Erkenntnissen zu Xamarin erheblich zu den Vor- und Nachteilen dieses Posts beigetragen haben.

Hier finden Sie diesen Beitrag in englisch.

6 Gedanken zu “Xamarin – Cross Platform Mobile Development (3/3)

  1. Vielen Dank übrigens für die spannende Serie! Ich bin tatsächlich grad im Moment Xamarin als Platform für ein App Projekt basierend auf .NET WebApp zu evaluieren. Hilft grad viel!

    • Hey David, danke für dein Kommentar. Freut mich zu hören, dass dir die Erkenntnisse weiterhelfen. Bei Detailfragen ungeniert fragen.

  2. Gibt es denn zwischenzeitlich Erfahrungswerte mit Xamarin.Forms? Es war in einem der Teile davon die Rede, dass damit theoretisch eine gemeinsame Codebase von 100% erreicht werden kann. Mich würde interessieren, inwieweit dies in realen Projekten der Fall ist und ob sich der Einsatz generell lohnt.

    • Hallo Herr Müller,

      eine sehr gute Frage.
      Wir haben Xamarin Forms aus Testzwecken zunächst für ein kleines Projekt eingesetzt, das absichtlich nur Standardkomponenten verwenden sollte. Hier gibt es einige nette Vorteile, die aus der .Net-Welt bereits wohlbekannt sind, wie das 2-Way-Binding.
      Aber dennoch nutzt Xamarin Forms eine eigenständige Semantik. Die Syntax gleicht zwar dem XAML, das man kennt, leider sind jedoch etliche Funktionen (noch) nicht verfügbar, Attribute heißen anders und werden anders angesprochen. Häufig fehlen diese auch schlichtweg. Die Dokumentation ist hier auch noch in der Entwicklungsphase.

      Nachdem das Grundgerüst mit Basiskomponenten schnell stand, haben wir es um kleine „custom“ Components erweitern wollen und auch hier zeigt sich schnell, dass angebotene Elemente nicht gänzlich anpassbar sind, selbst wenn CustomRenderers geschrieben werden. Ein schönes Beispiel war die horizontale und vertikale Positionierung des Textes innerhalb eines Buttons, was am Ende ein Label werden musste, weil der Code – wie man ihn sonst nutzen würde – hier nicht gegriffen hatte und überschrieben wurde.

      Meine persönliche Empfehlung ist, weiterhin das UI für die entsprechende Plattform spezifisch umzusetzen bis Xamarin Forms ein wenig gereifter ist und auch wirklich mit dem gewohnten XAML vergleichbar ist, sowohl im Funktionsumfang als auch der Dokumentation.

      • Besten Dank für die Info. Hab mal ein wenig reingelesen und mich schnell gewundert, dass z.B. auf einem Mapmarker kein OnClick-Listener registriert werden kann. Da fehlen scheinbar wirklich noch selbst Basisfunktionalitäten.

  3. Super Beitrag.

    Besonders die aufgelisteten Vorteile und Nachteil sind interessant. Problematisch ist sicherlich auch, wie im Artikel erwähnt, dass die Code Basis, bei einem Wechsel auf die Native Entwicklung nicht mehr nutzbar wird.

    Da ich auch ein wenig Erfahrungen mit der Plattform sammeln durfte habe ich auch ein wenig darüber geschrieben: http://www.yuhiro.de/xamarin-erfahrung/

    Könnt Ihr Xamarin für die Entwicklung von Mobile Apps empfehlen?

    Vielen Dank nochmals für den Beitrag.

Schreibe einen Kommentar

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

*

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>