Interoperabilità di Native Library

Panoramica

L'interoperabilità di Native Library (in precedenza definita approccio "Slim Binding"), si riferisce a un modello per l'accesso agli SDK nativi nelle app MAUI .NET, tra cui .NET per Android, .NET per iOS e .NET per le app Catalyst mac. L'idea è creare un'astrazione personalizzata o un thin "wrapper" con una superficie API semplificata agli SDK nativi che si è interessati a chiamare da .NET. I progetti di libreria/framework nativi "wrapper" vengono creati in Android Studio usando Java/Kotlin e/o Xcode usando Objective-C/Swift. Questo approccio è particolarmente utile quando è necessaria solo una piccola sezione della superficie API dell'SDK, anche se funziona bene anche per l'utilizzo della superficie API più grande tutto lo stesso.

Informazioni su quando e perché usare l'interoperabilità di Native Library

L'interoperabilità di Native Library è un approccio molto efficace per l'integrazione con librerie native, anche se potrebbe non essere sempre la soluzione migliore per il progetto. In genere, se si mantengono già i binding e si è a proprio agio a farlo, non è necessario modificare gli approcci. Per i progetti che richiedono un uso esteso dell'API di una libreria o per i fornitori che supportano sviluppatori MAUI .NET, le associazioni tradizionali potrebbero essere ancora più adatte. L'interoperabilità di Native Library offre tuttavia un'alternativa che spesso è più facile da comprendere, implementare e gestire.

Un vantaggio fondamentale dell'interoperabilità di Native Library è la sua efficacia con superfici API semplici. Quando i wrapper includono solo tipi primitivi supportati da .NET, gli strumenti di associazione esistenti possono generare definizioni affidabili con un intervento manuale minimo, spesso necessario per le associazioni tradizionali. Questo rende il processo semplice, soprattutto perché l'implementazione dell'API wrapper segue in genere la documentazione dell'SDK e spesso consente la copia diretta dalla documentazione del fornitore.

Anche se la configurazione iniziale può essere più complessa, la gestione degli aggiornamenti agli SDK sottostanti richiede in genere meno lavoro. Gli aggiornamenti spesso comportano semplicemente la modifica della versione e la ricompilazione del progetto. Anche se si verificano modifiche di rilievo nelle superfici o negli SDK dell'API, è più probabile che l'utilizzo dell'API wrapper e dell'applicazione .NET rimangano stabili, richiedendo meno modifiche rispetto alle associazioni tradizionali.

In sintesi, l'interoperabilità di Native Library offre diversi vantaggi:

• Semplifica la documentazione dell'SDK seguente con linguaggi e strumenti nativi
• Richiede un intervento meno manuale per creare associazioni funzionanti
• Semplifica la manutenzione e riduce la frequenza degli aggiornamenti necessari
• Migliora l'isolamento dell'app dalle modifiche apportate agli SDK sottostanti

Anche se la risoluzione delle catene di dipendenze (in particolare in Android) può richiedere un impegno simile a quello delle associazioni tradizionali, i vantaggi di implementazione e manutenzione semplificati rendono l'interoperabilità di Native Library una scelta interessante per molti progetti.

Informazioni su Maui.NativeLibraryInterop

Una sfida notevole con la creazione e la gestione delle associazioni create tramite l'interoperabilità di Native Library consiste nel unire manualmente i progetti nativi, le relative dipendenze native, gli output di compilazione e il progetto della libreria di binding .NET. Maui.NativeLibraryInterop consente di iniziare rapidamente il processo creando e personalizzando gli esempi per le esigenze dell'app.

Parte di questo include l'orchestrazione di parti del processo di compilazione tramite le chiamate di MSBuild. Le attività necessarie a questo scopo includono le seguenti:

• Risoluzione o download delle dipendenze native dell'SDK
• Compilazione del progetto di binding slim nativo e delle relative dipendenze
• Spostamento degli artefatti nativi necessari nella directory di lavoro prevista
• Generazione della definizione API per il progetto di libreria di binding

Il processo di compilazione dell'associazione viene esteso per ottenere e compilare dipendenze native dell'SDK aggiungendo il CommunityToolkit.Maui.NativeLibraryInterop.BuildTasks pacchetto NuGet al progetto di associazione:

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

I progetti di associazione Android aggiungeranno un @(NLIGradleProjectReference) elemento che punta alla cartella radice che contiene il progetto gradle wrapper nativo:

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

I progetti di associazione iOS aggiungeranno un @(NLIXcodeProjectReference) elemento che punta al progetto Xcode wrapper nativo:

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

I progetti di associazione Android generano automaticamente la definizione dell'API tenendo conto di eventuali modifiche manuali facoltative come quelle implementate tramite il file di trasformazione Metadata.xml .

Un progetto di libreria di binding iOS deve includere un'API definita in modo esplicito. A tale scopo, Objective-Sharpie può essere eseguito automaticamente nel framework nativo risultante per produrre un file di definizione API (ApiDefinition.cs) insieme a esso. Questo può fungere da riferimento utile durante la creazione e la gestione del file di ApiDefintion.cs usato dal progetto di associazione iOS.

Le dipendenze native necessarie vengono incorporate nell'assembly di associazione. Quando un progetto .NET aggiunge un riferimento al progetto nativo, le dipendenze native vengono incluse automaticamente nell'app.