Interop voor systeemeigen bibliotheken

Overview

Systeemeigen bibliotheek-interoperabiliteit (voorheen 'Slim binding' genoemd), verwijst naar een patroon voor toegang tot systeemeigen SDK's in .NET MAUI-apps, waaronder .NET voor Android, .NET voor iOS en .NET voor Mac Catalyst-apps. Het idee is om uw eigen abstractie of dunne 'wrapper' te maken met een vereenvoudigd API-oppervlak voor de systeemeigen SDK's die u wilt aanroepen vanuit .NET. De systeemeigen 'wrapper'-bibliotheek/frameworkprojecten worden gemaakt in Android Studio met behulp van Java/Kotlin en/of Xcode met Objective-C/Swift. Deze benadering is vooral nuttig wanneer u slechts een klein deel van het API-oppervlak van de SDK nodig hebt, hoewel deze ook geschikt is voor een groter API-oppervlakgebruik.

Begrijpen wanneer en waarom u interoperabiliteit met systeemeigen bibliotheken gebruikt

Interoperabiliteit met native bibliotheken is een zeer effectieve manier om te integreren met native bibliotheken, al is het niet altijd de beste oplossing voor uw project. Over het algemeen is het niet nodig om benaderingen te wijzigen als u al bindingen onderhoudt en dit gemakkelijk kunt blijven doen. Voor projecten waarvoor een uitgebreid gebruik van de API van een bibliotheek nodig is of voor leveranciers die .NET MAUI ontwikkelaars ondersteunen, zijn traditionele bindingen mogelijk nog steeds geschikter. Interop met systeemeigen bibliotheken biedt echter een alternatief dat vaak gemakkelijker te begrijpen, te implementeren en te onderhouden is.

Een belangrijk voordeel van interoperabiliteit met systeemeigen bibliotheken is dat deze goed werkt bij eenvoudige API's. Wanneer wrappers alleen primitieve typen bevatten die .NET ondersteunt, kunnen bestaande bindingshulpprogramma's betrouwbare definities genereren met minimale handmatige interventie, wat vaak vereist is voor traditionele bindingen. Dit maakt het proces eenvoudig, met name omdat de implementatie van de wrapper-API doorgaans SDK-documentatie volgt en vaak rechtstreeks vanuit de leveranciersdocumentatie kan worden gekopieerd.

Hoewel de eerste installatie misschien ingewikkelder is, is het beheren van updates voor onderliggende SDK's over het algemeen minder inspanning vereist. Updates zijn vaak alleen nodig om de versie aan te passen en het project opnieuw te bouwen. Zelfs als er fouten optreden in de API-oppervlakken of SDK's, is het gebruik van de wrapper-API en het gebruik van .NET toepassing stabieler, waardoor er minder aanpassingen nodig zijn in vergelijking met traditionele bindingen.

Kortom, interoperabiliteit met systeemeigen bibliotheken heeft verschillende voordelen:

• Vereenvoudigt de volgende SDK-documentatie met systeemeigen talen en hulpprogramma's
• Vereist minder handmatige tussenkomst om werkende koppelingen te maken
• Maakt onderhoud eenvoudiger en vermindert de frequentie van de benodigde updates
• Verbetert de isolatie van de app van wijzigingen in onderliggende SDK's

Hoewel het oplossen van afhankelijkheidsketens (met name op Android) evenveel inspanning kan vergen als bij traditionele bindings, maken de voordelen van een gestroomlijnde implementatie en eenvoudiger onderhoud Native Library Interop tot een aantrekkelijke keuze voor veel projecten.

Inzicht in Maui.NativeLibraryInterop

Een belangrijke uitdaging bij het maken en onderhouden van bindingen die zijn gemaakt via systeemeigen bibliotheekinterop, is het handmatig samenvoegen van de systeemeigen projecten, hun systeemeigen afhankelijkheden, het bouwen van uitvoer en het .NET Binding-bibliotheekproject. Maui.NativeLibraryInterop helpt u snel op weg door de voorbeelden als basis te gebruiken en aan te passen aan de behoeften van uw eigen app.

Een deel hiervan omvat het organiseren van onderdelen van het buildproces via MSBuild-aanroepen. Dit kan het volgende omvatten:

• Systeemeigen SDK-afhankelijkheden oplossen of downloaden
• Het systeemeigen slanke bindingsproject en de bijbehorende afhankelijkheden bouwen
• De benodigde systeemeigen artefacten naar de verwachte werkmap verplaatsen
• De API-definitie voor het bindingsbibliotheekproject genereren

Android-bindingsprojecten voegen een @(AndroidGradleProject) item toe dat verwijst naar een build.gradle-bestand dat wordt gebruikt om het gradle-project te bouwen:

<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-bindingsprojecten voegen een @(XcodeProject) item toe dat verwijst naar het systeemeigen wrapper Xcode-project:

<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-bindingsprojecten genereren automatisch de API-definitie, waarbij rekening wordt gehouden met eventuele optionele handmatige wijzigingen, zoals die zijn geïmplementeerd via het Metadata.xml transformatiebestand.

Een iOS-bindingsbibliotheekproject moet een expliciet gedefinieerde API bevatten. Om dit te helpen, moet Objective-Sharpie worden uitgevoerd op het resulterende systeemeigen framework om ernaast een API-definitiebestand (ApiDefinition.cs) te produceren. Dit fungeert als een nuttige referentie bij het maken en onderhouden van het ApiDefinition.cs-bestand dat wordt gebruikt door het iOS-bindingsproject.

De vereiste systeemeigen afhankelijkheden worden ingesloten in de bindingsassembly. Wanneer een .NET project een verwijzing naar het systeemeigen project toevoegt, worden de systeemeigen afhankelijkheden automatisch opgenomen in de app.