Native Bibliotheks-Interoperabilität

Übersicht

Die native Bibliotheksinteroperabilität (früher als „Slim Binding-Ansatz“ bezeichnet) bezieht sich auf ein Muster für den Zugriff auf native SDKs in .NET MAUI-Apps, einschließlich .NET für Android, .NET für iOS und .NET für Mac Catalyst-Apps. Die Idee besteht darin, Ihre eigene Abstraktion oder dünne „Wrapper“ mit einer vereinfachten API-Oberfläche für die nativen SDKs zu erstellen, die Sie von .NET aus aufrufen möchten. Die nativen "Wrapper"-Bibliotheks-/Frameworkprojekte werden in Android Studio mithilfe von Java/Kotlin und/oder Xcode mithilfe von Objective-C/Swift erstellt. Dieser Ansatz ist besonders vorteilhaft, wenn Sie nur einen kleinen Teil der API-Oberfläche des SDK benötigen, obwohl er auch bei der Nutzung einer größeren API-Oberfläche gut funktioniert.

Verstehen, wann und warum die native Bibliotheks-Interoperabilität verwendet wird

Die native Bibliotheks-Interoperabilität ist ein sehr effektiver Ansatz für die Integration in native Bibliotheken, obwohl es möglicherweise nicht immer die beste Lösung für Ihr Projekt ist. Allgemein gilt: Wenn Sie bereits Bindungen unterhalten und dies auch weiterhin tun möchten, ist es nicht erforderlich, die Vorgehensweise zu ändern. Für Projekte, die eine umfangreiche Nutzung der API einer Bibliothek erfordern, oder für Anbieter, die .NET MAUI-Entwickler unterstützen, sind traditionelle Bindungen möglicherweise immer noch besser geeignet. Die native Bibliotheks-Interoperabilität bietet jedoch eine Alternative, die oft einfacher zu verstehen, zu implementieren und zu unterhalten ist.

Ein wichtiger Vorteil der nativen Bibliotheks-Interoperabilität ist ihre Effektivität bei einfachen API-Oberflächen. Wenn Wrapper nur primitive Typen umfassen, die .NET unterstützt, können vorhandene Bindungstools zuverlässige Definitionen mit minimalem manuellen Eingriff generieren, was bei herkömmlichen Bindungen oft erforderlich ist. Dies macht den Prozess einfach, zumal die Implementierung der Wrapper-API in der Regel der SDK-Dokumentation folgt und oft das direkte Kopieren aus der Herstellerdokumentation erlaubt.

Während das anfängliche Setup komplizierter sein kann, erfordert die Verwaltung von Updates für zugrunde liegende SDKs im Allgemeinen weniger Aufwand. Aktualisierungen umfassen häufig das einfache Anpassen der Version und das Neuerstellen des Projekts. Auch wenn in den API-Schnittstellen oder SDKs inkompatible Änderungen auftreten, bleiben die Schnittstelle der Wrapper-API und deren Nutzung durch die .NET-Anwendung eher stabil, sodass im Vergleich zu herkömmlichen Bindungen weniger Anpassungen erforderlich sind.

Zusammenfassend bietet die native Bibliotheks-Interoperabilität mehrere Vorteile:

• Vereinfacht das Befolgen der SDK-Dokumentation mit nativen Sprachen und Tools
• Erfordert weniger manuelle Eingriffe zum Erstellen von funktionierenden Bindungen
• Erleichtert die Wartung und reduziert die Häufigkeit erforderlicher Updates
• Verbessert die Isolation der App vor Änderungen an zugrunde liegenden SDKs

Obwohl das Auflösen von Abhängigkeitsketten (insbesondere unter Android) ähnliche Anstrengungen wie herkömmliche Bindungen erfordern kann, machen die optimierten Implementierungs- und Wartungsvorteile die native Bibliotheks-Interoperabilität zu einer attraktiven Wahl für viele Projekte.

Grundlegendes zu Maui.NativeLibraryInterop

Eine besondere Herausforderung beim Erstellen und Pflegen von Bindungen, die über native Bibliotheks-Interoperabilität erstellt wurden, ist das manuelle Zusammenführen der nativen Projekte, ihrer nativen Abhängigkeiten, Build-Ausgaben und des .NET Binding-Bibliotheksprojekts. Maui.NativeLibraryInterop hilft Ihnen, den Prozess zu beschleunigen, indem Sie auf den Beispielen aufbauen und diese an die Bedürfnisse Ihrer eigenen Anwendung anpassen.

Dazu gehört auch die Orchestrierung von Teilen des Buildprozesses durch MSBuild-Aufrufe. Dies kann beinhalten:

• Auflösen oder Herunterladen nativer SDK-Abhängigkeiten
• Erstellen des nativen Slim Binding-Projekts und seiner Abhängigkeiten
• Verschieben der erforderlichen nativen Artefakte in das erwartete Arbeitsverzeichnis
• Generieren der API-Definition für das Bindungsbibliotheksprojekt

Android-Bindungsprojekte fügen ein @(AndroidGradleProject) Element hinzu, das auf eine Build.gradle-Datei verweist, die zum Erstellen des Gradle-Projekts verwendet wird:

<ItemGroup>
    <AndroidGradleProject Include="../native/build.gradle.kts" >
        <ModuleName>newbinding</ModuleName>
        <!-- Metadata applicable to @(AndroidLibrary) will be used if set, otherwise the following defaults will be used:
        <Bind>true</Bind>
        <Pack>true</Pack>
        -->
    </AndroidGradleProject>
</ItemGroup>

iOS-Bindungsprojekte werden ein @(XcodeProject)-Element hinzufügen, das auf das native Wrapper Xcode-Projekt verweist:

<ItemGroup>
    <XcodeProject Include="../native/NewBinding/NewBinding.xcodeproj">
        <SchemeName>NewBinding</SchemeName>
        <!-- Metadata applicable to @(NativeReference) will be used if set, otherwise the following defaults will be used:
        <Kind>Framework</Kind>
        <SmartLink>true</SmartLink>
        -->
    </XcodeProject>
</ItemGroup>

Android-Bindungsprojekte generieren die API-Definition automatisch unter Berücksichtigung allfälliger optionaler manueller Änderungen wie derjenigen, die über die Metadata.xml-Transformationsdatei implementiert werden.

Ein iOS-Bindungsbibliotheksprojekt muss eine explizit definierte API enthalten. Um dies zu unterstützen, muss Objective-Sharpie auf dem resultierenden nativen Framework ausgeführt werden, um eine API-Definitionsdatei (ApiDefinition.cs) zusammen zu erstellen. Dies dient als hilfreicher Verweis beim Erstellen und Verwalten der ApiDefinition.cs Datei, die vom iOS-Bindungsprojekt verwendet wird.

Die erforderlichen nativen Abhängigkeiten sind in die Bindingassembly eingebettet. Wenn ein .NET-Projekt einen Verweis auf das native Projekt hinzufügt, werden die nativen Abhängigkeiten automatisch in die App einbezogen.