Erhalten Sie Zugang zu diesem und mehr als 300000 Büchern ab EUR 5,99 monatlich.
• Praktischer Leitfaden für den schnellen Einstieg
• Vermittelt auch spezielleres Wissen, z. B. zur Datenbankanbindung oder zu wiederverwendbarem Code
• Die Xamarin.Forms-App für .NET MAUI fit machen
• Mit durchgängigem Beispiel
• Ihr exklusiver Vorteil: E-Book inside beim Kauf des gedruckten Buches
Sie möchten Apps entwickeln, die sowohl auf iOS als auch auf Android nativ lauffähig sind? Schritt für Schritt führt André Krämer (Microsoft MVP) Sie in die Welt der Cross-Plattform-Entwicklung mit Xamarin.Forms und C# ein. Von der einheitlichen Codebasis über die Oberflächengestaltung und Datenbankanbindung bis zum Zugriff auf Geräte-APIs lernen Sie hier alles, um plattformübergreifende Apps zu entwickeln.
Im Laufe der Lektüre dieses Buches programmieren Sie eine Beispiel-App für ein fiktives Restaurant und vertiefen dabei das in den Kapiteln erworbene Wissen.
Das Buch setzt Grundkenntnisse in der Programmierung mit C# voraus. Erfahrung mit XAML ist von Vorteil, jedoch nicht erforderlich.
Sämtliche Beispiele des Buchs finden Sie im zugehörigen GitHub-Repository.
AUS DEM INHALT //
Schnelleinstieg: Ihre erste App mit Xamarin.Forms in einer Stunde/Überblick über Xamarin.Android, Xamarin.iOS und Xamarin.Forms/Architektur von Cross-Plattform-Apps/Oberflächendesign mit Layoutcontainern/Eingabeformulare anlegen/Navigation und die Xamarin.Forms Shell/Listen/Bilder, Icons und Schriftarten/Styles und Themes in Xamarin.Forms/Aufruf von Webservices/Lokale Datenhaltung/Xamarin.Essentials
Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 435
Veröffentlichungsjahr: 2021
Das E-Book (TTS) können Sie hören im Abo „Legimi Premium” in Legimi-Apps auf:
André Krämer
Cross-Plattform-Apps mit Xamarin.Forms entwickeln
Mit C# für Android und iOS programmieren
Alle in diesem Buch enthaltenen Informationen, Verfahren und Darstellungen wurden nach bestem Wissen zusammengestellt und mit Sorgfalt getestet. Dennoch sind Fehler nicht ganz auszuschließen. Aus diesem Grund sind die im vorliegenden Buch enthaltenen Informationen mit keiner Verpflichtung oder Garantie irgendeiner Art verbunden. Autor und Verlag übernehmen infolgedessen keine juristische Verantwortung und werden keine daraus folgende oder sonstige Haftung übernehmen, die auf irgendeine Art aus der Benutzung dieser Informationen – oder Teilen davon – entsteht.Ebenso übernehmen Autor und Verlag keine Gewähr dafür, dass beschriebene Verfahren usw. frei von Schutzrechten Dritter sind. Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Buch berechtigt deshalb auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten wären und daher von jedermann benutzt werden dürften.
Bibliografische Information der Deutschen Nationalbibliothek:Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar.
Dieses Werk ist urheberrechtlich geschützt.Alle Rechte, auch die der Übersetzung, des Nachdruckes und der Vervielfältigung des Buches, oder Teilen daraus, vorbehalten. Kein Teil des Werkes darf ohne schriftliche Genehmigung des Verlages in irgendeiner Form (Fotokopie, Mikrofilm oder ein anderes Verfahren) – auch nicht für Zwecke der Unterrichtsgestaltung – reproduziert oder unter Verwendung elektronischer Systeme verarbeitet, vervielfältigt oder verbreitet werden.
© 2021 Carl Hanser Verlag München, www.hanser-fachbuch.deLektorat: Sylvia HasselbachCopy editing: Walter Saumweber, RatingenUmschlagdesign: Marc Müller-Bremer, München, www.rebranding.deUmschlagrealisation: Max KostopoulosTitelmotiv: © Stephan Rönigk, unter Verwendung von Grafiken von © fotolia.com/Dora Vision
Print-ISBN: 978-3-446-45155-1E-Book-ISBN: 978-3-446-45366-1E-Pub-ISBN: 978-3-446-47204-4
Titelei
Impressum
Inhalt
Vorwort
Der Autor
Hinweise zum Buch
1 Einführung
1.1 Xamarin und die Xamarin-Plattform
1.2 Überblick über die Xamarin-Plattform
1.3 Architektur der Xamarin-Plattform
1.3.1 Mono und das .NET Framework
1.3.2 Mono als Grundlage der Xamarin-Plattform
1.3.2.1 Xamarin.Android
1.3.2.2 Xamarin.iOS
1.4 Entwicklungswerkzeuge
1.5 Was Sie in diesem Kapitel gelernt haben
2 Schnelleinstieg: Ihre erste App mit Xamarin.Forms in einer Stunde
2.1 Das Konzept der App
2.1.1 Die besondere Stärke der App
2.1.2 Auswahl der App-Funktionen
2.1.3 Skizze der Benutzeroberfläche
2.2 Anlegen des Projekts
2.3 Umsetzen der Oberfläche
2.4 Implementieren des Quellcodes
2.5 Die fertige App
2.6 Was Sie in diesem Kapitel gelernt haben
3 Überblick über Android und Xamarin.Android
3.1 Das Betriebssystem Android
3.2 Architektur von Xamarin.Android
3.3 Software Development Kits
3.3.1 Android-API-Level
3.4 Eine einfache Android-App mit Visual Studio anlegen
3.4.1 Ordnerstruktur einer einfachen App
3.4.2 Standarddateien einer einfachen App
3.5 Apps testen und debuggen
3.5.1 Test im Emulator
3.5.1.1 Android-Emulatoren
3.5.2 Debugging auf einem echten Gerät
3.6 Was Sie in diesem Kapitel gelernt haben
4 Überblick über iOS und Xamarin.iOS
4.1 Das Betriebssystem iOS
4.1.1 Verbreitung und Versionen
4.2 Architektur von Xamarin.iOS
4.3 Software Development Kits und Systemvoraussetzungen
4.3.1 Xcode und das iOS SDK installieren
4.3.2 Mono, Xamarin.iOS und Visual Studio für Mac installieren
4.3.3 Integration in Visual Studio für Windows installieren
4.4 Eine Verbindung zum Mac herstellen
4.5 Eine einfache iOS-App mit Visual Studio anlegen
4.5.1 Ordner- und Dateistruktur einer einfachen App
4.6 Apps testen und debuggen
4.6.1 Tests im Simulator
4.6.2 Einschränkungen des Simulators
4.6.3 Debugging auf einem echten Gerät
4.7 Was Sie in diesem Kapitel gelernt haben
5 Überblick über Xamarin.Forms
5.1 Der Xamarin.Forms-Ansatz
5.2 Funktionsumfang
5.2.1 Views, Layouts, Pages und Cells
5.2.2 GestureRecognizer
5.2.3 Navigation
5.2.4 MessagingCenter
5.2.5 DependencyService
5.2.6 App Lifecycle
5.3 Architektur von Xamarin.Forms
5.4 Eine einfache Xamarin.Forms-App in Visual Studio anlegen
5.4.1 Projekt-, Ordner- und Dateistruktur einer Xamarin.Forms-App
5.4.1.1 Das Android-Projekt
5.4.1.2 Das iOS-Projekt
5.4.1.3 Das plattformübergreifend geteilte Projekt
5.5 Grenzen von Xamarin.Forms
5.6 Was Sie in diesem Kapitel gelernt haben
6 Architektur von Cross-Plattform-Apps
6.1 Plattformübergreifende Wiederverwendung
6.2 Freigegebene Projekte und Präprozessoranweisungen
6.2.1 Ein freigegebenes Projekt in Visual Studio anlegen
6.2.2 Vorteile von freigegebenen Projekten
6.2.3 Nachteile von freigegebenen Projekten
6.2.4 Fazit zu freigegebenen Projekten und Präprozessoranweisungen
6.3 .NET-Standard-Klassenbibliotheken für plattformübergreifenden Quellcode nutzen
6.3.1 Ein .NET-Standard-Projekt in Visual Studio anlegen
6.3.2 Vorteile von .NET-Standard-Projekten
6.3.3 Nachteile von .NET-Standard-Projekten
6.3.4 Fazit zu .NET-Standard-Projekten
6.4 Abhängigkeitsmanagement
6.4.1 Der Xamarin.Forms DependencyService
6.4.2 Dependency Injection mit dem Inversion of Control Container Microsoft.Extensions.DependencyInjection
6.5 Was Sie in diesem Kapitel gelernt haben
7 Oberflächendesign mit Layoutcontainern
7.1 Das Xamarin.Forms-StackLayout
7.2 Das Xamarin.Forms-Grid
7.3 Das Xamarin.Forms-AbsoluteLayout
7.4 Das Xamarin.Forms-FlexLayout
7.5 ScrollView
7.6 Was Sie in diesem Kapitel gelernt haben
8 Eingabeformulare anlegen
8.1 Grundlegende Steuerelemente
8.1.1 Übergreifende Konzepte zu Steuerelementen
8.1.1.1 Größe und Position von Views
8.1.1.2 Zugriff auf Views im Code-Behind
8.1.1.3 Plattformspezifische Eigenschaftswerte vergeben
8.1.2 Views zur Darstellung von Inhalten
8.1.2.1 Label
8.1.2.2 WebView
8.1.2.3 ActivityIndicator und Progressbar
8.1.3 Texteingaben mit Entry und Editor
8.1.4 Button
8.1.5 Steuerelemente zur Auswahl
8.1.5.1 RadioButton
8.1.5.2 CheckBox
8.1.5.3 Switch
8.1.5.4 Picker
8.1.5.5 Datum und Uhrzeit mit DatePicker und TimePicker auswählen
8.2 Das Model-View-ViewModel (MVVM)-Muster und Datenbindung
8.2.1 Das MVVM-Muster
8.2.2 Datenbindung
8.2.2.1 Einfache Datenbindung
8.2.2.2 Command-Binding
8.2.2.3 Performanceschub durch kompilierte Bindung
8.2.3 Fazit zur Datenbindung und dem MVVM-Muster
8.3 Steuerelemente in der Beispiel-App
8.3.1 Das Model anlegen
8.3.2 Das ViewModel
8.3.3 Die View
8.3.4 Aufruf der Profilseite und Registrierung der Abhängigkeiten
8.3.5 Ein Wort zur Strukturierung der App
8.4 Was Sie in diesem Kapitel gelernt haben
9 Navigation und die Xamarin.Forms Shell
9.1 Navigation in mobilen Apps
9.1.1 Registerkarten
9.1.2 Hierarchische Navigation
9.1.3 Seitenleiste
9.2 Die Xamarin.Forms Shell
9.2.1 Überblick über die Shell
9.2.2 Eine Navigationsstruktur mit der Shell definieren
9.2.2.1 Eine Registerkartennavigation mit der Shell anlegen
9.2.2.2 Eine seitliche Navigationsleiste mit der Shell
9.2.2.3 Die seitliche Navigation mit Registerkarten kombinieren
9.2.2.4 Menüeinträge als Aktionselemente nutzen
9.2.3 Kopf- und Fußzeile der Shell definieren
9.2.4 Routenbasierte Navigation
9.3 Dependency Injection und die Xamarin.Forms Shell
9.4 Navigation in der Beispiel-App
9.4.1 Die Shell anlegen
9.4.2 Änderungen an der Dependency Injection
9.4.3 Das Navigationsframework der Shell abstrahieren
9.5 Was Sie in diesem Kapitel gelernt haben
10 Listen
10.1 Listen unter Xamarin.Forms
10.2 Die Xamarin.Forms-CollectionView
10.2.1 Einträge selektieren
10.2.2 Kontextmenüs
10.2.3 Daten aktualisieren
10.2.4 Gruppierte Einträge
10.3 Listen in der Beispiel-App
10.3.1 Daten in der Beispiel-App
10.3.2 Die Startseite der App
10.3.3 Die Speisekarte
10.3.4 Die Detailseite
10.4 Was Sie in diesem Kapitel gelernt haben
11 Bilder, Icons und Schriftarten
11.1 Bilder darstellen
11.1.1 Plattformspezifische Bilder
11.1.2 Eingebettete Bilder
11.2 Schriftarten
11.3 Icon-Schriftarten verwenden
11.4 Bilder und Schriftarten in der Beispiel-App
11.4.1 Startseite und Menü
11.4.2 Kategorie- und Detailseite
11.5 Was Sie in diesem Kapitel gelernt haben
12 Styles und Themes in Xamarin.Forms
12.1 Styles in Xamarin.Forms
12.1.1 Implizite und explizite Stildefinitionen
12.1.2 Mehrere Formatvorlagen mit Style-Classes anwenden
12.2 Styling mit Cascading Style Sheets (CSS)
12.3 Themes
12.3.1 Hell- und Dunkelmodus des Betriebssystems unterstützen
12.4 Styles und Dunkelmodus in der Beispiel-App
12.5 Was Sie in diesem Kapitel gelernt haben
13 Aufruf von Webservices
13.1 Webservices mit dem „HttpClient“ aufrufen
13.1.1 Daten mit GET lesen
13.1.2 Daten mit POST anlegen
13.1.3 Daten mit PUT ändern
13.1.4 Daten mit DELETE löschen
13.1.5 Umgang mit dem Offline-Fall
13.2 Webservices in der Beispiel-App
13.3 Was Sie in diesem Kapitel gelernt haben
14 Lokale Datenhaltung
14.1 Zugriff auf das lokale Dateisystem
14.1.1 Die Android-Verzeichnisstruktur
14.1.2 Die iOS-Verzeichnisstruktur
14.1.3 Dateizugriff über die Klassen File und Directory aus dem Namensraum System.IO
14.2 Lokale Datenhaltung mit einer SQLite-Datenbank
14.3 Was Sie in diesem Kapitel gelernt haben
15 Zugriff auf native Gerätefunktionen mit Xamarin.Essentials
15.1 Funktionsüberblick über Xamarin.Essentials
15.2 Xamarin.Essentials im eigenen Projekt einbinden
15.3 Xamarin.Essentials in der Beispiel-App
15.4 Was Sie in diesem Kapitel gelernt haben
16 Nachwort
Im Frühjahr 2013 hörte ich auf der Fahrt zu einem Kunden die Tablet Show, einen früheren Podcast von Carl Franklin und Richard Campbell zum Thema Mobile Development. Mein Hauptinteresse galt damals, wie bei so vielen .NET Entwicklern, der Entwicklung von Windows-8-Apps. Gemeinsam mit einem Bekannten hatte ich wenige Monate zuvor eine App für Windows 8 veröffentlicht, die zu dieser Zeit gerade die Schallmauer von 1 000 000 Downloads durchbrach.
In früheren Episoden der Tablet Show hatte ich bereits einige nützliche Tipps erhalten, die uns bei der Optimierung unserer App halfen, und so war ich sehr neugierig, was diese Folge Neues bringen würde.
In dieser Folge berichtete Miguel de Icaza, einer der beiden Gründer der Firma Xamarin, dass es eine kostenfreie, eingeschränkte Einsteigerversion von Xamarin geben wird sowie eine günstige Variante für einzelne Entwickler. Außerdem kündigte er an, dass die Entwicklung von Xamarin-Apps von nun an auch in Visual Studio möglich war.
Ab diesem Zeitpunkt war ich von Xamarin fasziniert. Die Tatsache, dass ich mit meinen C#-, .NET- und Visual-Studio-Kenntnissen dank Xamarin in der Lage war, Apps für Android und iOS zu schreiben, ohne Java oder Objective-C lernen zu müssen, begeisterte mich, und diese Begeisterung hält bis heute an.
Kurz nachdem ich den Podcast gehört hatte, installierte ich die Xamarin-Werkzeuge auf meinem Rechner und legte mit den ersten Experimenten los. Da ich keinen Mac hatte, konnte ich am Anfang nur für Android programmieren. Da mir das nicht genug war, kaufte ich mir einige Monate später einen günstigen Mac und ein günstiges iPhone, um auch für iOS entwickeln zu können.
Ab diesem Zeitpunkt wuchs mein Wunsch, mein Wissen über diese großartige Technologie zu teilen. Ich startete damit, Schulungen und Workshops zum Thema Xamarin zu halten, Fachartikel darüber zu schreiben, auf Konferenzen und User Group Meetings darüber zu sprechen und Videokurse für LinkedIn Learning aufzuzeichnen und Kunden bei der Umsetzung ihrer Projekte zu unterstützen.
Mein Enthusiasmus für das Thema Xamarin und insbesondere das Thema Xamarin.Forms ist seit 2013 ungebrochen. Noch immer freue ich mich darüber, wenn ich Entwicklern etwas über Xamarin beibringen und mein Wissen somit weitergeben kann.
Ein Buch zu schreiben ist harte Arbeit. Härter als ich es erwartet hatte, als ich im Sommer 2016 die Anfrage des Carl Hanser Verlags erhielt, ob ich ein Buch über Xamarin schreiben möchte. Zunächst zögerte ich, denn ich konnte zu diesem Zeitpunkt bereits auf zwei gescheiterte Buchprojekte zurückblicken, die beide nach 130 Seiten abgebrochen wurden. Am Ende siegte jedoch meine Leidenschaft für das Thema Xamarin und nach Rücksprache mit meiner Familie und meiner Lektorin sagte ich zu.
Vom Gedanken, ein Buch zu schreiben, bis zum fertigten Buch dauerte es fast fünf Jahre. Als Außenstehender mag man da vielleicht den Kopf schütteln und sich fragen, warum es so lange dauerte. Natürlich könnte ich Ihnen jetzt erzählen, dass gute Texte ähnlich wie guter Wein eine lange Zeit reifen müssen, aber das wäre einfach Unsinn.
Die wirklichen Ursachen sind eine Kombination verschiedener Gründe. Der Hauptgrund war sicherlich, dass ich noch nie ein Buch (zu Ende) geschrieben hatte und schlichtweg nicht wusste, wie man das macht, ein Buch schreiben. Als Ergebnis machte ich das, was in der Entwicklung von Individualsoftware normalerweise der Auftraggeber macht: Ich wollte einfach zu viel. Meine Vision war es, ein Buch zu schreiben, das Xamarin.Android, Xamarin.iOS, Xamarin.Forms und die Entwicklung von UWP Apps von der Idee bis zum Deployment behandelt.
Die ersten 3 ½ Jahre hielt ich an diesem Plan fest und scheiterte auf voller Linie damit. Der mangelnde Fokus kombiniert mit der Tatsache, dass es eigentlich vier Bücher in einem gewesen wären, der Situation, dass dies mein erstes Buch war und dass ständig, wenn ich ein Kapitel fertig hatte, sich etwas Grundlegendes seitens Microsoft, Apple oder Google änderte, führte dazu, dass ich große Teile des Buches oder der Beispielcodes immer wieder neu schrieb und somit auf der Stelle trat.
Im Frühjahr 2020, als ich das Buch schon fast aufgeben wollte, einigte ich mich mit meiner Lektorin beim Carl Hanser Verlag darauf, das Thema des Buches etwas enger zu fassen und mich auf die Entwicklung von Xamarin.Forms-Apps zu konzentrieren. In diesem Bereich liegt sicherlich auch das Hauptinteresse der Leser, zumindest wenn meine Schulungs- und Beratungsanfragen sowie die Abrufe meiner Videokurse repräsentativ sind. Seit längerer Zeit steigt hier das Interesse an Xamarin.Forms, während Xamarin.Android und Xamarin. iOS so gut wie gar nicht mehr nachgefragt werden.
Als Microsoft auf der Build-Konferenz im Mai 2020 dann .NET MAUI als Evolution von Xamarin.Forms ankündigte und kaum ein Wort über Xamarin.Android oder Xamarin.iOS verlor, war die Strategie klar: Dieses Buch muss sich auf Xamarin.Forms konzentrieren. Also startete ich im Mai 2020 von vorne mit dem Buch und schrieb große Teile der bis dahin 130 geschriebenen Seiten neu.
Mangelnder Fokus und eine zu große Vision waren aber nur eine Ursache für den langen Weg bis zum fertigen Buch. Eine andere war, dass das Schreiben dieses Buches nicht meine Haupttätigkeit war. Stattdessen verdiente ich mein Geld in der Anfangsphase hauptsächlich als Trainer und Berater, ehe ich 2018 die Quality Bytes GmbH, eine Softwarefirma spezialisiert auf die Entwicklung von Apps und Cloud Solutions, gründete und aufbaute, was aufwendiger war als ich dachte. Und das Leben besteht nicht nur aus Arbeit, sondern auch aus Familie. Meine wundervolle Frau Ana und unsere drei großartigen Kinder wollten natürlich auch Aufmerksamkeit von mir und Zeit mit mir verbringen. Das Endergebnis war, dass das Schreiben eine von vielen Tätigkeiten war. Im Laufe der Jahre experimentierte ich mit verschiedensten Techniken, um den Schreibprozess zu optimieren und somit schneller fertig zu werden. Der Durchbruch kam in den letzten zwei Monaten. Nachdem ich nach neun Monaten wieder nur 130 Seiten fertig hatte, schrieb ich den Rest des Buches in zwei Monaten. Die angewandte Optimierungstechnik lässt sich übrigens sehr einfach zusammenfassen: „Einfach machen“.
Falls also einer der Leser selbst mit dem Gedanken spielt, sein erstes Buch zu schreiben, dann kann ich ihn oder sie nur herzlich dazu motivieren und folgende Tipps mit auf den Weg geben:
Es ist einfacher, den Umfang des Buches klein zu planen. Nach meiner Erfahrung wächst der Umfang von ganz allein während des Schreibprozesses. Außerdem hilft es ungemein, Gewohnheiten zu schaffen und zum Beispiel jeden Tag ein wenig zu schreiben als sich z. B. vorzunehmen in einer Woche das halbe Buch fertigzustellen.
Wie Sie gerade erfahren haben, war der Weg zu diesem Buch etwas „holprig“. Vermutlich wäre es nie erschienen, wenn es nicht zahlreiche Menschen gegeben hätte, die mir geholfen haben und denen ich meinen Dank aussprechen möchte.
Mein größter Dank gilt meiner Frau Ana, die mich während der ganzen Zeit unterstützt, ermutigt und an mich geglaubt hat. Während der letzten fünf Jahre musste sie nicht nur wegen der Arbeit an diesem Buch, sondern auch wegen meiner anderen beruflichen Verpflichtungen häufig auf meine Gesellschaft verzichten. Sie war dabei stets verständnisvoll und spornte mich an, wenn meine Motivation sank. Dass eine Frau ihrem Mann so viele Freiräume für seine persönlichen Projekte einräumt, ist nicht selbstverständlich und ich bin froh, eine so wundervolle Partnerin gefunden zu haben.
Bedanken möchte ich mich auch bei meinen Kindern Joel und Lyandra und bei meinem Stiefsohn Raúl. Ihr wart stets geduldig und verständnisvoll, wenn ich keine Zeit für euch hatte, da ich an diesem Buch arbeitete.
Mein Dank gilt außerdem meiner Mutter Sylvia, die mir im Grundschulalter einen Atari 800XL zusammen mit dem Buch „Spielend Programmieren lernen“ kaufte und damit die Grundlage für eine erfolgreiche IT-Berufslaufbahn geschaffen hat. Außerdem las sie jedes Kapitel meiner fehlgeschlagenen Buchprojekte sowie meiner Diplom- und Masterarbeit Korrektur und gab mir wertvolle Tipps, um meinen Schreibstil zu verbessern.
Ein besonderer Dank gilt auch meiner Lektorin Sylvia Hasselbach beim Carl Hanser Verlag, die trotz meiner vorherigen missglückten Buchversuche das notwendige Vertrauen in mich hatte und dieses Buchprojekt mit mir startete. Besonders möchte ich ihre Geduld bei den vielen E-Mails und Telefonaten hervorheben, bei denen ich neue Terminverschiebungen ankündigte. Weiter möchte ich mich bei Walter Saumweber bedanken, der dieses Buch Korrektur las und mir in geduldigen Telefonaten freundlich und gut gelaunt wertvolle Tipps zu meinen Texten gab. Darüber hinaus möchte ich mich auch bei Kristin Rothe und Irene Weilhart vom Carl Hanser Verlag für die gute Zusammenarbeit bedanken.
Außerdem möchte ich meinem Informatiklehrer Gerd Larscheid danken, der mein Interesse an der Programmierung Mitte der 90er Jahre, als ich Schüler in seiner Klasse war, förderte. Er ist der beste Informatiklehrer, den ich jemals kennengelernt habe. Von ihm lernte ich nicht nur programmieren, sondern auch, dass es beim Programmieren nicht nur um das Schreiben von Quellcode, sondern um das Lösen von (Geschäfts-)Problemen mit der Hilfe von Software geht. Diese Erkenntnis war für meine berufliche Laufbahn unverzichtbar.
Bedanken möchte ich mich auch bei meinem guten Freund Oliver, der dieses Buch direkt nach der Ankündigung vorbestellte und mich in den letzten Jahren immer wieder motivierte, es zu Ende zu schreiben.
Selbstverständlich gibt es nicht nur Menschen im persönlichen Umfeld, denen mein Dank gilt, sondern auch Wegbegleiter aus der Entwickler-Community.
Hier gibt es so viele – aktuelle und ehemalige Kollegen, Sprecher und Aussteller auf Konferenzen –, dass es schwerfällt, jemanden besonders hervorzuheben. Trotzdem möchte ich nicht nur all denjenigen, die zur vorherigen Gruppe gehören, meinen pauschalen Dank aussprechen, sondern einige namentlich nennen. Zum einen wäre da Thomas Claudius Huber, mit dem ich mir während des Microsoft MVP Summits 2014, als ich an meinem Windows-8-Buch schrieb und daran verzweifelte, ein Zimmer teilte. Thomas erzählte mir seine inspirierende Geschichte darüber, wie er sein dreimal so dickes WPF-Buch geschrieben hatte. Seine Erzählungen waren so motivierend, dass ich auch heute noch häufig daran denke.
Weiter wäre da Manfred Steyer, den ich seit vielen Jahren von verschiedenen Konferenzen kenne und der ein erfahrener Autor ist. 2019 hielt er in meiner Firma eine Angular-Schulung. Während des Abendessens an einem der Schulungstage fragte ich ihn nach Tipps und er sagte mir, dass ich am besten erst einmal die Beispiele fertig programmiere. Während der Entwicklung der Beispiele würde mir klarwerden, was ich detailliert beschreiben muss, und was nicht. Mit diesem Hinweis hatte er eindeutig recht und es war dieser Hinweis, dessen Umsetzung mir in den letzten zwei Monaten dabei half, Fahrt aufzunehmen.
Mein Dank gilt weiterhin dem Xamarin-Team für das herausragende Produkt sowie den vielen Freiwilligen in der Community, die auf der ganzen Welt ihr Wissen in der Form von Blog-Beiträgen und Vorträgen teilen, oder ihre Freizeit in Open-Source-Projekte stecken.
Außerdem möchte ich auch Dr. Holger Schwichtenberg für die großartige Zusammenarbeit in den letzten Jahren danken. Er war es, der mich als Autor beim Carl Hanser Verlag ins Gespräch brachte und ohne den es dieses Buch wohl niemals geben würde.
Schlussendlich gilt mein Dank natürlich auch Ihnen! Vielen Dank, dass Sie sich für dieses Buch entschieden haben. Wenn Sie zu denen gehören, die mehr oder weniger geduldig auf das Erscheinen dieses Buches gewartet haben, dann möchte ich mich an dieser Stelle bei Ihnen für die lange Wartezeit entschuldigen und hoffe, dass der Inhalt die Wartezeit wieder wettmacht.
André Krämer
Mai 2021
André Krämer startete seine berufliche Laufbahn 1997 mit einer Ausbildung zum Fachinformatiker für Anwendungsentwicklung, nachdem er zuvor auf der höheren Berufsfachschule für Datenverarbeitung den Abschluss als staatlich geprüfter kaufmännischer Assistent für Datenverarbeitung machte.
Nach seiner Ausbildung bei einem großen IT-Systemhaus arbeitete er zunächst als Entwickler und später als technischer Teamleiter in seinem Ausbildungsbetrieb. Bereits damals fokussierte er sich auf Microsoft-Technologien.
2002 wechselte er zu einem international tätigen Softwarehaus für Software im industriellen Qualitätsmanagement und sammelte dort umfangreiche Erfahrungen mit Microsoft .NET ab der Version 1.0. Während dieser Zeit studierte er nebenberuflich an der FH Köln Wirtschaftsinformatik und erlangte seinen Abschluss als Diplom-Informatiker (FH).
2008 bis 2011 arbeitete er für ein internationales Beratungsunternehmen als Senior Application Architect und absolvierte währenddessen ein nebenberufliches Studium zum Master of Science Wirtschaftsinformatik an der TH Kön.
2012 machte er sich selbständig, wurde Partner im www.IT-Visions.de-Expertennetzwerk, und arbeitete bis Sommer 2018 als Trainer und Berater. Während dieser Zeit führte er überwiegend Individualschulungen für Softwareentwickler durch und schulte vor allem die Themen App-Entwicklung mit Xamarin, Web-Entwicklung mit ASP.NET und DevOps mit Azure DevOps. Im Rahmen seiner Tätigkeit veröffentlichte er über 20 Videokurse für LinkedIn Learning, schrieb zahlreiche Fachartikel und sprach regelmäßig auf Entwicklerkonferenzen.
2013 erhielt er für sein Fachwissen und Community-Engagement von Microsoft die Auszeichnung zum Microsoft Most Valuable Professional (MVP), und wurde seitdem jedes Jahr erneut mit dem Titel ausgezeichnet.
2018 wagte er den nächsten Schritt und gründete die Quality Bytes GmbH, ein Softwarehaus in Bad Breisig am Rhein zwischen Bonn und Koblenz, und übernahm dort die Geschäftsführung. Mit seinem mittlerweile 15-köpfigen Team schreibt er dort Individualsoftware auf Projektbasis für seine Kunden.
Der Fokus der Quality Bytes GmbH liegt auf der Entwicklung von Mobile Apps für Android, iOS und Windows mit Xamarin, der Entwicklung von Webportalen für die Microsoft Azure Cloud oder das Selbsthosting auf der Basis von Angular und ASP.NET Core sowie der Implementierung von SAP-Integrationslösungen.
Wenn Sie Projektunterstützung in einem der genannten Bereiche benötigen, dann freuen sich André Krämer und sein Team über Ihre Nachricht unter [email protected] oder den Besuch des Internetauftritts der Quality Bytes GmbH, den Sie unter https://qualitybytes.de finden.
Sein aktuelles Interesse im Bereich der Softwareentwicklung gilt neben Xamarin, ASP.NET und Azure DevOps den Themen Azure und Docker sowie agilen Entwicklungsmethoden.
Seine Freizeit verbringt André Krämer am liebsten mit seiner Familie. Nachdem die beiden ältesten Kinder bereits erwachsen und ausgezogen sind, beobachten er und seine Frau mit großer Freude die fußballerischen Aktivitäten ihres jüngsten Sohns. Alle drei sind daher häufig auf den Fußballplätzen rund um Koblenz anzutreffen.
Dieses Buch besteht aus 15 Kapiteln, die Sie Schritt für Schritt auf Ihrem Weg zum App-Entwickler begleiten. Hier eine kurze Beschreibung des Inhalts der einzelnen Kapitel:
Kapitel 1, Einführung
Im ersten Kapitel erhalten Sie grundlegende Informationen über die Xamarin-Plattform und das zugrunde liegende Ökosystem.
Kapitel 2, Schnelleinstieg: Ihre erste App mit Xamarin.Forms in einer Stunde
Das zweite Kapitel führt Sie Schritt für Schritt von der Idee über die Planung zur ersten App und das alles in einer Stunde. Das Ziel dieses Kapitels ist es, Ihnen Appetit auf mehr zu machen und zu zeigen, wie leistungsfähig Xamarin ist.
Kapitel 3, Überblick über Android und Xamarin.Android
Obwohl Xamarin.Forms die zugrunde liegenden Betriebssysteme und Programmierframeworks weitestgehend abstrahiert, schadet ein grundlegendes Verständnis der Zielplattformen nicht. In diesem Kapitel sehen wir uns daher Grundlegendes zu Android und Xamarin.Android an. Außerdem werfen wir einen Blick darauf, wie Sie Ihr System für die Entwicklung mit Android konfigurieren müssen.
Kapitel 4, Überblick über iOS und Xamarin.iOS
Dieses Kapitel ist das Gegenstück zu Kapitel 3, nur dass es dieses Mal um iOS und nicht um Android geht.
Kapitel 5, Überblick über Xamarin.Forms
Nachdem in den Kapiteln 3 und 4 die spezifischen Plattformen behandelt wurden, geht es in Kapitel 5 um die Grundlagen zu Xamarin.Forms. Wir beleuchten in diesem Kapitel die Xamarin.Forms-Architektur und sehen uns den Aufbau von Xamarin.Forms-Projekten an.
Kapitel 6, Architektur von Cross-Plattform-Apps
In diesem Kapitel sehen wir uns verschiedene Strategien zum Teilen von Quellcode zwischen den verschiedenen Plattformen an. Unter anderem erfahren Sie, wie Sie durch den Einsatz von Microsoft.Extentions.DependencyInjection plattformübergreifenden und plattformspezifischen Quellcode separieren können.
Kapitel 7, Oberflächendesign mit Layoutcontainern
Im siebten Kapitel dreht sich alles darum, wie Sie Oberflächenelemente auf dem Bildschirm mit Layoutcontainern wie dem StackLayout oder dem Grid positionieren können.
Kapitel 8, Eingabeformulare anlegen
In Kapitel 7 haben Sie gelernt, wie Sie Steuerelemente auf dem Bildschirm positionieren können, in Kapitel 8 lernen Sie, welche Steuerelemente dies überhaupt sind. Wir werfen in diesem Kapitel einen Blick auf die gängigen Steuerelemente und ihre Einsatzmöglichkeiten.
Kapitel 9, Navigation und die Xamarin.Forms-Shell
Die Xamarin.Forms-Shell gehört zu den neueren Steuerelementen von Xamarin.Forms. Ihr Zweck ist es, eine einheitliche, routenbasierte Navigationsstruktur in Apps zu ermöglichen. In Kapitel 9 werfen wir einen Blick auf die Shell und sehen uns gemeinsam an, wie Sie mit der Shell eine seitliche Navigationsleiste, auch Burger-Menü genannt, oder eine Navigation über Tabs realisieren können.
Kapitel 10, Listen
Viele mobile Anwendungen bestehen zu großen Teilen aus Listen. Daher ist es nicht verwunderlich, dass Listen ein eigenes Kapitel erhalten und nicht nur ein kleiner Teil von Kapitel 8 sind. In Kapitel 10 sehen wir uns die Klasse CollectionView näher an, die die Klasse ListView zur Darstellung von Listen abgelöst hat.
Kapitel 11, Bilder, Icons und Schriftarten
Nutzer von mobilen Apps haben viel höhere Erwartungen an schöne Benutzeroberflächen als zum Beispiel Anwender klassischer Desktopsoftware. Bilder, Icons und Schriftarten sind drei Elemente, mit denen Sie diese Erwartungen erfüllen können. Ihren praktischen Einsatz sehen wir uns in Kapitel 11 an.
Kapitel 12, Styles und Themes in Xamarin.Forms
Styles werden in Xamarin.Forms genutzt, um Steuerelementen ein einheitliches Erscheinungsbild zu geben. Dieses Kapitel gibt Ihnen einen Einblick in die Nutzung von Styles.
Kapitel 13, Aufruf von Webservices
Daten von entfernten Webservices spielen für viele Apps eine große Rolle. In diesem Kapitel beschäftigen wir uns daher damit, wie wir Daten von Webservices abrufen, sie effizient zwischenspeichern und Daten an Webservices für schreibende Zugriffe übergeben.
Kapitel 14, Lokale Datenhaltung
Neben externen Daten sind selbstverständlich auch interne Daten wichtig. In Kapitel 14 sehen wir uns detailliert an, wie Sie Daten lokal im Dateisystem oder in einer lokalen SQLite-Datenbank speichern können.
Kapitel 15, Zugriff auf native Gerätefunktionen mit Xamarin.Essentials
In den Kapiteln 1 bis 14 haben wir uns überwiegend mit den plattformübergreifenden Aspekten der App-Entwicklung beschäftigt. Das Besondere einer App ist allerdings nicht nur, dass Sie sie überall hin mitnehmen können, sondern dass sie Sensoren und Funktionen des Mobilgeräts oder des mobilen Betriebssystems nutzen können. In diesem Kapitel werfen wir einen Blick auf Xamarin.Essentials, eine Bibliothek, die uns den plattformübergreifenden Zugriff auf Gerätefunktionen ermöglicht.
Dieses Buch ist für Softwareentwickler gedacht, die plattformübergreifende Apps mit Xamarin.Forms für Android und iOS schreiben möchten. Die primäre Zielgruppe sind Einsteiger und Fortgeschrittene, aber auch für Experten ist das ein oder andere Kapitel dabei.
Für die Lektüre dieses Buches sollten Sie bereits Erfahrung mit C#, Visual Studio und dem .NET Framework haben. Sie müssen kein Experte sein, aber ohne Vorwissen im Bereich der .NET-Entwicklung werden Sie wenig Freude an diesem Buch haben. Sollten Sie in diesem Umfeld noch keine Erfahrung haben, dann empfehle ich Ihnen, sich zunächst C#- und .NET-Basiswissen über Fachbücher oder eines der vielen Tutorials aus dem Internet anzueignen. Anschließend können Sie mit diesem Buch loslegen.
Der Inhalt des Buches ist so aufgebaut, dass Sie Schritt für Schritt das notwendige Wissen erlangen, um Apps mit Xamarin.Forms zu entwickeln. Daher empfehle ich Ihnen, das Buch von vorne nach hinten zu lesen. Jedes Kapitel startet mit einem kurzen Überblick und endet mit einer Zusammenfassung, anhand deren Sie kontrollieren können, ob Sie die Kernaussagen des Kapitels nachvollziehen konnten.
Wenn Sie bereits Erfahrung mit Xamarin.Forms haben, dann spricht natürlich nichts dagegen, einzelne Kapitel zu überspringen oder sich themenbezogen auf einzelne Kapitel zu konzentrieren.
An dieser Stelle möchte ich Sie jedoch darauf hinweisen, dass die Kapitel und vor allem der Quellcode der durchgehenden Beispiel-App jeweils auf den Inhalten vorheriger Kapitel aufbauen. Wenn Ihnen beim Sprung in ein Kapitel auffällt, dass Ihnen Grundlagen fehlen, dann empfehle ich Ihnen einen Blick in die vorherigen Kapitel.
Abschließend ist es mir noch wichtig anzumerken, dass dieses Buch kein Ersatz für die offizielle Xamarin-Online-Dokumentation (https://docs.microsoft.com/de-de/xamarin) ist. Dafür ist diese schlichtweg zu umfangreich. Dieses Buch legt den Fokus auf den praktischen Einsatz von Xamarin und kann dementsprechend nicht jede verfügbare Funktion beschreiben.
Zu fast jedem Kapitel gibt es Codebeispiele. Diese können Sie unter
https://github.com/andrekraemer/xamarin-buch
entweder vollständig als ZIP-Datei herunterladen oder über einen beliebigen Git-Client clonen.
Je Kapitel gibt es einen Ordner mit dem Namen Kap<Nr>, also zum Beispiel Kap02 für das Kapitel 2 oder Kap15 für das Kapitel 15. Außerdem gibt es auf oberster Ebene noch den Ordner Beispieldateien. In diesem Ordner finden Sie Bilddateien, Schriftarten und Daten, die Sie zur Bearbeitung der durchgängigen Beispielanwendung benötigen.
Dieses Buch verfolgt zwei Strategien für die Codebeispiele. In jedem Kapitel-Ordner gibt es Unterordner, die auf dem Wort Demo enden. In diesen Unterordnern finden Sie die Beispielcodes zu den Listings der entsprechenden Kapitel.
Ab Kapitel 5 gibt es außerdem in den meisten Kapitel-Ordnern den Unterordner ElVegetarianoFurio. Dabei handelt es sich um den Quellcode der Beispiel-App, die wir Schritt für Schritt in diesem Buch entwickeln werden. Der Quellcode der Beispiel-App in den jeweiligen Kapitelordnern entspricht dem Fortschritt zum Ende des Kapitels.
Inhalt der Beispiel-App ist die Umsetzung einer Speisekarten-App für das fiktive vegetarische, spanische Restaurant El Vegetariano Furio (zu Deutsch: Der wütende Vegetarier).
Bild 1.1 zeigt die Startseite der fertigen Beispiel-App, Bild 1.2 zeigt die Speisekarte in der Übersicht sowie die Detailseite einer Speise.
Bild 1.1 Die Startseite der Beispiel-App
Bild 1.2 Übersicht über die Speisekarte und die Detailseite der Beispiel-App
Den vollständigen Quellcode der App werden wir Schritt für Schritt gemeinsam in den einzelnen Kapiteln schreiben. Es wird nichts ausgelassen oder übersprungen, sodass Sie in der Lage sind, mit zu programmieren. Die Musterlösung der einzelnen Kapitel finden Sie, wie bereits gesagt, im Ordner ElVegetarianoFurio der einzelnen Unterkapitel.
Wenn Sie das Beispiel nicht durchgängig entwickeln, sondern mittendrin einsteigen möchten, dann ist dies natürlich kein Problem. Kopieren Sie einfach meine Musterlösung vom vorherigen Kapitel und legen Sie los.
Kein Buch ist fehlerfrei. Zumindest liest man dies in allen Fachbüchern, die man am Markt erhält. Wenn also bereits alle Autoren vor mir eingeräumt haben, dass ihr Buch Fehler hat, dann sollte ich wohl davon ausgehen, dass sich auch in meinem Buch trotz sehr gründlicher Prüfung – schließlich habe ich mir fünf Jahre Zeit genommen – Fehler eingeschlichen haben.
Korrekturen zu fachlichen Fehlern im Text sowie Rechtschreibkorrekturen finden Sie auf der Webseite zu diesem Buch, die Sie unter
https://andrekraemer.de/xamarin-buch
erreichen.
Eventuelle Fehler in den Codebeispielen werde ich kontinuierlich auf dem GitHub-Repository zu diesem Buch unter
https://github.com/andrekraemer/xamarin-buch
korrigieren. Wenn Sie in den Beispielen einen Fehler finden sollten, der noch nicht korrigiert ist, dann zögern Sie nicht, einen Issue über das GitHub-Repository anzulegen.
Dieses Buch lebt, wie alle Bücher, von Rückmeldungen und Kritiken der Leser. Ich lade Sie also herzlich ein, Rezensionen über das Buch, positiv wie negativ (am liebsten natürlich positiv) auf den gängigen Internetplattformen zu hinterlassen.
Scheuen Sie sich auch nicht, mich bei Fragen oder Anmerkungen zum Buch direkt per E-Mail unter [email protected] oder auf Twitter unter https://twitter.com/codemurai anzuschreiben. Bitte haben Sie aber Verständnis dafür, dass ich unter der E-Mail-Adresse nur Fragen, die sich direkt auf den Inhalt des Buches beziehen, beantworten kann.
Darüber hinausgehende Fragen kläre ich jedoch gerne in Schulungen und Workshops, die Sie auch unter dieser E-Mail-Adresse anfragen können.
Während des Schreibens dieses Buches habe ich mir Mühe gegeben, verständliche deutsche Sätze zu schreiben. Ich hoffe dies durchgehend geschafft zu haben und setze große Hoffnungen auf das Lektorat, falls dem nicht so sein sollte.
Überall, wo es sinnvoll war, habe ich außerdem deutsche statt englische Fachbegriffe genutzt. So werden Sie in diesem Buch häufiger Begriffe wie Schaltfläche statt Button oder Ereignisbehandlungsroutine statt Event-Handler finden. Aufgrund der Erfahrung aus meinen Schulungen und Workshops habe ich auch die deutschen Spracheinstellungen für Visual Studio für dieses Buch genutzt, da ein nicht unerheblicher Teil der Teilnehmer meiner Schulungen Visual Studio auf Deutsch benutzen. Daher finden Sie auch Begriffe wie Projektmappen-Explorer statt Solution-Explorer in diesem Buch.
Die deutsche Variante habe ich allerdings nur für etablierte Begriffe genutzt. Die krampfhafte Übersetzung von Begriffen, die durchgängig jeder noch so puristische Entwickler nutzt, den ich kenne, habe ich mir gespart. Statt Sie also rätseln zu lassen, was es mit einem Wegbestimmungssystem auf sich haben könnte, habe ich lieber den etablierten Ausdruck Routing-System genutzt.
In dem Wissen, dass man es niemals allen recht machen kann, nehme ich auch hier gerne Ihre Rückmeldung direkt per E-Mail unter [email protected] oder auf Twitter unter https://twitter.com/codemurai entgegen.
Im November 2021 wird .NET MAUI, der Nachfolger von Xamarin.Forms, erscheinen. Natürlich stellt sich nun die berechtigte Frage, ob es sich trotzdem noch lohnt, dieses Buch zu lesen. Wenn Sie dieses Buch vor dem Erscheinen von .NET MAUI lesen, dann ist die Antwort auf diese Frage ganz klar „ja!“. Ein Großteil des Wissens, dass Sie sich bei der Lektüre dieses Buches aneignen, wird auf .NET MAUI übertragbar sein. Mit der Hilfe dieses Buches können Sie also das notwendige Vorwissen erlangen, um mit .NET MAUI ab November durchstarten zu können.
Während des Verfassens dieses Buches habe ich auch darauf geachtet, Themen, die unter .NET MAUI vollständig anders gelöst werden, wie zum Beispiel Renderer, auszulassen. Außerdem habe ich statt des Xamarin.Forms DependencyService, den es unter .NET MAUI nicht mehr geben wird, den Einsatz von Microsoft.Extentions.DependencyInjection für das Thema Dependency Injection erläutert, da dies auch bei .NET MAUI Anwendung finden wird.
Selbst nach der Veröffentlichung von .NET MAUI kann es sinnvoll sein, dieses Buch zu lesen. Zum einen für den Fall, dass Sie eine bestehende Anwendung pflegen müssen, die noch nicht zu .NET MAUI migriert wird, zum anderen falls es noch kein Buch zu .NET MAUI gibt. Denn auch für diesen Fall ist das vorliegende Buch besser als gar keines, schließlich ist die Ähnlichkeit beider Frameworks sehr hoch.
Ein Buch zum Thema .NET MAUI habe ich übrigens bereits in Planung. Dieses Mal bin ich auch guter Dinge, dass es in kürzerer Zeit, relativ nah am Erscheinungstermin von .NET MAUI, fertig sein wird.
In diesem Sinne wünsche ich Ihnen viel Spaß und Erfolg bei der Lektüre dieses Buches und freue mich auf ein Wiedersehen beim nächsten Buch.
There’s no chance that the iPhone is going to get any significant market share. No chance.
Steve Ballmer
Unzutreffender hätte Steve Ballmer, der ehemalige CEO von Microsoft, im April 2007 die Zukunftsaussichten für das iPhone wohl kaum einschätzen können.
Wenige Wochen vor dessen Veröffentlichung ging er in einem Interview mit der USA Today davon aus, dass der Marktanteil des im Januar 2007 angekündigten iPhones ungefähr zwei bis drei Prozent ausmachen wird und Microsoft mit seinem Betriebssystem den Mobiltelefonmarkt mit einer Verbreitung von ca. 60 bis 80 % beherrschen wird.
Heute wissen wir, dass Ballmer nicht nur vollkommen falsch mit seiner Einschätzung lag, sondern dass Apple mit der Einführung des iPhones den Wendepunkt im Markt für Mobiltelefone einläutete. Während zuvor meist sogenannte Feature Phones, also Mobiltelefone im klassischen Sinne, die weder über einen Touchscreen noch einen Internetzugang oder App Store verfügten, verkauft wurden, lag der Marktanteil der Smartphones bereits im dritten Quartal 2014 laut einer Studie des amerikanischen IT-Marktforschungsunternehmens Gartner bei 66 Prozent. In der Studie wurde davon ausgegangen, dass bis 2018 neun von zehn Mobiltelefonen ein Smartphone sind.
Gemeinsam mit dem Siegeszug der Smartphones stieg auch der Bedarf an sogenannten Enterprise Mobile Apps, also solchen Apps, die Mitarbeiter, Partner oder Kunden von Unternehmen bei ihrer täglichen Arbeit unterstützen. Beispiele für solche Apps wären unter anderem eine Zeiterfassungs-App, eine Reisekosten-App, eine Customer-Relationship-Management (CRM)-App, eine Support-/Ticket-App, oder eine mobile Variante einer anderen internen Software. Gartner geht davon aus, dass der Bedarf an solchen Enterprise Mobile Apps die verfügbaren Entwicklungskapazitäten um den Faktor fünf übersteigen wird.
Verschärft wird diese Problematik dadurch, dass eine Mobile App häufig nicht nur für ein Betriebssystem entwickelt werden muss, sondern für zwei oder drei. Dies liegt daran, dass es für Unternehmen in der Regel nicht möglich ist, ihren Kunden die Nutzung eines bestimmten mobilen Betriebssystems, zum Beispiel iOS, vorzuschreiben. Selbst innerhalb des Unternehmens ist diese Möglichkeit nicht immer gegeben, da immer mehr Firmen auf eine Strategie setzen, die sich Bring Your Own Device (BYOD) nennt, bei der die Angestellten ihre privaten Mobiltelefone, Tablets usw. mit ins Unternehmen einbringen. Auch in diesem Fall kann das Unternehmen die Verwendung eines bestimmten mobilen Betriebssystems meist nicht vorschreiben, da es sich um die privat angeschafften Geräte der Mitarbeiter handelt.
Viele Unternehmen stehen somit vor der Herausforderung, dass sie eine oder mehrere Apps für zwei oder mehr mobile Betriebssysteme entwickeln müssen. Dabei kann es sich um eine interne App zur Optimierung der eigenen Unternehmensabläufe, um eine externe App, die zur Kommunikation mit den Kunden genutzt wird, oder – im Fall von Softwarehäusern – um eine mobile Variante eines bereits bestehenden Produkts handeln.
Natürlich stellt sich nun die Frage, wie diese Herausforderung möglichst wirtschaftlich gemeistert werden kann. So stehen neben der Variante, für jedes mobile Betriebssystem eine eigene App mit den plattformspezifischen Werkzeugen zu entwickeln, weitere Alternativen zur Verfügung, die es ermöglichen, Apps für mehrere Plattformen auf einer gemeinsamen Code-Basis zu erzeugen. Zu den bekanntesten Alternativen gehören React Native, Flutter, Native Script, Apache Cordova und Xamarin.
In diesem Buch werden Sie lernen, wie Sie Apps für Android und iOS auf Basis der Xamarin-Plattform unter der Verwendung von Xamarin.Forms entwickeln können. Das Buch richtet sich dabei hauptsächlich an Entwickler, die aktuell Software auf Basis der Microsoft .NET-Plattform unter der Verwendung von Visual Studio entwickeln und eine Enterprise bzw. Line-Of-Business (LOB)-App entwickeln möchten. Die Entwicklung von Spielen für mobile Endgeräte ist somit explizit ausgeklammert.
1.1Xamarin und die Xamarin-PlattformWenn man von Xamarin spricht, dann meint man in der Regel die Xamarin-Plattform, ein Produkt der Firma Microsoft. Sie ermöglicht die Entwicklung von Apps für iOS und Android in Microsofts Programmiersprache C#. Eine spezielle Version für Windows-Apps gibt es nicht, da Windows-Apps bereits von Haus aus in C# entwickelt werden.
Grundlage für die Xamarin-Plattform ist das Mono Framework. Mono ist eine quelloffene Implementierung des Microsoft .NET Framework für Linux, Mac OSX und Windows, die unter einer MIT-Lizenz steht. Das Projekt wurde im Dezember 2000 durch Miguel de Icaza gestartet. Im Mai 2011 gründete er gemeinsam mit einem Partner die Firma Xamarin, die im März 2016 von Microsoft aufgekauft wurde.
In diesem Zuge wurde das Software Development Kit (SDK) der Xamarin-Plattform unter eine MIT-Open-Source-Lizenz gestellt. Die Integration in die Entwicklungsumgebung Visual Studio bleibt jedoch zunächst proprietär.
Xamarin, Xamarin-Plattform und .NET Multi-platform App UI (MAUI)
Die Xamarin-Plattform ist ein Produkt von Microsoft, welches ursprünglich von der Firma Xamarin entwickelt wurde. Xamarin ist somit der Name einer durch Microsoft aufgekauften Firma, der Begriff Xamarin-Plattform bzw. auf Englisch Xamarin Platform steht für das Produkt zur Entwicklung plattformübergreifender Lösungen.
Viele Entwickler sagen lediglich Xamarin, wenn sie von der Xamarin-Plattform sprechen. Zur Steigerung des Leseflusses halte ich es auch in diesem Buch so und werde statt Xamarin-Plattform an den meisten Stellen einfach Xamarin schreiben. Selbstverständlich ist dann stets das Produkt und nicht die Firma gemeint.
Der Name Xamarin wird ab der Version .NET 6 mit geplantem Veröffentlichungsdatum im November 2021 verschwinden. Xamarin.Forms wird dann zu .NET Multi-platform App UI, kurz .NET MAUI umbenannt. Aus Xamarin.Android wird .NET for Android und aus Xamarin.iOS wird .NET for iOS.
Wer mit Xamarin entwickelt, dem steht neben der Programmiersprache C# ein Großteil der Klassenbibliotheken des .NET Frameworks sowie alle nativen APIs der jeweiligen Plattform zur Verfügung. Das Ergebnis des Xamarin-Übersetzungsvorgangs ist eine native App für die jeweilige Plattform.
Zur Entwicklung von Oberflächen greift Xamarin auf die nativen Oberflächen-Steuerelemente aus den SDKs der mobilen Betriebssysteme zurück. Dadurch gibt es keine Layoutabweichungen zwischen einer App, die mit Xamarin entwickelt wurde, und einer App, die direkt mit den Werkzeugen und Programmiersprachen von Apple und Google entwickelt wurde. Ein Benutzer erkennt also keinen Unterschied zwischen einer Xamarin-App und einer traditionellen App.
Da sich die Oberflächentechnologien von Android und iOS jedoch unterscheiden, bedeutet dies, dass die Oberflächen unter Xamarin separat entwickelt werden müssen, oder zumindest mussten. Seit der Version 3 steht mit Xamarin.Forms eine Abstraktionsschicht bereit, die optional genutzt werden kann.
Wird Xamarin.Forms nicht genutzt, so kann plattformübergreifend lediglich die Geschäftslogik der App sowie die Datenzugriffsschicht zum Zugriff auf lokale Datenbanken oder externe Web Services genutzt werden. In einer typischen Drei-Schichten-Architektur, wie sie Bild 1.1 zeigt, hätte man demnach in den unteren beiden Schichten plattformübergreifend nutzbaren C# Quellcode. Diese Herangehensweise wird häufig auch der „klassische Xamarin Ansatz“ genannt.
Bild 1.1Typische Xamarin Drei-Schichten-Architektur
Zusätzlich zum geteilten Quellcode wird beim klassischen Ansatz je Plattform ein weiteres Xamarin-Projekt angelegt, welches die Oberfläche in Form von Android-XML-Layout-Dateien bzw. iOS Storyboards oder UWP XAML Views enthält. Darüber hinaus beinhalten diese Projekte auch Oberflächenlogik sowie plattformspezifischen Quellcode, zum Beispiel zum Ansteuern der Sensoren, der Kamera etc. über die nativen SDKs der Hersteller.
Der Anteil an plattformübergreifend nutzbarem Quellcode hängt von der Komplexität der Oberfläche sowie der Nutzung nativer SDKs und APIs ab. In den wenigen belastbaren Quellen findet man Werte zwischen 60 und 90 Prozent. Xamarin selbst nennt einen durchschnittlichen Wert von 75 Prozent. Der Einsatz gängiger Entwurfsmuster in der Softwareentwicklung, zum Beispiel eines Model-View-Controller (MVC)- oder Model-View-Presenter (MVP)-Musters kann den Anteil des übergreifenden Quellcodes positiv beeinflussen.
Mit Xamarin.Forms, einer Technologie, die im Sommer 2015 als Teil der Xamarin-Plattform-Version 3 eingeführt wurde, kann der Anteil an plattformübergreifend nutzbarem Quellcode weiter erhöht werden. Xamarin selbst spricht von über 90 % bzw. von fast 100 %.
Mit Xamarin.Forms können Oberflächen anstatt mit iOS Storyboards und Android-XML-Layout-Dateien übergreifend mit XAML oder in C#-Quellcode beschrieben werden. Xamarin nutzt hier allerdings einen eigenen XAML-Dialekt, der nicht zum XAML der UWP-Apps kompatibel ist.
Die Idee hinter Xamarin.Forms ist, dass Oberflächen lediglich abstrakt auf der Basis vordefinierter Elemente beschrieben werden. Zu diesen Elementen gehören unter anderem Eingabefelder, Schaltflächen oder Navigationselemente wie Tabs. Zu jedem dieser Steuerelemente gibt es pro Plattform einen sogenannten Renderer, der auf Basis der abstrakten Beschreibung ein konkretes, plattformspezifisches Steuerelement erzeugt. Zur Laufzeit der App werden die einzelnen Renderer aufgerufen. Dementsprechend erhält man, trotz einer plattformübergreifenden Beschreibung des Layouts, native Oberflächen mit entsprechender Performance.
Da der Xamarin-XAML-Dialekt, ähnlich wie der Microsoft-XAML-Dialekt, Datenbindung zur Synchronisation der Oberfläche und Domänenklassen unterstützt, kann unter Xamarin. Forms das Model-View-ViewModel (MVVM)-Muster eingesetzt werden, um die Oberflächenlogik plattformunabhängig zu implementieren. Daher beschränkt sich der plattformspezifische Quellcode in einer Xamarin.Forms-Anwendung tatsächlich auf wenige Zeilen. Diese sind meist auch nur notwendig, wenn auf Hardwarefunktionen des Geräts zugegriffen werden muss, zum Beispiel auf die Kamera oder den Beschleunigungssensor. Bild 1.2 verdeutlicht diesen Zusammenhang.
Bild 1.2Drei-Schichten-Architektur mit Xamarin.Forms
Der Xamarin.Forms-Ansatz macht gerade in Apps im geschäftlichen Umfeld Sinn. Häufig werden in diesem Bereich keine speziellen Anforderungen an die Oberfläche gestellt.
Xamarin.Forms wird eins zu eins in die Standardoberflächenelemente der jeweiligen Plattform übersetzt. Infolgedessen entspricht das Layout einer Xamarin.Forms-App dem, was ein Benutzer der jeweiligen Plattform erwartet. Sollten trotzdem in einer App in manchen Szenarien Designs fernab des Standards notwendig sein, so haben Entwickler über die Implementierung eigener Renderer oder über einen Mischbetrieb zwischen Xamarin.Forms und dem klassischen Xamarin-Ansatz stets die Möglichkeit, auch besondere Oberflächenwünsche zu realisieren.
1.3Architektur der Xamarin-PlattformWie bereits zuvor beschrieben, ist das Mono Framework die technische Grundlage der Xamarin-Plattform. Bei diesem Framework handelt es sich um eine quelloffene Implementierung von Microsofts .NET Framework und des C#-Compilers.
1.3.1Mono und das .NET FrameworkDer Zusammenhang zwischen dem .NET Framework und Mono lässt sich wie folgt erklären: Als Microsoft das .NET Framework und die Programmiersprache C# Ende der 1990er Jahre/Anfang 2000 entwickelte, entschied man sich bereits während der Entwicklung dazu, sowohl die Sprache C# als auch Teile des Frameworks bei der European Computer Manufacturers Association (ECMA) zu standardisieren. Als Ergebnis kamen die Standards Ecma-334 (C#) sowie Ecma-335 (Common Language Infrastructure, CLI) heraus. Die CLI beschreibt eine sprach- und plattformunabhängige Laufzeitumgebung sowie ein Set an Standardbibliotheken.
Mit dem .NET Framework veröffentlichte Microsoft 2002 eine Implementierung des C#-Compilers sowie mit der Common Language Runtime und der Framework Class Library (FCL), deren Kern die Base Class Library (BCL) bildet, eine Implementierung der CLI für Windows-Systeme.
2001 wurde durch Miguel de Icaza, ein späterer Mitbegründer des Unternehmens Xamarin, das Mono-Open-Source-Projekt gegründet. Ziel des Projekts war die Bereitstellung einer quelloffenen Implementierung der Ecma-Standards 334 und 335 für Windows, Linux, Unix sowie macOS. Die Version 1.0 von Mono wurde 2004 veröffentlicht.
Mono besteht aus den folgenden Komponenten:
C#-Compiler: Der Mono-C#-Compiler (MCS) deckt die C#-Versionen 1.0 bis 6.0 vollständig ab. Ab Mono 5, das im Mai 2017 erschien, nutzt Mono den Roslyn-Compiler statt des eigenen Compilers. Dieser wird auch von Microsoft in Visual Studio genutzt. Durch diesen Schritt unterstützt Mono über den Roslyn-Compiler nun auch aktuelle C#-Versionen.
Mono Runtime: Die Mono-Laufzeitumgebung ist eine Umsetzung der CLI, also das Pendant zur Microsoft .NET CLR. Sie beinhaltet neben einem Just-in-Time (JIT)-Compiler auch einen Ahead-of-Time-Compiler. Letzterer wird insbesondere im iOS-Umfeld benötigt. Darüber hinaus gehört auch ein Garbage Collector zur Laufzeitumgebung.
Framework Class Library: Mono verfügt über eine Klassenbibliothek, die CLI-Standardbibliothek.
Mono Class Library: Abgesehen von der CLI-Standardbibliothek stellt Mono weitere Klassen zur Verfügung, die zum Beispiel im Umfeld von Linux-basierten Anwendungen nützlich sind.
Bild 1.3 zeigt die einzelnen Bestandteile und verdeutlicht den Zusammenhang zwischen den jeweiligen ECMA-Standards, dem .NET Framework und der Mono-Plattform.
Bild 1.3Der Zusammenhang zwischen dem .NET Framework und Mono
Bemerkenswert ist, dass die Mono-Implementierung in großen Teilen kompatibel zum .NET Framework ist, obwohl die Umsetzung vollkommen eigenständig und rein auf der Basis der Ecma-Standarddokumente geschah.
In den ersten Jahren wurde keinerlei Quellcode zwischen den Frameworks ausgetauscht. Erst nachdem Microsoft Ende 2014 das .NET Framework unter eine MIT-Open-Source-Lizenz stellte, wurde innerhalb des Mono-Projekts damit begonnen, Quellcode aus der .NET Framework Class Library in die Mono Class Library zu übernehmen.
Gleichzeitig begann Microsoft auch direkt an einer quelloffenen, plattformübergreifenden Variante des .NET Frameworks mit dem Namen .Net Core zu arbeiten. Diese neue Variante bringt, wie in Bild 1.4 zu sehen ist, eine eigene Klassenbibliothek mit dem Namen CoreFX mit.
Bild 1.4.NET Framework, Xamarin und .NET Core
Mit der Version 5 verschwand der Namenszusatz Core von .NET Core. Hintergrund ist, dass das klassische .NET Framework nicht mehr weiterentwickelt und von .NET Core abgelöst wird. Im Zuge dieser Zusammenführung soll ab .NET 6 auch eine gemeinsame Klassenbibliothek auf der Basis der CoreFX für .NET und Xamarin (bzw. .NET MAUI) eingeführt werden.
1.3.2Mono als Grundlage der Xamarin-PlattformZur Entwicklung und Ausführung von Apps unter Android und iOS nutzt Xamarin eine angepasste Variante des Mono-Frameworks. Das bedeutet, dass eine mit Xamarin entwickelte App durch den Mono-C# Compiler-übersetzt wird und zur Ausführungszeit die Mono-Laufzeitumgebung und die Mono-Klassenbibliothek nutzt.
Obwohl Entwickler mit Kenntnissen im Umfeld des .NET Frameworks den Eindruck haben, genau dieses auch zu nutzen, werden durch Xamarin-Apps weder die .NET Framework Class Library, noch die Common Language Runtime (CLR) genutzt.
Grafisch zeigt diese Situation Bild 1.5. Während klassische Anwendungstypen, wie Windows-Presentation-Foundation (WPF)-Anwendungen, das traditionelle .NET Framework nutzen, ist die Grundlage von Xamarin-Apps das Mono-Framework.
Bild 1.5Zuordnung von Anwendungstypen und Frameworks
Wie die Xamarin-Architektur auf den Plattformen Android und iOS im Überblick aussieht, erfahren Sie in den nächsten beiden Abschnitten.
1.3.2.1Xamarin.AndroidUnter Android sieht die Xamarin-Architektur wie folgt aus: Die Xamarin-Anwendung wird durch den Compiler in Intermediate Language (IL) kompiliert und durch die in C implementierte Mono-Laufzeitumgebung ausgeführt, die parallel zur Android Runtime ART VM auf dem Linux-Kernel des Android-Betriebssystems ausgeführt wird.
Der Just-In-Time-Compiler der Mono-Laufzeitumgebung übersetzt den IL-Code zur Ausführungszeit in nativen Maschinencode, der schließlich zur Ausführung kommt.
Über den sogenannten Managed Callable Wrapper (MCW) kann in C# geschriebener Code Funktionen des Android-Application-Frameworks, der Android Libraries oder anderer Java-Bibliotheken aufrufen. Auch das Implementieren von Java-Schnittstellen oder das Überschreiben virtueller Java-Methoden ermöglicht der MCW.
Um notwendige Typkonvertierungen kümmert sich der MCW. Diese sind erforderlich, da zum Beispiel Strings unter C# anders verwaltet werden als unter Java. Ehe der Java-Code jedoch aufgerufen werden kann, muss zuvor eine entsprechende Binding-Bibliothek erstellt werden. Für sämtliche Android-Standardklassen ist dies bereits durch Xamarin erledigt worden. Eigene Bindungen für andere Bibliotheken können über die Xamarin-Werkzeuge generiert und, falls notwendig, von Hand modifiziert werden.
Neben dem MCW gibt es noch den Android Callable Wrapper (ACW). Er wird genutzt, um C#-Code für Aufrufe aus Android nutzbar zu machen. Dies ist zum Beispiel dann der Fall, wenn im Rahmen eines Callbacks (Rückruffunktion) eine eigene Methode aus einer Android-Klasse heraus aufgerufen werden soll. Einen Überblick über die zuvor beschriebene Arbeitsweise von Xamarin unter Android gibt Bild 1.6.
Bild 1.6Architektur von Xamarin.Android
Da die .NET-Klassenbibliothek im Gegensatz zum Android Application Framework nicht bereits mit dem Android-Betriebssystem installiert wird, muss sie für jede Xamarin-App einzeln verteilt werden. Gleiches gilt für die Mono-Laufzeitumgebung.
Dadurch ist das Installationspaket einer Xamarin-App mindestens 2,5 MB größer als das einer vergleichbaren nativen App, die direkt mit dem Android oder iOS SDK unter Java bzw. Objective-C oder Swift entwickelt wurde.
Bei einem von Xamarin erzeugten Installationspaket handelt es sich um ein Standard-Android-APK-Paket. Aus Sicht des Endanwenders ist eine Xamarin-Android-App also, abgesehen vom größeren Installationspaket, eine App so wie jede andere Android-App auch.
Die bisherige Betrachtung von Xamarin.Android soll an dieser Stelle für einen ersten Überblick reichen. Detailliertere Informationen zu Android und Xamarin.Android erhalten Sie in Kapitel 3.
1.3.2.2Xamarin.iOSUnter iOS wird der Quellcode ähnlich wie bei der Android-Variante zunächst in IL kompiliert. Dieser IL-Code wird allerdings nicht zur Ausführungszeit durch den Just-In-Time-Compiler übersetzt und durch die Mono-Laufzeitumgebung ausgeführt. Stattdessen wird der IL-Code Ahead-of-Time (AOT) in ARM-Maschinencode kompiliert.
Der Grund für die AOT-Übersetzung ist, dass Apple keine Ausführung von dynamisch geniertem Code unter iOS erlaubt. Da jedoch genau dies durch den Just-In-Time-Compiler und die Laufzeitumgebung geschieht, muss der IL-Code durch den AOT-Compiler in ARM-Maschinencode übersetzt werden. Bild 1.7 verdeutlicht diesen Ablauf.
Bild 1.7Übersetzung von iOS-Anwendungen
Eine weitere Einschränkung liegt darin, dass iOS-Apps nur auf einer original Apple-Hardware übersetzt werden dürfen. Das bedeutet, dass Xamarin-Entwickler entweder direkt auf einem Mac arbeiten müssen oder zumindest Zugriff auf einen Mac benötigen, um mithilfe von Visual Studio die App remote auf diesem zu übersetzen.
Auch die Betrachtung von Xamarin.iOS soll an dieser Stelle fürs Erste abgeschlossen sein. Detaillierte Informationen zu iOS und Xamarin.iOS erhalten Sie in Kapitel 4.
1.4EntwicklungswerkzeugeZur Entwicklung von Apps mit Xamarin können Sie auf einem Mac Visual Studio für Mac nutzen. Es handelt sich dabei um eine Weiterentwicklung von Xamarin Studio, welches im Mai 2017 durch Visual Studio für Mac ersetzt wurde. Für Windows steht eine Integration in Microsoft Visual Studio zur Verfügung.
Visual Studio für Mac bietet alle Funktionen, die Entwickler von einer modernen IDE erwarten. Quellcode kann nicht nur editiert und übersetzt werden, sondern kompilierte Apps können auch sofort zum Debugging auf einem Gerät oder im Android-Emulator bzw. iOS-Simulator gestartet werden.
Darüber hinaus verfügt die Entwicklungsumgebung über einen leistungsstarken iOS Storyboard Designer zum Designen von iOS-Bildschirmmasken (siehe Bild 1.8), den Sie ab Kapitel 4 näher kennenlernen werden. Dieser ist kompatibel zu Apples Xcode Storyboard Designer.
Für Android-Bildschirmmasken steht ein ähnlicher Maskeneditor bereit. Für die Arbeit im Team bietet Xamarin Studio eine Schnittstelle zu den Versionsverwaltungssystemen Git und Subversion. Eine Anbindung an die Team-Foundation-Server-Versionsverwaltung fehlt.
Bild 1.8iOS Storyboard Designer in Visual Studio
Die Entwicklung einer App mit Xamarin kann sowohl unter macOS, als auch unter Windows durchgeführt werden.
Da das iOS SDK allerdings nur für macOS von Apple zur Verfügung gestellt wird, dies jedoch zum Übersetzen einer Xamarin.iOS-App benötigt wird, ist ein Apple Mac mit installiertem Xcode und iOS SDK zwingend erforderlich. Die Entwicklung von Xamarin.Forms-Apps für iOS kann auf einem iOS-Gerät zwar mithilfe von Xamarin Hot Restart auch ohne Mac stattfinden, zur vollständigen Entwicklung und vor allem Verpackung von iOS-Apps ist ein Mac jedoch unverzichtbar.
Trotz dieser Einschränkung kann die Entwicklung vollständig unter Windows in Visual Studio stattfinden. Ein Bestandteil von Xamarin.iOS ist der sogenannte Mac Build Agent, der detailliert in Kapitel 4 behandelt wird. Dieser wird auf einem Apple Mac mit Xcode und iOS SDK installiert, sobald Visual Studio for Mac auf dem Mac installiert wurde. Danach kann unter Windows in Microsoft Visual Studio über die Xamarin-Erweiterung eine Verbindung zu diesem Build Agent hergestellt werden.
Fortan wird jede Übersetzungs- oder Debugging-Anforderung von Visual Studio an den Mac Build Agent weiterdelegiert. Über diesen Weg ist es dann nicht nur möglich, eine App auf dem Remote-Mac zu übersetzen. Auch das Debugging einer App auf einem angeschlossenen iOS-Gerät aus Visual Studio unter Windows ist über diesen Weg möglich.
Der gewohnte Komfort während des Debuggings, also zum Beispiel das Setzen von Haltepunkten oder das Inspizieren von Variablenwerten zur Laufzeit, bleibt auch in dieser Kombination erhalten.
Für die Entwicklung von Apps für mehrere mobile Betriebssysteme werden eine Vielzahl von Werkzeugen benötigt.
So müssen neben der reinen Integration in Visual Studio zum Beispiel das Java Software Development Kit (JDK), das Android SDK, diverse Emulatoren und noch vieles mehr installiert und konfiguriert werden.
Da diese verschiedenen Werkzeuge Abhängigkeiten untereinander haben, stellte sich die Installation eines Xamarin-Entwicklungssystems während der ersten Tage der Xamarin-Plattform als eine wirkliche Herausforderung dar. Der Xamarin Installer wurde jedoch stetig verbessert und installierte von Version zu Version immer mehr der einzelnen Bestandteile zuverlässig selbst im Rahmen der Xamarin-Hauptinstallation.
Ab Visual Studio 2017 ist die Installation unter Windows sehr einfach geworden. Innerhalb des Visual Studio Installers müssen Sie lediglich die Auswahlbox Mobile-Entwicklung mit .NET auswählen, wie in Bild 1.9 gezeigt.
Bild 1.9Installation von Xamarin und den notwendigen SDKS über den Visual Studio Installer
Bei der Xamarin-Plattform handelt es sich um ein Produkt von Microsoft, das die Entwicklung von Apps für Android und iOS mit C# und dem .NET Framework ermöglicht.
Statt des klassischen .NET Frameworks nutzt Xamarin eine alternative, quelloffene Implementierung: das Mono Framework.