MicrosoftNewsReport

[ErlÀuterung] Was genau ist Xamarin und wieso hat Microsoft es gekauft?

Microsoft Windows 10

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.

Xamarin – Was ist das eigentlich?

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.

ios-app-xamarin

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 vs. die Windows „Bridges“ (Project Islandwood, Astoria etc.)

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.

Probleme von Xamarin

Eines der grĂ¶ĂŸten Probleme von Xamarin dĂŒrfte der Preis sein.

K1024_Screenshot (74)

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?

Ausblick

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.


Quelle

Vorheriger Artikel

Acer prÀsentiert seine Windows 10 Phones in aufwendigen Werbevideos

NĂ€chster Artikel

WhatsApp stellt Support fĂŒr Windows Phone 7 und andere Betriebssysteme ein

4 Kommentare

  1. 27. Februar 2016 von 14:04 — Antworten

    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.

    • 27. Februar 2016 von 15:48 — Antworten

      Wirklich super deine ErgĂ€nzung Hannes, vielen Dank dafĂŒr â˜ș

    • 28. Februar 2016 von 3:07 — Antworten

      Wie schön war die Zeit frĂŒher, als man mit .NET Windows Forms programmiert hat…

  2. 27. Februar 2016 von 15:43 — Antworten

    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.

Antworten

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