Partager via

Plateforme Apple (iOS et Mac)

  • Article

Partage de code

Pour les éléments de votre code qui n’ont pas d’éléments d’interface utilisateur, la meilleure façon de partager du code entre iOS et Mac est toujours d’utiliser des bibliothèques de classes portables.

Pour le code qui doit effectuer un travail d’interface utilisateur et pourtant, vous souhaitez partager, vous devez utiliser des projets partagés qui vous permettent de placer du code à partager dans un seul projet et de le compiler avec Mac et iOS lorsqu’il est référencé.

API unifiée

Les projets d’API unifiée pour iOS et Mac utilisent les mêmes espaces de noms pour les frameworks afin que le même fichier de code puisse être utilisé sur les deux plateformes, pour un partage de code fluide. Il active également les builds 32 et 64 bits. L’API unifiée est le modèle par défaut depuis début 2015 et est recommandé pour tous les nouveaux projets. Seuls les projets d’API unifiée peuvent être soumis à l’App Store.

API classiques

Notes

Dépréciation du profil classique : À mesure que de nouvelles plateformes sont ajoutées dans Xamarin.iOS, nous commençons à déprécier progressivement les fonctionnalités du profil classique (monotouch.dll). Par exemple, l’option non-CNRC (new-ref-count) a été supprimée. Le CNRC a toujours été activé pour toutes les applications unifiées (c’est-à-dire que les autres applications n’ont jamais été proposées) et n’a aucun problème connu. Les versions ultérieures supprimeront l’option d’utilisation de Boehm comme récupérateur de mémoire. Il s’agissait également d’une option jamais disponible pour les applications unifiées. La suppression complète de la prise en charge classique est prévue pour l’automne 2016 avec la publication de Xamarin.iOS 10.0.

Les API Xamarin.iOS et Xamarin.Mac d’origine (non unifiées) ont rendu le partage de code plus difficile, car les frameworks natifs avaient MonoTouch. des préfixes d’espace de noms ou MonoMac. . Nous avons fourni des espaces de noms vides qui permettent aux développeurs de partager du code en ajoutant using des instructions qui référencent les espaces de noms MonoMac et MonoTouch sur le même fichier, mais c’était un peu laid. L’API classique ne doit continuer à être utilisée que dans les applications héritées distribuées en interne (la mise à niveau vers l’API unifiée est recommandée).

Mise à jour de l’API classique vers l’API unifiée

Il existe des instructions détaillées pour mettre à jour n’importe quelle application de l’API Classique vers l’API Unifiée.

Bibliothèques de liaison Objective-C

Xamarin vous permet d’intégrer des bibliothèques natives dans vos applications avec des liaisons. Cette section explique comment :

  • fonctionnement des liaisons,
  • comment créer manuellement un projet de liaison qui vous permet d’importer Objective-C du code dans Xamarin, et
  • comment utiliser notre outil Objective Sharpie pour automatiser le processus.

Références natives

Types natifs Mac/iOS

Pour prendre en charge le code 32 et 64 bits en toute transparence à partir de C# et F#, nous introduisons de nouveaux types de données. Découvrez ces outils ici.

Création d’applications 32 et 64 bits

Ce que vous devez savoir pour prendre en charge les applications 32 et 64 bits.

Utilisation de types natifs dans des applications multiplateformes

Cet article traite de l’utilisation des nouveaux types natifs d’API unifiée iOS (nint, nuint, nfloat) dans une application multiplateforme où le code est partagé avec des appareils non iOS tels que des systèmes d’exploitation Android ou Windows Phone. Il fournit des informations sur le moment où les types natifs doivent être utilisés et fournit plusieurs solutions possibles aux cas où le nouveau type doit être utilisé avec du code multiplateforme.

Pile HttpClient et sélecteur d’implémentation de SSL/TLS

Le nouveau sélecteur de pile HttpClient contrôle l’implémentation HttpClient à utiliser dans votre application Xamarin.iOS, Xamarin.tvOS et Xamarin.Mac. Vous pouvez maintenant basculer vers une implémentation qui utilise les transports natifs d’iOS, tvOS ou OS X (NSUrlSession ou CFNetwork selon le système d’exploitation).

SSL (Secure Socket Layer) et son successeur, TLS (Transport Layer Security), prennent en charge http et d’autres connexions réseau via System.Net.Security.SslStream. La nouvelle option de génération d’implémentation SSL/TLS bascule entre la propre pile TLS de Mono et l’autre alimentée par la pile TLS d’Apple présente sur Mac et iOS.