Partager via

Partie 3 - Configuration d’une solution multiplateforme Xamarin

  • Article

Quelles que soient les plateformes utilisées, les projets Xamarin utilisent tous le même format de fichier solution (format de fichier Visual Studio .sln ). Les solutions peuvent être partagées entre les environnements de développement, même si des projets individuels ne peuvent pas être chargés (par exemple, un projet Windows dans Visual Studio pour Mac).

Lors de la création d’une application multiplateforme, la première étape consiste à créer une solution vide. Cette section explique ce qui se passe ensuite : configuration des projets pour la création d’applications mobiles multiplateformes.

Partage de code

Reportez-vous au document Options de partage de code pour obtenir une description détaillée de la façon d’implémenter le partage de code sur plusieurs plateformes.

.NET Standard

Les projets .NET Standard offrent un moyen simple de partager du code entre les plateformes, en produisant des assemblys qui peuvent être utilisés sur Windows, des plateformes Xamarin (iOS, Android, Mac) et Linux. Il s’agit de la méthode recommandée pour partager du code pour les solutions Xamarin.

Autres options

Historiquement, Xamarin a utilisé des bibliothèques de classes portables (PCL)] et des projets partagés. Aucun de ces projets n’est recommandé pour les nouveaux projets ; et vous devez envisager de migrer des applications existantes pour utiliser .NET Standard.

Remplissage de la solution

Quelle que soit la méthode utilisée pour partager du code, la structure de solution globale doit implémenter une architecture en couches qui encourage le partage de code. L’approche Xamarin consiste à regrouper le code en deux types de projet :

  • Projet principal (ou « partagé ») : écrivez du code réutilisable dans un seul endroit pour être partagé sur différentes plateformes. Utilisez les principes d’encapsulation pour masquer les détails de l’implémentation dans la mesure du possible.
  • Projets d’application spécifiques à la plateforme : consommez le code réutilisable avec le plus petit couplage possible. Les fonctionnalités spécifiques à la plateforme sont ajoutées à ce niveau, basées sur les composants exposés dans le projet Core.

Projet principal

Les projets principaux qui partagent du code doivent être .NET Standard et référencer uniquement les assemblys disponibles sur toutes les plateformes, c’est-à-dire. les espaces de noms de framework courants tels que System, System.Core et System.Xml.

Les projets principaux doivent implémenter autant de fonctionnalités non-interface utilisateur que possible, ce qui peut inclure les couches suivantes :

  • Couche de données : code qui prend en charge le stockage de données physiques, par exemple. SQLite-NET ou même des fichiers XML. Les classes de couche de données sont normalement utilisées uniquement par la couche d’accès aux données.
  • Couche d’accès aux données : définit une API qui prend en charge les opérations de données requises pour les fonctionnalités de l’application, telles que les méthodes d’accès aux listes de données, les éléments de données individuels, ainsi que la création, la modification et la suppression des données.
  • Couche d’accès au service : couche facultative pour fournir des services cloud à l’application. Contient du code qui accède aux ressources réseau distantes (services web, téléchargements d’images, etc.) et éventuellement la mise en cache des résultats.
  • Couche métier : définition des classes Model et des classes Façade ou Manager qui exposent des fonctionnalités aux applications spécifiques à la plateforme.

Projets d’application spécifiques à la plateforme

Les projets spécifiques à la plateforme doivent référencer les assemblys requis pour établir une liaison au SDK de chaque plateforme (Xamarin.iOS, Xamarin.Android, Xamarin.Mac ou Windows) ainsi que le projet .NET Standard.

Les projets spécifiques à la plateforme doivent implémenter :

  • Couche Application – Fonctionnalité et conversion spécifiques de la plateforme entre les objets De couche métier et l’interface utilisateur.
  • Couche interface utilisateur : écrans, contrôles d’interface utilisateur personnalisés, présentation de la logique de validation.

Références de projets

Les références de projet reflètent les dépendances d’un projet. Les projets principaux limitent leurs références aux assemblys courants afin que le code soit facile à partager. Les projets d’application spécifiques à la plateforme référencent le projet .NET Standard, ainsi que les autres assemblys spécifiques à la plateforme dont ils ont besoin pour tirer parti de la plateforme cible.

Des exemples spécifiques de la façon dont les projets doivent être structurés sont donnés dans les études de cas.

Ajout de fichiers

Action de génération

Il est important de définir l’action de génération correcte pour certains types de fichiers. Cette liste affiche l’action de génération pour certains types de fichiers courants :

  • Tous les fichiers C# – Action de génération : Compiler
  • Images dans Xamarin.iOS & Windows – Action de génération : contenu
  • Fichiers XIB et Storyboard dans Xamarin.iOS – Action de génération : InterfaceDefinition
  • Images et dispositions XML dans Android – Action de génération : AndroidResource
  • Fichiers XAML dans les projets Windows – Action de génération : page
  • Fichiers XAML Xamarin.Forms – Action de génération : EmbeddedResource

En règle générale, l’IDE détecte le type de fichier et suggère l’action de génération correcte.

Respect de la casse

Enfin, n’oubliez pas que certaines plateformes ont des systèmes de fichiers respectant la casse (par exemple, iOS et Android), veillez à utiliser une norme d’affectation de noms de fichiers cohérente et assurez-vous que les noms de fichiers que vous utilisez dans le code correspondent exactement au système de fichiers. Cela est particulièrement important pour les images et d’autres ressources que vous référencez dans le code.