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-Oberflächen oder SDKs Breaking Changes auftreten, bleiben die Wrapper-API-Oberfläche und die Verwendung der .NET-Anwendung wahrscheinlich stabil, was im Vergleich zu herkömmlichen Bindungen weniger Anpassungen erfordert.

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.

Verstehen von 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

Der Buildprozess für Bindungen wird erweitert, um native SDK-Abhängigkeiten abzurufen und zu erstellen, indem das CommunityToolkit.Maui.NativeLibraryInterop.BuildTasks-NuGet-Paket zu Ihrem Bindungsprojekt hinzugefügt wird:

<ItemGroup>
    <PackageReference Include="CommunityToolkit.Maui.NativeLibraryInterop.BuildTasks" Version="0.0.1-pre1" />
</ItemGroup>

Android-Bindungsprojekte werden ein @(NLIGradleProjectReference)-Element hinzufügen, das auf den Stammordner verweist, der das native Wrapper Gradle-Projekt enthält:

<ItemGroup>
    <NLIGradleProjectReference Include="../native" >
        <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>
        -->
    </NLIGradleProjectReference>
</ItemGroup>

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

<ItemGroup>
    <NLIXcodeProjectReference Include="../native/NewBinding/NewBinding.xcodeproj">
        <SchemeName>NewBinding</SchemeName>
        <SharpieNamespace>NewBinding</SharpieNamespace>
        <SharpieBind>true</SharpieBind>
        <!-- Metadata applicable to @(NativeReference) will be used if set, otherwise the following defaults will be used:
        <Kind>Framework</Kind>
        <SmartLink>true</SmartLink>
        -->
    </NLIXcodeProjectReference>
</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, kann Objective-Sharpie automatisch auf dem resultierenden nativen Framework ausgeführt werden, um gleichzeitig eine API-Definitionsdatei (ApiDefinition.cs) zu erstellen. Dies kann beim Erstellen und Unterhalten der vom iOS-Bindungsprojekt verwendeten ApiDefintion.cs-Datei hilfreich sein.

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