Teil 3 – Einrichten einer plattformübergreifenden Xamarin-Lösung

  • Artikel

Unabhängig davon, welche Plattformen verwendet werden, verwendet Xamarin alle das gleiche Lösungsdateiformat (das Dateiformat von Visual Studio.sln). Lösungen können in Entwicklungsumgebungen gemeinsam genutzt werden, auch wenn einzelne Projekte nicht geladen werden können (z. B. ein Windows-Projekt in Visual Studio für Mac).

Beim Erstellen einer neuen plattformübergreifenden Anwendung besteht der erste Schritt darin, eine leere Lösung zu erstellen. In diesem Abschnitt wird erläutert, was als Nächstes geschieht: Einrichten der Projekte zum Erstellen plattformübergreifender mobiler Apps.

Code freigeben

Im Dokument "Codefreigabeoptionen" finden Sie eine ausführliche Beschreibung der Implementierung von Codefreigaben auf allen Plattformen.

.NET Standard

.NET Standard-Projekte bieten eine einfache Möglichkeit zum Freigeben von Code über Plattformen hinweg und erstellen Assemblys, die auf Windows-, Xamarin-Plattformen (iOS, Android, Mac) und Linux verwendet werden können. Dies ist die empfohlene Methode zum Freigeben von Code für Xamarin-Lösungen.

Weitere Optionen

Historisch verwendete Xamarin portable Klassenbibliotheken (PCLs)] und freigegebene Projekte. Keine dieser Projekte wird für neue Projekte empfohlen; und Sie sollten die Migration vorhandener Apps in Erwägung ziehen, um .NET Standard zu verwenden.

Auffüllen der Lösung

Unabhängig davon, welche Methode zum Freigeben von Code verwendet wird, sollte die gesamte Lösungsstruktur eine mehrschichtige Architektur implementieren, die die Codefreigabe fördert. Der Xamarin-Ansatz besteht darin, Code in zwei Projekttypen zu gruppieren:

  • Kernprojekt (oder "Freigegeben") – Schreiben Sie wiederverwendbaren Code an einer zentralen Stelle, um auf verschiedenen Plattformen gemeinsam genutzt zu werden. Verwenden Sie die Prinzipien der Kapselung, um Implementierungsdetails möglichst auszublenden.
  • Plattformspezifische Anwendungsprojekte – Nutzen Sie den wiederverwendbaren Code mit so wenig Kopplung wie möglich. Plattformspezifische Features werden auf dieser Ebene hinzugefügt, die auf Komponenten basieren, die im Core-Projekt verfügbar gemacht werden.

Kernprojekt

Kernprojekte, die Code freigeben, sollten .NET Standard und nur Referenzassemblys sein, die auf allen Plattformen verfügbar sind – d. h. die allgemeinen Framework-Namespaces wie System, System.Core und System.Xml.

Kernprojekte sollten so viele Funktionen wie möglich implementieren, die nicht-UI-Funktionen aufweisen, die die folgenden Ebenen umfassen können:

  • Data Layer – Code, der sich um physische Datenspeicherung kümmert, z. B. SQLite-NET - oder sogar XML-Dateien. Die Datenschichtklassen werden normalerweise nur von der Datenzugriffsschicht verwendet.
  • Data Access Layer – Definiert eine API, die die erforderlichen Datenvorgänge für die Funktionalität der Anwendung unterstützt, z. B. Methoden für den Zugriff auf Listen mit Daten, einzelne Datenelemente und das Erstellen, Bearbeiten und Löschen dieser Daten.
  • Service Access Layer – Eine optionale Ebene zur Bereitstellung von Clouddiensten für die Anwendung. Enthält Code, der auf Remotenetzwerkressourcen (Webdienste, Bilddownloads usw.) zugreift, und möglicherweise das Zwischenspeichern der Ergebnisse.
  • Business Layer – Definition der Modellklassen und der Fassaden- oder Managerklassen, die Funktionen für plattformspezifische Anwendungen verfügbar machen.

Plattformspezifische Anwendungsprojekte

Plattformspezifische Projekte müssen auf die Assemblys verweisen, die zum Binden an das SDK der einzelnen Plattformen (Xamarin.iOS, Xamarin.Android, Xamarin.Mac oder Windows) sowie an das .NET Standard-Projekt erforderlich sind.

Die plattformspezifischen Projekte sollten folgendes implementieren:

  • Application Layer – Plattformspezifische Funktionalität und Bindung/Konvertierung zwischen den Business Layer-Objekten und der Benutzeroberfläche.
  • Benutzeroberflächenebene – Bildschirme, benutzerdefinierte Benutzeroberflächensteuerelemente, Darstellung der Validierungslogik.

Projektverweise

Projektverweise spiegeln die Abhängigkeiten für ein Projekt wider. Kernprojekte beschränken ihre Verweise auf allgemeine Assemblys, sodass der Code einfach freigegeben werden kann. Plattformspezifische Anwendungsprojekte verweisen auf das .NET Standard-Projekt sowie auf alle anderen plattformspezifischen Assemblys, die sie benötigen, um die Zielplattform zu nutzen.

Spezifische Beispiele dafür, wie Projekte strukturiert werden sollen, werden in den Fallstudien gegeben.

Hinzufügen von Dateien

Buildvorgang

Es ist wichtig, die richtige Buildaktion für bestimmte Dateitypen festzulegen. Diese Liste zeigt die Buildaktion für einige gängige Dateitypen:

  • Alle C#-Dateien – Buildaktion: Kompilieren
  • Bilder in Xamarin.iOS & Windows – Buildaktion: Inhalt
  • XIB- und Storyboarddateien in Xamarin.iOS – BuildAktion: InterfaceDefinition
  • Bilder und XML-Layouts in Android – Buildaktion: AndroidResource
  • XAML-Dateien in Windows-Projekten – Buildaktion: Seite
  • Xamarin.Forms XAML-Dateien – Buildaktion: EmbeddedResource

Im Allgemeinen erkennt die IDE den Dateityp und schlägt die richtige Buildaktion vor.

Unterscheidung nach Groß-/Kleinschreibung

Denken Sie schließlich daran, dass einige Plattformen über Dateisysteme mit Groß-/Kleinschreibung (z. B. iOS und Android) verfügen. Achten Sie daher darauf, einen konsistenten Dateibenennungsstandard zu verwenden und sicherzustellen, dass die dateinamen, die Sie im Code verwenden, exakt mit dem Dateisystem übereinstimmen. Dies ist besonders wichtig für Bilder und andere Ressourcen, auf die Sie im Code verweisen.