Interop för inbyggt bibliotek

Overview

Native Library Interop (kallades tidigare "Slim Binding"-metoden) refererar till ett mönster för åtkomst till interna SDK:er i .NET MAUI appar, inklusive .NET för Android, .NET för iOS och .NET för Mac Catalyst-appar. Tanken är att skapa din egen abstraktion eller tunna "wrapper" med en förenklad API-yta till de interna SDK:er som du är intresserad av att anropa från .NET. De interna "wrapper"-biblioteks-/ramverksprojekten skapas i Android Studio med hjälp av Java/Kotlin och/eller Xcode med Objective-C/Swift. Den här metoden är särskilt fördelaktig när du bara behöver en liten del av API-ytan i SDK: n, men det fungerar också bra för större API-ytanvändning på samma sätt.

Förstå när och varför du ska använda interop för inbyggt bibliotek

Interop för internt bibliotek är en mycket effektiv metod för att integrera med inbyggda bibliotek, även om det kanske inte alltid passar bäst för projektet. Om du redan underhåller bindningar och är bekväm med att fortsätta med det finns det i allmänhet inget behov av att ändra metoder. För projekt som kräver omfattande användning av ett biblioteks API eller för leverantörer som stöder .NET MAUI utvecklare kan traditionella bindningar fortfarande vara lämpligare. Interop för internt bibliotek erbjuder dock ett alternativ som ofta är enklare att förstå, implementera och underhålla.

En viktig fördel med Interop för inbyggt bibliotek är dess effektivitet med enkla API-ytor. När omslutande klasser endast använder primitiva typer som .NET stöder kan befintliga bindningsverktyg generera tillförlitliga definitioner med minimala manuella åtgärder, något som ofta krävs för traditionella bindningar. Detta gör processen enkel, särskilt eftersom implementeringen av omslutnings-API:et vanligtvis följer SDK-dokumentationen och ofta tillåter direktkopiering från leverantörsdokumentation.

Även om den inledande installationen kan vara mer invecklad kräver hantering av uppdateringar av underliggande SDK:er i allmänhet mindre arbete. Uppdateringar innebär ofta att helt enkelt justera versionen och återskapa projektet. Även om icke-bakåtkompatibla ändringar sker i API:erna eller SDK:erna är det mer sannolikt att wrapper-API:t och .NET-programmets användning av det förblir stabila, vilket kräver färre justeringar jämfört med traditionella bindningar.

Sammanfattningsvis ger interoperabilitet med inbyggda bibliotek flera fördelar:

• Förenklar följande SDK-dokumentation med inbyggda språk och verktyg
• Kräver mindre manuell insats för att skapa fungerande bindningar
• Gör underhåll enklare och minskar frekvensen för nödvändiga uppdateringar
• Förbättrar isoleringen av appen från ändringar i underliggande SDK:er

Även om lösningen av beroendekedjor (särskilt på Android) kan kräva liknande arbete som traditionella bindningar, gör de effektiva implementerings- och underhållsfördelarna native Library Interop till ett tilltalande val för många projekt.

Förståelse för Maui.NativeLibraryInterop

En viktig utmaning med att skapa och underhålla bindningar som skapats via interop för inbyggt bibliotek är att manuellt sammanfoga de interna projekten, deras interna beroenden, bygga utdata och projektet .NET Binding-bibliotek. Maui.NativeLibraryInterop hjälper dig att komma igång med processen genom att skapa från och anpassa exemplen efter din egen apps behov.

En del av detta omfattar orkestrering av delar av byggprocessen via MSBuild-anrop. Detta kan omfatta:

• Lösa eller ladda ned interna SDK-beroenden
• Skapa det inbyggda slimmade bindningsprojektet och dess beroenden
• Flytta nödvändiga interna artefakter till den förväntade arbetskatalogen
• Generera API-definitionen för bindningsbiblioteksprojektet

Android-bindningsprojekt lägger till ett @(AndroidGradleProject) objekt som pekar på en build.gradle-fil som ska användas för att skapa gradle-projektet:

<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-bindningsprojekt lägger till ett @(XcodeProject) objekt som pekar på det interna omslutningsprojektet Xcode:

<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-bindningsprojekt genererar API-definitionen automatiskt med hänsyn till eventuella valfria manuella ändringar som de som implementeras via Metadata.xml transformeringsfilen.

Ett iOS-bindningsbiblioteksprojekt måste innehålla ett explicit definierat API. För att hjälpa till med detta måste Objective-Sharpie köras i det resulterande interna ramverket för att skapa en API-definitionsfil (ApiDefinition.cs) tillsammans med den. Detta fungerar som en användbar referens när du skapar och underhåller den ApiDefinition.cs fil som används av iOS-bindningsprojektet.

De nödvändiga inbyggda beroendena bäddas in i bindningssammansättningen. När ett .NET projekt lägger till en referens till det interna projektet inkluderas de interna beroendena automatiskt i appen.