Condividi tramite


Eseguire la migrazione di un binding all'API unificata

Questo articolo illustra i passaggi necessari per aggiornare un progetto di associazione Xamarin esistente per supportare le API unificate per le applicazioni Xamarin.IOS e Xamarin.Mac.

Panoramica

A partire dal 1° febbraio 2015 Apple richiede che tutti i nuovi invii a iTunes e Mac App Store siano applicazioni a 64 bit. Di conseguenza, qualsiasi nuova applicazione Xamarin.iOS o Xamarin.Mac dovrà usare la nuova API unificata anziché le API MonoTouch e MonoMac esistenti per supportare 64 bit.

Inoltre, qualsiasi progetto di associazione Xamarin deve supportare anche le nuove API unificate da includere in un progetto Xamarin.iOS o Xamarin.Mac a 64 bit. Questo articolo illustra i passaggi necessari per aggiornare un progetto di associazione esistente per usare l'API unificata.

Requisiti

Per completare i passaggi presentati in questo articolo, è necessario quanto segue:

  • Visual Studio per Mac: la versione più recente di Visual Studio per Mac installata e configurata nel computer di sviluppo.
  • Apple Mac : è necessario un mac Apple per compilare progetti di binding per iOS e Mac.

I progetti di associazione non sono supportati in Visual Studio in un computer Windows.

Modificare le istruzioni Using

Le API unificate semplificano la condivisione del codice tra Mac e iOS e consentono di supportare applicazioni a 32 e 64 bit con lo stesso file binario. Eliminando i prefissi MonoMac e MonoTouch dagli spazi dei nomi, la condivisione più semplice viene eseguita tra progetti di applicazione Xamarin.Mac e Xamarin.iOS.

Di conseguenza, sarà necessario modificare uno dei contratti di associazione (e altri .cs file nel progetto di associazione) per rimuovere i prefissi MonoMac e MonoTouch dalle using istruzioni.

Ad esempio, date le istruzioni using seguenti in un contratto di associazione:

using System;
using System.Drawing;
using MonoTouch.Foundation;
using MonoTouch.UIKit;
using MonoTouch.ObjCRuntime;

Si rimuove MonoTouch il prefisso con il risultato seguente:

using System;
using System.Drawing;
using Foundation;
using UIKit;
using ObjCRuntime;

Anche in questo caso, sarà necessario eseguire questa operazione per qualsiasi .cs file nel progetto di associazione. Con questa modifica, il passaggio successivo consiste nell'aggiornare il progetto di associazione in modo da usare i nuovi tipi di dati nativi.

Per altre informazioni sull'API unificata, vedere la documentazione dell'API unificata. Per altre informazioni sul supporto di applicazioni a 32 e 64 bit e informazioni sui framework, vedere la documentazione considerazioni sulla piattaforma a 32 e 64 bit.

Eseguire l'aggiornamento ai tipi di dati nativi

Objective-C esegue il mapping del NSInteger tipo di dati a su sistemi a int32_t 32 bit e su su sistemi a int64_t 64 bit. Per corrispondere a questo comportamento, la nuova API unificata sostituisce gli usi precedenti di int (che in .NET è sempre System.Int32definito come ) in un nuovo tipo di dati: System.nint.

Insieme al nuovo nint tipo di dati, l'API unificata introduce i nuint tipi e nfloat per il NSUInteger mapping anche ai tipi e CGFloat .

Dato quanto sopra, è necessario esaminare l'API e assicurarsi che qualsiasi istanza di NSIntegere di cui è stato eseguito il mapping in precedenza a uintinte che sia stato eseguito il mapping ai nuovi nuintninttipi e floatnfloat .CGFloatNSUInteger

Ad esempio, data una Objective-C definizione di metodo di:

-(NSInteger) add:(NSInteger)operandUn and:(NSInteger) operandDeux;

Se il contratto di associazione precedente aveva la definizione seguente:

[Export("add:and:")]
int Add(int operandUn, int operandDeux);

La nuova associazione verrà aggiornata in modo che sia:

[Export("add:and:")]
nint Add(nint operandUn, nint operandDeux);

Se si esegue il mapping a una libreria di terze parti più recente rispetto a quella a cui è stato inizialmente collegato, è necessario esaminare i .h file di intestazione per la libreria e verificare se eventuali chiamate esplicite a int, unsigned intint32_t, uint32_t o float sono state aggiornate in modo da essere o NSUIntegerNSIntegerCGFloat. In tal caso, sarà necessario apportare anche le stesse modifiche ai nintnuint tipi e nfloat ai relativi mapping.

Per altre informazioni su queste modifiche ai tipi di dati, vedere il documento Tipi nativi.

Aggiornare i tipi CoreGraphics

I tipi di dati point, size e rettangolo usati con CoreGraphics 32 o 64 bit a seconda del dispositivo in cui sono in esecuzione. Quando Xamarin ha originariamente associato le API iOS e Mac, sono state usate strutture di dati esistenti che corrispondono ai tipi di dati in System.Drawing (RectangleF ad esempio).

A causa dei requisiti per supportare 64 bit e i nuovi tipi di dati nativi, è necessario apportare le modifiche seguenti al codice esistente quando si chiamano CoreGraphic i metodi:

  • CGRect : usare CGRect invece di RectangleF quando si definiscono aree rettangolari a virgola mobile.
  • CGSize : usare CGSize invece di SizeF quando si definiscono dimensioni a virgola mobile (larghezza e altezza).
  • CGPoint : usare CGPoint invece di PointF quando si definisce una posizione a virgola mobile (coordinate X e Y).

Dato quanto sopra, sarà necessario esaminare l'API e assicurarsi che qualsiasi istanza di CGRecto che in precedenza fosse associata a RectangleFSizeF o PointF che sia stata modificata direttamente nel tipo CGSizeCGRectnativo o CGPoint .CGPointCGSize

Ad esempio, dato un Objective-C inizializzatore di:

- (id)initWithFrame:(CGRect)frame;

Se l'associazione precedente includeva il codice seguente:

[Export ("initWithFrame:")]
IntPtr Constructor (RectangleF frame);

Il codice verrà aggiornato in:

[Export ("initWithFrame:")]
IntPtr Constructor (CGRect frame);

Dopo tutte le modifiche apportate al codice, è necessario modificare il progetto di associazione o creare un file da associare alle API unificate.

Modificare il progetto di associazione

Come passaggio finale per aggiornare il progetto di associazione per usare le API unificate, è necessario modificare l'oggetto MakeFile usato per compilare il progetto o il tipo di progetto Xamarin (se si esegue il binding dall'interno di Visual Studio per Mac) e indicare a btouch di eseguire il binding alle API unificate anziché a quelle classiche.

Aggiornamento di un MakeFile

Se si usa un makefile per compilare il progetto di associazione in un .DLL Xamarin, sarà necessario includere l'opzione della --new-style riga di comando e chiamare btouch-native invece di btouch.

Quindi, data la seguente MakeFile:

BINDDIR=/src/binding
XBUILD=/Applications/Xcode.app/Contents/Developer/usr/bin/xcodebuild
PROJECT_ROOT=XMBindingLibrarySample
PROJECT=$(PROJECT_ROOT)/XMBindingLibrarySample.xcodeproj
TARGET=XMBindingLibrarySample
BTOUCH=/Developer/MonoTouch/usr/bin/btouch

all: XMBindingLibrary.dll

libXMBindingLibrarySample-i386.a:
	$(XBUILD) -project $(PROJECT) -target $(TARGET) -sdk iphonesimulator -configuration Release clean build
	-mv $(PROJECT_ROOT)/build/Release-iphonesimulator/lib$(TARGET).a $@

libXMBindingLibrarySample-arm64.a:
	$(XBUILD) -project $(PROJECT) -target $(TARGET) -sdk iphoneos -arch arm64 -configuration Release clean build
	-mv $(PROJECT_ROOT)/build/Release-iphoneos/lib$(TARGET).a $@

libXMBindingLibrarySample-armv7.a:
	$(XBUILD) -project $(PROJECT) -target $(TARGET) -sdk iphoneos -arch armv7 -configuration Release clean build
	-mv $(PROJECT_ROOT)/build/Release-iphoneos/lib$(TARGET).a $@

libXMBindingLibrarySampleUniversal.a: libXMBindingLibrarySample-armv7.a libXMBindingLibrarySample-i386.a libXMBindingLibrarySample-arm64.a
	lipo -create -output $@ $^

XMBindingLibrary.dll: AssemblyInfo.cs XMBindingLibrarySample.cs extras.cs libXMBindingLibrarySampleUniversal.a
	$(BTOUCH) -unsafe -out:$@ XMBindingLibrarySample.cs -x=AssemblyInfo.cs -x=extras.cs --link-with=libXMBindingLibrarySampleUniversal.a,libXMBindingLibrarySampleUniversal.a

clean:
	-rm -f *.a *.dll

È necessario passare dalla chiamata btouch a btouch-native, in modo da regolare la definizione di macro come indicato di seguito:

BTOUCH=/Developer/MonoTouch/usr/bin/btouch-native

Aggiornare la chiamata a btouch e aggiungere l'opzione --new-style come indicato di seguito:

XMBindingLibrary.dll: AssemblyInfo.cs XMBindingLibrarySample.cs extras.cs libXMBindingLibrarySampleUniversal.a
	$(BTOUCH) -unsafe --new-style -out:$@ XMBindingLibrarySample.cs -x=AssemblyInfo.cs -x=extras.cs --link-with=libXMBindingLibrarySampleUniversal.a,libXMBindingLibrarySampleUniversal.a

È ora possibile eseguire MakeFile come di consueto per compilare la nuova versione a 64 bit dell'API.

Aggiornamento di un tipo di progetto di associazione

Se si usa un modello di progetto di associazione Visual Studio per Mac per compilare l'API, sarà necessario eseguire l'aggiornamento alla nuova versione api unificata del modello di progetto di associazione. Il modo più semplice per eseguire questa operazione consiste nell'avviare un nuovo progetto di associazione API unificata e copiare tutto il codice e le impostazioni esistenti.

Effettua le operazioni seguenti:

  1. Avviare Visual Studio per Mac.

  2. Selezionare File>Nuova>soluzione...

  3. Nella finestra di dialogo Nuova soluzione selezionare Progetto di associazione iOS unified API>iOS:>

    Nella finestra di dialogo Nuova soluzione selezionare iOS/API unificata/Progetto di associazione iOS

  4. Nella finestra di dialogo "Configura il nuovo progetto" immettere un nome per il nuovo progetto di associazione e fare clic sul pulsante OK .

  5. Includere la versione a 64 bit della Objective-C libreria per cui verranno create associazioni.

  6. Copiare il codice sorgente dal progetto di associazione api classica a 32 bit esistente , ad esempio i ApiDefinition.cs file e StructsAndEnums.cs .

  7. Apportare le modifiche indicate in precedenza ai file di codice sorgente.

Con tutte queste modifiche, è possibile compilare la nuova versione a 64 bit dell'API come si farebbe con la versione a 32 bit.

Riepilogo

In questo articolo sono state illustrate le modifiche che devono essere apportate a un progetto di associazione Xamarin esistente per supportare le nuove API unificate e i dispositivi a 64 bit e i passaggi necessari per compilare la nuova versione compatibile a 64 bit di un'API.