Partager via

Migrer une liaison vers l’API unifiée

  • Article

Cet article décrit les étapes requises pour mettre à jour un projet de liaison Xamarin existant pour prendre en charge les API unifiées pour les applications Xamarin.IOS et Xamarin.Mac.

Vue d’ensemble

À compter du 1er février 2015, Apple exige que toutes les nouvelles soumissions à iTunes et au Mac App Store doivent être des applications 64 bits. Par conséquent, toute nouvelle application Xamarin.iOS ou Xamarin.Mac doit utiliser la nouvelle API unifiée au lieu des API MonoTouch et MonoMac classiques existantes pour prendre en charge 64 bits.

En outre, tout projet de liaison Xamarin doit également prendre en charge les nouvelles API unifiées à inclure dans un projet Xamarin.iOS ou Xamarin.Mac 64 bits. Cet article décrit les étapes requises pour mettre à jour un projet de liaison existant afin d’utiliser l’API unifiée.

Spécifications

Voici les étapes décrites dans cet article :

  • Visual Studio pour Mac : la dernière version de Visual Studio pour Mac installée et configurée sur l’ordinateur de développement.
  • Apple Mac - Un mac Apple est requis pour générer des projets de liaison pour iOS et Mac.

Les projets de liaison ne sont pas pris en charge dans Visual Studio sur un ordinateur Windows.

Modifier les instructions Using

Les API unifiées facilitent le partage de code entre Mac et iOS, ainsi que la prise en charge des applications 32 et 64 bits avec le même binaire. En supprimant les préfixes MonoMac et MonoTouch des espaces de noms, le partage plus simple est obtenu dans les projets d’application Xamarin.Mac et Xamarin.iOS.

Par conséquent, nous devons modifier l’un de nos contrats de liaison (et d’autres .cs fichiers dans notre projet de liaison) pour supprimer les préfixes MonoMac et MonoTouch de nos using instructions.

Par exemple, étant donné les instructions using suivantes dans un contrat de liaison :

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

Nous supprimerions le MonoTouch préfixe résultant des opérations suivantes :

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

Là encore, nous devons effectuer cette opération pour n’importe quel .cs fichier dans notre projet de liaison. Avec cette modification en place, l’étape suivante consiste à mettre à jour notre projet de liaison pour utiliser les nouveaux types de données natifs.

Pour plus d’informations sur l’API unifiée, consultez la documentation de l’API unifiée. Pour plus d’informations sur la prise en charge des applications 32 et 64 bits et des informations sur les infrastructures, consultez la documentation sur les considérations relatives à la plateforme 32 et 64 bits.

Mettre à jour vers des types de données natifs

Objective-C mappe le NSInteger type de données aux int32_t systèmes 32 bits et aux int64_t systèmes 64 bits. Pour correspondre à ce comportement, la nouvelle API unifiée remplace les utilisations précédentes de (qui dans .NET est définie comme étant toujours System.Int32) à un nouveau type de int données : System.nint.

Outre le nouveau nint type de données, l’API unifiée introduit également les types et nfloat les nuint types pour le mappage aux types et CGFloat aux NSUInteger types.

Étant donné les éléments ci-dessus, nous devons passer en revue notre API et vérifier que n’importe quelle instance de , et que nous avons précédemment mappé à int, uint et float obtenir la mise à jour vers les nouveaux nintet nfloatnuint types.CGFloatNSUIntegerNSInteger

Par exemple, en fonction d’une Objective-C définition de méthode de :

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

Si le contrat de liaison précédent avait la définition suivante :

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

Nous allons mettre à jour la nouvelle liaison pour qu’elle soit :

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

Si nous mappons à une bibliothèque tierce de version plus récente que ce à quoi nous avions initialement lié, nous devons examiner les .h fichiers d’en-tête de la bibliothèque et voir si des appels sortants, explicites à , ou int32_tuint32_tfloatunsigned intont été mis à intniveau pour être un NSInteger, NSUInteger ou un .CGFloat Si c’est le cas, les mêmes modifications apportées aux nintnuintnfloat types doivent également être apportées à leurs mappages.

Pour en savoir plus sur ces modifications de type de données, consultez le document Types natifs .

Mettre à jour les types CoreGraphics

Les types de données point, taille et rectangle utilisés avec CoreGraphics 32 ou 64 bits en fonction de l’appareil sur lequel ils s’exécutent. Lorsque Xamarin a initialement lié les API iOS et Mac, nous avons utilisé des structures de données existantes qui correspondent aux types de données dans System.Drawing (RectangleF par exemple).

En raison des exigences de prise en charge de 64 bits et des nouveaux types de données natifs, les ajustements suivants doivent être apportés au code existant lors de l’appel CoreGraphic de méthodes :

  • CGRect - Utiliser CGRect au lieu de RectangleF définir des régions rectangulaires à virgule flottante.
  • CGSize - Utilisez CGSize plutôt SizeF que lorsque vous définissez des tailles à virgule flottante (largeur et hauteur).
  • CGPoint : utilisez CGPoint plutôt que lors de PointF la définition d’un emplacement à virgule flottante (coordonnées X et Y).

Étant donné les éléments ci-dessus, nous devons passer en revue notre API et vérifier que n’importe quelle instance de , ou qui était précédemment liée RectangleFà , SizeF ou PointF être remplacée par le type CGRectnatif , CGSize ou CGPoint directement.CGPointCGSizeCGRect

Par exemple, en fonction d’un Objective-C initialiseur de :

- (id)initWithFrame:(CGRect)frame;

Si notre liaison précédente incluait le code suivant :

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

Nous allons mettre à jour ce code pour :

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

Avec toutes les modifications de code maintenant en place, nous devons modifier notre projet de liaison ou créer un fichier à lier aux API unifiées.

Modifier le projet de liaison

Comme dernière étape de mise à jour de notre projet de liaison pour utiliser les API unifiées, nous devons modifier le MakeFile projet que nous utilisons pour générer le projet ou le type de projet Xamarin (si nous sommes liés à partir de Visual Studio pour Mac) et demander à btouch de se lier aux API unifiées au lieu des API classiques.

Mise à jour d’un MakeFile

Si nous utilisons un makefile pour générer notre projet de liaison dans un .DLL Xamarin, nous devons inclure l’option --new-style de ligne de commande et appeler btouch-native au lieu de btouch.

Ainsi, étant donné les éléments suivants 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

Nous devons passer de l’appel btouch à btouch-native, nous allons donc ajuster notre définition de macro comme suit :

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

Nous allons mettre à jour l’appel et btouch ajouter l’option --new-style comme suit :

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

Nous pouvons maintenant exécuter notre MakeFile version normale pour générer la nouvelle version 64 bits de notre API.

Mise à jour d’un type de projet de liaison

Si nous utilisons un modèle de projet de liaison Visual Studio pour Mac pour générer notre API, nous devons effectuer une mise à jour vers la nouvelle version de l’API unifiée du modèle de projet de liaison. La méthode la plus simple consiste à démarrer un nouveau projet de liaison d’API unifiée et à copier sur l’ensemble du code et des paramètres existants.

Effectuez les actions suivantes :

  1. Démarrez Visual Studio pour Mac.

  2. Sélectionnez Nouvelle >solution de fichier...>

  3. Dans la boîte de dialogue Nouvelle solution, sélectionnez Projet de liaison iOS>d’API>unifiée iOS :

    Dans la boîte de dialogue Nouvelle solution, sélectionnez iOS / API unifiée / Projet de liaison iOS

  4. Dans la boîte de dialogue « Configurer votre nouveau projet », entrez un nom pour le nouveau projet de liaison, puis cliquez sur le bouton OK .

  5. Incluez la version 64 bits de Objective-C la bibliothèque pour laquelle vous allez créer des liaisons.

  6. Copiez le code source à partir de votre projet de liaison d’API classique 32 bits existant (par exemple, les fichiers et StructsAndEnums.cs les ApiDefinition.cs fichiers).

  7. Apportez les modifications indiquées ci-dessus aux fichiers de code source.

Avec toutes ces modifications en place, vous pouvez générer la nouvelle version 64 bits de l’API comme vous le feriez pour la version 32 bits.

Résumé

Dans cet article, nous avons montré les modifications qui doivent être apportées à un projet de liaison Xamarin existant pour prendre en charge les nouvelles API unifiées et les nouveaux appareils 64 bits et les étapes nécessaires pour générer la nouvelle version compatible 64 bits d’une API.