Der Kauf von Xamarin vor einigen Tagen hat innerhalb der Microsoft Community für Aufsehen gesorgt. Aber wieso eigentlich? Viele von uns haben sicher schon von Xamarin gehört und wissen auch so ungefähr was man damit machen kann (“gleichzeitig für iOS, Android und Windows programmieren”).
Vielleicht ist es für manche aber interessant zu erfahren, wofür genau Xamarin nützlich ist und wieso die Redmonder sich dazu entschlossen haben es zu übernehmen. Diese Fragen möchte ich in bester “Löwenzahn”-Manier (R.I.P.) versuchen zu beantworten.
Ich gebe dabei zu bedenken, dass ich kein Entwickler bin und lediglich recherchierte Informationen, gebündelt an euch weitergeben kann. Developer können mich also gerne auf Unklarheiten aufmerksam machen.
Wie im normalen Leben auch, gibt es in der Programmierwelt verschiedene Sprachen. Die relevantesten für diesen Artikel sind C (genauer gesagt C#), Java und Objective-C.
Vereinfacht ausgedrückt, können wir jede dieser drei Sprachen einzelnen Betriebssystem zuordnen, auf denen vornehmlich damit gearbeitet wird: C# -Windows, Java – Android und Objective-C – iOS. Bei iOS verlagert sich die Entwicklerpräferenz gerade auf die Programmiersprache Swift, was an dieser Stelle erstmal keine Rolle spielt.
Xamarin ist deshalb so praktisch für Windows Entwickler, weil sie den Großteil ihres Codes, der in C# kompiliert wurde, für die Programmierung von Android und iOS Apps nutzen können.
Für Betriebssystemspezifische Features wie Live-Kachel-Funktion oder Widgets, müssen Entwickler noch Anpassungen vornehmen. Das C# Grundgerüst und damit ein Großteil des Codes kann aber übernommen werden und erleichtert den Arbeitsaufwand enorm.
Man kann also durchaus von einer universellen Programmiersprache sprechen, die aber einige Einschränkungen mit sich bringt. Ohne zusätzliche Anpassungen erhält der Entwickler zwar eine App, die auf Windows, iOS und Android läuft. Die UI (User Interface) ist dann aber recht simpel gehalten. Neuere Versionen von Xamarin sollen aber enorme Fortschritte gemacht haben, so das “universeller” Code auch komplexere UIs erlaubt.
Das erstaunliche an Xamarin ist, dass der Code auf jede der Plattformen nativ läuft und so eine sehr gute Performance bietet. So gibt es zwar Cross-Platform Tools, die ebenfalls inkompatible Programmiersprachen auf verschiedenen Systemen lauffähig machen, doch hier wird eine Emulation verwendet – dementsprechend Probleme, gibt es dann auch in der Stabilität und Geschwindigkeit der Anwendungen.
Wie man diesem Diagramm entnehmen kann, sind Xamarin Apps auf iOS sogar schneller als das üblicherweise verwendete Objective-C. Das neuere Swift hat aber noch die Nase vorn.
Xamarin ist aber kein Konverter im Sinne der Windows “Bridges”, die Microsoft auf der letztjährigen Build vorgestellt hat. Ein iOS Entwickler kann mittels Project Islandwood eine App von “seinem” (Objective-C) System , in eine Universal App für Windows konvertieren. Entwickler, die mit Xamarin arbeiten möchten, müssen jedoch in C# programmieren können.
So gesehen ist Xamarin eine Ergänzung und, zumindest für bereits bestehende Apps, kein Ersatz für die “Bridges”.
*Project Astoria ist mittlerweile gestorben und spielt an dieser Stelle keine Rolle mehr.
Eines der größten Probleme von Xamarin dürfte der Preis sein.
Für Unternehmen (die momentan auch Hauptnutzer von Xamarin sind) sind die Ausgaben Peanuts. Möchte aber ein kleines Team aus 5 Mann eine App erschaffen, die dann auch auf iOS und Android laufen soll, müssen sie jährlich mit knapp $10.000 rechnen.
Indie Entwickler, haben immer noch eine Rechnung von knapp $600 zu bezahlen und müssen auch noch auf eine Visual Studio Lizenz verzichten (€2000/Jahr).
Ich bin gespannt was sich Microsoft einfallen lässt, um diese Kosten zu senken. Warum nicht für ein paar Jahre kostenlos anbieten?
Wie bereits weiter oben erwähnt ist Xamarin eine Ergänzung zur “Bridge”-Strategie von Microsoft. Entwicklern stehen nun sowohl Tools zur Konvertierung ihrer iOS Apps zur Windows Plattform zur Verfügung als auch Mittel, um eine neue App von Anfang an für alle großen mobilen Systeme komaptibel zu machen.
Und das ist erst der Anfang. Nach dem Kauf von Xamarin werden die Redmonder das System nun weiter verfeinern. Das Ziel dürfte sein, einen Konverter zu entwickeln, der jede gängige Programmiersprache für alle Systeme kompatibel macht.
Ich habe keinen Schimmer ob so etwas in naher Zukunft realisierbar ist, aber Microsoft verfolgt meiner Meinung nach eine sehr klare Strategie zum Thema “echte Universal Apps”.
Ich bin gespannt auf die Build 2016.
Der Microsoft Flight Simulator wird optisch weiter aufgewertet. Wir wissen, dass es auch unter unseren…
Die meisten unserer Leser dürften zu Hause über einen Schreibtisch verfügen, an welchem nicht nur…
Manche Dinge brauchen ihre Zeit. Als die Apple Vision Pro angekündigt wurde und letztlich an…
Zum Thema Nachhaltigkeit gehört auch der Umstand, elektrische Geräte zu reparieren und nach diesem erfolgreichen…
Microsoft-Dienste und E-Mail-Server sind in den letzten Wochen nicht immer positiv in den Medien hervorgehoben…
Ein smarter WLAN- und Bluetooth-Lautsprecher inkl. Alexa und einem gigantischen sowie sattem Klang – so…
Diese Webseite benutzt Cookies.
Zeige Kommentare
Apps bestehen meist aus mehreren "Schichten".
1. Datenbankzugriff bzw. Zugriff auf externen Services, welche beispielsweise Daten bereitstellen z.B. die meisten News Seiten erlauben es, Artikel im JSON oder XML Format abzurufen, vermutlich auch eure. :)
2. Sog. "Business Logik", welche Benutzeranmeldung handhabt, Daten über die 1. Schicht abruft und für das User Interface aufbereitet, die eigentliche Logik/Funktion der App.
3. User Interface. Hier werden die in 2. aufbereiteten Daten angezeigt, Eingaben entgegengenommen, Interaktion mit dem User findet statt.
Wenn eine Firma eine App entwickelt und für Android, iOS und Windows bereitstellen möchte, muss sie diese App 3-mal implementieren, benötigt Entwickler für Android (Java), iOS (Swift) und Windows (C#). Jeder der genannten Schichten muss 3-mal implementiert werden.
Das ist natürlich initial aufwändiger, ev. Fehler muss man 3-mal korrigieren, künftige Erweiterungen muss man 3-mal ergänzen usw.
Mittels Xamarin kann nun die 1. und 2. Schicht in C# programmiert werden.
Abhängig von der App gibt es damit schon mal ca. 60-70% gemeinsamen Programmcode.
Für das UI gibt es 2 Wege.
1. Einerseits erlaubt es Xamarin, direkt das UI und die Controls der spezifischen Plattform zu verwenden. Damit ist dann tatsächlich alles möglich, weil man exakt festlegen kann, welche Controls für welche Plattform verwendet werden sollen. Das UI von Windows/Android/iOS ist doch recht unterschiedlich und manche Controls gibt es auch nicht auf allen Plattformen ident.
2. Xamarin.Forms verwenden.
Damit wird das UI in einer Beschreibungssprache (XAML) definiert.
Xamarin.Forms kennt für die unterschiedlichen Plattformen sog. "Renderer" welche wissen, wie ein bestimmtes in XAML beschriebenes Control auf der jeweiligen Plattform darzustellen ist.
Beispiel: TextBox Control (Control zur Texteingabe)
Diese sieht auf allen Plattformen etwas anders aus, hat aber nahezu idente Funktion.
Nun gibt es in Xamarin.Forms ein "TextBox" Control.
Anders gesagt: Die Beschreibung "Zeige hier eine TextBox an" in Xamarin.Forms ist für alle Plattformen ident.
Abhängig davon, für welche Plattform man das Projekt compliert, wird jeweils das TextBox Control der jeweiligen Plattform verwendet.
Wie diese TextBox dann aber tatsächlich aussieht ist somit von Plattform zu Plattform unterschiedlich, weil jeweils die Plattformspezifische Variante verwendet wird.
Mit Xamarin.Forms erreicht man dann z.B. 90% Codesharing, da auch große Teile der 3. Schicht (UI) nur 1-mal programmiert werden muss.
Und genau DAS ist der große Vorteil für Firmen, weil man heutzutage eine App möglichst auf alle Plattformen bringen möchten (bzw. zumindest auf Android und iOS...). Im Gegensatz zu den Ansätzen, welche im Hintergrund JavaScript verwenden (z.B. Apache Cordova), das eine App erstellt, die im Browser läuft ist es bei Xamarin so, dass eine sog. native App erstellt wird.
Im Detail ist es natürlich komplexer.
Beim Kompilieren wird C# Programmcode in eine MSIL (MS intermediate language übersetzt), eine Art Assemblersprache.
Die sog. .net Runtime führt diese IL zur Laufzeit aus und übersetzt diese zur Laufzeit auch in native Code.
Auch Java bzw. Android hat eine Runtime, in diesem Fall z.B. die Dalvik Runtime, welche Java-Bytecode ausführt.
Die Kommunikation zwischen .net Runtime und Dalvik Runtime wird dabei von Xamarin gehandhabt und bleibt dem Entwickler eigentlich verborgen was gut ist d.h. man muss sich nicht darum kümmern.
Für iOS ist es anders: Apple erlaubt keine Runtime. Zum Zeitpunkt der Kompilierung muss hier daher sämtlicher C# Code in Maschinensprache übersetzt werden.
Diese ganzen "Details" werden von Xamarin jedoch wie gesagt sehr gut verborgen.
Derzeit sind die Tools von Visual Studio zur Erzeugung von Windows Apps einfach noch weit besser als jene für Xamarin.Forms, nicht überraschend. Ich hoffe, dass durch die Übernahme durch MS genau hier angesetzt wird und mittelfristig die Visual Studio Integration noch verbessert wird...und vor allem kostenlos wird. ;)
Abschließend: Xamarin ist in gewisser Weise das Gegenteil zu den MS Bridges.
Die Bridges erlauben es Objective-C Code zu kompilieren und auf Windows laufen zu lassen.
Xamarin ermöglicht es, C# Code zu kompilieren und auf Android und iOS laufen zu lassen.
Wirklich super deine Ergänzung Hannes, vielen Dank dafür ☺
Wie schön war die Zeit früher, als man mit .NET Windows Forms programmiert hat...
Vielen Dank Hannes für deine super tolle Ergänzung. Mir fehlt in Windows eigentlich nur noch meine Husqvarna automower app, so das ich neben meinem 950 ein iPad mini weiter nutzen muss.