Création D'applications Mobiles Avec Xamarin Forms PDF

Contents
Création d’applications mobiles avec Xamarin.Forms

1. Comment Xamarin.Forms est-il intégré ?
2. Anatomie d’une application
3. Détails du texte
4. Défilement de la pile
5. Gestion des tailles
6. Clics de bouton
7. XAML et code
8. Code et XAML en harmonie
9. Appels d’API spécifiques de la plateforme
10. Extensions de balisage XAML
11. Infrastructure Bindable
12. Styles
13. Bitmaps
14. Disposition absolue
15. Interface interactive
16. Liaison de données
17. Maîtrise de la grille
18. MVVM
19. Vues de collection
20. E/S de fichier et asynchrone
21. Transformations
22. Animation
23. Déclencheurs et comportements
24. Navigation entre les pages
25. Types de page
26. Dispositions personnalisées
27. Renderers personnalisés
28. Emplacement et mappages
Création d’applications mobiles avec xamarin.Forms
11/01/2019 • 10 minutes to read • Edit Online
télécharger l’exemple
Le livre création d’applications mobiles avec Xamarin.Forms par Charles Petzold est un guide
pour apprendre à écrire des applications Xamarin.Forms. La seule condition requise est la base
de connaissances de la C# langage de programmation. Ce livre fournit une exploration complète
dans l’interface utilisateur de Xamarin.Forms et couvre également l’animation, MVVM,
déclencheurs, les comportements, des dispositions personnalisées, des convertisseurs
personnalisés et bien plus encore.
Le livre a été publié dans le ressort de 2016 et n’a pas été mis à jour depuis. Il existe une grande partie dans le
carnet qui seront utiles reste, mais certains le matériau est obsolète, et certaines rubriques ne sont plus
entièrement correcte ou terminée.
Téléchargez le livre électronique gratuit

Téléchargez votre format de livre électronique par défaut à partir de Microsoft Virtual Academy :
PDF (56 Mo)
ePub (151 Mo)
Kindle Édition (325 Mo)
Vous pouvez également Téléchargez des chapitres au format PDF.
Exemples
Les exemples sont disponible sur githubet incluent des projets pour iOS, Android et la plateforme universelle
Windows (UWP ). (Xamarin.Forms ne gère plus de Windows 10 Mobile, mais les applications Xamarin.Forms
seront exécutera sur le bureau Windows 10).
Récapitulatif des chapitres

Récapitulatif des chapitres sont disponibles dans le table du chapitre ci-dessous. Ces synthèses décrivent le contenu
de chaque chapitre et incluent plusieurs types de liens :
Liens vers les chapitres réelles du livre (en bas de la page) et aux articles connexes
Des liens vers tous les exemples dans le xamarin-forms-livre-samples référentiel GitHub
Liens vers la documentation API pour obtenir une description plus détaillée de Xamarin.Forms classes,
structures, propriétés, énumérations, etc.
Ces synthèses également indiquent quand le matériel dans le chapitre peut être quelque peu obsolète.
Téléchargez des chapitres et des résumés

CHAPITRE TEX TE COMPLET RÉCAPITULATIF
Chapitre 1. Fonctionnement de Télécharger PDF Résumé

Xamarin.Forms ajuster ?
Chapitre 2. Anatomie d’une application Télécharger PDF Résumé
Chapitre 3. Détails du texte Télécharger PDF Résumé
Chapitre 4. Défilement de la pile Télécharger PDF Résumé
Chapitre 5. Gestion des tailles Télécharger PDF Résumé
Chapitre 6. Clics de bouton Télécharger PDF Résumé
Chapitre 7. Visual Studio XAML. Code Télécharger PDF Résumé
Chapitre 8. Code et XAML en harmonie Télécharger PDF Résumé
Chapitre 9. Appels d’API de plateforme Télécharger PDF Résumé

spécifique
Chapitre 10. Extensions de balisage Télécharger PDF Résumé

XAML
Chapitre 11. Infrastructure Bindable Télécharger PDF Résumé
Chapitre 12. Styles Télécharger PDF Résumé
Chapitre 13. Bitmaps Télécharger PDF Résumé
Chapitre 14. Disposition absolue Télécharger PDF Résumé
Chapitre 15. L’Interface Interactive Télécharger PDF Résumé
Chapitre 16. Liaison de données Télécharger PDF Résumé
Chapitre 17. Maîtrise de la grille Télécharger PDF Résumé
Chapitre 18. MVVM Télécharger PDF Résumé
Chapitre 19. Vues de collection Télécharger PDF Résumé
Chapitre 20. E/s de fichier et asynchrone Télécharger PDF Résumé
Chapitre 21. Transformations Télécharger PDF Résumé
Chapitre 22. Animation Télécharger PDF Résumé
Chapitre 23. Déclencheurs et Télécharger PDF Résumé

comportements
Chapitre 24. Navigation entre les pages Télécharger PDF Résumé

CHAPITRE TEX TE COMPLET RÉCAPITULATIF
Chapitre 25. Types de page Télécharger PDF Résumé
Chapitre 26. Dispositions personnalisées Télécharger PDF Résumé
Chapitre 27. Renderers personnalisés Télécharger PDF Résumé
Chapitre 28. Emplacement et mappages Télécharger PDF Résumé
Façons dans lequel le livre est obsolète

Depuis la publication de création d’applications mobiles avec Xamarin.Forms, plusieurs nouvelles fonctionnalités
ont été ajoutées à Xamarin.Forms. Ces nouvelles fonctionnalités sont décrites dans les articles individuels dans le
Xamarin.Forms documentation.
Autres modifications ont provoqué le contenu de l’annuaire à être obsolètes :
Bibliothèques .NET standard 2.0 ont remplacé les bibliothèques de classes portables
En règle générale, une application Xamarin.Forms utilise une bibliothèque de partager du code entre les différentes
plateformes. À l’origine, il s’agissait d’une bibliothèque de classes Portable (PCL ). Il existe de nombreuses
références à des bibliothèques de classes portables tout au long de ce livre et les résumés de chapitre.
La bibliothèque de classes Portable a été remplacée par une bibliothèque .NET Standard 2.0, comme décrit dans
l’article .NET Standard 2.0 Support dans Xamarin.Forms. Tous les exemple de code à partir de l’ouvrage a été mis à
jour pour utiliser les bibliothèques .NET Standard 2.0.
La plupart des informations dans le livre concernant le rôle de la bibliothèque de classes Portable reste la même
pour une bibliothèque .NET Standard 2.0. La différence est qu’uniquement une bibliothèque de classes portable a
une numérique « profil ». En outre, il existe des bibliothèques .NET Standard 2.0 présente plusieurs avantages. Par
exemple, le chapitre 20, Async et les e/s de fichier explique comment utiliser des plateformes sous-jacentes pour
effectuer des e/s de fichier. Cela n’est plus nécessaire. La bibliothèque .NET Standard 2.0 prend en charge la version
classique System.IO classes pour toutes les plateformes de Xamarin.Forms.
La bibliothèque .NET Standard 2.0 permet également à utiliser les applications Xamarin.Forms HttpClient pour
accéder aux fichiers sur Internet plutôt que WebRequest ou d’autres classes.
Le rôle de XAML a été élevé
Création d’applications mobiles avec Xamarin.Forms commence par décrire comment écrire des applications
Xamarin.Forms à l’aide de c#. Le d’Extensible Application Markup Language (XAML ) n’est pas introduites jusqu'à
ce que chapitre 7. Visual Studio XAML. Code.
XAML a maintenant un rôle plus important dans Xamarin.Forms. Les modèles de solution Xamarin.Forms
distribués avec Visual Studio créent des fichiers page XAML. Un développeur à l’aide de Xamarin.Forms devez
vous familiariser avec le XAML dès que possible. Le langage de balisage d’Application eXtensible (XAML ) section
de la documentation de Xamarin.Forms contient plusieurs articles concernant XAML pour vous aider à démarrer.
Plateformes prises en charge
Xamarin.Forms ne gère plus de Windows 8.1 et Windows Phone 8.1.
Le livre fait parfois référence à la Windows Runtime. Il s’agit d’un terme qui englobe l’API de Windows utilisée
dans plusieurs versions de Windows et Windows Phone. Les versions plus récentes de Xamarin.Forms se limite à
la prise en charge de la plateforme Windows universelle, qui est l’API pour Windows 10 et Windows 10 Mobile.
Une bibliothèque .NET Standard 2.0 ne prend pas en charge n’importe quelle version de Windows 10 Mobile. Par
conséquent, une application Xamarin.Forms à l’aide d’une bibliothèque .NET Standard ne s’exécutera pas sur un
appareil Windows 10 Mobile. Les applications Xamarin.Forms continuent à exécuter sur le bureau Windows 10,
versions 10.0.16299.0 et versions ultérieures.
Xamarin.Forms a prise en charge de la version préliminaire de la Mac, WPF, GTK #, et Tizen plateformes.
Récapitulatif des chapitres
Les résumés de chapitre incluent les informations concernant les modifications dans Xamarin.Forms, car le livre a
été écrit. Il s’agit souvent sous la forme de notes :
NOTE
Notes sur chaque page indiquent où Xamarin.Forms est différente de la matière présentée dans le livre.
Exemples
Dans le xamarin-forms-livre-samples référentiel GitHub, le code d’origine à partir de livre branche contient
des exemples de programme cohérents avec le livre. Le master branche contient des projets qui ont été mis à
niveau pour supprimer les API déconseillées et refléter API améliorées. En outre, les projets Android dans le
master branche ont été mis à niveau pour Android Material Design via AppCompat et s’affichent généralement
texte noir sur un arrière-plan blanc.
Liens associés
Blog de MS Press
Exemple de code de livre
Résumé du chapitre 1. Comment Xamarin.Forms est-il
intégré ?
NOTE
Notes sur cette page indiquent des zones où Xamarin.Forms est différente de la matière présentée dans le livre.
Une des tâches plus désagréables de programmation consiste à porter un code de base à partir d’une plateforme à
l’autre, en particulier si cette plateforme implique un langage de programmation différents. Il est tentant, lorsque le
portage du code pour refactoriser d’également, mais si les deux plateformes doivent être conservées en parallèle,
puis les différences entre les deux bases de code seront compliquer une maintenance ultérieure.
Développement mobile multiplateforme

Ce problème est courant lors du ciblage de plateformes mobiles. Actuellement, il existe deux principales
plateformes mobiles, de la famille de Apple de l’iPhone et iPad exécutant le système d’exploitation iOS et le
système d’exploitation Android qui s’exécute sur un large éventail de téléphones et tablettes. Une autre plate-forme
significative est Universal Windows Platform (UWP de Microsoft), ce qui permet à un programme unique cibler à
la fois Windows 10.
Un fournisseur de logiciels qui souhaite cibler ces plateformes doit faire face à des paradigmes de l’interface
utilisateur différents, les trois différents environnements de développement, les trois différentes interfaces de
programmation, et—peut-être plus maladroitement—trois langages de programmation différents : Objective-C
pour l’iPhone et iPad, Java pour Android, et C# pour Windows.
La solution c# et .NET
Bien que Objective-C, Java et c# sont toutes dérivées de langage de programmation C, ils ont évolué en chemins
d’accès très différentes. C# est la plus récente de ces langages et a été maturation de façons très utile. En outre, c#
est étroitement associé à une infrastructure de programmation entière, appelée .NET, qui prend en charge la
mathématiques, le débogage, la réflexion, collections, globalisation, d’e/s de fichier, mise en réseau, sécurité,
threading, services web, gestion des données et XML et JSON de lecture et l’écriture.
Xamarin fournit actuellement des outils pour cibler le Mac, iOS et Android API à l’aide de c# et .NET native. Ces
outils sont appelés Xamarin.Mac, Xamarin.iOS et Xamarin.Android, collectivement regroupés sous la plateforme
Xamarin. Il s’agit des bibliothèques et des liaisons qui expriment les API natives de ces plateformes avec les
langages .NET.
Les développeurs peuvent utiliser la plateforme Xamarin pour écrire des applications en c# qui cible Mac, iOS ou
Android. Mais si vous ciblez plusieurs plateformes, il est judicieux de partager une partie du code entre les
plateformes cibles. Cela implique la séparation du programme en code dépend de la plateforme (généralement
impliquant l’interface utilisateur) et de code indépendant de la plateforme, ce qui nécessite généralement
uniquement base .NET framework. Ce code indépendant de la plateforme peut résider dans une bibliothèque de
classes Portable (PCL ), ou un projet partagé, souvent appelé projet de ressource partagé ou SAP.
NOTE
Bibliothèques de classes portables ont été remplacés par des bibliothèques .NET Standard. Exemples de code à partir de
l’ouvrage a été converti pour utiliser les bibliothèques .NET standard.
Présentation de Xamarin.Forms
Lorsque vous ciblez plusieurs plateformes mobiles, Xamarin.Forms permet le partage de code encore plus. Un seul
programme écrit pour Xamarin.Forms peut cibler ces plateformes :
iOS pour les programmes qui s’exécutent sur l’iPhone, iPad et iPod touch
Android pour les programmes qui s’exécutent sur les téléphones et tablettes Android
la plateforme Windows universelle pour cible Windows 10
NOTE
Xamarin.Forms ne gère plus de Windows 8.1, Windows Phone 8.1 ou Windows 10 Mobile, mais les applications
Xamarin.Forms s’exécutent sur le bureau Windows 10. Il est également prise en charge de la version préliminaire de la Mac,
WPF, GTK #, et Tizen plateformes.
La majeure partie d’un programme de Xamarin.Forms existe dans une bibliothèque ou un SAP. Chacune des
plateformes se compose d’un stub de petite application qui appelle ce code partagé.
Les APIs Xamarin.Forms mapper à des contrôles natifs sur chaque plateforme, afin que chaque plateforme gère
son apparence caractéristique :
Les captures d’écran de gauche à droite affichent un iPhone et un téléphone Android :

Sur chaque écran, la page contient un Xamarin.Forms Label pour afficher du texte, un Button pour l’initiation
d’actions, un Switch pour Si vous choisissez une valeur activé/désactivé et un Slider pour spécifier une valeur
dans une plage continue. Les quatre de ces vues sont des enfants d’un StackLayout sur un ContentPage .
Également attaché à la page est une barre d’outils Xamarin.Forms composé de plusieurs ToolbarItem objets. Ceux-
ci sont visibles sous forme d’icônes en haut de l’iOS et Android écrans et en bas de l’écran de Windows 10 Mobile.
Xamarin.Forms prend également en charge XAML, l’Extensible Application Markup Language développés par
Microsoft pour plusieurs plateformes d’application. Tous les éléments visuels du programme ci-dessus sont définis
dans XAML, comme illustré dans le PlatformVisuals exemple.
Un programme de Xamarin.Forms peut déterminer quelle plate-forme il s’exécute et exécuter un code différent en
conséquence. Plus puissant, les développeurs peuvent écrire du code personnalisé pour les différentes plateformes
et exécuter ce code à partir d’un programme de Xamarin.Forms de manière indépendante de la plateforme. Les
développeurs peuvent également créer des contrôles supplémentaires en écrivant des convertisseurs pour chaque
plateforme.
Xamarin.Forms est une bonne solution pour les applications line of business, ou pour créer des prototypes ou
effectuer une démonstration rapide de la preuve de concept, il est moins idéal pour les applications qui nécessitent
des graphiques vectoriels ou interaction tactile complexes.
Votre environnement de développement

Votre environnement de développement dépend de ce que vous souhaitez cibler des plateformes et les ordinateurs
que vous voulez utiliser.
Si vous souhaitez cibler iOS, vous devez un Mac avec Xcode et la plateforme Xamarin installé. Prenant en charge
Android ainsi nécessite l’installation de Java et les kits de développement logiciel requis. Vous pouvez ensuite cibler
iOS et Android à l’aide de Visual Studio pour Mac.
Installation de Visual Studio vous permet de sur le PC cibler iOS, Android et toutes les plateformes Windows.
Toutefois, cibler iOS à partir de Visual Studio nécessite toujours un Mac avec Xcode et la plateforme Xamarin
installé.
Vous pouvez tester les programmes sur un appareil réel que connectés par USB à l’ordinateur ou sur un simulateur.
Installation
Avant de créer et de création d’une application Xamarin.Forms, vous devriez créer et créer séparément une
application iOS, une application Android et une application UWP, selon les plateformes que vous souhaitez cible et
votre environnement de développement.
Les sites web de Xamarin et Microsoft contiennent des informations sur la façon de procéder :
Bien démarrer avec iOS
Bien démarrer avec Android
Centre de développement Windows
Une fois que vous pouvez créer et n’exécuter des projets pour ces plateformes individuelles, vous devez avoir
aucun problème de création et exécution d’une application Xamarin.Forms.
Liens connexes
Chapitre 1 de texte intégral (PDF )
Exemple de chapitre 1
Résumé du chapitre 2. Anatomie d’une application
NOTE
Dans une application Xamarin.Forms, les objets qui occupent l’espace sur l’écran sont appelés éléments visuels, il
est encapsulé par le VisualElement classe. Éléments visuels peuvent être divisées en trois catégories
correspondant à ces classes :
Page
Disposition
Affichage
Un Page dérivé occupe tout l’écran, ou presque tout l’écran. Souvent, l’enfant d’une page est un Layout dérivé
pour organiser les éléments visuels enfants. Les enfants de la Layout peut être autre Layout classes ou View
dérivés (souvent appelé éléments), qui sont des objets familiers tels que le texte, images bitmap, curseurs, boutons,
zones de liste et ainsi de suite.
Ce chapitre montre comment créer une application en se concentrant sur la Label , qui est le View dérivée qui
affiche du texte.
Saluez
Sur la plateforme Xamarin est installée, vous pouvez créer une solution Xamarin.Forms dans Visual Studio ou
Visual Studio pour Mac. Le Hello solution utilise une bibliothèque de classes Portable pour le code commun.
NOTE
Cet exemple montre une solution Xamarin.Forms créée dans Visual Studio sans aucune modification. La solution
se compose de six projets :
Hello, une bibliothèque de classes Portable (PCL ) partagés par les autres projets
Hello.Droid, un projet d’application pour Android
Hello.iOS, un projet d’application pour iOS
Hello.UWP, un projet d’application pour la plateforme Windows universelle (Windows 10 et Windows 10
Mobile)
Hello.Windows, un projet d’application pour Windows 8.1
Hello.WinPhone, un projet d’application pour Windows Phone 8.1
NOTE
Xamarin.Forms ne gère plus de Windows 8.1, Windows Phone 8.1 ou Windows 10 Mobile, mais les applications
Xamarin.Forms s’exécutent sur le bureau Windows 10.
Vous pouvez apporter l’une de ces projets d’application du projet de démarrage, puis générer et exécuter le
programme sur un appareil ou un simulateur.
Dans la plupart de vos programmes de Xamarin.Forms, vous ne modifient les projets d’application. Souvent, ils
restent minuscules stubs simplement pour lancer le programme. La majeure partie de votre objectif sera de la
bibliothèque commune à toutes les applications.
Dans les fichiers

Les éléments visuels affichés par le Hello programme sont définis dans le constructeur de la App classe. App
dérive de la classe Xamarin.Forms Application .
NOTE
Les modèles de solution Visual Studio pour Xamarin.Forms créent une page avec un fichier XAML. XAML n’est pas abordé
dans cet ouvrage jusqu'à chapitre 7.
Le références section de la Hello projet PCL inclut les assemblys Xamarin.Forms suivants :
Xamarin.Forms.Core
Xamarin.Forms.Xaml
Xamarin.Forms.Platform
Le références sections des projets de cinq application incluent des assemblys supplémentaires qui s’appliquent à
chaque plate-forme :
Xamarin.Forms.Platform.Android
Xamarin.Forms.Platform.iOS
Xamarin.Forms.Platform.UWP
Xamarin.Forms.Platform.WinRT
Xamarin.Forms.Platform.WinRT.Tablet
Xamarin.Forms.Platform.WinRT.Phone
NOTE
Le références sections de ces projets répertorient ne sont plus les assemblys. Au lieu de cela, le fichier projet contient un
PackageReference étiquettes référençant le package Xamarin.Forms NuGet. Le références section dans les listes de Visual
Studio le Xamarin.Forms package plutôt que les assemblys Xamarin.Forms.
Chacun des projets d’application contient un appel à la méthode statique Forms.Init méthode dans le
Xamarin.Forms espace de noms. Ce code initialise la bibliothèque Xamarin.Forms. Une version différente de
Forms.Init est défini pour chaque plateforme. Vous trouverez les appels à cette méthode dans les classes
suivantes :
iOS : AppDelegate
Android : MainActivity
UWP : App (classe), OnLaunched (méthode)
En outre, chaque plateforme doit instancier la App classe emplacement dans la bibliothèque partagée. Cela se
produit dans un appel à LoadApplication dans les classes suivantes :
iOS : AppDelegate
Android : MainActivity
UWP : MainPage
Sinon, ces projets d’application sont des programmes de « ne rien faire » normal.
Bibliothèque de classes portable ou SAP ?

Il est possible de créer une solution Xamarin.Forms avec le code commun dans une bibliothèque de classes
Portable (PCL ) ou un projet de ressource partagé (SAP ). Pour créer une solution SAP, sélectionnez l’option partagé
dans Visual Studio. Le HelloSap solution montre le modèle SAP sans aucune modification.
NOTE
Bibliothèques de classes portables a été remplacée par des bibliothèques .NET Standard. Exemples de code à partir de
l’ouvrage a été converti pour utiliser les bibliothèques .NET standard. Sinon, les bibliothèques .NET Standard et de
bibliothèque de classes portable sont conceptuellement très similaires.
Les regroupements d’approche de bibliothèque tous les courantes de code dans un projet de bibliothèque
référencé par les projets d’application de plateforme. Avec l’approche SAP, le code commun existe dans tous les
projets d’application de plateforme efficacement et est partagé entre eux.
La plupart des développeurs Xamarin.Forms préfère l’approche de la bibliothèque. Dans cet ouvrage, la plupart
des solutions utilisent une bibliothèque. Ceux qui utilisent SAP incluent un Sap suffixe du nom de projet.
L’approche SAP le code dans le projet partagé permet d’exécuter un code différent pour les différentes
plateformes à l’aide de directives de préprocesseur c# ( #if , # elif , et #endif ) avec ces prédéfinis des
identificateurs :
iOS : __IOS__
Android : __ANDROID__
UWP : WINDOWS_UWP
Dans une bibliothèque partagée, vous pouvez déterminer la plateforme que vous exécutez lors de l’exécution,
comme vous le verrez plus loin dans ce chapitre.
Étiquettes de texte
Le Greetings solution montre comment ajouter un nouveau fichier c# à la Greetings projet. Ce fichier définit une
classe nommée GreetingsPage qui dérive de ContentPage . Dans cet ouvrage, la plupart des projets contiennent
une seule ContentPage dérivé dont le nom est le nom du projet avec le suffixe Page ajouté.
Le GreetingsPage constructeur instancie un Label vue, qui est la vue Xamarin.Forms qui affiche du texte. Le Text
propriété est définie sur le texte affiché par le Label . Ce programme définit la Label à la Content propriété du
ContentPage . Le constructeur de la App classe instancie ensuite GreetingsPage et lui affecte son MainPage
propriété.
Le texte est affiché dans le coin supérieur gauche de la page. Sur iOS, cela signifie qu’il chevauche barre d’état de
la page. Il existe plusieurs solutions à ce problème :
Solution 1. Inclure la marge intérieure dans la page
Définir un Padding propriété sur la page. Padding est de type Thickness , une structure avec quatre propriétés :
Left
Top
Right
Bottom
Padding définit une zone à l’intérieur d’une page où le contenu est exclu. Cela permet la Label pour éviter le
remplacement de la barre d’état iOS.
Solution 2. Inclure la marge intérieure simplement pour iOS (SAP uniquement)
Définir une propriété « Marge » uniquement sur iOS à l’aide d’un SAP avec une directive de préprocesseur c#.
Cela est illustré dans le GreetingsSap solution.
Solution 3. Inclure la marge intérieure simplement pour iOS (bibliothèque de classes portable ou SAP)
Dans la version de Xamarin.Forms utilisé pour le livre, un Padding propriété spécifique à iOS dans une
bibliothèque de classes portable ou une SAP peut être sélectionnée à l’aide de la Device.OnPlatform ou
Device.OnPlatform<T> méthode statique. Ces méthodes sont désormais déconseillés.
Le Device.OnPlatform méthodes sont utilisées pour exécuter du code de plateforme spécifique ou pour
sélectionner les valeurs spécifiques à la plateforme. En interne, elles rendent utilisent le Device.OS en lecture seule
propriété statique, qui retourne un membre de la TargetPlatform énumération :
iOS
Android
Windows pour les appareils UWP.
Le Device.OnPlatform méthodes, le Device.OS propriété et le TargetPlatform énumération sont tous maintenant

déconseillé. Au lieu de cela, utilisez le Device.RuntimePlatform propriété et comparer le string retourner de valeur
avec les champs statiques suivantes :
iOS , la chaîne « iOS »
Android , la chaîne « Android »
UWP , la chaîne « UWP », qui fait référence à la plateforme Windows universelle
Le Device.Idiom propriété en lecture seule statique est liée. Cela retourne un membre de la TargetIdiom , ce qui a
ces membres :
Desktop
Tablet
Phone
Unsupported n’est pas utilisé
Pour iOS et Android, la limite entre Tablet et Phone est une largeur de portrait de 600 unités. Pour la plateforme
Windows, Desktop indique une application UWP s’exécutant sous Windows 10, et Phone indique une application
UWP s’exécutant sous Windows 10 application.
3 a de solution. Définir la marge sur l’étiquette

Le Margin propriété a été introduite trop tard pour être inclus dans le livre, mais il est également de type
Thickness et vous pouvez le définir sur le Label pour définir une zone en dehors de la vue qui est incluse dans le
calcul de la disposition de la vue.
Le Padding propriété est disponible uniquement sur Layout et Page dérivés. Le Margin propriété n’est
disponible sur tous les View dérivés.
Solution 4. Centrer l’étiquette dans la page
Vous pouvez centrer le Label au sein de la Page (ou le placer dans un des huit autres endroits) en définissant le
HorizontalOptions et VerticalOptions propriétés de la Label une valeur de type LayoutOptions . Le
LayoutOptions structure définit deux propriétés :
Un Alignment propriété de type LayoutAlignment , une énumération avec quatre membres : Start , ce qui
signifie que gauche ou supérieur en fonction de la orientation, Center , End , ce qui signifie que le droit ou
inférieur selon l’orientation, et Fill .
Un Expands propriété de type bool .
Généralement ces propriétés ne sont pas utilisées directement. Au lieu de cela, les combinaisons de ces deux
propriétés sont fournies par huit propriétés en lecture seule statiques de type LayoutOptions :
LayoutOptions.Start
LayoutOptions.Center
LayoutOptions.End
LayoutOptions.Fill
LayoutOptions.StartAndExpand
LayoutOptions.CenterAndExpand
LayoutOptions.EndAndExpand
LayoutOptions.FillAndExpand
HorizontalOptions et VerticalOptions sont des propriétés les plus importantes dans la disposition de
Xamarin.Forms et sont décrits plus en détail dans chapitre 4. Défilement de la pile.
Voici le résultat avec la HorizontalOptions et VerticalOptions propriétés de Label toutes deux définies sur
LayoutOptions.Center :
Solution 5. Centrer le texte dans l’étiquette

Vous pouvez également centrer le texte (ou placez-le dans les huit autres emplacements sur la page) en définissant
le HorizontalTextAlignment et VerticalTextAlignment propriétés de Label à un membre de la TextAlignment
énumération :
Start , signification gauche ou supérieur (selon l’orientation)
Center
End , ce qui signifie qu’à droite ou en bas (selon l’orientation)
Ces deux propriétés sont définies uniquement par Label , tandis que le HorizontalAlignment et VerticalAlignment
propriétés sont définies par View et héritée par toutes les View dérivés. Les résultats visuels peuvent sembler
similaires, mais ils sont très différents, comme illustré dans le chapitre suivant.
Liens connexes
Chapitre 2, texte intégral (PDF )
Exemples de chapitre 2
Chapitre 2 F# exemples
Bien démarrer avec Xamarin.Forms
Résumé du chapitre 3. Détails du texte
Ce chapitre explore le Label vue plus en détail, y compris les couleurs, polices et la mise en forme.
Habillage des paragraphes

Lorsque le Text propriété du Label contient du texte long, Label encapsule automatiquement à plusieurs lignes
comme illustré par la Baskervilles exemple. Vous pouvez incorporer des codes Unicode tels que « \u2014 » pour
le cadratin, ou C# caractères comme « \r » pour arrêter l’exécution vers une nouvelle ligne.
Lorsque le HorizontalOptions et VerticalOptions propriétés d’un Label sont définies sur LayoutOptions.Fill , le
la taille globale de la Label est régie par l’espace qui son conteneur met à disposition. Le Label est dite contraint.
La taille de la Label est la taille de son conteneur.
Lorsque le HorizontalOptions et VerticalOptions propriétés sont définies sur les valeurs autres que
LayoutOptions.Fill , la taille de la Label est régie par l’espace nécessaire pour restituer le texte, jusqu'à la taille de
son conteneur rend disponible pour le Label . Le Label est dite sans contrainte et détermine sa taille.
(Remarque : Les termes du contrat contraint et sans contrainte peut-être absurdes, une vue sans contrainte est
généralement inférieure à une vue contrainte. En outre, ces termes ne sont pas utilisés régulièrement dans les
premiers chapitres du livre.)
Une vue comme un Label peut être limité dans une dimension et sans contraintes dans l’autre. Un Label sera
uniquement habiller le texte sur plusieurs lignes si elle est contrainte horizontalement.
Si un Label est contraint, il peut-être occuper beaucoup plus d’espace requis pour le texte. Le texte peut être placé
dans la zone globale de la Label . Définir le HorizontalTextAlignment propriété à un membre de la TextAlignment
énumération ( Start , Center , ou End ) pour contrôler l’alignement de toutes les lignes du paragraphe. La valeur
par défaut est Start et aligne le texte à gauche.
Définir le VerticalTextAlignment propriété à un membre de la TextAlignment énumération pour positionner le
texte en haut, center ou en bas de la zone occupée par le Label .
Définir le LineBreakMode propriété à un membre de la LineBreakMode énumération ( WordWrap , CharacterWrap ,
NoWrap , HeadTruncation , MiddleTruncation , ou TailTruncation ) pour contrôle comment le plusieurs lignes dans
un saut de paragraphe ou sont tronqués.
Couleurs du texte et d’arrière-plan

Définir le TextColor et BackgroundColor propriétés de Label à Color valeurs pour contrôler la couleur du texte
et d’arrière-plan.
Le BackgroundColor s’applique à l’arrière-plan de toute la zone occupée par le Label . Selon le HorizontalOptions
et VerticalOptions propriétés, que la taille peut être beaucoup plus volumineuses que la zone requise pour
afficher le texte. Vous pouvez utiliser des couleurs pour faire des essais avec différentes valeurs de
HorizontalOptions , VerticalOptions , HorizontalExeAlignment , et VerticalTextAlignment pour voir comment elles
affectent la taille et la position de la Label et la taille et la position du texte dans le Label .
La structure de couleur
Le Color structure vous permet de spécifier les couleurs en tant que valeurs de rouge-vert-bleu (RVB ) ou des
valeurs de Teinte-Saturation-Luminosité (TSL ), ou avec un nom de couleur. Un canal Alpha est également
disponible pour indiquer la transparence.
Utilisez un Color constructeur pour spécifier :
un nuance de gris
un valeur RVB
un valeur RVB avec transparence
Les arguments sont double valeurs comprises entre 0 et 1.
Vous pouvez également utiliser plusieurs méthodes statiques pour créer Color valeurs :
Color.FromRgb pour double valeurs RVB à partir de 0 à 1
Color.FromRgb pour les valeurs RVB de nombre entier compris entre 0 et 255
Color.FromRgba pour double valeurs RVB avec transparence
Color.FromRgba pour les valeurs RVB d’entières avec la transparence
Color.FromHsla pour double valeurs TSL avec transparence
Color.FromUint pour un uint valeur calculée en tant que ( B + 256 * ( G + 256 * ( R + 256 * A )))
Color.FromHex pour un string format de chiffres hexadécimaux sous la forme « #AARRGGBB » ou
« #RRGGBB » ou « #ARGB » ou « #RGB », où chaque lettre correspond à un chiffre hexadécimal pour la valeur
alpha, rouge, verts et bleus de canaux. Cette méthode est principale utilisé pour les conversions de couleur
XAML, comme indiqué dans chapitre 7, XAML et code.
Une fois créé, un Color valeur est immuable. Les caractéristiques de la couleur peuvent être obtenus à partir des
propriétés suivantes :
R
G
B
A
Hue
Saturation
Luminosity
Il s’agit de tous les double valeurs comprises entre 0 et 1.

Color définit également 240 champs statiques publics en lecture seule des couleurs courantes. Au moment de
que l’ouvrage a été écrit, des couleurs courantes uniquement 17 étaient disponibles.
Un autre champ statique public en lecture seule définit une couleur avec tous les canaux de couleur a la valeur
zéro :
Color.Transparent
Plusieurs méthodes d’instance permettent la modification d’une couleur existante pour créer une nouvelle couleur :
AddLuminosity
MultiplyAlpha
WithHue
WithLuminosity
WithSaturation
Enfin, deux propriétés statiques en lecture seule définissent la valeur de couleur spécial :
Color.Default , la valeur tous les canaux –1
Color.Accent
Color.Default Permet d’appliquer le modèle de couleurs de la plateforme, et par conséquent a une signification
différente dans différents contextes sur différentes plateformes. Par défaut, les jeux de couleurs de plateforme
sont :
iOS : Texte sombre sur un arrière-plan clair
Android : Texte sur un arrière-plan foncé (dans le livre) ou texte sombre sur un arrière-plan clair de lumière
(pour Material Design via AppCompat dans le master branche de l’exemple de référentiel de code)
UWP : Texte sombre sur un arrière-plan clair
Le Color.Accent valeur les résultats dans une couleur spécifique à la plateforme (et parfois sélectionnables par
l’utilisateur) qui est visible sur un arrière-plan sombre ou clair.
Changer les couleurs de l’application

Les différentes plateformes ont un modèle de couleurs par défaut, comme indiqué dans la liste ci-dessus.
Lorsque vous ciblez Android, il est possible de basculer vers un schéma sombre sur clair en spécifiant un thème
clair dans le fichier Android.Manifest.xml ou en AppCompat Ajout et Material Design.
Pour les plateformes Windows, le thème de couleur est généralement sélectionné par l’utilisateur, mais vous
pouvez ajouter un RequestedTheme attribut la valeur Light ou Dark dans le fichier App.xaml de la plateforme. Par
défaut, le fichier App.xaml dans le projet UWP contient un RequestedTheme attribut la valeur Light .
Attributs et les tailles de police

Définir le FontFamily propriété du Label à une chaîne telle que « Times Roman » pour sélectionner une famille
de polices. Toutefois, vous devez spécifier une famille de polices qui est pris en charge sur la plateforme spécifique,
et les plateformes ne sont pas cohérents à cet égard.
Définir le FontSize propriété du Label à un double pour spécifier la hauteur approximative de la police.
Consultez chapitre 5, gestion des tailles, pour plus d’informations sur le choix intelligemment les tailles de police.
Vous pouvez également obtenir un plusieurs prédéfini dépend de la plateforme de tailles de police. Statiques
Device.GetNamedSize (méthode) et surcharger retournent un double valeur de taille de police appropriée à la
plateforme basée sur les membres de la NamedSize énumération ( Default , Micro , Small , Medium , et Large ).
La valeur retournée par la Medium membre n’est pas nécessairement identique à Default . Le NamedFontSizes
exemple affiche le texte avec ces tailles nommées.
Définir le FontAttributes propriété du Label à un membre de ces FontAttributes énumération, Bold , Italic ,
ou None . Vous pouvez combiner la Bold et Italic membres avec le langage c# opérateur de bits OR.
Texte mis en forme

Dans tous les exemples jusqu’ici, l’intégralité du texte affiché par le Label a été formaté de manière uniforme.
Pour faire varier la mise en forme dans une chaîne de texte, ne définissez pas la Text propriété du Label . Au lieu
de cela, définissez la FormattedText propriété à un objet de type FormattedString .
FormattedString a un Spans propriété qui est une collection de Span objets. Chaque Span objet possède son
propre Text , FontFamily , FontSize , FontAttributes , ForegroundColor , et BackgroundColor propriétés.
Le VariableFormattedText exemple montre comment utiliser le FormattedText propriété pour une seule ligne de
texte, et VariableFormattedParagraph illustre cette technique pour tout un paragraphe, comme illustré ici :
Le NamedFontSizes programme utilise un seul Label et un FormattedString objet pour afficher toutes les tailles
de police nommé pour chaque plateforme.
Liens connexes
Label
Utilisation des couleurs
Résumé du chapitre 4. Défilement de la pile
Ce chapitre est principalement consacré au introduisant le concept de disposition, qui est le terme général pour les
classes et les techniques de Xamarin.Forms utilise pour organiser l’affichage visuel de plusieurs vues sur la page.
Disposition implique plusieurs classes qui dérivent de Layout et Layout<T> . Ce chapitre se concentre sur
StackLayout .
NOTE
Le FlexLayout introduite dans Xamarin.Forms 3.0 peut être utilisé de manière similaire à StackLayout , mais avec plus de
souplesse.
A également introduit dans ce chapitre sont les ScrollView , Frame , et BoxView classes.
Piles de vues
StackLayout dérive de Layout<View> et hérite d’un Children propriété de type IList<View> . Vous ajoutez
plusieurs éléments d’affichage à cette collection, et StackLayout les affiche dans une pile horizontale ou verticale.
Définir le Orientation propriété du StackLayout à un membre de la StackOrientation énumération, soit
Vertical ou Horizontal . La valeur par défaut est Vertical .
Définir le Spacing propriété du StackLayout à un double valeur à spécifier un espacement entre les enfants. La
valeur par défaut est 6.
Dans le code, vous pouvez ajouter des éléments à la Children collection de StackLayout dans un for ou
foreach boucle comme illustré dans le ColorLoop exemple, ou vous pouvez initialiser le Children collection
avec une liste des vues individuelles comme illustré dans ColorList. Les enfants doivent dériver de View mais
peut inclure d’autres StackLayout objets.
Faire défiler un contenu

Si un StackLayout contient trop grand nombre d’enfants à afficher sur une page, vous pouvez placer le
StackLayout dans un ScrollView pour permettre le défilement.
Définir le propriété du ScrollView à la vue que vous souhaitez faire défiler. Il s’agit souvent un
Content
StackLayout , mais il peut être n’importe quelle vue.
Définir le propriété du ScrollView à un membre de la ScrollOrientation propriété, Vertical ,

Orientation
Horizontal , ou Both . La valeur par défaut est Vertical . Si le contenu d’un ScrollView est un StackLayout , les
deux orientations doivent être cohérentes.
Le ReflectedColors exemple illustre l’utilisation de ScrollView et StackLayout pour afficher les couleurs
disponibles. L’exemple montre également comment utiliser la réflexion .NET pour obtenir toutes les propriétés
statiques publiques et les champs de la Color structure sans avoir à les répertorier explicitement.
L’option se développe
Lorsqu’un StackLayout piles ses enfants, chacun d’eux occupe une position particulière au sein de la hauteur totale
de la StackLayout qui varie selon la taille de l’enfant et les paramètres de son HorizontalOptions et
VerticalOptions propriétés. Ces propriétés sont attribuées aux valeurs de type LayoutOptions .
Le LayoutOptions structure définit deux propriétés :

Alignment du type énumération LayoutAlignment avec quatre membres, Start , Center , End , et Fill
Expands de type bool
Pour votre commodité, le LayoutOptions structure définit également les huit champs en lecture seule statiques de
type LayoutOptions qui englobent toutes les combinaisons des propriétés de l’instance de deux :
LayoutOptions.Start
LayoutOptions.Center
LayoutOptions.End
LayoutOptions.Fill
LayoutOptions.StartAndExpand
LayoutOptions.CenterAndExpand
LayoutOptions.EndAndExpand
LayoutOptions.FillAndExpand
La discussion suivante implique un StackLayout avec une orientation verticale par défaut. Horizontal StackLayout
est analogue.
Pour un vertical StackLayout , le HorizontalOptions paramètre détermine la façon dont un enfant est positionné
horizontalement dans la largeur de la StackLayout . Un Alignment paramètre Start , Center , ou End provoque
l’enfant d’être horizontalement sans contrainte. L’enfant détermine sa propre largeur et est positionné sur la
gauche, centre ou à droite de la StackLayout . Le Fill option entraîne l’enfant à limiter horizontalement et remplit
la largeur de la StackLayout .
Pour un vertical StackLayout , chaque enfant est verticalement sans contrainte et obtient un vertical de
l’emplacement en fonction de la hauteur de l’enfant, auquel cas la VerticalOptions paramètre n’est pas pertinent.
Si vertical StackLayout lui-même est sans contrainte—autrement dit si son VerticalOptions paramètre est Start
, Center , ou End , puis la hauteur de la StackLayout est la hauteur totale de ses enfants.
Toutefois, si la verticale StackLayout est contraint verticalement—si son VerticalOptions paramètre est Fill —
puis la hauteur de la StackLayout sera la hauteur de son conteneur, ce qui peut être supérieure au total hauteur de
ses enfants. Si tel est le cas, et si au moins un enfant a un VerticalOptions avec un Expands indicateur de true ,
puis l’espace supplémentaire dans le StackLayout est répartis équitablement entre tous les enfants avec un
Expands indicateur de true . La hauteur totale des enfants sera ensuite égale à la hauteur de la StackLayout et le
Alignment dans le cadre de la VerticalOptions paramètre détermine la façon dont l’enfant est positionnée
verticalement dans son emplacement.
Cela est illustré dans le VerticalOptionsDemo exemple.
Frame et BoxView
Ces deux vues rectangulaires servent souvent à des fins de présentation.
Le Frame affiche un cadre rectangulaire autour d’une autre vue, ce qui peut être une disposition comme
StackLayout . Frame hérite une Content propriété à partir de ContentView que vous définissez à la vue à afficher
dans le Frame . Le Frame est transparent par défaut. Définissez les trois propriétés suivantes pour personnaliser
l’apparence de l’image :
Le OutlineColor propriété pour le rendre visible. Il est courant de définir OutlineColor à Color.Accent lorsque
vous ne connaissez pas le jeu de couleurs sous-jacent.
Le HasShadow propriété peut être définie sur true pour afficher une ombre noir sur les appareils iOS.
Définir le Padding propriété un Thickness le contenu de valeur à laisser un espace entre l’image et l’image. La
valeur par défaut est de 20 unités de tous les côtés.
Le Frame a la valeur par défaut HorizontalOptions et VerticalOptions les valeurs de LayoutOptions.Fill , ce qui
signifie que le Frame remplira son conteneur. Avec d’autres paramètres, la taille de la Frame est basée sur la taille
de son contenu.
Le Frame est illustrée dans le FramedText exemple.
Le BoxView affiche une zone rectangulaire de la couleur spécifiée par son Color propriété.
Si le est limité (son HorizontalOptions et VerticalOptions propriétés ont leurs paramètres par défaut de
BoxView
LayoutOptions.Fill ), le BoxView remplit l’espace disponible pour lui. Si le BoxView n’est pas limitée (avec
HorizontalOptions et LayoutOptions paramètres de Start , Center , ou End ), il a une dimension par défaut du
carré de 40 unités. Un BoxView peut être limité dans une dimension et sans contraintes dans l’autre.
Souvent, vous devez définir le WidthRequest et HeightRequest propriétés de BoxView afin de lui donner une taille
spécifique. Ceci est illustré par la SizedBoxView exemple.
Vous pouvez utiliser plusieurs instances de StackLayout pour combiner un BoxView et plusieurs Label instances
dans un Frame pour afficher une couleur particulière, puis placez chacun de ces vues dans une StackLayout dans
un ScrollView pour créer l’attrayante liste de couleurs affichées dans le ColorBlocks exemple :
Un ScrollView dans un StackLayout ?

Placer un StackLayout dans un ScrollView est commun, mais en ajoutant un ScrollView dans un StackLayout
est également parfois commode. En théorie, cela ne doit pas être possible, car les enfants d’une verticale
StackLayout sont verticalement sans contrainte. Mais un ScrollView doit donc être contraint verticalement. Il doit
disposer d’une hauteur spécifique afin qu’elle puisse ensuite déterminer la taille de son enfant pour le défilement.
L’astuce consiste à donner le ScrollView enfant de la StackLayout un VerticalOptions paramètre FillAndExpand .
Cela est illustré dans le BlackCat exemple.
Le BlackCat exemple montre également comment définir et accéder aux ressources de programme qui sont
incorporés dans la bibliothèque partagée. Cela est également possible avec les projets de ressource partagé (SAP )
mais le processus est un peu plus compliqué, comme le BlackCatSap montre des exemples.
Liens connexes
StackLayout
ScrollView
BoxView
Résumé du chapitre 5. Gestion des tailles
NOTE
Plusieurs tailles de Xamarin.Forms ont été rencontrées jusqu'à présent :

La hauteur de la barre d’état iOS est 20
Le BoxView a une largeur par défaut et une hauteur de 40
La valeur par défaut Padding dans un Frame est 20
La valeur par défaut Spacing sur le StackLayout est 6
Le Device.GetNamedSize méthode retourne une taille de police numérique
Ces tailles ne sont pas des pixels. Au lieu de cela, ils sont des unités indépendantes du périphérique reconnues
indépendamment par chaque plateforme.
Pixels, points, points de distribution, adresses IP dynamiques et DIUs

Au début de l’historique du Mac d’Apple et Microsoft Windows, les programmeurs a travaillé en unités de pixels.
Toutefois, l’arrivée de résolution supérieure affiche requis une approche abstraite et plus virtualisée aux
coordonnées d’écran. Dans l’univers Mac, les programmeurs travaillé en unités de points, traditionnellement
1/72ème de pouce, les développeurs Windows utilisé lors de la unités indépendantes du périphérique (DIUs) en
fonction de 1/96ème de pouce.
Toutefois, les appareils mobiles sont généralement conservées plus proches de la face et ont une résolution
supérieure à desktop écrans, ce qui implique qu’une densité de pixels supérieure peut être tolérée.
Les programmeurs ciblant les appareils iPhone et iPad d’Apple continuent de fonctionner en unités de points, mais
il existe 160 de ces points par pouce. Selon l’appareil, il peut être 1, 2 ou 3 pixels vers le point.
Android est similaire. Les programmeurs traitent en unités de pixels indépendants de densité (dps), et la relation
entre les points de distribution et de pixels est basée sur 160 DP par pouce.
Les téléphones Windows et les appareils mobiles ont également établi des facteurs d’échelle qui impliquent
quelque chose proche de 160 unités indépendantes du périphérique par pouce.
NOTE
Xamarin.Forms ne gère plus n’importe quel téléphone basée sur Windows ou un appareil mobile.
En résumé, un programmeur Xamarin.Forms ciblant les téléphones et tablettes peut supposer que toutes les
unités de mesure sont basées sur le critère suivant :
160 unités par pouce, équivalent à
64 unités pour le centimètre
En lecture seule Width et Height propriétés définies par VisualElement ont par défaut les valeurs de « simuler »
–1. Uniquement lorsqu’un élément a été dimensionné et prise en charge dans la disposition de ces propriétés
reflètent la taille réelle de l’élément dans les unités indépendantes du périphérique. Cette taille inclut au moins un
Padding défini sur l’élément, mais pas le Margin .
Un élément visuel se déclenche le SizeChanged événement lors de son Width ou Height a changé. Le WhatSize
exemple utilise cet événement pour afficher la taille de l’écran de programme.
Tailles SURMONTANT
Le MetricalBoxView utilise WidthRequest et HeightRequest pour afficher un BoxView un pouce en hauteur et
l’autre centimètre large.
Tailles de police estimé

Le tailles de police exemple montre comment utiliser la règle de 160-unités-à-the-pouce pour spécifier des
tailles de police en unités de points. La cohérence visuelle entre les plateformes à l’aide de cette technique est
meilleure que Device.GetNamedSize .
Ajustement du texte à la taille disponible

Il est possible d’adapter un bloc de texte dans un rectangle particulier en calculant un FontSize de la Label selon
les critères suivants :
Interligne est de 120 % de la taille de police (130 % sur les plateformes Windows).
Largeur de caractère moyenne est de 50 % de la taille de police.
Le EstimatedFontSize exemple illustre cette technique. Ce programme a été écrit avant la Margin propriété était
disponible, de sorte qu’il utilise un ContentView avec un Padding paramètre pour simuler un marge.
Une horloge de la taille de l’ajustement

Le FitToSizeClock exemple montre comment utiliser Device.StartTimer à démarrer un minuteur qui indique
périodiquement à l’application lorsqu’il est temps pour mettre à jour de l’horloge. La taille de police est définie à
un sixième de la largeur de page pour rendre l’affichage aussi grand que possible.
Problèmes d’accessibilité
Le EstimatedFontSize programme et le FitToSizeClock programme les deux contiennent un subtil défaut : si
l’utilisateur modifie les paramètres d’accessibilité du téléphone sur Android ou Windows 10 Mobile, le programme
n’est plus peut estimer la taille du texte est rendu en fonction de la taille de police. Le AccessibilityTest exemple
illustre ce problème.
Ajustement empirique de texte

Un autre en fonction du texte à un rectangle consiste à empirique calculer la taille du rendu de texte et l’ajuster
vers le haut ou vers le bas. Le programme dans les appels de livre GetSizeRequest sur un élément visuel pour
obtenir la taille souhaitée de l’élément. Méthode a été déconseillée et les programmes doivent appeler à la place
Measure .
Pour un Label , le premier argument doit être de la largeur du conteneur (pour permettre le retour à la ligne),
tandis que le second argument doit être défini à Double.PositiveInfinity pour que la hauteur sans contrainte. Le
EmpiricalFontSize exemple illustre cette technique.
Liens connexes
Résumé du chapitre 6. Clics de bouton
Le Button est la vue qui permet aux utilisateurs de lancer une commande. Un Button est identifié par le texte (et
éventuellement une image comme illustré dans chapitre 13, Bitmaps). Par conséquent, Button définit un grand
nombre des propriétés du mêmes comme Label :
Text
FontFamily
FontSize
FontAttributes
TextColor
Button définit également trois propriétés qui régissent l’apparence de sa bordure, mais la prise en charge de ces
propriétés et leur indépendance mutuelle est spécifiques à la plateforme :
BorderColor de type Color
BorderWidth de type Double
BorderRadius de type Double
Button hérite également toutes les propriétés de VisualElement et View , y compris BackgroundColor ,
HorizontalOptions , et VerticalOptions .
Traitement de la, cliquez sur

Le Button classe définit un Clicked événement est déclenché lorsque l’utilisateur actionne le Button . Le Click
gestionnaire est de type EventHandler . Le premier argument est le Button génère l’événement de l’objet ; le
deuxième argument est un EventArgs objet qui fournit des informations supplémentaires.
Le ButtonLogger simple illustre Clicked gestion.
Bouton de partage clique sur

Plusieurs Button vues peuvent partager la même Clicked gestionnaire, mais le gestionnaire doit généralement
déterminer quelle Button est chargé pour un événement particulier. Une approche consiste à stocker les
différentes Button objets en tant que champs et celle qui déclenche l’événement dans le Gestionnaire de contrôle.
Le TwoButtons exemple illustre cette technique. Le programme montre aussi comment définir le IsEnabled
propriété d’un Button à false lorsque vous appuyez sur la Button n’est plus valide. Désactivé Button ne génère
pas un Clicked événement.
Gestionnaires d’événements anonyme

Il est possible de définir Clicked gestionnaires en tant que fonctions lambda anonyme, comme le
ButtonLambdas montre des exemples. Toutefois, gestionnaires anonymes ne peut pas être partagés sans un code
de réflexion désordonnées.
Distinction des vues avec des ID

Plusieurs Button objets peuvent également être distingués en définissant le StyleId propriété ou AutomationId
propriété à un string . Cette propriété est définie par Element , mais elle n’est pas utilisée dans Xamarin.Forms.
Elle est destinée à être utilisée uniquement par les programmes d’application.
Le SimplestKeypad exemple utilise le même gestionnaire d’événements pour toutes les touches numériques 10
sur un pavé numérique et fait la distinction entre eux avec le StyleId propriété :
Enregistrer les données temporaires

De nombreuses applications ont besoin pour enregistrer les données lorsqu’un programme est arrêté et recharger
ces données lorsque le programme démarre à nouveau. Le Application classe définit plusieurs membres qui
aident à votre programme enregistrer et restaurer les données temporaires :
Le Properties propriété est un dictionnaire avec string clés et object éléments. Le contenu du dictionnaire
est automatiquement enregistré dans le stockage local des applications avant l’arrêt du programme et rechargé
lorsque le programme démarre.
Le Application classe définit trois méthodes virtuelles protégées qui le programme de standard App
substitue : OnStart , OnSleep , et OnResume . Ils se rapportent aux cycle de vie des applications événements.
Le SavePropertiesAsync méthode enregistre le contenu du dictionnaire.
Il n’est pas nécessaire d’appeler SavePropertiesAsync . Le contenu du dictionnaire est automatiquement enregistré
avant l’arrêt du programme et récupéré avant le démarrage du programme. Il est utile lors du test de programme
pour enregistrer les données si le programme se bloque.
Également est utile :
Application.Current , une propriété statique qui retourne actuel Application objet que vous pouvez ensuite
utiliser pour obtenir le Properties dictionnaire.
La première étape consiste à identifier toutes les variables dans la page que vous souhaitez rendre persistantes
lorsque le programme se termine. Si vous connaissez tous les endroits où ces variables changer, vous pouvez
simplement les ajouter à la Properties dictionnaire à ce stade. Dans le constructeur de la page, vous pouvez
définir les variables à partir de la Properties dictionnaire si la clé existe.
Un programme plus vaste devrez probablement à traiter les événements de cycle de vie d’application. La plus
importante est la OnSleep (méthode). Un appel à cette méthode indique que le programme a quitté le premier
plan. Peut-être l’utilisateur a appuyé sur le accueil bouton sur l’appareil, ou affiche toutes les applications ou
s’arrête le téléphone. Un appel à OnSleep est la seule notification qu’un programme reçoit avant d’être arrêté. Le
programme doit saisir cette occasion pour vous assurer que le Properties dictionnaire est à jour.
Un appel à OnResume indique que le programme ne s’est pas achevé après le dernier appel à OnSleep mais est
maintenant en cours d’exécution au premier plan à nouveau. Le programme peut utiliser cette opportunité pour
actualiser les connexions internet (par exemple).
Un appel à OnStart se produit lors du démarrage du programme. Il n’est pas nécessaire d’attendre jusqu'à ce que
l’appel de cette méthode pour accéder à la Properties dictionnaire, car le contenu a déjà été restaurée lorsque le
App constructeur est appelé.
Le PersistentKeypad exemple est très similaire à SimplestKeypad , à ceci près que le programme utilise le
OnSleep remplacement pour enregistrer l’entrée de clavier en cours, et le constructeur de la page pour restaurer
ces données.
NOTE
Une autre approche pour l’enregistrement des paramètres de programme est fournie par le Xamarin.Essentials préférences
classe.
Liens connexes
Bouton de Xamarin.Forms
Résumé du chapitre 7. XAML et code
NOTE
Xamarin.Forms prend en charge un langage de balisage basé sur XML appelé l’Extensible Application Markup
Language ou le XAML (prononcé « zammel »). XAML offre une alternative à c# dans la définition de la disposition
de l’interface utilisateur d’une application Xamarin.Forms et dans la définition des liaisons entre les éléments
d’interface utilisateur et les données sous-jacentes.
Propriétés et les attributs

Structures et classes de Xamarin.Forms deviennent des éléments XML dans XAML, et les propriétés de ces classes
et des structures deviennent des attributs XML. Pour être instancié en XAML, une classe doit avoir généralement
d’un constructeur sans paramètre public. Les propriétés définies dans XAML doivent avoir public set accesseurs.
Pour les propriétés des types de base de données ( string , double , bool , et ainsi de suite), l’analyseur XAML
utilise la norme TryParse méthodes pour convertir les paramètres de l’attribut à ces types. L’analyseur XAML
peut également facilement gérer des types énumération, et il peut associer des membres de l’énumération si le
type d’énumération est marqué avec le Flags attribut.
Pour aider l’analyseur XAML, des types plus complexes (ou propriétés de ces types) peuvent inclure un
TypeConverterAttribute qui identifie une classe qui dérive de TypeConverter qui prend en charge la conversion à
partir de valeurs de chaîne à ces types. Par exemple, le ColorTypeConverter convertit de noms et les chaînes, telles
que « #rrggbb », couleur dans Color valeurs.
Syntaxe d’élément de propriété

Dans XAML, les classes et les objets créés à partir de celles-ci sont exprimées en tant qu’éléments XML. Ils sont
appelés éléments objet. La plupart des propriétés de ces objets sont exprimées en tant qu’attributs XML. Ils sont
appelés les attributs de propriété.
Parfois, une propriété doit être définie à un objet qui ne peuvent pas être exprimé sous forme de chaîne simple.
Dans ce cas, XAML prend en charge une balise appelée un élément property qui se compose du nom de la classe
et du nom de propriété séparés par un point. Un élément objet peut ensuite apparaître dans une paire de balises
d’élément de propriété.
Ajout d’une page XAML à votre projet

Une bibliothèque de classes Portable Xamarin.Forms peut contenir une page XAML quand il est tout d’abord créé,
ou vous pouvez ajouter une page XAML à un projet existant. Dans la boîte de dialogue Ajouter un nouvel élément,
choisissez l’élément qui fait référence à une page XAML, ou ContentPage et XAML. (Pas un ContentView .)
NOTE
Options de Visual Studio ont été modifiés depuis la rédaction de ce chapitre.
Deux fichiers sont créés : un fichier XAML avec la .xaml d’extension de nom de fichier et un fichier c# avec
l’extension. xaml.cs. Le fichier c# est souvent appelé le code-behind du fichier XAML. Le fichier code-behind est
une définition de classe partielle qui dérive de ContentPage . Au moment de la génération, le XAML est analysé et
une autre définition de classe partielle est générée pour la même classe. Cette classe générée inclut une méthode
nommée InitializeComponent qui est appelée à partir du constructeur du fichier code-behind.
Pendant l’exécution, à la fin de la InitializeComponent appeler, tous les éléments du fichier XAML ont été
instanciés et initialisés comme si elles avaient été créées dans le code c#.
L’élément racine dans le fichier XAML est ContentPage . La balise racine contient au moins deux déclarations
d’espace de noms XML, un pour les éléments de Xamarin.Forms et l’autre définition d’un x préfixe pour les
éléments et attributs intrinsèques à toutes les implémentations XAML. La balise racine contient également un
x:Class attribut qui indique l’espace de noms et le nom de la classe qui dérive de ContentPage . Cela correspond à
l’espace de noms et le nom dans le fichier code-behind.
La combinaison de XAML et de code est illustrée par la CodePlusXaml exemple.
Le compilateur XAML
Xamarin.Forms a un compilateur XAML, mais son utilisation est facultative en fonction de l’utilisation d’un
XamlCompilationAttribute . Si le XAML n’est pas compilé, le XAML est analysé au moment de la génération et le
fichier XAML est incorporé dans la bibliothèque PCL, où il est également analysé lors de l’exécution. Si le XAML
est compilé, le processus de génération convertit le XAML dans un format binaire et le traitement de l’exécution
est plus efficace.
Spécificité de plateforme dans le fichier XAML

Dans XAML, le OnPlatform classe peut être utilisée pour sélectionner le balisage de dépend de la plateforme. Ceci
est une classe générique et doit être instancié avec une x:TypeArguments attribut qui correspond au type de cible.
Le OnIdiom classe est similaire mais utilisé beaucoup moins souvent.
L’utilisation de OnPlatform a changé depuis le livre a été publié. Il a été initialement utilisé conjointement avec les
propriétés nommées iOS , Android , et WinPhone . Il est maintenant utilisé avec enfant On objets. Définir le
Platform en une chaîne cohérente avec le public const champs de la Device classe. Définir le Value propriété
une valeur cohérente avec la x:TypeArguments attribut de la OnPlatform balise.
OnPlatform est illustrée dans le ScaryColorList exemple, appelée ainsi car il contient des blocs de XAML
quasiment identique. L’existence de ce balisage et répétitive suggère que les techniques doivent être disponibles
pour la réduire.
Les attributs de propriété de contenu

Certains éléments de propriété se produisent très fréquemment, telles que la <ContentPage.Content> balise sur
l’élément racine d’un ContentPage , ou le <StackLayout.Children> balise qui englobe les enfants de StackLayout .
Chaque classe est autorisé à identifier une propriété avec une ContentPropertyAttribute sur la classe. Pour cette
propriété, les balises d’élément de propriété ne sont pas nécessaires. ContentPage définit sa propriété de contenu
en tant que Content , et Layout<T> (la classe à partir de laquelle StackLayout dérive) définit sa propriété de
contenu en tant que Children . Ces balises d’élément de propriété ne sont pas nécessaires.
L’élément de propriété de Label est Text .
Texte mis en forme

Le TextVariations exemple contient plusieurs exemples de paramètre de la Text et FormattedText propriétés de
Label . Dans XAML, Span objets apparaissent en tant qu’enfants de le FormattedString objet.
Quand une chaîne multiligne est définie sur le Text propriété, les caractères de fin de ligne sont convertis en
caractères d’espace, mais les caractères de fin de ligne sont conservées quand une chaîne multiligne apparaît en
tant que contenu de la Label ou Label.Text balises :
Liens connexes
Chapitre 7 F# exemple
Notions de base XAML
Résumé du chapitre 8. Code et XAML en harmonie
Ce chapitre explore XAML de façon plus approfondie, et en particulier comment code et XAML interagissent.
Passage des arguments

En règle générale, une classe instanciée dans XAML doit avoir un constructeur sans paramètre public ; l’objet
résultant est initialisé par le biais des paramètres de propriété. Toutefois, il existe deux autres méthodes que les
objets peuvent être instanciés et initialisés.
Bien qu’il s’agit des techniques à usage général, ils sont principalement utilisés dans le cadre de modèles de vue de
MVVM.
Constructeurs avec des arguments
Le ParameteredConstructorDemo exemple montre comment utiliser le x:Arguments balise pour spécifier des
arguments de constructeur. Ces arguments doivent être délimités par des balises d’élément indiquant le type de
l’argument. Pour les types de données .NET base, les balises suivantes sont disponibles :
x:Object
x:Boolean
x:Byte
x:Int16
x:Int32
x:Int64
x:Single
x:Double
x:Decimal
x:Char
x:String
x:TimeSpan
x:Array
x:DateTime
Puis-je appeler des méthodes à partir de XAML ?

Le FactoryMethodDemo exemple montre comment utiliser le x:FactoryMethod élément pour spécifier une
méthode de fabrique qui est appelée pour créer un objet. Une telle méthode de fabrique doit être publique et
statique, et il doit créer un objet du type dans lequel elle est définie. (Par exemple le Color.FromRgb qualifie de
méthode, car elle est publique et statique et retourne une valeur de type Color .) Les arguments à la méthode de
fabrique sont spécifiés dans x:Arguments balises.
L’attribut x : Name
Le x:Name attribut permet à un objet instancié dans XAML à donner un nom. Les règles pour ces noms sont les
mêmes que pour les noms de variables c#. Après le retour de la InitializeComponent appeler le constructeur, le
fichier code-behind peut faire référence à ces noms pour accéder à l’élément XAML correspondant. Les noms sont
convertis en fait par l’analyseur XAML dans les champs privés de la classe partielle générée.
Le XamlClock exemple illustre l’utilisation de x:Name pour permettre au fichier de code-behind de conserver deux
Label éléments définis dans XAML mis à jour avec la date et heure actuelles.
Le même nom ne peut pas être utilisé pour plusieurs éléments dans la même page. Il s’agit d’un problème
particulier si vous utilisez OnPlatform pour créer en parallèle des objets nommés pour chaque plateforme. Le
PlatformSpecificLabele exemple illustre un meilleur moyen de faire quelque chose de similaire.
Vues personnalisées en fonction du XAML

Il existe plusieurs façons d’éviter la répétition de balisage en XAML. Une technique courante consiste à créer une
nouvelle classe XAML qui dérive de ContentView . Cette technique est illustrée dans le ColorViewList exemple. Le
ColorView dérive de la classe ContentView pour afficher une couleur particulière et son nom, tandis que le
ColorViewListPage dérive de la classe ContentPage comme d’habitude et explicitement crée des 17 instances de
ColorView .
L’accès à la ColorView classe dans XAML nécessite une autre déclaration d’espace de noms XML, généralement
nommée local pour les classes dans le même assembly.
Événements et gestionnaires
Événements peuvent être affectés aux gestionnaires d’événements dans XAML, mais le Gestionnaire d’événements
doit être implémenté dans le fichier code-behind. Le XamlKeypad montre comment créer une interface utilisateur
de clavier dans XAML et comment implémenter le Clicked gestionnaires dans le fichier code-behind.
Appuyez sur les mouvements

N’importe quel View objet peut obtenir l’entrée tactile et générer des événements à partir de cette entrée. Le View
classe définit un GestureRecognizers propriété de collection qui peut contenir une ou plusieurs instances des
classes qui dérivent de GestureRecognizer .
Le TapGestureRecognizer génère Tapped événements. Le MonkeyTap programme montre comment associer
TapGestureRecognizer objets à quatre BoxView éléments pour créer un jeu d’imitation :
Mais le MonkeyTap programme doit vraiment son. (Consultez le chapitre suivant.)
Liens connexes
Exemples du chapitre 8
Chapitre 8 F# exemple
Passage des Arguments dans XAML
Résumé du chapitre 9. Appels d’API spécifiques à la
plateforme
NOTE
Il est parfois nécessaire d’exécuter du code qui varie par plateforme. Ce chapitre explore les techniques.
Prétraitement dans le projet actif partagé

Un projet de ressource partagée Xamarin.Forms peut exécuter un code différent pour chaque plateforme en
utilisant les directives de préprocesseur c# #if , #elif , et endif . Cela est illustré dans PlatInfoSap1:
Toutefois, le code résultant peut être horrible et difficile à lire.
Classes parallèles dans le projet de ressources partagées

Une approche plus structurée à l’exécution de code spécifique à la plateforme dans SAP est illustrée dans le
PlatInfoSap2 exemple. Chacun des projets de plateforme contient une classe portant le même nommée et des
méthodes, mais implémentée pour cette plate-forme particulière. SAP ensuite simplement instancie la classe et
appelle la méthode.
DependencyService et la bibliothèque de classes Portable

NOTE
Une bibliothèque ne peut pas accéder normalement les classes dans les projets d’application. Cette restriction
semble pour empêcher la technique démontrée dans PlatInfoSap2 d’être utilisé dans une bibliothèque. Toutefois,
Xamarin.Forms contient une classe nommée DependencyService qui utilise la réflexion .NET pour accéder à des
classes publiques dans le projet d’application à partir de la bibliothèque.
La bibliothèque doit définir un interface avec les membres qu’il a besoin pour chaque plateforme. Ensuite,
chacune des plateformes contient une implémentation de cette interface. La classe qui implémente l’interface doit
être identifiée avec un DependencyAttribute sur le niveau de l’assembly.
La bibliothèque utilise ensuite le générique Get méthode de DependencyService pour obtenir une instance de la
classe de plateforme qui implémente l’interface.
Cela est illustré dans le DisplayPlatformInfo exemple.
Génération de sons spécifiques à la plateforme

Le MonkeyTapWithSound exemple ajoute des sonneries à la MonkeyTap programme en accédant à des
installations de sons dans chaque plateforme.
Liens connexes
Service de dépendance
Résumé du chapitre 10. Extensions de balisage XAML
Normalement, l’analyseur XAML convertit n’importe quelle chaîne définie comme valeur d’attribut sur le type de la
propriété en fonction de conversion des types de données .NET de base, standard ou un TypeConverter dérivé est
attaché à la propriété ou son type avec un TypeConverterAttribute .
Mais il est parfois utile de définir un attribut à partir d’une autre source, par exemple, un élément dans un
dictionnaire, ou la valeur d’une propriété statique ou d’un champ, ou d’un calcul quelconque.
Il s’agit du travail d’un extension de balisage XAML. Malgré son nom, les extensions de balisage XAML sont pas
une extension au format XML. XAML est toujours juridique XML.
L’infrastructure de code
Une extension de balisage XAML est une classe qui implémente le IMarkupExtension interface. Une telle classe
comporte souvent le mot Extension à la fin de son nom, mais s’affiche généralement dans XAML sans ce suffixe.
Les extensions de balisage XAML suivantes sont prises en charge par toutes les implémentations de XAML :
x:Static prise en charge par StaticExtension
x:Reference prise en charge par ReferenceExtension
x:Type prise en charge par TypeExtension
x:Null prise en charge par NullExtension
x:Array prise en charge par ArrayExtension
Ces quatre extensions de balisage XAML sont prises en charge par de nombreuses implémentations du XAML, y
compris Xamarin.Forms :
StaticResource prise en charge par StaticResourceExtension
DynamicResource prise en charge par DynamicResourceExtension
Binding prise en charge par BindingExtension —abordés dans chapitre 16. Liaison de données
TemplateBinding prise en charge par TemplateBindingExtension —non traitées dans le livre
Une extension de balisage XAML supplémentaire est incluse dans Xamarin.Forms en lien avec RelativeLayout :
ConstraintExpression —non couvertes dans le livre
L’accès aux membres statiques

Utilisez le x:Static élément à définir un attribut à la valeur d’un membre de propriété, champ ou énumération
statique publique. Définir le Member propriété pour le membre statique. Il est généralement plus facile de spécifier
x:Static et le nom du membre entre accolades. Le nom de la Member propriété ne doit pas être inclus, juste le
membre lui-même. Cette syntaxe courante est indiquée dans le SharedStatics exemple. Les champs statiques eux-
mêmes sont définis dans le AppConstants classe. Cette technique vous permet d’établir des constantes utilisées via
un programme.
Avec une déclaration d’espace de noms XML supplémentaire, vous pouvez référencer des propriétés statiques
publiques, des champs ou des membres de l’énumération définies dans le .NET framework, en particulier comme
illustré dans le SystemStatics exemple .
Dictionnaires de ressources
Le VisualElement classe définit une propriété nommée Resources que vous pouvez définir pour un objet de type
ResourceDictionary . Dans XAML, vous pouvez stocker les éléments dans ce dictionnaire et les identifier avec le
x:Key attribut. Les éléments stockés dans le dictionnaire de ressources sont partagées entre toutes les références
à l’élément.
StaticResource pour la plupart des cas
Dans la plupart des cas, vous utiliserez le StaticResource extension de balisage pour référencer un élément du
dictionnaire de ressources, comme illustré dans le ResourceSharing exemple . Vous pouvez utiliser un
StaticResourceExtension élément ou StaticResource entre accolades :
Ne confondez pas la x:Static extension de balisage et le StaticResource extension de balisage.

Une arborescence de dictionnaires
Lorsque l’analyseur XAML rencontre un StaticResource , il commence la recherche vers le haut l’arborescence
visuelle pour une clé correspondante et recherche les ResourceDictionary dans l’application App classe. Cela
permet des éléments dans un dictionnaire de ressources plus en détail l’arborescence visuelle pour remplacer un
dictionnaire de ressources plus haut dans l’arborescence visuelle. Cela est illustré dans le ResourceTrees exemple.
DynamicResource à des fins spéciales
Le StaticResource extension de balisage provoque un élément à récupérer à partir du dictionnaire lors d’une
arborescence d’éléments visuels est généré pendant la InitializeComponent appeler. Une alternative à
StaticResource est DynamicResource , qui maintient un lien vers la clé de dictionnaire et met à jour la cible lors de
l’élément référencé par les principales modifications apportées.
La différence entre StaticResource et DynamicResource est illustrée dans le DynamicVsStatic exemple.
Une propriété définie par DynamicResource doit reposer sur une propriété pouvant être liée comme indiqué dans
chapitre 11, infrastructure bindable.
Extensions de balisage moins utilisée

Utilisez le x:Null extension de balisage pour définir une propriété null .
Utilisez le x:Type extension de balisage pour définir une propriété à un .NET Type objet.
Utilisez x:Array pour définir un tableau. Spécifiez le type des membres du groupe en définissant le [ Type ]
propriété à un x:Type extension de balisage.
Une extension de balisage personnalisée

Vous pouvez créer vos propres extensions de balisage XAML en écrivant une classe qui implémente le
IMarkupExtension créent une interface avec un ProvideValue (méthode).
Le HslColorExtension classe satisfait ces exigences. Il crée une valeur de type Color en fonction des valeurs de
propriétés nommées H , S , L , et A . Cette classe est le premier élément dans une bibliothèque Xamarin.Forms
nommée Xamarin.FormsBook.Toolkit qui est développée et utilisé au cours de ce livre.
Le CustomExtensionDemo exemple montre comment référencer cette bibliothèque et d’utiliser l’extension de
balisage personnalisée.
Liens connexes
Chapitre 10 échantillons
Extensions de balisage XAML
Résumé du chapitre 11. Infrastructure Bindable
Tous les programmeurs c# est familiarisé avec c# propriétés. Les propriétés contiennent une définir accesseur
et/ou un obtenir accesseur. Elles sont souvent appelées propriétés CLR pour le Common Language Runtime.
Xamarin.Forms définit une définition de propriété améliorée appelée un propriété pouvant être liée encapsulé par
le BindableProperty classe et pris en charge par le BindableObject classe. Ces classes sont associés mais bien
distincts : le BindableProperty est utilisé pour définir la propriété proprement dite ; BindableObject est similaire à
object : c’est une classe de base des classes qui définissent les propriétés pouvant être liées.
La hiérarchie de classes de Xamarin.Forms

Le ClassHierarchy exemple utilise la réflexion pour afficher une hiérarchie de classes de Xamarin.Forms et
illustrer le rôle crucial joué par BindableObject dans cette hiérarchie. BindableObject dérive de Object et est la
classe parente à Element à partir de laquelle VisualElement dérive. C’est la classe parent à Page et View , qui est
la classe parente à Layout :
Un coup de œil dans BindableObject et BindableProperty

Dans les classes qui dérivent de BindableObject nombreuses propriétés CLR sont dits se reposer » sur
« Propriétés pouvant être liées. Par exemple, le Text propriété de la Label classe est une propriété CLR, mais la
Label classe définit également un champ statique public en lecture seule nommé TextProperty de type
BindableProperty .
Une application peut définir ou obtenir le Text propriété du Label normalement, ou l’application peut définir le
Text en appelant le SetValue méthode définie par BindableObject avec un Label.TextProperty argument. De
même, une application peut obtenir la valeur de la Text propriété en appelant le GetValue (méthode), en utilisant
un Label.TextProperty argument. Cela est illustré par la PropertySettings exemple.
En effet, le Text propriété CLR est entièrement implémentée à l’aide de la SetValue et GetValue méthodes
définies par BindableObject conjointement avec le Label.TextProperty propriété statique.
BindableObject et BindableProperty prennent en charge pour :
Ce qui donne les valeurs de propriétés par défaut
Stockage de leurs valeurs actuelles
Offrant des mécanismes de valider les valeurs de propriété
Maintenir la cohérence entre les propriétés associées dans une classe unique
Répondre aux modifications de propriétés
Déclencher des notifications lorsqu’une propriété est sur le point de changer ou a changé
Prise en charge de la liaison de données
Prise en charge des styles
Prise en charge des ressources dynamiques
Chaque fois qu’une propriété qui est associée à la modification d’une propriété pouvant être liée, BindableObject
se déclenche un PropertyChanged événement qui identifie la propriété qui a changé. Cet événement n’est pas
déclenché lorsque la propriété est définie sur la même valeur.
Certaines propriétés ne sont pas soutenues par les propriétés pouvant être liées et certaines classes de
Xamarin.Forms — comme Span — ne dérivent pas de BindableObject . Seule une classe qui dérive de
BindableObject peut prendre en charge les propriétés pouvant être liées, car BindableObject définit le SetValue
et GetValue méthodes.
Étant donné que Span ne dérive pas de BindableObject , aucune de ses propriétés — comme Text — sont
soutenus par une propriété pouvant être liée. C’est pourquoi un DynamicResource définition sur le Text propriété
du Span lève une exception dans le DynamicVsStatic exemple dans le chapitre précédent. Le
DynamicVsStaticCode exemple montre comment définir une ressource dynamique dans le code à l’aide du
SetDynamicResource méthode définie par Element . Le premier argument est un objet de type BindableProperty .
De même, le SetBinding méthode définie par BindableObject a un premier argument de type BindableProperty .
Définition des propriétés pouvant être liées

Vous pouvez définir vos propres propriétés pouvant être liées à l’aide de la méthode statique
BindableProperty.Create méthode pour créer un champ en lecture seule statique de type BindableProperty .
Cela est illustré dans le AltLabel classe dans le Xamarin.FormsBook.Toolkit bibliothèque. La classe dérivée de
Label et vous permet de spécifier une taille de police en points. Il est montré dans le PointSizedText exemple.
Quatre arguments de la BindableProperty.Create méthode sont requis :

propertyName : le nom de la propriété (le même que le nom de propriété CLR )
returnType : le type de la propriété CLR
declaringType : le type de la classe déclarant la propriété
defaultValue : la valeur de propriété par défaut
Étant donné que defaultValue est de type object , le compilateur doit être en mesure de déterminer le type de la
valeur par défaut. Par exemple, si le returnType est double , la defaultValue doit être défini sur quelque chose
comme 0.0 plutôt que simplement 0, ou l’incompatibilité de type déclenchera une exception lors de l’exécution.
Il est également très courant pour une propriété pouvant être liée à inclure :
propertyChanged : une méthode statique appelée lorsque la propriété change de valeur. Le premier argument
est l’instance de la classe dont la propriété a été modifiée.
Les autres arguments de BindableProperty.Create ne sont pas aussi courantes :
defaultBindingMode : utilisé dans le cadre de la liaison de données (comme indiqué dans chapitre 16. Liaison
de données)
validateValue : un rappel pour rechercher une valeur valide
propertyChanging : un rappel pour indiquer le moment où la propriété va être modifiée
coerceValue : un rappel pour forcer une valeur définie à une autre valeur
defaultValueCreate : un rappel pour créer une valeur par défaut qui ne peut pas être partagée entre des
instances de la classe (par exemple, une collection)
La propriété peut être liée en lecture seule
Une propriété peut être en lecture seule. Création d’une propriété en lecture seule, vous devez appeler la méthode
statique BindableProperty.CreateReadOnly pour définir un champ statique privé en lecture seule de type
BindablePropertyKey .
Ensuite, définissez la propriété CLR set accesseur d’en tant que private pour appeler un SetValue surcharge
avec le BindablePropertyKey objet. Ainsi, la propriété est définie en dehors de la classe.
Cela est illustré dans le CountedLabel classe utilisée dans le BaskervillesCount exemple.
Liens connexes
Propriétés pouvant être liées
Résumé du chapitre 12. Styles
Dans Xamarin.Forms, les styles permettent plusieurs vues partager une collection de paramètres de propriété. Cela
réduit le balisage et que vous permet de maintenir cohérentes thèmes visuels.
Les styles sont presque toujours définis et utilisés dans le balisage. Un objet de type Style est instancié dans un
dictionnaire de ressources et la Style propriété d’un élément visuel en utilisant un StaticResource ou
DynamicResource balisage extension.
Le Style de base
Un Style nécessite que son TargetType être définie sur le type de l’objet visuel, il s’applique à. Quand un Style
est instancié dans un dictionnaire de ressources (comme c’est commun) il requiert également un x:Key attribut.
Le Style a une propriété de type de contenu Setters , qui est une collection de Setter objets. Chaque Setter
associe un Property avec un Value .
Dans XAML les Property paramètre est le nom d’une propriété CLR (comme le Text propriété de Button ), mais
la propriété de style doit reposer sur une propriété pouvant être liée. En outre, la propriété doit être définie dans la
classe indiquée par le TargetType paramètre ou héritées par cette classe.
Vous pouvez spécifier le Value définition à l’aide de l’élément de propriété <Setter.Value> . Cela vous permet de
définir Value à un objet qui ne peuvent pas être exprimé dans une chaîne de texte, ou à un OnPlatform de l’objet,
ou à un objet instancié à l’aide de x:Arguments ou x:FactoryMethod . Le Value propriété peut également être
définie avec un StaticResource expression à un autre élément dans le dictionnaire.
Le BasicStyle programme illustre la syntaxe de base et indique comment référencer la Style avec un
StaticResource extension de balisage :
Le Style objet et tout objet créé dans le Style objet comme un Value paramètre sont partagés entre toutes les
vues faisant référence à cette Style . Le Style ne peut pas contenir tout ce qui ne peut pas être partagée, comme
un View dérivé.
Impossible de définir des gestionnaires d’événements dans un Style . Le GestureRecognizers propriété ne peut
pas être définie dans un Style , car il n’est pas associé à une propriété pouvant être liée.
Styles de code
Bien qu’il n’est pas courant, vous pouvez instancier et initialiser Style objets dans le code. Cela est illustré par la
BasicStyleCode exemple.
Héritage de style
Style a un BasedOn propriété que vous pouvez définir pour un StaticResource extension de balisage faisant
référence à un autre style. Ainsi, les styles hériter des styles précédentes et ajouter ou remplacer les paramètres de
propriété. Le StyleInheritance illustre cela.
Si Style2 repose sur Style1 , le TargetType de Style2 doit être le même que Style1 ou dérivé Style1 . Le
dictionnaire de ressources dans lequel Style1 est stocké doit être le même dictionnaire de ressources en tant que
Style2 ou un dictionnaire de ressources plus haut dans l’arborescence visuelle.
Styles implicites
Si un Style dans une ressource dictionnaire n’a pas un x:Key attribut de paramètre, il est affecté
automatiquement, une clé de dictionnaire et Style objet devient un style implicite. Une vue sans un Style
paramètre et dont le type correspond à la TargetType exactement trouverez ce style, comme le ImplicitStyle
illustre.
Un style implicite peut dériver un Style avec un x:Key paramètre mais pas l’inverse. Vous ne pouvez pas
référencer explicitement un style implicite.
Vous pouvez implémenter les trois types de hiérarchie avec des styles et BasedOn :
À partir de styles définis sur le Application et Page jusqu'à styles définis sur les dispositions plus bas dans
l’arborescence visuelle.
À partir de styles définis pour les classes de base telles que VisualElement et View pour les styles définis pour
les classes spécifiques.
À partir de styles avec des clés de dictionnaire explicite pour les styles implicites.
Ces hiérarchies sont illustrées dans le StyleHierarchy exemple.
Styles dynamiques
Un style dans un dictionnaire de ressources peut être référencé par DynamicResource plutôt que StaticResource .
Cela rend le style un style dynamique. Si ce style est remplacé dans le dictionnaire de ressources par un autre style
avec la même clé, les vues référençant ce style avec DynamicResource change automatiquement. En outre, l’absence
d’une entrée de dictionnaire avec la clé spécifiée entraîne StaticResource pour lever une exception, mais pas
DynamicResource .
Vous pouvez utiliser cette technique pour modifier dynamiquement un style ou thèmes comme le DynamicStyles
montre des exemples.
Toutefois, vous ne pouvez pas définir le BasedOn propriété à un DynamicResource extension de composition, car
BasedOn n’est pas sauvegardé par une propriété pouvant être liée. Pour dériver un style dynamiquement, ne
définissez pas BasedOn . Au lieu de cela, définissez la BaseResourceKey propriété à la clé du style que vous souhaitez
dériver à partir du dictionnaire. Le DynamicStylesInheritance exemple illustre cette technique.
Styles d’appareils
Le Device.Styles classe imbriquée définit 12 champs en lecture seule statiques pour les six styles avec une
TargetType de Label que vous pouvez utiliser pour les types courants d’utilisations de texte.
Six de ces champs sont de type Style que vous pouvez définir directement à un Style propriété dans le code :
BodyStyle
TitleStyle
SubtitleStyle
CaptionStyle
ListItemTextStyle
ListItemDetailTextStyle
Les six autres champs sont de type string et est utilisable comme clés de dictionnaire pour les styles dynamiques :
BodyStyleKey égal à « BodyStyle »
TitleStyleKey égal à « TitleStyle »
SubtitleStyleKey égal à « SubtitleStyle »
CaptionStyleKey égal à « CaptionStyle »
ListItemTextStyleKey égal à « ListItemTextStyle »
ListItemDetailTextStyleKey égal à « ListItemDetailTextStyle »
Ces styles sont illustrées par la DeviceStylesList exemple.
Liens connexes
Styles
Résumé du chapitre 13. Bitmaps
NOTE
Xamarin.Forms Image élément affiche une bitmap. Toutes les plateformes de Xamarin.Forms prend en charge les
formats de fichier JPEG, PNG, GIF et BMP.
Bitmaps dans Xamarin.Forms proviennent de quatre endroits :
Sur le web tel que spécifié par une URL
Incorporé comme ressource dans la bibliothèque partagée
Incorporé comme ressource dans les projets d’application de plateforme
À partir de n’importe quel endroit qui peuvent être référencées par un .NET Stream de l’objet, y compris
MemoryStream
Ressources bitmap dans la bibliothèque partagée sont indépendant de la plateforme, tandis que les ressources de
bitmap dans les projets de plateforme sont spécifiques à la plateforme.
NOTE
Le texte du livre fait référence aux bibliothèques de classes portables, qui ont été remplacés par des bibliothèques .NET
Standard. Exemples de code à partir de l’ouvrage a été converti pour utiliser les bibliothèques .NET standard.
La bitmap est spécifiée en définissant le Source propriété du Image à un objet de type ImageSource , une classe
abstraite avec trois dérivés :
UriImageSource Pour accéder à une image bitmap sur le web basé sur un Uri objet défini sa Uri propriété
FileImageSource Pour accéder à une image bitmap stockée dans un projet d’application de plateforme basée
sur un chemin d’accès de dossier et le fichier défini sur sa File propriété
StreamImageSource pour charger une bitmap à l’aide de .NET Stream objet spécifié en retournant un Stream à
partir d’un Func définie sur sa Stream propriété
Vous pouvez également (et plus fréquemment), vous pouvez utiliser les méthodes statiques suivantes de la
ImageSource de classe, qui retournent toutes ImageSource objets :
ImageSource.FromUri Pour accéder à une image bitmap sur le web basé sur un Uri objet
ImageSource.FromResource Pour accéder à une image bitmap stockée en tant que ressource incorporée dans
l’application de bibliothèque de classes portable ; ImageSource.FromResource ou ImageSource.FromResource pour
accéder à une image bitmap dans un autre assembly source
ImageSource.FromFile Pour accéder à une image bitmap à partir d’un projet d’application de plateforme
ImageSource.FromStream pour charger une image bitmap selon un Stream objet
Il n’existe aucun équivalent de la classe de la Image.FromResource méthodes. Le UriImageSource classe est utile si
vous avez besoin de contrôler la mise en cache. Le FileImageSource classe est utile dans XAML.
StreamImageSource est utile pour le chargement asynchrone de Stream objets, tandis que ImageSource.FromStream
est synchrone.
Bitmaps indépendantes de la plate-forme

Le WebBitmapCode projet charge une image bitmap sur le web à l’aide ImageSource.FromUri . Le Image élément
est défini sur le Content propriété de la ContentPage , donc il est limité à la taille de la page. Quelle que soit la
taille de la bitmap, une contrainte Image élément est étiré pour la taille de son conteneur et le bitmap s’affiche
dans sa taille maximale dans le Image élément tout en conservant les proportions de la bitmap. Zones de la
Image au-delà de l’image bitmap peut être en couleur avec BackgroundColor .
Le WebBitmapXaml exemple est similaire, mais se contente de définir le Source URL à la propriété. La
conversion est contrôlée par le ImageSourceConverter classe.
Ajuster et remplissage
Vous pouvez contrôler la manière dont l’image bitmap est étirée en définissant le Aspect propriété de la Image à
un des membres suivants de la Aspect énumération :
AspectFit : respecte les proportions (valeur par défaut)
Fill : remplit la zone, ne respecte pas les proportions
AspectFill : remplit la zone mais respecte les proportions, faire partie de l’image bitmap de rognage
Ressources incorporées
Vous pouvez ajouter un fichier bitmap pour une bibliothèque de classes portable, ou dans un dossier dans la
bibliothèque PCL. Attribuez-lui un Action de génération de EmbeddedResource. Le ResourceBitmapCode
exemple montre comment utiliser ImageSource.FromResource pour charger le fichier. Le nom de ressource passé à
la méthode se compose du nom d’assembly, suivi d’un point, suivie du nom de dossier facultatif et un point, suivi
par le nom de fichier.
Les jeux de programme le VerticalOptions et HorizontalOptions propriétés de la Image à LayoutOptions.Center ,
ce qui rend le Image élément sans contrainte. Le Image et l’image bitmap ont la même taille :
Sur iOS et Android, le Image est la taille en pixels de la bitmap. Il existe une correspondance biunivoque entre
les pixels du bitmap et de pixels de l’écran.
Sur la plateforme Windows universelle, le Image est la taille en pixels de l’image bitmap en unités
indépendantes du périphérique. Sur la plupart des périphériques, chaque pixel de bitmap occupe plusieurs
pixels de l’écran.
Le StackedBitmap exemple met un Image dans un vertical StackLayout dans XAML. Une extension de balisage
nommée ImageResourceExtension permet de référencer la ressource incorporée dans XAML. Cette classe charge
uniquement des ressources à partir de l’assembly dans lequel il se trouve, donc il ne peut pas être placé dans une
bibliothèque.
Plus d’informations sur le dimensionnement
Il est souvent souhaitable de bitmaps de taille cohérente parmi toutes les plateformes. Expérimenter
StackedBitmap, vous pouvez définir un WidthRequest sur le Image élément dans un vertical StackLayout pour
que la taille cohérente entre les plateformes, mais vous pouvez réduire uniquement la taille à l’aide de cette
technique.
Vous pouvez également définir le HeightRequest pour rendre une image de tailles cohérente sur les plateformes,
mais la contrainte largeur de l’image bitmap limitera la polyvalence de cette technique. Pour une image dans un
vertical StackLayout , HeightRequest doit être évitée.
La meilleure approche consiste à commencer par une image bitmap plus large que la largeur de téléphone en
unités indépendantes du périphérique et définissez WidthRequest largeur souhaitée en unités indépendantes du
périphérique. Cela est illustré dans le DeviceIndBitmapSize exemple.
Le MadTeaParty affiche le chapitre 7, de Lewis Carroll aventures d’A lice au pays des merveilles avec les
illustrations d’origine par John Tenniel :
Navigation et en attente
Le ImageBrowser exemple permet à l’utilisateur de parcourir les images stockées sur le site web de Xamarin. Il
utilise le .NET WebRequest classe pour télécharger un fichier JSON avec la liste des images bitmap.
NOTE
Xamarin.Forms les programmes doivent utiliser HttpClient plutôt que WebRequest pour accéder aux fichiers via internet.
Le programme utilise une ActivityIndicator pour indiquer que quelque chose se passe. Comme chaque bitmap
est le chargement, en lecture seule IsLoading propriété du Image est true . Le IsLoading propriété repose sur
une propriété pouvant être liée, par conséquent, un PropertyChanged événement est déclenché lorsque cette
propriété est modifiée. Le programme attache un gestionnaire à cet événement et utilise le paramètre actuel de
IsLoaded pour définir le IsRunning propriété de la ActivityIndicator .
Diffusion en continu de bitmaps

Le ImageSource.FromStreamméthode crée un ImageSource basé sur .NET Stream . La méthode doit être passée un
Func objet retourne un Stream objet.
L’accès à des flux de données
Le BitmapStreams exemple montre comment utiliser le ImaageSource.FromStream méthode pour charger une
image bitmap stockée en tant que ressource incorporée et pour charger une image bitmap sur le web.
Générer des images bitmap au moment de l’exécution
Toutes les plateformes de Xamarin.Forms prend en charge le format de fichier non compressé BMP, qui est facile
à construire dans le code, puis stockez dans un MemoryStream . Cette technique permet la création de façon
algorithmique des bitmaps lors de l’exécution, tel qu’implémenté dans le BmpMaker classe dans le
Xamrin.FormsBook.Toolkit bibliothèque.
« Faire il vous-même le » DiyGradientBitmap exemple illustre l’utilisation de BmpMaker pour créer une image
bitmap avec une image de dégradé.
Bitmaps spécifiques à la plateforme
Toutes les plateformes de Xamarin.Forms permettent de stocker des images bitmap dans les assemblys
d’application de plateforme. Lorsque extrait par une application Xamarin.Forms, ces bitmaps de plateforme sont
de type FileImageSource . Vous les utilisez pour :
le Icon propriété de MenuItem
le Icon propriété de ToolbarItem
le Image propriété de Button
Les assemblys de plateforme contiennent déjà des bitmaps pour les icônes et écrans de démarrage :
Dans le projet iOS, dans le ressources dossier
Dans le projet Android, dans les sous-dossiers de le ressources dossier
Dans les projets Windows, dans le actifs dossier (bien que les plateformes Windows ne limitent pas les
bitmaps à ce dossier)
Le PlatformBitmaps exemple utilise du code pour afficher une icône dans les projets d’application de plateforme.
Résolutions de bitmap
Toutes les plateformes permettent de stocker plusieurs versions des images bitmap pour les résolutions de
périphérique différent. Lors de l’exécution, la version correcte est chargée en fonction de la résolution de l’appareil
de l’écran.
Sur iOS, ces bitmaps sont différenciées par le suffixe du nom de fichier :
Pas de suffixe pour les appareils de 160 DPI (1 pixel à l’unité indépendante du périphérique)
'@2x' suffixe pour les appareils de 320 DPI (2 pixels à le DIU )
'@3x' suffixe pour les appareils de 480 PPP (de 3 pixels pour le DIU )
Une image bitmap destinée à être affiché sous forme d’un pouce carré existerait dans trois versions :
MyImage.jpg à 160 pixels carrés
MyImage@2x.jpg à 320 pixels carrés
MyImage@3x.jpg à 480 pixels carrés
Le programme fait référence à cette image bitmap en tant que MyImage.jpg, mais la version correcte est
récupérée pendant l’exécution en fonction de la résolution de l’écran. Quand elles sont libres, l’image bitmap
restitue toujours à 160 unités indépendantes du périphérique.
Pour Android, les bitmaps sont stockés dans différents sous-dossiers situés de le ressources dossier :
drawable-ldpi (faible PPP ) pour les appareils de 120 DPI (0,75 pixels pour le DIU )
drawable-mdpi (moyenne) pour les appareils de 160 DPI (1 pixel à la DIU )
drawable-hdpi (élevé) pour les appareils de 240 DPI (1,5 pixels pour le DIU )
drawable-xhdpi (très élevée) pour les appareils de 320 DPI (2 pixels à le DIU )
drawable-xxhdpi (très très élevée) pour les appareils de 480 PPP (de 3 pixels pour le DIU )
drawable-xxxhdpi (trois points forts supplémentaires) pour les appareils de 640 PPP (4 pixels pour le DIU )
Pour une image bitmap destinée à être rendu à un pouce carré, les différentes versions de l’image bitmap auront
le même nom mais une taille différente et être stockées dans ces dossiers :
drawable-ldpi/MyImage.jpg à 120 pixels carrés
drawable-mdpi/MyImage.jpg à 160 pixels carrés
drawable-hdpi/MyImage.jpg à 240 pixels carrés
drawable-xhdpi/MyImage.jpg à 320 pixels carrés
drawable-xxhdpi/MyImage.jpg à 480 pixels carrés
drawable-xxxhdpi/MyImage.jpg à 640 pixels carrés
La bitmap est toujours le rendu à 160 unités indépendantes du périphérique. (Le modèle de solution
Xamarin.Forms standard inclut uniquement le hdpi, xhdpi et les dossiers xxhdpi.)
Le projet UWP prend en charge un schéma d’affectation de noms bitmap comprenant un facteur d’échelle en
pixels indépendants du périphérique unitaire sous forme de pourcentage, par exemple :
MyImage.scale-200.jpg à 320 pixels carrés
Seuls certains pourcentages sont valides. Les exemples de programmes de ce livre d’incluent uniquement les
images avec mise à l’échelle-200 suffixes, mais les modèles de solution Xamarin.Forms actuels incluent mise à
l’échelle-100, mise à l’échelle-125, mise à l’échelle-150, et mise à l’échelle-400.
Lors de l’ajout de bitmaps pour les projets de plateforme, le Action de génération doit être :
iOS : BundleResource
Android : AndroidResource
UWP : contenu
Le ImageTap exemple crée deux objets de type bouton consistant en Image éléments avec un
TapGestureRecognizer installé. Il est prévu que les objets soient carré d’un pouce. Le Source propriété du Image
est définie à l’aide de OnPlatform et On objets à référencer les noms de fichiers potentiellement différents sur les
plateformes. Les images bitmap incluent les numéros d’indiquant leur taille en pixels, pour voir quelle bitmap de
taille est récupéré et affiché.
Barres d’outils et leurs icônes
Une des principales utilisations des bitmaps de spécifique à la plateforme est la barre d’outils de Xamarin.Forms,
qui est construite en ajoutant ToolbarItem des objets sur le ToolbarItems collection définie par Page .
ToobarItem dérive de MenuItem dont elle hérite des propriétés.
Le plus important ToolbarItem sont des propriétés :

Text pour le texte qui peut s’afficher en fonction de la plateforme et Order
Icon de type FileImageSource pour l’image qui peut s’afficher en fonction de la plateforme et Order
Order de type ToolbarItemOrder , une énumération avec trois membres, Default , Primary , et Secondary .
Le nombre de Primary éléments doivent être limités à trois ou quatre. Vous devez inclure un Text définissant
pour tous les éléments. Pour la plupart des plateformes, uniquement le Primary éléments nécessitent une Icon
mais nécessite Windows 8.1 une Icon pour tous les éléments. Les icônes doivent être des unités indépendantes
du périphérique 32 carrées. Le FileImageSource type indique qu’ils sont spécifiques à la plateforme.
Le ToolbarItemse déclenche un Clicked événement lorsque l’utilisateur appuie dessus, comme un Button .
ToolbarItem prend également en charge Command et CommandParameter propriétés souvent utilisées dans le cadre
de MVVM. (Consultez chapitre 18, MVVM ).
IOS et Android exigent qu’une page qui affiche une barre d’outils un NavigationPage ou une page faite par un
NavigationPage . Le ToolbarDemo jeux du programme le MainPage propriété de son App classe à la
NavigationPage constructeur avec un ContentPage argument et montre le Gestionnaire d’événements et de la
construction d’une barre d’outils.
Images de bouton
Vous pouvez également utiliser des images bitmap spécifiques à la plateforme pour définir le Image propriété de
Button à une image bitmap du carré 32 unités indépendantes du périphérique, tel qu’indiqué par le
ButtonImage exemple.
NOTE
L’utilisation d’images sur les boutons a été améliorée. Consultez à l’aide de bitmaps avec des boutons.
Liens connexes
Chapitre 13, texte intégral (PDF )
Utilisation d’images
À l’aide de bitmaps avec des boutons
Résumé du chapitre 14. Disposition absolue
Comme StackLayout , AbsoluteLayout dérive Layout<View> et hérite d’un Children propriété. AbsoluteLayout
implémente un système de disposition qui exige que le programmeur spécifier les positions de ses enfants et,
éventuellement, de leur taille. La position est spécifiée par le coin supérieur gauche de l’enfant par rapport à l’angle
supérieur gauche de la AbsoluteLayout en unités indépendantes du périphérique. AbsoluteLayout implémente
également une fonctionnalité de dimensionnement et de positionnement proportionnel.
AbsoluteLayout doit être considérée comme un système de disposition de spécial à être utilisé uniquement quand
le programmeur peut imposer une taille sur les enfants (par exemple, BoxView éléments) ou lorsque la taille de
l’élément n’affecte pas le positionnement d’autres enfants. Le HorizontalOptions et VerticalOptions propriétés
n’ont aucun effet sur les enfants d’un AbsoluteLayout .
Ce chapitre présente également la fonctionnalité importante de attaché propriétés pouvant être liées qui autorisent
les propriétés définies dans une classe (dans ce cas AbsoluteLayout ) à joindre à une autre classe (un enfant de le
AbsoluteLayout ).
DispositionAbsolue dans le code

Vous pouvez ajouter un enfant à la Children collection d’un AbsoluteLayout à l’aide de la norme Add (méthode),
mais AbsoluteLayout fournit également une étendue Add méthode qui vous permet de spécifier un Rectangle .
Un autre Add méthode nécessite uniquement un Point , auquel cas l’enfant n’est pas limitée et se redimensionne.
Vous pouvez créer un Rectangle valeur avec un constructeur qui requiert quatre valeurs — les deux premiers
indiquant la position du coin supérieur gauche de l’enfant par rapport à son parent et les deux indiquant le taille de
l’enfant. Vous pouvez également utiliser un constructeur qui nécessite un Point et un Size valeur.
Ces Add méthodes sont illustrées dans AbsoluteDemo, les positions BoxView à l’aide des éléments Rectangle
valeurs et un Label élément à l’aide de simplement un Point valeur.
Le ChessboardFixed exemple utilise 32 BoxView éléments pour créer le modèle échiquier. Le programme donne
le BoxView taille éléments codés en dur du carré de 35 unités. Le AbsoluteLayout a son HorizontalOptions et
VerticalOptions définie sur LayoutOptions.Center , ce qui conduit le AbsoluteLayout pour avoir une taille totale du
carré de 280 unités.
Joint des propriétés pouvant être liées

Il est également possible de définir la position et, éventuellement, la taille d’un enfant d’un AbsoluteLayout après
qu’il a été ajouté à la Children collection à l’aide de la méthode statique AbsoluteLayout.SetLayoutBounds . Le
premier argument est l’enfant ; le second est un Rectangle objet. Vous pouvez spécifier que l’enfant se
redimensionne horizontalement et verticalement en définissant les valeurs de largeur et hauteur le
AbsoluteLayout.AutoSize constante.
Le ChessboardDynamic exemple met le AbsoluteLayout dans un ContentView avec un SizeChanged gestionnaire

à appeler AbsoluteLayout.SetLayoutBounds sur tous les enfants pour les rendre aussi grand que possible.
La propriété jointe peut être liée qui AbsoluteLayout définit le champ statique en lecture seule de type n’est
BindableProperty nommé AbsoluteLayout.LayoutBoundsProperty . La méthode statique
AbsoluteLayout.SetLayoutBounds méthode est implémentée en appelant SetValue sur l’enfant ayant le
AbsoluteLayout.LayoutBoundsProperty . L’enfant contienne un dictionnaire dans lequel la propriété jointe peut être
liée et sa valeur sont stockées. Pendant la disposition, le AbsoluteLayout pouvez obtenir cette valeur en appelant
AbsoluteLayout.GetLayoutBounds , qui est implémentée avec un GetValue appeler.
Redimensionnement proportionnel et positionnement

AbsoluteLayout implémente un redimensionnement proportionnel et la fonctionnalité de positionnement. La
classe définit une deuxième propriété jointe peut être liée, LayoutFlagsProperty , avec les méthodes statiques
associées AbsoluteLayout.SetLayoutFlags et AbsoluteLayout.GetLayoutFlags .
L’argument AbsoluteLayout.SetLayoutFlags et la valeur de retour de AbsoluteLayout.GetLayoutFlags est une valeur
de type AbsoluteLayoutFlags , une énumération avec les membres suivants :
None (égal à 0)
XProportional (1 )
YProportional (2 )
PositionProportional (3 )
WidthProportional (4 )
HeightProportional (8 )
SizeProportional (12 )
All (\xFFFFFFFF )
Vous pouvez combiner ces éléments avec le langage c# opérateur de bits OR.
Avec ces indicateurs définis, certaines propriétés de la Rectangle structure de limites de mise en page utilisée pour
positionner et dimensionner l’enfant sont interprétés proportionnellement.
Lorsque le WidthProportional indicateur est défini, un Width valeur 1 indique que l’enfant est la même largeur
que le AbsoluteLayout . Une approche similaire est utilisée pour la hauteur.
Le positionnement proportionnelle prend la taille en compte. Lorsque le XProportional indicateur est défini, le X
propriété de la Rectangle limites de disposition est proportionnelle. Une valeur de 0 signifie que l’enfant du bord
gauche est positionnée sur le bord gauche de la AbsoluteLayout , mais une position de 1 signifie que le bord droit
de l’enfant est positionné sur le bord droit de la AbsoluteLayout , pas au-delà du bord droit de la AbsoluteLayout
comme vous le feriez notre t. Un X l’enfant horizontalement dans les centres de propriété de 0,5 le
AbsoluteLayout .
Le ChessboardProportional exemple illustre l’utilisation de redimensionnement proportionnel et de

positionnement.
Utilisation des coordonnées proportionnelles

Parfois, il est plus simple de considérer un positionnement proportionnelle différemment de la façon dont il est
implémenté dans le AbsoluteLayout . Vous préférerez peut-être utiliser des coordonnées proportionnelles où un X
propriété 1 positionne bord gauche de l’enfant (plutôt que le bord droit) sur le bord droit de la AbsoluteLayout .
Ce schéma de positionnement alternatif peut être appelé « coordonnées fractionnaires enfants. » Vous pouvez
convertir à partir des coordonnées fractionnaires enfants pour les limites de disposition requis pour
AbsoluteLayout à l’aide des formules suivantes :
layoutBounds.X = (fractionalChildCoordinate.X / (1 - layoutBounds.Width))

layoutBounds.Y = (fractionalChildCoordinate.Y / (1 - layoutBounds.Height))
Le ProportionalCoordinateCalc illustre cela.
DispositionAbsolue et XAML
Vous pouvez utiliser un AbsoluteLayout dans XAML et définissez les propriétés de peut être liées attachées sur les
enfants d’un AbsoluteLayout à l’aide de valeurs d’attribut de AbsoluteLayout.LayoutBounds et
AbsoluteLayout.LayoutFlags . Cela est illustré dans le AbsoluteXamlDemo et ChessboardXaml exemples. Le
programme de ce dernier contient 32 BoxView éléments mais utilise implicite Style qui inclut le
AbsoluteLayout.LayoutFlags propriété conserver le balisage jusqu’au minimum.
Est un attribut dans XAML se compose d’un nom de classe, un point et un nom de propriété toujours une propriété
jointe peut être liée.
Superpositions
Vous pouvez utiliser AbsoluteLayout pour construire un superposition, qui couvre la page avec d’autres contrôles,
peut-être pour protéger l’utilisateur d’interagir avec les contrôles normales sur la page.
Le SimpleOverlay exemple illustre cette technique et montre la ProgressBar , qui affiche l’étendue à laquelle un
programme a terminé une tâche.
Un peu de fantaisie
Le DotMatrixClock exemple affiche l’heure actuelle avec un affichage simulé matricielle 5 / 7. Chaque point est
un BoxView (il y 228 d'entre eux) dimensionné et positionné sur le AbsoluteLayout .
Le BouncingText programme anime deux Label objets à rebondit horizontalement et verticalement sur l’écran.
Liens connexes
AbsoluteLayout
Propriétés jointes
Résumé du chapitre 15. L’interface interactive
Ce chapitre explore huit View dérivés qui permettent d’interagir avec l’utilisateur.
Vue d’ensemble de la vue

Xamarin.Forms contient 20 instanciables classes dérivées de View mais pas Layout . Six d'entre eux ont été traités
dans les chapitres précédents :
Label : Chapitre 2. Anatomie d’une application
BoxView : Chapitre 3. Défilement de la pile
Button : Chapitre 6. Clics de bouton
Image : Chapitre 13. Bitmaps
ActivityIndicator : Chapitre 13. Bitmaps
ProgressBar : Chapitre 14. DispositionAbsolue
Les huit vues dans ce chapitre autoriser efficacement l’utilisateur d’interagir avec les types de données de base
.NET :
TYPE DE DONNÉES AFFICHAGES
Double Slider , Stepper
Boolean Switch
String Entry , Editor , SearchBar
DateTime DatePicker , TimePicker
Vous pouvez considérer de ces vues en tant que représentations interactives visuelles des types de données sous-
jacente. Ce concept est expliquée plus dans le chapitre suivant, chapitre 16. Liaison de données.
Les vues de six restants sont traités dans les chapitres suivants :
WebView : Chapitre 16. Liaison de données
Picker : Chapitre 19. Vues de collection
ListView : Chapitre 19. Vues de collection
TableView : Chapitre 19. Vues de collection
Map : Chapitre 28. Emplacement et mappages
OpenGLView : Non traitée dans ce livre (et aucune prise en charge pour les plateformes Windows)
Curseur et l’exécution pas à pas

Les deux Slider et Stepper autoriser l’utilisateur de choisir une valeur numérique à partir d’une plage. Le
Slider est une plage continue, tandis que le Stepper implique des valeurs discrètes.
Principes de base de curseur
Le Slider est une barre représentant une plage de valeurs à partir d’un minimum de gauche à un maximum sur la
droite horizontale. Il définit trois propriétés publiques :
Value de type double , valeur 0 par défaut
Minimum de type double , valeur 0 par défaut
Maximum de type double , la valeur 1 par défaut
Les propriétés pouvant être liées qui assortir ces propriétés de vous assurer qu’elles sont cohérentes :
Pour toutes les trois propriétés, le coerceValue méthode spécifiée pour la propriété pouvant être liée garantit
que Value entre Minimum et Maximum .
Le validateValue méthode sur MinimumProperty retourne false si Minimum est définie sur une valeur
supérieure ou égale à Maximum et il est similaire pour MaximumProperty . Retour false à partir de la
validateValue causes de la méthode un ArgumentException à signaler.
Slider se déclenche le ValueChanged événement avec un ValueChangedEventArgs argument lorsque la Value

propriété change, par programme ou lorsque l’utilisateur manipule le Slider .
Le SliderDemo exemple illustre l’utilisation simple du Slider .
Pièges courants
À la fois dans le code et XAML, le Minimum et Maximum propriétés sont définies dans l’ordre que vous spécifiez.
Veillez à initialiser ces propriétés afin que Maximum est toujours supérieure à Minimum . Dans le cas contraire, une
exception est levée.
L’initialisation de la Slider propriétés peuvent entraîner la Value propriété à modifier et le ValueChanged
événement à déclencher. Vous devez vous assurer que le Slider Gestionnaire d’événements n’accède pas à des
vues qui n’ont pas encore été créés pendant l’initialisation de la page.
Le ValueChanged événement ne se déclenche pendant Slider l’initialisation, sauf si le Value les modifications de
propriété. Vous pouvez appeler la ValueChanged gestionnaire directement à partir du code.
Sélection de couleur de curseur
Le RgbSliders programme contienne trois Slider les éléments qui vous permettent de sélectionner une couleur
de manière interactive en spécifiant ses valeurs RVB :
Le TextFade exemple utilise deux Slider éléments à déplacer deux Label éléments entre un AbsoluteLayout et
fondu dans l’autre.
La différence de l’exécution pas à pas
Le Stepper définit les propriétés et les événements en tant que même Slider mais le Maximum propriété est
initialisée à 100 et Stepper définit une propriété quatrième :
Increment de type double , initialisé à 1
Visuellement, la Stepper se compose de deux boutons nommés – et +. En appuyant sur – diminue Value par
Increment à un minimum de Minimum . En appuyant sur + augmente Value par Increment à un maximum de
Maximum .
Cela est illustré par la StepperDemo exemple.
Commutateur et la case à cocher

Le Switch permet à l’utilisateur de spécifier une valeur booléenne.
Principes fondamentaux de commutateur
Visuellement, le Switch se compose d’un bouton bascule qui peut être désactivée puis activé. La classe définit une
propriété :
IsToggled de type bool
Switch définit un événement :

Toggled accompagné d’un ToggledEventArgs objet, déclenché lorsque le IsToggled les modifications de
propriété.
Le SwitchDemo programme illustre le Switch .
Une case à cocher traditionnel
Certains développeurs peuvent préférer une plus traditionnelle CheckBox à la Switch . Le
Xamarin.FormsBook.Toolkit bibliothèque contient un CheckBox classe qui dérive de ContentView . CheckBox est
implémentée par le CheckBox.xaml et CheckBox.xaml.cs fichiers. CheckBox définit trois propriétés ( Text , FontSize
, et IsChecked ) et un CheckedChanged événement.
Le CheckBoxDemo illustre cela CheckBox .
Saisie de texte
Xamarin.Forms définit trois vues qui permettent l’utilisateur d’entrer et de modifier le texte :
Entry pour une seule ligne de texte
Editor plusieurs lignes de texte
SearchBar pour une seule ligne de texte à des fins de recherche.
Entry et Editor dérivent InputView , qui dérive à son View . SearchBar dérive directement de View .
Clavier et le focus
Sur les téléphones et tablettes sans claviers physiques, le Entry , Editor , et SearchBar tous les éléments de
provoquent un clavier virtuel à la fenêtre contextuelle. La présence de ce clavier sur l’écran concerne le focus
d’entrée. Une vue doit avoir à la fois son IsVisible et IsEnabled propriétés définies sur true pour obtenir le
focus d’entrée.
Deux méthodes, une propriété en lecture seule et deux événements sont impliqués avec focus d’entrée. Elles sont
définies par VisualElement :
Le Focus méthode tente de définir le focus d’entrée à un élément et retourne true en cas de réussite
Le Unfocus méthode supprime le focus d’entrée à partir d’un élément
Le IsFocused propriété en lecture seule indique si l’élément a le focus d’entrée
Le Focused événements indique quand un élément obtient le focus d’entrée
Le Unfocused événements indique quand un élément perd le focus d’entrée
Choix du clavier
Le InputView classe à partir de laquelle Entry et Editor dériver ne définit qu’une seule propriété :
Keyboard de type Keyboard
Indique le type de clavier qui s’affiche. Certains claviers sont optimisés pour des URI ou des nombres.
Le Keyboard classe permet la définition d’un clavier avec un ligne statique Keyboard.Create méthode avec un
argument de type KeyboardFlags , une énumération avec les indicateurs de bits suivants :
None la valeur 0
CapitalizeSentence la valeur 1
Spellcheck la valeur est 2
Suggestions la valeur 4
All la valeur \xFFFFFFFF
Lors de l’utilisation de la propriété multiline Editor quand au moins un paragraphe de texte est attendu, l’appel
Keyboard.Create constitue une bonne approche à la sélection d’un clavier. Pour la ligne unique Entry , les
propriétés statiques suivantes en lecture seule de Keyboard sont utiles :
Default
Text
Chat
Url
Email
Telephone
Numeric pour les nombres positifs, avec ou sans virgule décimale.
Le KeyboardTypeConverter permet de spécifier ces propriétés dans XAML, comme illustré par la EntryKeyboards
programme.
Événements et propriétés de l’entrée
La ligne unique Entry définit les propriétés suivantes :
Text de type string , le texte qui apparaît dans le Entry
TextColor de type Color
FontFamily de type string
FontSize de type double
FontAttributes de type FontAttributes
IsPassword de type bool , ce qui entraîne des caractères à masquer
Placeholder de type string , pour les couleur atténuées texte qui apparaît dans le Entry avant que quoi que
ce soit est typé
PlaceholderColor de type Color
Le Entry définit également deux événements :

TextChanged avec un TextChangedEventArgs objet, déclenché chaque fois que le Text les modifications de
propriété
Completed , déclenché lorsque l’utilisateur est terminée et que le clavier est fermé. L’utilisateur indique
l’achèvement de manière spécifique à la plateforme
Le QuadraticEquations illustre ces deux événements.
La différence de l’éditeur
La propriété multiline Editor définit les mêmes Text et Font propriétés comme Entry mais pas les autres
propriétés. Editor définit également les deux mêmes propriétés que Entry .
JustNotes est un programme de prise de notes de forme libre qui enregistre et restaure le contenu de la Editor .
Le SearchBar
Le SearchBar ne dérive pas de InputView , donc il n’a pas un Keyboard propriété. Mais il dispose de tous les Text ,
Font , et Placeholder propriétés qui Entry définit. En outre, SearchBar définit trois propriétés supplémentaires :
CancelButtonColor de type Color

SearchCommand de type ICommand pour une utilisation avec les liaisons de données et MVVM
SearchCommandParameter de type Object , pour une utilisation avec SearchCommand
La plateforme spécifique Annuler bouton efface le texte. Le SearchBar comporte également un bouton de
recherche spécifiques à la plateforme. En appuyant sur un de ces boutons déclenche un des deux événements qui
SearchBar définit :
TextChanged accompagné d’un TextChangedEventArgs objet

SearchButtonPressed
Le SearchBarDemo exemple illustre la SearchBar .
Sélection de date et d’heure

Le DatePicker et TimePicker vues instaurez des contrôles spécifiques à une plateforme permettant aux utilisateurs
de spécifier une date ou heure.
DatePicker
DatePicker définit les quatre propriétés :
MinimumDate de type DateTime , initialisé pour le 1er janvier 1900.
MaximumDate de type DateTime , initialisé pour le 31 décembre 2100
Date de type DateTime , initialisée à DateTime.Today
Format de type string , .NET mise en forme de chaîne initialisé à « d », le modèle de date courte, ce qui
entraîne un affichage de la date comme « 7/20/1969 » dans le fuseau horaire.
Vous pouvez définir le DateTime propriétés dans XAML en exprimant les propriétés en tant qu’éléments de
propriété et à l’aide de la culture dite indifférente courte-date de format (« 20/7/1969 »).
Le DaysBetweenDates exemple calcule le nombre de jours entre deux dates sélectionnées par l’utilisateur.
Le TimePicker (ou s’agit-il d’un TimeSpanPicker ?)
TimePicker définit deux propriétés et aucun événement :
Time est de type TimeSpan plutôt que DateTime , indiquant le temps écoulé depuis minuit
Format de type string , la mise en forme de chaîne initialisée à « t », le modèle d’heure courte, ce qui entraîne
un affichage de l’heure comme « 1:45 PM » dans le fuseau horaire de .NET.
Le SetTimer programme montre comment utiliser le TimePicker pour spécifier une heure d’une minuterie. Le
programme ne fonctionne que si vous le conservez au premier plan.
SetTimer montre également comment utiliser le DisplayAlert méthode de Page pour afficher un message
d’alerte.
Liens connexes
Slider
Entrée
Éditeur
DatePicker
Résumé du chapitre 16. Liaison de données
NOTE
Les programmeurs souvent se retrouvent écrire des gestionnaires d’événements qui détectent lorsqu’une
propriété d’un objet a changé et l’utilisent pour modifier la valeur d’une propriété dans un autre objet. Ce
processus peut être automatisé avec la technique de liaison de données. Liaisons de données sont généralement
définis dans XAML et font partie de la définition de l’interface utilisateur.
Très souvent, ces liaisons de données connecter des objets d’interface utilisateur aux données sous-jacentes. Il
s’agit d’une technique qui est expliquée plus en chapitre 18. MVVM. Toutefois, les liaisons de données peuvent
également connecter deux ou plusieurs éléments d’interface utilisateur. La plupart des premiers exemples de
liaison de données dans ce chapitre présentent cette technique.
Principes fondamentaux de liaison

Plusieurs propriétés, méthodes et classes sont impliqués dans la liaison de données :
Le Binding dérive de la classe BindingBase et encapsule de nombreuses caractéristiques d’une liaison de
données
Le BindingContext propriété est définie par le BindableObject classe
Le SetBinding méthode est également définie par le BindableObject classe
Le BindableObjectExtensions classe définit trois supplémentaires SetBinding méthodes
Les deux classes suivantes prennent en charge les extensions de balisage XAML pour les liaisons :
BindingExtension prend en charge le Binding extension de balisage
ReferenceExtension prend en charge le x:Reference extension de balisage
Deux interfaces sont impliqués dans la liaison de données :

INotifyPropertyChanged dans le System.ComponentModel espace de noms est pour l’implémentation de
notification lorsqu’une propriété change
IValueConverter permet de définir de petites classes qui convertissent les valeurs d’un type vers un autre
dans les liaisons de données
Une liaison de données connecte à deux propriétés de l’objet de même, ou deux objets différents (le plus souvent).
Ces deux propriétés sont appelées les source et cible. En règle générale, une modification dans la propriété source
provoque une modification se produise dans la propriété cible, mais parfois, la direction est inversée. Quel que
soit :
le cible propriété doit être stockée par un BindableProperty
le source propriété est généralement un membre d’une classe qui implémente INotifyPropertyChanged
Une classe qui implémente INotifyPropertyChanged se déclenche un PropertyChanged événement lorsqu’une

propriété change de valeur. BindableObject implémente INotifyPropertyChanged et déclenche automatiquement
un PropertyChanged événement lorsqu’une propriété stockée par un BindableProperty modifie les valeurs, mais
vous pouvez écrire vos propres classes qui implémentent INotifyPropertyChanged sans dériver BindableObject .
Code et XAML
Le OpacityBindingCode exemple montre comment définir une liaison de données dans le code :
La source est le Value propriété d’un Slider
La cible est le Opacity propriété d’un Label
Les deux objets sont connectés en définissant le BindingContext de la Label de l’objet à le Slider objet. Les
deux propriétés sont connectées en appelant un SetBinding méthode d’extension sur le Label faisant référence
à la OpacityProperty propriété pouvant être liée et le Value propriété de la Slider exprimée sous la forme un
chaîne.
Manipulation de la Slider provoque ensuite la Label à apparaître et disparaître.
Le OpacityBindingXaml est le même programme avec la liaison de données définie dans XAML. Le
BindingContext du Label est définie sur une x:Reference extension de balisage faisant référence à la Slider et
le Opacity propriété de la Label est défini sur le Binding extension de balisage avec son Path propriété faisant
référence à la Value propriété de la Slider .
Source et BindingContext
Le BindingSourceCode exemple montre une autre approche dans le code. Un Binding objet est créé en
définissant le Source propriété le Slider objet et le Path la propriété « Valeur ». Le SetBinding méthode de
BindableObject est ensuite appelée sur le Label objet.
Le Binding constructeur pourrait également avoir été utilisé pour définir le Binding objet.
Le BindingSourceXaml exemple illustre la technique comparable dans XAML. Le Opacity propriété de la
Label est définie sur une Binding extension de balisage avec Path défini sur le Value propriété et Source
définie sur une Embedded x:Reference extension de balisage.
En résumé, il existe deux façons de référencer l’objet de source de liaison :
Via le BindingContext propriété de la cible
Via le Source propriété de la Binding objet lui-même
Si les deux sont spécifiés, la seconde est prioritaire. L’avantage de la BindingContext est qu’elle est propagée à
travers l’arborescence visuelle. Il s’agit de très pratique si plusieurs propriétés de la cible sont liées au même objet
source.
Le WebViewDemo programme illustre cette technique avec le WebView élément. Deux Button héritent des
éléments de navigation et en amont un BindingContext à partir de leur parent qui fait référence à la WebView . Le
IsEnabled propriétés des deux boutons ont puis simple Binding des extensions de balisage qui ciblent le bouton
IsEnabled propriétés basées sur les paramètres de la CanGoBack et CanGoForward propriétés en lecture seule de
la WebView .
Le mode de liaison
Définir le Mode propriété du Binding à un membre de la BindingMode énumération :
OneWay afin que les modifications dans la propriété source affectent la cible
OneWayToSource afin que les modifications dans la propriété cible affecte la source
TwoWay afin que les modifications dans la source et la cible affecte les uns des autres
Default Pour utiliser le DefaultBindingMode spécifié lorsque la cible BindableProperty a été créé. Si aucun n’a
été spécifié, la valeur par défaut est OneWay pour les propriétés pouvant être liées normales, et
OneWayToSource pour les propriétés pouvant être liées en lecture seule.
NOTE
Le BindingMode énumération maintenant inclut également OnTime pour appliquer une liaison uniquement lorsque le
contexte de liaison change et non lorsque la propriété source change.
Les propriétés qui sont susceptibles d’être des cibles de liaisons de données dans les scénarios MVVM en général
ont un DefaultBindingMode de TwoWay . Ces équivalents sont :
Value propriété de Slider et Stepper
IsToggled propriété de Switch
Text propriété de Entry , Editor , et SearchBar
Date propriété de DatePicker
Time propriété de TimePicker
Le BindingModes exemple montre les modes de quatre liaison avec une liaison de données où la cible est le
FontSize propriété d’un Label et la source est le Value propriété d’un Slider . Cela permet à chaque Slider
pour contrôler la taille de police correspondantes Label . Mais le Slider éléments ne sont pas initialisés, car le
DefaultBindingMode de la FontSize propriété est OneWay .
Le ReverseBinding exemple définit les liaisons sur le Value propriété de la Slider faisant référence à la
FontSize propriété de chaque Label . Cela semble être descendante, mais il fonctionne mieux dans l’initialisation
le Slider éléments, car le Value propriété de la Slider a un DefaultBindingMode de TwoWay .
Ce comportement est analogue à la façon dont les liaisons sont définies dans MVVM, et vous utiliserez ce type de
liaison fréquemment.
Chaîne mise en forme

Lorsque la propriété cible est de type string , vous pouvez utiliser la StringFormat propriété définie par
BindingBase pour convertir la source en un string . Définir le StringFormat propriété à une mise en forme de
chaîne que vous utiliseriez avec la méthode statique de .NET String.Format format pour afficher l’objet. Lorsque
vous utilisez cette chaîne de mise en forme dans une extension de balisage, placez-la entre guillemets simples afin
des accolades ne sont pas être confondue avec une extension de balisage incorporé.
Le ShowViewValues exemple montre comment utiliser StringFormat dans XAML.
Le WhatSizeBindings exemple illustre l’affichage de la taille de la page avec des liaisons à le Width et Height
propriétés de la ContentPage .
Pourquoi elle est appelée « Path » ?

Le Path propriété du Binding est ce qu’on appelle, car elle peut être une série de propriétés et indexeurs séparés
par des points. Le BindingPathDemos montre plusieurs exemples.
Convertisseurs de valeur de liaison

Lorsque les propriétés source et cible d’une liaison de types différents, vous pouvez convertir entre les types à
l’aide d’un convertisseur de liaison. Il s’agit d’une classe qui implémente le IValueConverter interface et contient
deux méthodes : Convert pour convertir la source à la cible, et ConvertBack Pour convertir la cible à la source.
Le IntToBoolConverter classe dans le Xamarin.FormsBook.Toolkit bibliothèque est un exemple de conversion
d’un int à un bool . Est illustrée par la ButtonEnabler exemple, ce qui permet uniquement la Button si au
moins un caractère a été tapé dans un Entry .
Le BoolToStringConverter classe convertit un bool à un string et définit deux propriétés pour spécifier que le
texte doit être retourné pour false et true valeurs. Le BoolToColorConverter est similaire. Le SwitchText
exemple illustre l’utilisation de ces deux convertisseurs pour afficher des textes différents dans différentes
couleurs selon un Switch paramètre.
Générique BoolToObjectConverter peut remplacer le BoolToStringConverter et BoolToColorConverter et agissent
comme généralisée bool -à-convertisseur d’objet de tout type.
Liaisons et des vues personnalisées

Vous pouvez simplifier les contrôles personnalisés à l’aide de liaisons de données. Le NewCheckBox.cs fichier de
code définit Text , TextColor , FontSize , FontAttributes , et IsChecked propriétés, mais n’a aucune logique pour
les éléments visuels du contrôle. À la place la NewCheckBox.cs.xaml fichier contient tout le balisage pour les visuels
du contrôle par le biais des liaisons de données sur le Label les éléments basés sur les propriétés définies dans
le fichier code-behind.
Le NewCheckBoxDemo exemple illustre la NewCheckBox contrôle personnalisé.
Liens connexes
Liaison de données
Résumé du chapitre 17. Maîtrise de la grille
Le Grid est un mécanisme de disposition puissants qui réorganise ses enfants en lignes et colonnes de cellules. Le
code HTML similaire à la différence table élément, le Grid est destiné uniquement à des fins de disposition
plutôt que de présentation.
La grille de base
Grid dérive de Layout<View> , qui définit un Children propriété qui Grid hérite. Vous pouvez remplir cette
collection dans XAML ou de code.
La grille dans XAML
La définition d’un Grid dans XAML commence généralement par remplissage le RowDefinitions et
ColumnDefinitions collections de la Grid avec RowDefinition et ColumnDefinition objets. Voici comment vous
établissez le nombre de lignes et colonnes de la Grid et leurs propriétés.
RowDefinition a un Height propriété et ColumnDefinition a un Width propriété, tous deux de type GridLength ,
une structure.
Dans XAML, le GridLengthTypeConverter convertit les chaînes de texte simples dans GridLength valeurs. Dans les
coulisses, le GridLength constructeur crée le GridLength valeur basée sur un nombre et une valeur de type
GridUnitType , une énumération avec trois membres :
Absolute — la largeur ou la hauteur est spécifiée en unités indépendantes du périphérique (il s’agit d’un
nombre en XAML )
Auto — la largeur ou hauteur est redimensionnée automatiquement selon le contenu de la cellule (« Auto »
dans XAML )
Star — restes hauteur ou la largeur est allouée proportionnellement (un nombre avec «* », appelé en étoile,
dans XAML )
Chaque enfant de le Grid doit également être affecté une ligne et colonne (explicitement ou implicitement). Ligne
s’étend et étendues de colonne sont facultatifs. Ceux-ci sont spécifiées à l’aide des propriétés pouvant être liées
jointes — propriétés qui sont définies par le Grid mais définies sur les enfants de le Grid . Grid définit quatre
propriétés pouvant être liées attachées statiques :
RowProperty — la ligne de base zéro ; valeur par défaut est 0
ColumnProperty — la colonne de base zéro ; valeur par défaut est 0
RowSpanProperty — le nombre de lignes enfant s’étend sur ; valeur par défaut est 1
ColumnSpanProperty — le nombre de colonnes enfant s’étend sur ; valeur par défaut est 1
Dans le code, un programme peut utiliser les huit méthodes statiques pour définir et obtenir ces valeurs :
Grid.SetRow et Grid.GetRow
Grid.SetColumn et Grid.GetColumn
Grid.SetRowSpan et Grid.GetRowSpan
Grid.SetColumnSpan et Grid.GetColumnSpan
Dans XAML, vous utilisez les attributs suivants pour la définition de ces valeurs :
Grid.Row
Grid.Column
Grid.RowSpan
Grid.ColumnSpan
Le SimpleGridDemo exemple montre comment créer et initialiser un Grid dans XAML.

Le Grid hérite le Padding propriété Layout et définit deux propriétés supplémentaires qui fournissent
l’espacement entre les lignes et colonnes :
RowSpacing a la valeur par défaut de 6
ColumnSpacing a la valeur par défaut de 6
Le RowDefinitions et ColumnDefinitions collections ne sont pas strictement obligatoires. S’il est absent, le Grid
crée des lignes et des colonnes pour le Grid enfants et leur donne toutes les une valeur par défaut GridLength de
«*» (en étoile).
La grille dans le code
Le GridCodeDemo exemple montre comment créer et remplir un Grid dans le code. Vous pouvez définir les
propriétés jointes pour chaque enfant directement ou indirectement en appelant supplémentaires Add méthodes
telles que Add défini par le Grid.IGridList interface.
Le graphique à barres grille
Le GridBarChart exemple montre comment ajouter plusieurs BoxView éléments à un Grid à l’aide de la majeure
partie AddHorizontal (méthode). Par défaut, ces BoxView éléments ont la même largeur. La hauteur de chaque
BoxView peut ensuite être contrôlé et ressemble à un graphique à barres.
Le Grid dans le GridBarChart exemple partages un AbsoluteLayout parent avec initialement invisible Frame . Le
programme définit également un TapGestureRecognizer sur chaque BoxView à utiliser le Frame pour afficher des
informations sur la barre drainée.
Alignement de la grille
Le GridAlignment exemple montre comment utiliser le VerticalOptions et HorizontalOptions propriétés afin
d’aligner les enfants dans un Grid cellule.
Le SpacingButtons exemple tout aussi espaces Button éléments centrés dans Grid cellules.
Les bordures et les séparateurs de cellule
Le Grid n’inclut pas une fonctionnalité qui dessine les bordures ou des séparateurs de cellule. Toutefois, vous
pouvez créer vos propres.
Le GridCellDividers montre comment définir des lignes supplémentaires et colonne en particulier pour
dynamique BoxView éléments afin de reproduire les lignes de démarcation.
Le GridCellBorders programme ne crée pas de toutes les cellules, mais au lieu de cela aligne BoxView éléments
dans chaque cellule pour imiter une bordure de cellule.
Exemples de grille presque réel

Le KeypadGrid exemple utilise un Grid pour afficher un pavé numérique :
Répondre aux changements d’orientation
Le Grid peut aider à structurer un programme pour répondre aux changements d’orientation. Le GridRgbSliders
exemple illustre une technique qui déplace un élément entre une deuxième ligne d’un téléphone orienté en mode
portrait et la deuxième colonne d’un téléphone en mode paysage.
Initialise le programme Slider éléments à une plage de 0 à 255 et utilise les liaisons de données pour afficher la
valeur des curseurs au format hexadécimal. Étant donné que le Slider valeurs sont virgule flottante et la mise en
forme de chaîne de format hexadécimal fonctionne uniquement avec des entiers, de .NET un DoubleToIntConvert
classe dans le Xamarin.FormsBook.Toolkit bibliothèque est utile.
Liens connexes
Grid
Résumé du chapitre 18. MVVM
Un des meilleurs moyens de concevoir une application est en séparant l’interface utilisateur à partir du code sous-
jacent, ce qui est parfois appelé le logique métier. Plusieurs techniques existent, mais celui qui est adapté aux
environnements basés sur le XAML est appelé Model-View -ViewModel ou MVVM.
Relations MVVM
Une application MVVM a trois couches :
Le modèle fournit des données sous-jacentes, parfois dans les fichiers ou web accède à
La vue est l’utilisateur interface ou la couche présentation, généralement implémentée dans XAML
Le ViewModel connecte le modèle et la vue
Le modèle est ignorant la du ViewModel et le ViewModel est ignorant la de la vue. Généralement, ces trois
couches se connectent entre eux à l’aide des mécanismes suivants :
Dans de nombreux programmes plus petits (et ceux qui sont encore plus important), le modèle est souvent absent
ou sa fonctionnalité est intégrée dans le ViewModel.
Liaison de données et ViewModels

Pour s’engager dans des liaisons de données, un ViewModel doit être capable d’informer la vue lorsqu’une
propriété du ViewModel a changé. Le ViewModel fait ceci en implémentant la INotifyPropertyChanged interface
dans le System.ComponentModel espace de noms. Il s’agit de partie de .NET au lieu de Xamarin.Forms.
(Généralement ViewModels tenter de maintenir l’indépendance de la plateforme.)
Le INotifyPropertyChanged interface déclare un événement unique nommé PropertyChanged qui indique la
propriété qui a changé.
Une horloge de ViewModel
Le DateTimeViewModel dans le Xamarin.FormsBook.Toolkit bibliothèque définit une propriété de type DateTime
que les modifications basé sur un minuteur. La classe implémente INotifyPropertyChanged et déclenche le
PropertyChanged événement chaque fois que le DateTime modifications apportées aux propriétés.
Le MvvmClock exemple instancie ce ViewModel et utilise des liaisons de données au ViewModel pour afficher
les mises à jour informations de date et heure.
Propriétés interactives d’un ViewModel
Propriétés d’un ViewModel peuvent être plus interactives, tel qu’indiqué par le SimpleMultiplierViewModel
(classe), qui fait partie de la SimpleMultiplier exemple. Les liaisons de données fournissent des valeurs
multiplicande et le multiplicateur de deux Slider éléments et afficher le produit avec un Label . Toutefois, vous
pouvez modifier considérablement cette interface utilisateur dans XAML sans aucune modification à la suite de
ViewModel ou le fichier code-behind.
Un ViewModel de couleur
Le ColorViewModel dans le Xamarin.FormsBook.Toolkit bibliothèque intègre les modèles de couleurs RVB et
TSL. Il est montré dans le HslSliders exemple :
Rationalisation du ViewModel
Le code dans le ViewModel peut être rationalisé en définissant un OnPropertyChanged à l’aide de la méthode la
CallerMemberName attribut, qui obtient le nom de propriété appelant automatiquement. Le ViewModelBase classe
dans le Xamarin.FormsBook.Toolkit bibliothèque effectue cette et fournit une classe de base ViewModel.
L’interface de commande
MVVM fonctionne avec les liaisons de données et des liaisons de données fonctionnent avec des propriétés, afin
de MVVM semble déficientes lorsqu’il s’agit de la gestion d’un Clicked événement d’un Button ou un Tapped
événement d’un TapGestureRecognizer . Pour autoriser les ViewModels gérer ces événements, Xamarin.Forms
prend en charge la interface de commande.
L’interface de commande se présente sous la Button avec deux propriétés publiques :
Command de type ICommand (défini dans le System.Windows.Input espace de noms)
CommandParameter de type Object
Pour prendre en charge l’interface de commande, un ViewModel doit définir une propriété de type ICommand puis
les données liées à la Command propriété de la Button . Le ICommand interface déclare deux méthodes et un
événement :
Un Execute méthode avec un argument de type object
Un CanExecute méthode avec un argument de type object qui retourne bool
Un CanExecuteChanged événement
En interne, un ViewModel définit chaque propriété de type ICommand à une instance d’une classe qui implémente
le ICommand interface. Via la liaison de données, le Button appelle initialement le CanExecute (méthode) et se
désactive si la méthode retourne false . Il définit également un gestionnaire pour le CanExecuteChanged
événements et les appels CanExecute chaque fois que cet événement est déclenché. Si le Button est activé, il
appelle le Execute méthode chaque fois que le Button un clic sur.
Vous devrez peut-être certains ViewModels antérieures à Xamarin.Forms, et ceux-ci peuvent prennent déjà en
charge l’interface de commande. Pour les ViewModels nouveau destiné à être utilisé uniquement avec
Xamarin.Forms, Xamarin.Forms fournit un Command classe et un Command<T> classe qui implémentent le ICommand
interface. Le type générique est le type de l’argument à la Execute et CanExecute méthodes.
Exécutions de méthode simple
Le PowersOfThree exemple montre comment utiliser l’interface de commande dans un ViewModel. Le
PowersViewModel classe définit deux propriétés de type ICommand et définit également deux propriétés privées
qu’il transmet à la plus simple Command constructeur. Le programme contient des liaisons de données à partir de
ce ViewModel à la Command propriétés de deux Button éléments.
Le Button éléments peuvent être facilement remplacées avec TapGestureRecognizer objets dans XAML sans
aucune modification de code.
Une calculatrice, presque
Le AddingMachine exemple rend utilisez à la fois le Execute et CanExecute méthodes de ICommand . Il utilise un
AdderViewModel classe dans le Xamarin.FormsBook.Toolkit bibliothèque. Le ViewModel contient six propriétés
de type ICommand . Celles-ci sont initialisées à partir de la Command constructeur et Command constructeur de
Command et le Command<T> constructeur de Command<T> . Les touches numériques de la machine à additionner sont
liés à la propriété qui est initialisée avec Command<T> et un string l’argument de Execute et CanExecute identifie
la clé.
ViewModels et le cycle de vie d’application

Le AdderViewModel utilisé dans le AddingMachine exemple définit également deux méthodes nommées
SaveState et RestoreState . Ces méthodes sont appelées à partir de l’application lorsqu’elle se met en veille et
lorsqu’il démarre à nouveau.
Liens connexes
Modèles d’Application d’entreprise à l’aide de livre électronique Xamarin.Forms
Résumé du chapitre 19. Vues de collection
NOTE
Xamarin.Forms définit trois vues qui maintiennent des collections et affichent leurs éléments :
Picker est une liste relativement courte des éléments de type chaîne qui permet à l’utilisateur à choisir une
ListView est souvent une longue liste d’éléments généralement du même type et de mise en forme,
également autoriser l’utilisateur à choisir une
TableView est une collection de cellules (généralement de différents types et des apparences) pour afficher
des données ou gérer l’entrée utilisateur
Il est courant pour les applications MVVM le ListView pour afficher la collection d’objets sélectionnable.
Options du programme avec le sélecteur

Le Picker est un bon choix lorsque vous avez besoin autoriser l’utilisateur à choisir une option parmi une liste
relativement courte des string éléments.
Le sélecteur et la gestion des événements
Le PickerDemo exemple montre comment utiliser XAML pour définir le Picker Title propriété et ajoutez
string éléments à la Items collection. Lorsque l’utilisateur sélectionne le Picker , elle affiche les éléments dans
le Items collection en fonction de la plateforme.
Le SelectedIndexChanged événements indique quand l’utilisateur a sélectionné un élément. Base zéro
SelectedIndex propriété indique ensuite l’élément sélectionné. Si aucun élément n’est sélectionné, SelectedIndex
est égal à –1.
Vous pouvez également utiliser SelectedIndex pour initialiser l’élément sélectionné, mais il doit être définie après
le Items collection est remplie. Dans XAML, cela signifie que vous allez probablement utiliser un élément de
propriété pour définir SelectedIndex .
Le sélecteur de liaison de données
Le SelectedIndex propriété est stockée par une propriété pouvant être liée mais Items n’est pas, par conséquent,
à l’aide de la liaison de données avec un Picker est difficile. Une solution consiste à utiliser le Picker en
association avec un ObjectToIndexConverter comme celui de la Xamarin.FormsBook.Toolkit bibliothèque. Le
PickerBinding montre comment cela fonctionne.
NOTE
Xamarin.Forms Picker inclut désormais ItemsSource et SelectedItem propriétés qui prennent en charge la liaison de
données. Consultez sélecteur.
Rendu des données avec ListView

Le ListView est la seule classe qui dérive de ItemsView<TVisual> dont elle hérite la ItemsSource et ItemTemplate
propriétés.
ItemsSource est de type IEnumerable , mais il est null par défaut et doit être explicitement initialisés ou
(généralement) une collection via une liaison de données. Les éléments de cette collection peuvent être de
n’importe quel type.
ListView définit un SelectedItem propriété qui est soit définie sur un des éléments dans le ItemsSource
collection ou null si aucun élément n’est sélectionné. ListView se déclenche le ItemSelected événement
lorsqu’un nouvel élément est sélectionné.
Collections et les sélections
Le ListViewList exemple remplit un ListView avec 17 Color des valeurs dans un List<Color> collection. Les
éléments sont sélectionnables, mais par défaut, ils sont affichés avec leurs résultats peu esthétiques ToString
représentations. Plusieurs exemples dans ce chapitre vous montrent comment corriger qui affichent et rendre
aussi attractif comme vous le souhaitez.
Le séparateur de ligne
Sur iOS et Android affiche, une fine ligne sépare les lignes. Vous pouvez contrôler ceci avec la
SeparatorVisibility et SeparatorColor propriétés. SeparatorVisibility propriété est de type
SeparatorVisibility , une énumération avec deux membres :
Default , le paramètre par défaut

None
L’élément sélectionné de liaison de données

Le SelectedItem propriété repose sur une propriété pouvant être liée, il peut être la source ou la cible d’une
liaison de données. Sa valeur par défaut BindingMode est OneWayToSource , mais il est généralement la cible d’une
liaison de données bidirectionnelle, en particulier dans les scénarios MVVM. Le ListViewArray exemple illustre
ce type de liaison.
La différence de ObservableCollection
Le ListViewLogger exemples de jeux de la ItemsSource propriété d’un ListView à un List<DateTime> collection
puis progressivement ajoute une nouvelle DateTime objet à la collection chaque seconde à l’aide d’un minuteur.
Toutefois, le ListView n’automatiquement mettre à jour lui-même, car le List<T> collection n’a pas un
mécanisme de notification pour indiquer quand les éléments sont ajoutés ou supprimés de la collection.
Une classe beaucoup mieux à utiliser dans de tels scénarios est ObservableCollection<T> définies dans le
System.Collections.ObjectModel espace de noms. Cette classe implémente le INotifyCollectionChanged interface
et par conséquent se déclenche un CollectionChanged événement lorsque des éléments sont ajoutés ou
supprimés de la collection, ou lorsqu’ils sont remplacés ou déplacés dans la collection. Lorsque le ListView en
interne détecte qu’une classe qui implémente INotifyCollectionChanged a été défini sur sa ItemsSource propriété,
elle joint un gestionnaire à la CollectionChanged événement et met à jour son affichage lorsque la collection est
modifiée.
Le ObservableLogger exemple illustre l’utilisation de ObservableCollection .
Modèles et des cellules
Par défaut, un ListView affiche les éléments dans sa collection à l’aide de chaque élément ToString (méthode).
Une meilleure approche consiste à définir un modèle pour afficher les éléments.
Pour essayer cette fonctionnalité, vous pouvez utiliser la NamedColor classe dans le
Xamarin.FormsBook.Toolkit bibliothèque. Cette classe définit un mappage statique All propriété de type
IList<NamedColor> contenant 141 NamedColor objets correspondant aux champs publics de la Color structure.
Le NaiveNamedColorList exemples de jeux le ItemsSource d’un ListView à ce NamedColor.All propriété, mais
uniquement les noms de classe qualifié complet de le NamedColor sont des objets affiché.
ListView a besoin d’un modèle pour afficher ces éléments. Dans le code, vous pouvez définir le ItemTemplate
propriété définie par ItemsView<TVisual> à un DataTemplate à l’aide de l’objet le DataTemplate constructeur qui
fait référence à un dérivé de la Cell classe. Cell a cinq dérivés :
TextCell — contient deux Label vues (point de vue conceptuel)
ImageCell — Ajoute un Image afficher à TextCell
EntryCell — contient un Entry afficher avec un Label
SwitchCell — contient un Switch avec un Label
ViewCell — peut être toute View (probablement avec enfants)
Puis appelez SetValue et SetBinding sur le DataTemplate objet à associer les valeurs avec le Cell propriétés,
ou pour définir des liaisons de données sur le Cell propriétés faisant référence à des propriétés des éléments
dans le ItemsSource collection. Cela est illustré dans le TextCellListCode exemple.
Comme chaque élément est affiché par le ListView , une petite arborescence visuelle est construite à partir du
modèle et des liaisons de données sont établies entre l’élément et les propriétés des éléments dans cette
arborescence d’éléments visuels. Vous pouvez obtenir une idée de ce processus en installant des gestionnaires
pour les ItemAppearing et ItemDisappearing événements de la ListView , ou à l’aide d’une alternative
DataTemplate constructeur qui utilise une fonction qui est appelée chaque fois qu’arborescence d’éléments visuels
d’un élément doit être créé.
Le TextCellListXaml montre un programme fonctionnellement identique entièrement dans XAML. Un
DataTemplate balise est définie sur le ItemTemplate propriété de la ListView , puis le TextCell est défini sur le
DataTemplate . Liaisons aux propriétés des éléments dans la collection sont définies directement sur le Text et
Detail propriétés de la TextCell .
Cellules personnalisées
Dans XAML, il est possible de définir un ViewCell à la DataTemplate , puis définissez une arborescence
d’éléments visuels personnalisé en tant que le View propriété du ViewCell . ( View est la propriété de contenu de
ViewCell la ViewCell.View balises ne sont pas nécessaires.) Le CustomNamedColorList exemple illustre cette
technique :
Obtenir la taille adaptées à toutes les plateformes peut être difficile. Le RowHeight propriété est utile, mais dans
certains cas, vous voudrez avoir recours à la HasUnevenRows propriété, qui est moins efficace, mais force le
ListView pour dimensionner les lignes. Pour iOS et Android, vous devez utiliser une de ces deux propriétés pour
obtenir le dimensionnement de la ligne appropriée.
Grouper les éléments de ListView
ListView prend en charge le regroupement d’éléments et de naviguer parmi ces groupes. Le ItemsSource
propriété doit être définie sur une collection de collections : l’objet qui ItemsSource a la valeur doit implémenter
IEnumerable , et chaque élément dans la collection doit également implémenter IEnumerable . Chaque groupe doit
inclure deux propriétés : une description du groupe et une abréviation à trois lettres.
Le NamedColorGroup classe dans le Xamarin.FormsBook.Toolkit bibliothèque crée sept groupes de NamedColor
objets. Le ColorGroupList exemple montre comment utiliser ces groupes avec le IsGroupingEnabled propriété
du ListView la valeur true et le GroupDisplayBinding et GroupShortNameBinding propriétés liées aux propriétés
dans chaque groupe.
En-têtes de groupe personnalisé
Il est possible de créer des en-têtes personnalisés pour le ListView groupes en remplaçant le
GroupDisplayBinding propriété avec le GroupHeaderTemplate définition d’un modèle pour les en-têtes.
ListView et l’interactivité
Généralement d’obtenir l’interaction utilisateur avec un ListView en attachant un gestionnaire à la ItemSelected
ou ItemTapped événement, ou en définissant une liaison de données sur le SelectedItem propriété. Mais certains
types de cellule ( EntryCell et SwitchCell ) autoriser l’interaction utilisateur, et il est également possible de créer
des cellules personnalisées qui elles-mêmes interagir avec l’utilisateur. Le InteractiveListView crée 100
instances de ColorViewModel et permet à l’utilisateur modifier chaque couleur à l’aide d’un trio de Slider
éléments. Le programme utilise également le ColorToContrastColorConverter dans le
Xamarin.FormsBook.Toolkit.
ListView et MVVM
ListView joue un rôle important dans les scénarios MVVM. Chaque fois qu’un IEnumerable collection existe
dans un ViewModel, il est souvent lié à un ListView . En outre, les éléments dans la collection souvent
implémentent INotifyPropertyChanged pour lier des propriétés dans un modèle.
Une collection de ViewModel
Pour cela, Explorer le SchoolOfFineArts bibliothèque crée plusieurs classes basées sur un fichier de données
XML et des images d’étudiants fictives de l’établissement fictif.
Le Student dérive de la classe ViewModelBase . Le StudentBody classe est une collection de Student objets et
dérive également de ViewModelBase . Le SchoolViewModel télécharge le fichier XML et les assemble tous les objets.
Le StudentList programme utilise une ImageCell pour afficher les étudiants et leurs images dans un ListView :
Le ListViewHeader exemple ajoute un Header propriété mais il ne s’affiche sur Android.
Sélection et le contexte de liaison
Le SelectedStudentDetail programme lie le BindingContext d’un StackLayout à la SelectedItem propriété de
la ListView . Cela permet au programme afficher des informations détaillées sur l’étudiant sélectionné.
Menus contextuels
Une cellule peut définir un menu contextuel qui est implémenté de manière spécifique à la plateforme. Pour créer
ce menu, ajoutez MenuItem des objets sur le ContextActions propriété de la Cell .
MenuItem définit les cinq propriétés :
Text de type string
Icon de type FileImageSource
IsDestructive de type bool
Command de type ICommand
CommandParameter de type object
Le Command et CommandParameter propriétés impliquent que le ViewModel pour chaque élément contient des
méthodes pour exécuter les commandes de menu souhaitée. Dans les scénarios non MVVM, MenuItem définit
également un Clicked événement.
Le CellContextMenu illustre cette technique. Le Command propriété de chaque MenuItem est liée à une propriété
de type ICommand dans la Student classe. Définir le IsDestructive propriété true pour un MenuItem qui
supprime ou l’objet sélectionné.
Faire varier les éléments visuels
Parfois, vous voudrez légères variantes dans les visuels des éléments dans le ListView basée sur une propriété.
Par exemple, lorsqu’un point de qualité moyenne se situe antérieures à 2.0, la ColorCodedStudents exemple
affiche le nom de cette étudiant en rouge. Cela s’effectue via l’utilisation d’un convertisseur de valeurs de liaison,
ThresholdToObjectConverter , dans le Xamarin.FormsBook.Toolkit bibliothèque.
L’actualisation du contenu
Le ListView prend en charge un mouvement déroulant pour actualiser ses données. Le programme doit définir
le IsPullToRefresh propriété true pour activer cette option. Le ListView répond à la liste déroulante en
définissant son IsRefreshing propriété true et en déclenchant le Refreshing événement et (pour les scénarios
MVVM ) appelant le Execute méthode de son RefreshCommand propriété.
Code de gestion de la Refresh événement ou la RefreshCommand éventuellement met à jour les données affichées
par le ListView et définit IsRefreshing à false .
Le RssFeed exemple montre comment utiliser un RssFeedViewModel qui implémente RefreshCommand et
IsRefreshing propriétés pour la liaison de données.
Le TableView et ses intentions

Bien que le ListView affiche généralement plusieurs instances du même type, le TableView se concentre
généralement sur la fourniture d’une interface utilisateur pour plusieurs propriétés de différents types. Chaque
élément est associé à sa propre Cell dérivés pour afficher la propriété ou en fournissant une interface utilisateur
à ce dernier.
Propriétés et des hiérarchies
TableView définit que quatre propriétés :
Intent de type TableIntent , énumération

Root de type TableRoot , la propriété de contenu de TableView
RowHeight de type int
HasUnevenRows de type bool
Le TableIntent énumération indique la façon dont vous prévoyez d’utiliser le TableView :

Data
Form
Settings
Menu
Ces membres suggèrent également certaines utilisations pour le TableView .

Plusieurs autres classes sont impliqués dans la définition d’une table :
TableSectionBase est une classe abstraite qui dérive de BindableObject et définit un Title propriété
TableSectionBase<T> est une classe abstraite qui dérive de TableSectionBase et implémente IList<T> et
INotifyCollectionChanged
TableSection dérive de TableSectionBase<Cell>
TableRoot dérive de TableSectionBase<TableSection>
En bref, TableViewa un Root propriété que vous définissez pour un TableRoot objet, qui est une collection de
TableSection objets, chacun d’eux est une collection de Cell objets. Une table comporte plusieurs sections, et
chaque section comporte plusieurs cellules. La table elle-même peut avoir un titre, et chaque section peut
contenir un titre. Bien que TableView utilise Cell dérivés, il ne fait pas utiliser de DataTemplate .
Un formulaire prosaïque
Le EntryForm exemple définit un PersonalInformation modèle de vue, une instance de qui devient le
BindingContext de la TableView . Chaque Cell dérivés dans son TableSection peut ensuite avoir des liaisons
aux propriétés de la PersonalInformation classe.
Cellules personnalisées
Le ConditionalCells exemple s’appuie sur EntryForm. Le ProgrammerInformation classe inclut une propriété
booléenne qui détermine l’applicabilité des deux propriétés supplémentaires. Pour ces deux propriétés
supplémentaires, le programme utilise un personnalisé PickerCell selon un PickerCell.xaml et PickerCell.xaml.cs
dans le Xamarin.FormsBook.Toolkit bibliothèque.
Bien que le propriétés des deux PickerCell éléments sont liés à la propriété booléenne dans
IsEnabled
ProgrammerInformation , cette technique ne semble pas fonctionner, ce qui demande à l’exemple suivant.
Sections conditionnelles
Le ConditionalSection exemple place les deux éléments sont conditionnels sur la sélection de l’élément
booléenne dans une fonction TableSection . Le fichier code-behind supprime cette section à partir de la
TableView ou ajoute il selon la propriété booléenne.
Un menu TableView
Une autre utilisation d’un TableView est un menu. Le MenuCommands exemple illustre un menu qui vous
permet de déplacer un peu BoxView autour de l’écran.
Liens connexes
Picker
ListView
TableView
Résumé du chapitre 20. E/s de fichier et asynchrone
NOTE
Une interface graphique utilisateur doit répondre aux événements d’entrée d’utilisateur séquentiellement. Cela
implique que tout le traitement des événements d’entrée de l’utilisateur doit se trouver dans un thread unique,
souvent appelé le thread principal ou thread d’interface utilisateur.
Les utilisateurs attendent des interfaces graphiques utilisateur d’être réactives. Cela signifie qu’un programme doit
traiter rapidement les événements d’entrée de l’utilisateur. Si cela n’est pas possible, le traitement puis doit être
relégué aux threads secondaires de l’exécution.
Plusieurs exemples de programmes dans ce livre ont utilisé le WebRequest classe. Dans cette classe le
BeginGetResponse méthode démarre un thread de travail, qui appelle une fonction de rappel lorsqu’il est terminé.
Toutefois, cette fonction de rappel s’exécute dans le thread de travail, le programme doit donc appeler
Device.BeginInvokeOnMainThread méthode pour accéder à l’interface utilisateur.
NOTE
Xamarin.Forms les programmes doivent utiliser HttpClient plutôt que WebRequest pour accéder aux fichiers via internet.
HttpClient prend en charge les opérations asynchrones.
Une approche plus moderne pour le traitement asynchrone est disponible dans .NET et c#. Cela implique le Task
et Task<TResult> classes et autres types dans le System.Threading et System.Threading.Tasks espaces de noms,
ainsi que le C# 5.0 async et await mots clés. C’est ce que ce chapitre se concentre sur.
À partir des rappels pour attendre

Le Page classe elle-même contient trois méthodes asynchrones pour afficher les zones de l’alerte :
DisplayAlert Retourne un Task objet
DisplayAlert Retourne un Task<bool> objet
DisplayActionSheet Retourne un Task<string> objet
Le Task objets indiquent que ces méthodes implémentent le modèle asynchrone basé sur une tâche, appelé TAP.
Ces Task objets sont retournés rapidement à partir de la méthode. Le Task<T> retournent des valeurs constituent
la « promesse » qui une valeur de type TResult seront disponibles lorsque la tâche se termine. Le Task valeur
renvoyée indique une action asynchrone sera terminée, mais aucune valeur n’est retournée.
Dans tous ces cas, le Task est terminée lorsque l’utilisateur ferme la fenêtre d’alerte.
Une alerte avec des rappels
Le AlertCallbacks exemple montre comment gérer Task<bool> retournent des objets et
Device.BeginInvokeOnMainThread appels à l’aide de méthodes de rappel.
Une alerte avec les expressions lambda
Le AlertLambdas exemple illustre l’utilisation des fonctions lambda anonyme pour la gestion des Task et
Device.BeginInvokeOnMainThread appels.
Une alerte avec await

Une approche plus simple implique la async et await mots clés introduits dans c# 5. Le AlertAwait exemple
illustre son utilisation.
Une alerte sans rien
Si la méthode asynchrone retourne Task plutôt que Task<TResult> , puis le programme n’a pas besoin d’utiliser
une de ces techniques si elle n’a pas besoin de savoir quand la tâche asynchrone est terminée. Le NothingAlert
illustre cela.
Enregistrement des paramètres de programme en mode asynchrone
Le SaveProgramChanges exemple illustre l’utilisation de la SavePropertiesAsync méthode de Application pour
enregistrer les paramètres du programme mesure qu’elles changent sans substitution de la OnSleep (méthode).
Un minuteur indépendant de la plateforme
Il est possible d’utiliser Task.Delay pour créer un minuteur indépendant de la plateforme. Le TaskDelayClock
illustre cela.
Fichier d’entrée/sortie
En règle générale, le .NET System.IO espace de noms a été la source de prise en charge d’e/s de fichier. Bien que
certaines méthodes dans cet espace de noms prennent en charge les opérations asynchrones, la plupart ne le faites
pas. L’espace de noms prend également en charge plusieurs appels de méthode simple qui exécutent des fonctions
d’e/s de fichier sophistiquées.
Une bonne et mauvaise nouvelle
Toutes les plateformes prises en charge par Xamarin.Forms prise en charge le stockage local application —
stockage privé pour l’application.
Les bibliothèques Xamarin.iOS et Xamarin.Android incluent une version du .NET Xamarin a expressément
adaptées à ces deux plateformes. Ceux-ci incluent des classes provenant System.IO que vous pouvez utiliser pour
effectuer des e/s de fichier avec le stockage local des applications dans ces deux plateformes.
Toutefois, si vous recherchez ces System.IO classes dans une bibliothèque de classes portable Xamarin.Forms,
vous ne trouverez pas les. Le problème est ce fichier d’e/s de Microsoft complètement repensée pour l’API de
Runtime de Windows. Programmes qui ciblent Windows 8.1, Windows Phone 8.1 et la plateforme Windows
universelle n’utilisent pas System.IO d’e/s de fichier.
Cela signifie que vous devrez utiliser le DependencyService (abordé en chapitre 9. Appels d’API spécifiques à la
plateforme pour implémenter des e/s de fichier.
NOTE
Les bibliothèques de classes portable ont été remplacés par les bibliothèques .NET Standard 2.0, et prend en charge de .NET
Standard 2.0 System.IO types pour toutes les plateformes de Xamarin.Forms. Il n’est plus nécessaire d’utiliser un
DependencyService pour la plupart des tâches d’e/s de fichier. Consultez gestion des fichiers dans Xamarin.Forms pour une
approche plus moderne d’e/s de fichier.
Une première tentative de fichier inter-plateformes d’e/s

Le TextFileTryout exemple définit un IFileHelper interface pour les e/s de fichier et les implémentations de cette
interface dans toutes les plateformes. Toutefois, les implémentations de Windows Runtime ne fonctionnent pas
avec les méthodes dans cette interface, car les méthodes d’e/s de fichier Windows Runtime sont asynchrones.
Prise en charge d’e/s de fichier Windows Runtime
Utilisent les classes de programmes s’exécutant sous le Runtime Windows le Windows.Storage et
Windows.Storage.Streams espaces de noms pour le fichier d’e/s, y compris le stockage local des applications. Étant
donné que Microsoft déterminé que toute opération qui requiert que plus de 50 millisecondes doivent être
asynchrones pour éviter de bloquer le thread d’interface utilisateur, ces méthodes d’e/s de fichier sont
principalement asynchrones.
Le code qui illustre cette nouvelle approche sera dans une bibliothèque afin qu’il peut être utilisé par d’autres
applications.
Bibliothèques propres à une plateforme

Il est préférable de stocker le code réutilisable dans des bibliothèques. Il s’agit évidemment plus difficile lorsque
différentes parties du code réutilisable sont pour les systèmes d’exploitation entièrement différents.
Le Xamarin.FormsBook.Platform solution illustre une approche. Cette solution contient sept projets différents :
Xamarin.FormsBook.Platform, une bibliothèque de classes portable Xamarin.Forms normal
Xamarin.FormsBook.Platform.iOS, une bibliothèque de classes iOS
Xamarin.FormsBook.Platform.Android, une bibliothèque de classes Android
Xamarin.FormsBook.Platform.UWP, une bibliothèque de classes Windows Universal
Xamarin.FormsBook.Platform.WinRT, un projet partagé pour le code qui est commune à toutes les
plateformes Windows
Tous les projets de plateforme individuels (à l’exception de Xamarin.FormsBook.Platform.WinRT) ont des
références à Xamarin.FormsBook.Platform. Les trois projets de Windows ont une référence à
Xamarin.FormsBook.Platform.WinRT.
Tous les projets contiennent un statique Toolkit.Init méthode pour vous assurer que la bibliothèque est chargée
s’il n’est pas directement référencé par un projet dans une solution d’application Xamarin.Forms.
Le Xamarin.FormsBook.Platform projet contient le nouvel IFileHelper interface. Toutes les méthodes ont
maintenant des noms avec Async retour et les suffixes Task objets.
Le Xamarin.FormsBook.Platform.WinRT projet contient le FileHelper classe pour l’exécution de Windows.
Le Xamarin.FormsBook.Platform.iOS projet contient le FileHelper classe pour iOS. Ces méthodes doivent
maintenant être asynchrones. Certaines des méthodes utilisent des versions asynchrones des méthodes définies
dans StreamWriter et StreamReader : WriteAsync et ReadToEndAsync . D’autres convertir un résultat pour un Task
à l’aide de l’objet le FromResult (méthode).
Le Xamarin.FormsBook.Platform.Android projet contient un texte similaire FileHelper classe pour Android.
Le Xamarin.FormsBook.Platform projet contient également un FileHelper classe qui facilite l’utilisation de la
DependencyService objet.
Pour utiliser ces bibliothèques, une solution d’application doit inclure tous les projets de la
Xamarin.FormsBook.Platform solution et chacun des projets d’application doivent avoir une référence à la
bibliothèque correspondante dans Xamarin.FormsBook.Platform.
Le TextFileAsync solution montre comment utiliser le Xamarin.FormsBook.Platform bibliothèques. Chacun
des projets a un appel à Toolkit.Init . L’application se sert de l’e/s de fichier asynchrone fonctions.
En conservant en arrière -plan
Méthodes dans les bibliothèques qui effectuent des appels à plusieurs méthodes asynchrones — tels que le
WriteFileAsync et ReadFileASync méthodes dans le Runtime Windows FileHelper classe — peut être effectuée
quelque plus efficace à l’aide de la ConfigureAwait méthode afin d’éviter de basculer vers le thread d’interface
utilisateur.
Ne pas bloquer le thread d’interface utilisateur !
Parfois, il est tentant afin d’éviter l’utilisation de ContinueWith ou await à l’aide de la Result propriété sur les
méthodes. Cela doit être évitée pour qu’il peut bloquer le thread d’interface utilisateur ou même bloquer
l’application.
Vos propres méthodes pouvant être attendus

Vous pouvez exécuter du code de façon asynchrone en le passant à une de la Task.Run méthodes. Vous pouvez
appeler Task.Run au sein d’une méthode async qui gère la partie de la surcharge.
Les différents Task.Run modèles sont décrits ci-dessous.
L’ensemble de Mandelbrot base
Pour dessiner l’ensemble en temps réel, de Mandelbrot le Xamarin.Forms.Toolkit bibliothèque possède un
Complex structure similaire à celui de la System.Numerics espace de noms.
Le MandelbrotSet exemple comporte un CalculateMandeblotAsync méthode dans son fichier code-behind qui
calcule l’ensemble de Mandelbrot base noir et blanc et utilise BmpMaker placer sur une image bitmap.
Marquage de progression
Pour signaler la progression à partir d’une méthode asynchrone, vous pouvez instancier un Progress<T> classe et
de définir votre méthode asynchrone pour avoir un argument de type IProgress<T> . Cela est illustré dans le
MandelbrotProgress exemple.
Annulation de la tâche
Vous pouvez également écrire une méthode asynchrone pour être annulable. Commencer avec une classe
nommée CancellationTokenSource . Le Token propriété est une valeur de type CancellationToken . Ces données
sont transmises à la fonction asynchrone. Un programme appelle la Cancel méthode de CancellationTokenSource
(généralement en réponse à une action de l’utilisateur) pour annuler la fonction asynchrone.
La méthode asynchrone peut vérifier périodiquement la IsCancellationRequested propriété du CancellationToken
et quitter si la propriété est true , ou simplement appeler le ThrowIfCancellationRequested (méthode), dans auquel
cas la méthode se termine par un OperationCancelledException .
Le MandelbrotCancellation exemple illustre l’utilisation d’une fonction pouvant être annulée.
Un ensemble de Mandelbrot MVVM
Le MandelbrotXF exemple a une interface utilisateur plus étendue, et il est principalement basé sur un
MandelbrotModel et MandelbrotViewModel classes :
Dans le web
Le WebRequest classe utilisée dans certains exemples utilise un ancienne protocole asynchrone appelé modèle de
programmation asynchrone ou APM. Vous pouvez convertir une telle classe au protocole TAP modern à l’aide d’un
de le FromAsync méthodes dans le TaskFactory classe. Le ApmToTap illustre cela.
Liens connexes
Chapitre 20 échantillons
Utilisation de fichiers
Résumé du chapitre 21. Transformations
Xamarin.Forms s’affiche sur l’écran dans un emplacement et une taille déterminée par son parent, qui est
généralement un Layout ou Layout<View> dérivé. Le transformer est une fonctionnalité de Xamarin.Forms qui
peut modifier cet emplacement, taille ou même l’orientation.
Xamarin.Forms prend en charge trois types de transformations :
Traduction — déplacer un élément horizontalement ou verticalement
Mise à l’échelle — modifier la taille d’un élément
Rotation — activer un élément autour d’un point ou d’un axe
Dans Xamarin.Forms, la mise à l’échelle est Isotrope ; elle affecte la largeur et la hauteur uniforme. Rotation est pris
en charge à la fois sur la surface à deux dimensions de l’écran et dans l’espace 3D. Il existe aucune transformation
d’inclinaison (ou élevée) et aucune transformation de matrice généralisée.
Transformations sont prises en charge avec huit propriétés de type double défini par le VisualElement classe :
TranslationX
TranslationY
Scale
Rotation
RotationX
RotationY
AnchorX
AnchorY
Toutes ces propriétés sont assorties de propriétés pouvant être liées. Ils peuvent être la cible de liaison de données
et un style. Chapitre 22. Animation montre comment ces propriétés peuvent être animées, mais certains
exemples de ce chapitre indiquent comment vous pouvez animer à l’aide de Xamarin.Forms minuteur.
Transformer les propriétés affectent uniquement la façon dont l’élément est rendu et faire pas affectent la façon
dont l’élément est perçu dans mise en page.
La transformation de traduction
Des valeurs différentes de zéro de la TranslationX et TranslationY propriétés déplacer un élément
horizontalement ou verticalement.
Le TranslationDemo programme vous permet de faire des essais avec ces propriétés avec deux Slider éléments
qui contrôlent la TranslationX et TranslationY propriétés d’un Frame . La transformation affecte également tous
les enfants de cet Frame .
Effets de texte
Une utilisation courante des propriétés de la traduction est pour décaler légèrement le rendu du texte. Cela est
illustré dans le TextOffsets exemple :
Un autre effet consiste à rendre plusieurs copies d’un Label pour ressembler à un bloc 3D, comme illustré dans le
BlockText exemple.
Sauts et animations
Le ButtonJump exemple utilise la traduction pour déplacer un Button chaque fois qu’il est activé par un clic, mais
son principal objectif est de démontrer que le Button reçoit l’entrée d’utilisateur à l’emplacement où le bouton est
restitué.
Le ButtonGlide exemple est similaire, mais utilise une horloge pour animer la Button d’un point vers un autre.
La transformation d’échelle
Le Scale transformation peut augmenter ou diminuer la taille rendue de l’élément. La valeur par défaut est 1. La
valeur 0 entraîne l’élément à être invisible. Valeurs négatives, l’élément semblent être pivotée de 180 degrés. Le
Scale propriété n’affecte pas la Width ou Height propriétés de l’élément. Ces valeurs restent les mêmes.
Vous pouvez expérimenter la Scale à l’aide de la propriété le SimpleScaleDemo exemple.

Le ButtonScaler exemple illustre la différence entre l’animation de la Scale propriété d’un Button et animer le
FontSize propriété. Le FontSize propriété affecte la Button est perçu dans disposition ; le Scale propriété n’a
pas.
Le ScaleToSize exemple calcule un Scale propriété qui est appliquée à un Label élément pour le rendre aussi
grand que possible tout en adaptant toujours au sein de la page.
Ancrage de la mise à l’échelle
Les éléments mis à l’échelle dans les trois exemples précédents ont tous les augmenter ou réduire la taille par
rapport au centre de l’élément. En d’autres termes, l’élément augmente ou diminue en taille identique dans toutes
les directions. Seul le point au centre de l’élément reste dans le même emplacement pendant la mise à l’échelle.
Vous pouvez modifier le centre de la mise à l’échelle en définissant le AnchorX et AnchorY propriétés. Ces
propriétés sont par rapport à l’élément lui-même. Pour AnchorX , la valeur 0 fait référence à gauche de l’élément et
1 fait référence à la partie droite. De même pour AnchorY , 0 est la partie supérieure et 1 est bas. Les deux
propriétés ont des valeurs par défaut de 0.5, qui est le centre.
Le AnchoredScaleDemo exemple vous permet de faire des essais avec la AnchorX et AnchorY propriétés ainsi
que le Scale propriété.
Sur iOS, à l’aide de valeurs non défaut de AnchorX et AnchorY propriétés est généralement pas compatible avec
les changements d’orientation de téléphone.
La transformation de rotation
Le Rotation propriété est spécifiée en degrés et indique une rotation autour d’un point de l’élément défini par
AnchorX et AnchorY . Le PlaneRotationDemo vous permet de faire des essais avec ces trois propriétés.
Effets de texte pivoté
Le BoxViewCircle exemple illustre les calculs nécessaires pour dessiner un cercle à l’aide de 64 minuscule
paysage BoxView éléments.
Le RotatedText exemple affiche plusieurs Label éléments avec la même chaîne de texte pivoté apparaît comme
membres spokes.
Le CircularText exemple affiche une chaîne de texte qui apparaît à la ligne dans un cercle.
Une horloge analogique
Le Xamarin.FormsBook.Toolkit bibliothèque contient un AnalogClockViewModel classe qui calcule les angles pour
entre les mains d’une horloge. Pour éviter les dépendances de plateforme dans le ViewModel, la classe utilise
Task.Delay au lieu d’un minuteur pour rechercher un nouveau DateTime valeur.
Également inclus dans Xamarin.FormsBook.Toolkit est un SecondTickConverter classe qui implémente

IValueConverter et permet d’arrondir un angle deuxième à la seconde près.
Le MinimalBoxViewClock utilise trois rotation BoxView éléments pour dessiner une horloge analogique.
Le BoxViewClock utilise BoxView pour les graphiques plus étendues, y compris les graduations marque autour
de la face de l’horloge et remet autrement faire pivoter une distance peu à partir de leurs principaux :
En outre un SecondBackEaseConverter classe Xamarin.FormsBook.Toolkit provoque la seconde aiguille

apparaisse sur ressortir un peu avant de passer à l’avance, puis à les replacer dans sa position correcte.
Curseurs verticales ?
Le VerticalSliders exemple montre que Slider éléments peut être pivotées de 90 degrés et fonctionnent
toujours. Toutefois, il est difficile de positionner ces paysage Slider éléments, car dans la mise en page ils toujours
apparaître à l’horizontale.
Rotations qui concerne 3D

Le RotationX propriété s’affiche pour faire pivoter un élément autour d’un axe des abscisses 3D afin que le haut et
le bas de l’élément semblent déplacer vers ou à partir de la visionneuse. De même, le RotationY semble faire
pivoter un élément autour de l’axe des ordonnées pour rendre les côtés gauche et droit de l’élément semblent à
déplacer vers ou à partir de la visionneuse.
Le AnchorX propriété affecte RotationY mais pas RotationX . Le AnchorY propriété affecte RotationX mais pas
RotationY . Vous pouvez expérimenter la ThreeDeeRotationDemo exemple pour Explorer les interactions de ces
propriétés.
Le système de coordonnées 3D impliqué par Xamarin.Forms est gaucher. Si vous pointez le pouce de votre main
gauche dans la direction de l’augmentation de X coordonnées coordonnées (à droite) et votre doigt intermédiaire
dans la direction de croissant Y (points vers le bas), puis votre curseur dans le sens d’augmentation de
coordonnées Z (hors de l’écran).
En outre, pour tous les trois axes, si vous pointez votre curseur gauche dans la direction de l’augmentation des
valeurs, puis la courbe de vos doigts indique la direction de rotation des angles de rotation positives.
Liens connexes
Résumé du chapitre 22. Animation
Vous avez vu que vous pouvez créer vos propres animations à l’aide de la minuterie Xamarin.Forms ou
Task.Delay , mais il est généralement plus simple, avec les fonctionnalités d’animation fournies par
Xamarin.Forms. Trois classes implémentent ces animations :
ViewExtensions , l’approche de haut niveau
Animation , plus polyvalent, mais il est plus difficile
AnimationExtension , le plus polyvalente plus bas niveau approche
En règle générale, les animations cibler les propriétés qui sont assorties de propriétés pouvant être liées. Cela n’est
pas obligatoire, mais ce sont les seules propriétés dynamiquement réagissent aux modifications.
Il n’existe aucune interface XAML pour ces animations, mais vous pouvez intégrer des animations dans XAML à
l’aide des techniques présentées dans chapitre 23. Déclencheurs et comportements.
Exploration des animations de base

Les fonctions d’animation de base sont des méthodes d’extension trouvées dans le ViewExtensions classe. Ces
méthodes s’appliquent à n’importe quel objet qui dérive de VisualElement . Les animations de la plus simple
ciblent les propriétés décrites dans les transformations Chapter 21. Transforms .
Le AnimationTryout montre comment la Clicked Gestionnaire d’événements pour un Button peut appeler le
RotateTo méthode d’extension pour mettre en place le bouton dans un cercle.
Le RotateTo de la méthode change le Rotation propriété de la Button comprise entre 0 et 360 au cours de la
seconde un quart (par défaut). Si le Button l’appui sur là encore, toutefois, elle ne fait rien, car le Rotation
propriété est déjà 360 degrés.
Définition de la durée de l’animation
Le deuxième argument de RotateTo est la durée en millisecondes. Si la valeur est une valeur élevée, en appuyant
sur la Button pendant une animation démarre un nouveau commencement d’animation à l’angle actuel.
Animations relatives
Le RelRotateTo méthode effectue une rotation relative en ajoutant une valeur spécifiée à la valeur existante. Cette
méthode permet le Button à drainer plusieurs fois et pour chaque heure augmente la Rotation propriété de 360
degrés.
En attente d’animations
Toutes les méthodes d’animation dans ViewExtensions retourner Task<bool> objets. Cela signifie que vous
pouvez définir une série d’animations séquentielles à l’aide de ContinueWith ou await . Le bool achèvement
valeur de retour est false si l’animation est terminée sans interruption ou true si elle a été annulée par le
CancelAnimation (méthode), ce qui annule toutes les animations initiées par le autre méthode dans
ViewExtensions qui sont définies sur le même élément.
Animations composite
Vous pouvez combiner des animations attendues et non attendu pour créer des animations composites. Voici les
animations dans ViewExtensions qui ciblent le TranslationX , TranslationY , et Scale propriétés de
transformation :
TranslateTo
ScaleTo
RelScaleTo
Notez que TranslateTo affecte potentiellement tous deux le TranslationX et TranslationY propriétés.
Task.WhenAll et Task.WhenAny
Il est également possible de gérer des animations simultanées à l’aide de Task.WhenAll , ce qui signale lorsque
plusieurs tâches tous terminés, et Task.WhenAny , qui signale quand la première de plusieurs tâches a terminé.
Rotation et les points d’ancrage
Lorsque vous appelez le ScaleTo , RelScaleTo , RotateTo , et RelRotateTo méthodes, vous pouvez définir le
AnchorX et AnchorY propriétés pour indiquer le Centre de mise à l’échelle et la rotation.
Le CircleButton illustre cette technique par révolution un Button autour du centre de la page.
Fonctions d’accélération
En règle générale, les animations sont linéaires à partir d’une valeur de début pour une valeur de fin. Fonctions
d’accélération peuvent provoquer des animations accélérer ou ralentir leur cours. Le dernier argument facultatif
pour les méthodes d’animation est de type Easing , une classe qui définit les 11 en lecture seule les champs
statiques de type Easing :
Linear , la valeur par défaut
SinIn , SinOut , et SinInOut
CubicIn , CubicOut , et CubicInOut
BounceIn et BounceOut
SpringIn et SpringOut
Le In suffixe indique que l’effet se trouve au début de l’animation, Out signifie à la fin, et InOut signifie qu’il est
au début et à la fin de l’animation.
Le BounceButton exemple illustre l’utilisation de fonctions d’accélération.
Vos propres fonctions d’accélération
Vous pouvez également définir vous propres fonctions d’accélération en passant un Func<double, double> à la
Easing constructeur. Easing définit également une conversion implicite de Func<double, double> à Easing .
L’argument à la fonction d’accélération est toujours dans la plage de 0 à 1 comme l’animation se poursuit de façon
linéaire à partir du début à la fin. La fonction généralement retourne une valeur dans la plage de 0 à 1, mais peut
être brièvement négatif ou supérieur à 1 (comme c’est le cas avec le SpringIn et SpringOut fonctions) ou
endommage les règles si vous savez ce que vous faites.
Le UneasyScale exemple illustre une fonction d’accélération personnalisée, et CustomCubicEase montre un
autre.
Le SwingButton montre également une fonction d’accélération personnalisée et également une technique
consistant à changer la AnchorX et AnchorY propriétés au sein d’une séquence d’animations de rotation.
Le Xamarin.FormsBook.Toolkit bibliothèque possède un JiggleButton la fonction de classe qui utilise une
accélération personnalisée à jiggle un bouton lorsque vous cliquez dessus. Le JiggleButtonDemo illustre cela.
Animations d’entrée
Un seul type populaires d’animation se produit lorsqu’une page s’affiche tout d’abord. Une animation de ce type
peut être démarrée le OnAppearing la substitution de la page. Pour ces animations, de son mieux pour configurer
le XAML de la manière dont la page affichage après l’animation, initialiser et animer la disposition à partir du
code.
Le FadingEntrance exemple utilise le FadeTo méthode d’extension pour le fondu dans le contenu de la page.
Le SlidingEntrance exemple utilise le TranslateTo méthode d’extension à la diapositive dans le contenu de la
page sur les côtés.
Le SwingingEntrance exemple utilise le RotateYTo méthode d’extension pour animer la RotationY propriété. Un
RotateXTo méthode est également disponible.
Animations indéfiniment
À l’autre extrême, « forever » les animations s’exécutent jusqu'à ce que le programme se termine.Elles sont
généralement destinées à des fins de démonstration.
Le FadingTextAnimation exemple utilise FadeTo animation à deux parties de texte disparaître en fondu.
PalindromeAnimation affiche un palindrome et ensuite séquentiellement fait pivoter les lettres individuelles à
180 degrés afin qu’elles soient toutes envers. Puis la chaîne entière est retournée par 180 degrés pour lire la
même que la chaîne d’origine.
Le CopterAnimation exemple fait pivoter une simple BoxView hélicoptère lors de la révolution il autour du
centre de l’écran.
RotatingSpokes tourne BoxView rayons autour du centre de l’écran, puis fait pivoter chaque membre spoke lui-
même pour créer des modèles intéressants :
Toutefois, augmentant progressivement la Rotation propriété d’un élément peut faillir à long terme, comme le
RotationBreakdown montre des exemples.
Le SpinningImage exemple utilise RotateTo , RotateXTo , et RotateYTo pour donner l’impression que si une
image bitmap fait tourner dans l’espace 3D.
Animer la propriété bounds
La seule méthode d’extension de ViewExtensions pas encore montré est LayoutTo , qui anime efficacement en
lecture seule Bounds propriété en appelant le Layout (méthode). Cette méthode est appelée normalement par
Layout dérivés que nous aborderons dans chapitre 26. CustomLayouts.
Le LayoutTo méthode doit être limitée à des usages spéciaux. Le BouncingBox programme l’utilise pour
compresser et décompresser un BoxView comme il rebondit sur les côtés d’une page.
Le XamagonXuzzle exemple utilise LayoutTo pour déplacer des vignettes disponibles dans une implémentation
de classique puzzle de 15-16 qui affiche une image brouillée plutôt que les vignettes numérotées :
Vos propres animations pouvant être attendues

Le TryAwaitableAnimation exemple crée une animation pouvant être attendue. La classe essentielle qui peut
retourner un Task objet à partir de la méthode et le signal lorsque l’animation est terminée est
TaskCompletionSource .
Plus profondément dans les animations

Le système d’animation Xamarin.Forms peut être un peu déroutant. Outre le Easing (classe), le système
d’animation comprend le ViewExtensions , Animation , et AnimationExtension classes.
Classe de ViewExtensions
Vous avez déjà vu ViewExtensions . Il définit neuf méthodes qui retournent Task<bool> et CancelAnimations .
Sept de la cible de neuf méthodes propriétés de transformation. Les deux autres sont FadeTo , les cibles le
Opacity propriété, et LayoutTo , qui appelle le Layout (méthode).
Classe d’animation
Le Animation classe a un constructeur avec cinq arguments pour définir le rappel et les méthodes terminés et les
paramètres de l’animation.
Animations enfants peuvent être ajoutées avec Add , Insert , WithConcurrent et la surcharge de WithConcurrent
.
L’objet d’animation est ensuite démarré avec un appel à la Commit (méthode).
Classe de AnimationExtensions
Le AnimationExtensions classe contient principalement des méthodes d’extension. Il existe plusieurs versions d’un
Animate (méthode) et les génériques Animate méthode est donc polyvalente pour qu’il est vraiment de la
fonction d’animation uniquement que vous avez besoin.
Utilisation de la classe d’Animation

Le ConcurrentAnimations exemple illustre la Animation classe avec plusieurs animations différents.
Animations enfants
Le ConcurrentAnimations exemple illustre également l’enfant d’animations qui utilisent le (similaire) Add et
Insert méthodes.
Au-delà des méthodes de haut niveau d’animation
Le ConcurrentAnimations exemple montre également comment exécuter des animations qui dépassent les
propriétés ciblées par le ViewExtensions méthodes. Dans un exemple, une série de périodes d’obtenir plus de
temps ; dans un autre exemple, un BackgroundColor propriété est animée.
Plusieurs de vos propres méthodes pouvant être attendus
Le TranslateTo méthode de ViewExtensions ne fonctionne pas avec le Easing.SpringOut (fonction). Il s’arrête
lorsque la sortie accélération obtient supérieures à 1.
Le Xamarin.FormsBook.Toolkit bibliothèque contient un MoreViewExtensions classe avec TranslateXTo et
TranslateYTo les méthodes d’extension qui n’ont pas ce problème, ainsi que CancelTranslateXTo et
CancelTranslateYTo méthodes d’annulation ceux animations.
Le SpringSlidingEntrance montre le TranslateXTo (méthode).

Le MoreExtensions classe contient également un TranslateXYTo méthode d’extension qui combine la traduction de
X et Y, et un CancelTranslateXYTo (méthode).
Implémentation d’une animation de Bézier
Il est également possible de développer une animation qui déplace un élément le long du tracé d’une spline de
Bézier. Le Xamarin.FormsBook.Toolkit bibliothèque contient un BezierSpline structure qui encapsule une
spline de Bézier et un BezierTangent énumération pour contrôler l’orientation.
Le MoreViewExtensions classe contient un BezierPathTo méthode d’extension et un CancelBezierPathTo
(méthode).
Le BezierLoop exemple illustre l’animation d’un élément le long d’un chemin d’accès Beizer.
Utilisation de AnimationExtensions
Un seul type d’animation manquant à partir de la collection standard est une animation de couleur. Le problème
est qu’il n’existe aucun moyen de droite pour interpoler entre deux Color valeurs. Il est possible d’interpoler les
valeurs RVB individuelles, mais simplement comme étant valides interpoler les valeurs TSL.
Pour cette raison, le MoreViewExtensions classe dans le Xamarin.FormsBook.Toolkit bibliothèque contient deux
Color méthodes d’animation : RgbColorAnimation et HslColorAnimation . ( Il existe également deux méthodes
d’annulation : CancelRgbColorAnimation et CancelHslColorAnimation ).
Les deux méthodes utilisent ColorAnimation , qui effectue l’animation en appelant le générique étendu Animate
méthode dans AnimationExtensions .
Le ColorAnimations exemple illustre l’utilisation de ces deux types d’animations de couleur.
Structuration de vos animations

Il est parfois utile exprimer des animations dans XAML et les utiliser conjointement avec MVVM. Cela est couvert
dans le chapitre suivant, chapitre 23. Déclencheurs et comportements.
Liens connexes
Animation
Résumé du chapitre 23. Déclencheurs et
comportements
Déclencheurs et comportements sont similaires, car ils sont tous les deux destinés à être utilisé dans les fichiers
XAML pour simplifier les interactions d’élément au-delà de l’utilisation des liaisons de données et pour étendre
les fonctionnalités des éléments XAML. Déclencheurs et comportements sont presque toujours utilisés avec les
objets d’interface utilisateur visual.
Pour prendre en charge les déclencheurs et les comportements, les deux VisualElement et Style prennent en
charge les deux propriétés de collection :
VisualElement.Triggers et Style.Triggers de type IList<TriggerBase>
VisualElement.Behaviors et Style.Behaviors de type IList<Behavior>
Déclencheurs
Un déclencheur est une condition (une modification de propriété ou le déclenchement d’un événement) qui
génère une réponse (un autre changement de propriété ou en cours d’exécution du code). Le Triggers propriété
du VisualElement et Style est de type IList<TriggersBase> . TriggerBase est une classe abstraite dont dérivent
les classes sealed quatre :
Trigger pour les réponses en fonction des modifications de propriété
EventTrigger pour les réponses en fonction de déclenchement d’événement
DataTrigger pour les réponses en fonction des liaisons de données
MultiTrigger pour les réponses selon plusieurs déclencheurs
Le déclencheur est toujours défini sur l’élément dont la propriété est en cours de modification par le déclencheur.
Le déclencheur de la plus simple
Le Trigger recherche un changement d’une valeur de propriété de classe et répond en définissant une autre
propriété du même élément.
Trigger définit trois propriétés :
Property de type BindableProperty
Value de type Object
Setters de type IList<SetterBase> , la propriété de contenu de Trigger
En outre, Trigger nécessite que la propriété suivante héritée TriggerBase être définies :
TargetType pour indiquer le type de l’élément sur lequel le Trigger est attaché
Le Property et Value constituent la condition et le Setters collection est la réponse. Lorsque l’indiquée
Property a la valeur indiquée par Value , le Setter des objets dans le Setters collection sont appliquées.
Lorsque le Property a une valeur différente, les accesseurs Set sont supprimés. Setter définit deux propriétés
qui sont les mêmes que les deux premières propriétés de Trigger :
Property de type BindableProperty
Le EntryPop exemple montre comment un Trigger appliqué à un Entry peut augmenter la taille de la Entry
via la Scale propriété lorsque la IsFocused propriété de la Entry est true .
Bien qu’il n’est pas courant, la Trigger peut être défini dans le code, comme le EntryPopCode montre des
exemples.
Le StyledTriggers exemple montre comment la Trigger peuvent être définies dans un Style à appliquer à
plusieurs Entry éléments.
Déclencher des actions et les animations
Il est également possible d’exécuter un peu de code basé sur un déclencheur.Ce code peut être une animation qui
cible une propriété. Une façon courante consiste à utiliser un EventTrigger , qui définit deux propriétés :
Event de type string , le nom d’un événement
Actions de type IList<TriggerAction> , une liste d’actions à exécuter en réponse.
Pour l’utiliser, vous devez écrire une classe qui dérive de TriggerAction<T> , généralement
TriggerAction<VisualElement> . Vous pouvez définir les propriétés de cette classe. Il s’agit des propriétés CLR
normales plutôt que des propriétés pouvant être liées, car TriggerAction ne dérive pas de BindableObject . Vous
devez substituer la Invoke méthode est appelée lorsque l’action est appelée. L’argument est l’élément cible.
Le ScaleAction classe dans le Xamarin.FormsBook.Toolkit bibliothèque est un exemple. Il appelle le ScaleTo
propriété à animer le Scale propriété d’un élément. Étant donné qu’un de ses propriétés est de type Easing , le
EasingConverter classe vous permet d’utiliser la norme Easing champs statiques dans XAML.
Le EntrySwell exemple montre comment appeler le ScaleAction à partir de EventTrigger objets qui surveille le
Focused et Unfocused événements.
Le CustomEasingSwell exemple montre comment définir une fonction d’accélération personnalisée pour
ScaleAction dans un fichier code-behind.
Vous pouvez également appeler des actions à l’aide un Trigger (distinguished de EventTrigger ). Cela nécessite
que vous êtes conscient que TriggerBase définit deux collections :
EnterActions de type IList<TriggerAction>
ExitActions de type IList<TriggerAction>
Le EnterExitSwell exemple montre comment utiliser ces collections.
Plusieurs déclencheurs d’événements
Le ScaleUpAndDownAction classe dans le Xamarin.FormsBook.Toolkit appels à des bibliothèques ScaleTo à deux
reprises pour descendre en puissance. Le ButtonGrowth utilise cela dans un style EventTrigger pour fournir des
commentaires visuels lorsqu’un Button est enfoncé. Cette animation double est également possible à l’aide de
deux actions dans la collection de type DelayedScaleAction
Le ShiverAction classe dans le Xamarin.FormsBook.Toolkit bibliothèque définit une action shiver
personnalisable. Le ShiverButtonDemo illustre cela.
Le NumericValidationAction classe dans le Xamarin.FormsBook.Toolkit bibliothèque est limitée à Entry
éléments et des jeux le TextColor propriété if rouge le Text propriété n’est pas un double . Le
TriggerEntryValidation illustre cela.
Déclencheurs de données
Le DataTrigger est similaire à la Trigger , sauf qu’au lieu de la surveillance d’une propriété pour les
modifications de valeur, il surveille une liaison de données. Ainsi, une propriété dans un seul élément pour affecter
une propriété dans un autre élément.
DataTrigger définit trois propriétés :
Binding de type BindingBase
Setters de type IList<SetterBase>
Le GenderColors exemple requiert le SchoolOfFineArt bibliothèque et définit les couleurs des noms des
étudiants en bleu ou rose selon le Sex propriété :
Le ButtonEnabler exemples de jeux le IsEnabled propriété d’un Entry à False si le Length propriété de la
Text propriété de la Entry est égal à 0. Notez que le Text propriété est initialisée avec une chaîne vide ; par
défaut, il est null et le DataTrigger ne fonctionnent pas correctement.
Combinaison de conditions dans le MultiTrigger
Le MultiTrigger est une collection de conditions. Lorsqu’ils sont tous les true , puis les accesseurs Set est
appliquées. La classe définit deux propriétés :
Conditions de type IList<Condition>
Setters de type IList<Setter>
Condition est une classe abstraite et dispose de deux classes descendants :
PropertyCondition , qui a Property et Value propriétés telles que Trigger
BindingCondition , qui a Binding et Value propriétés telles que DataTrigger
Dans le conditionsd exemple, un BoxView est coloré uniquement lorsqu’il y a quatre Switch éléments sont tous
activés.
Le OrConditions exemple montre comment vous pouvez effectuer un BoxView une couleur lorsque n’importe
quel de quatre Switch éléments sont sous tension. Cela nécessite une application de la loi de Morgan à
l’Allemagne et en inversant toute la logique.
Combinaison de AND et ou logique n’est pas si facile et nécessite généralement invisible Switch éléments des
résultats intermédiaires. Le XorConditions exemple montre comment un Button peut être activée si une de deux
Entry éléments ont du texte tapé, mais pas s’ils ont tous deux du texte tapé dans.
comportements
Tout ce que vous pouvez faire avec un déclencheur, vous pouvez également faire avec un comportement, mais les
comportements nécessitent toujours une classe qui dérive de Behavior<T> et remplace les deux méthodes
suivantes :
OnAttachedTo
OnDetachingFrom
L’argument est l’élément auquel le comportement est associé à. En règle générale, le OnAttachedTo méthode
attache des gestionnaires d’événements, et OnDetachingFrom détache les. Étant donné qu’une telle classe
enregistre généralement un état, il généralement ne peut pas être partagé dans un Style .
BehaviorEntryValidation exemple est similaire à TriggerEntryValidation sauf qu’elle utilise un comportement
— le NumericValidationBehavior classe dans le Xamarin.FormsBook.Toolkit bibliothèque.
Comportements avec des propriétés
Behavior<T> dérive de Behavior , qui dérive à son BindableObject , de sorte que les propriétés pouvant être liées
peuvent être définies sur un comportement. Ces propriétés peuvent être actives dans les liaisons de données.
Cela est illustré dans le EmailValidationDemo programme et qui utilisent le ValidEmailBehavior classe dans le
Xamarin.FormsBook.Toolkit bibliothèque. ValidEmailBehavior a une propriété en lecture seule et sert de
source dans les liaisons de données.
Le EmailValidationConv exemple utilise ce même comportement pour afficher un autre type d’indicateur pour
signaler qu’une adresse de messagerie est valide.
Le EmailValidationTrigger exemple est une variante de l’exemple précédent. ButtonGlide utilise un DataTrigger
en association avec ce comportement.
Active/désactive et les cases à cocher
Il est possible d’encapsuler le comportement d’un bouton bascule dans une classe comme ToggleBehavior dans le
Xamarin.FormsBook.Toolkit bibliothèque, puis définissez toutes les les éléments visuels pour le bouton bascule
entièrement dans XAML.
Le ToggleLabel exemple utilise le ToggleBehavior avec un DataTrigger à utiliser un Label avec deux chaînes de
texte pour le bouton bascule.
Le FormattedTextToggle exemple étend ce concept en basculant entre deux FormattedString objets.
Le ToggleBase classe dans le Xamarin.FormsBook.Toolkit dérive de la bibliothèque ContentView , définit un
IsToggled propriété et incorpore un ToggleBehavior pour le bouton bascule logique. Cela rend plus facile de
définir le bouton bascule dans XAML, comme illustré par la TraditionalCheckBox exemple.
Le SwitchCloneDemo inclut un SwitchClone classe qui dérive de ToggleBase et utilise un TranslateAction
classe pour construire un bouton bascule qui ressemble à la Xamarin.Forms Switch .
Un RotateAction dans le Xamarin.FormsBook.Toolkit fournit une animation utilisée pour effectuer un levier
animé dans la LeverToggle exemple.
Réponse aux clics
L’inconvénient de EventTrigger est que vous ne pouvez pas attacher un TapGestureRecognizer pour répondre aux
clics. Pour contourner ce problème est l’objectif de TapBehavior dans le Xamarin.FormsBook.Toolkit
Le BoxViewTapShiver exemple utilise TapBehavior à utiliser l’ancien ShiverAction pour l’appui sur BoxView
éléments.
Le ShiverViews exemple montre comment réduire le balisage en encapsulant un ShiverView classe.
Cases d’option
Le Xamarin.FormsBook.Toolkit bibliothèque possède également un RadioBehavior classe pour effectuer des
cases d’option qui sont regroupées par un string nom du groupe.
Le RadioLabels programme utilise des chaînes de texte de sa case. Le RadioStyle exemple utilise un Style
pour la différence d’aspect entre les boutons checked et unchecked. Le RadioImages exemple utilise des images
boxed pour ses boutons radio :
Le TraditionalRadios exemple dessine traditionnel boutons radio qui apparaît avec un point à l’intérieur d’un
cercle.
Effectuer des fondus et l’orientation
L’exemple final, MultiColorSliders vous permet de basculer entre trois modes de sélection de couleur différente
à l’aide de cases d’option. Les trois vues de fondu et arrière à l’aide un FadeEnableAction dans le
Xamarin.FormsBook.Toolkit bibliothèque.
Le programme répond également aux modifications de l’orientation portrait ou paysage à l’aide un
GridOrientationBehavior dans le Xamarin.FormsBook.Toolkit bibliothèque.
Liens connexes
Utilisation des déclencheurs
Comportements de Xamarin.Forms
Résumé du chapitre 24. Navigation entre les pages
De nombreuses applications sont constituées de plusieurs pages parmi lesquels l’utilisateur navigue. L’application
always a un principal page ou domestique page, et à partir de là, l’utilisateur navigue vers d’autres pages, qui sont
conservées dans une pile de navigation vers l’arrière. Options de navigation supplémentaires sont couverts dans
chapitre 25. Page variétés.
Pages modales et non modales

VisualElement définit un Navigation propriété de type INavigation , qui inclut les deux méthodes suivantes pour
accéder à une nouvelle page :
PushAsync
PushModalAsync
Les deux méthodes acceptent une Page instance en tant qu’argument et retournent un Task objet. Les deux
méthodes suivantes accédez à la page précédente :
PopAsync
PopModalAsync
Si l’interface utilisateur possède son propre retour bouton (comme les téléphones Android et Windows), il n’est
pas nécessaire pour l’application d’appeler ces méthodes.
Bien que ces méthodes sont disponibles à partir d’un VisualElement , elles sont généralement appelées à partir la
Navigation propriété du courant Page instance.
Les applications utilisent généralement des pages modales quand l’utilisateur est requis pour fournir des
informations sur la page avant de retourner à la page précédente. Les pages qui ne sont pas modales sont parfois
appelés non modales ou hiérarchique. Rien dans la page elle-même distingue en tant que modale ou non modale ;
Il est soumise à la place la méthode utilisée pour naviguer jusqu'à lui. Pour fonctionner sur toutes les plateformes,
une page modale doit fournir sa propre interface utilisateur pour revenir à la page précédente.
Le ModelessAndModal exemple vous permet d’Explorer la différence entre les pages non modales et modales.
Toute application qui utilise la navigation entre les pages doive passer sa page d’accueil pour le NavigationPage
constructeur, généralement dans le programme App classe. Un bonus est que vous n’avez plus besoin de définir
un Padding sur la page pour iOS.
Vous découvrirez que pour les non modales pages, la page Title propriété s’affiche. IOS, Android et les
plateformes de tablette et bureau Windows fournissent un élément d’interface utilisateur pour revenir à la page
précédente. Des cours, Android et Windows, les téléphones ont une norme retour bouton revenir en arrière.
Pour les pages modales, la page Title n’est pas affichée, et aucun élément d’interface utilisateur n’est fournie pour
revenir à la page précédente. Bien que vous pouvez utiliser la norme de téléphone Android et Windows retour
bouton pour revenir à la page précédente, la page modale sur d’autres plateformes doit fournir son propre
mécanisme pour revenir en arrière.
Transitions de page animés
Autres versions des différentes méthodes de navigation sont fournies avec un deuxième argument booléen que
vous définissez pour true si vous souhaitez que la transition de page à inclure une animation :
PushAsync
PushModalAsync
PopAsync
PopModalAsync
Toutefois, les méthodes de navigation de page standard incluent l’animation par défaut, afin qu’ils soient
uniquement un outil précieux pour la navigation vers une page particulière au démarrage (comme indiqué à la fin
de ce chapitre) ou lorsque vous fournissez votre propre animation d’entrée (comme indiqué dans Chapter22.
Animation).
Variations de visuels et fonctionnelles
NavigationPage inclut deux propriétés que vous pouvez définir lorsque vous instanciez la classe dans votre App
méthode :
BarBackgroundColor
BarTextColor
NavigationPage inclut également les quatre propriétés jointes pouvant être liées qui affectent la page spécifique
sur lequel elles sont définies :
SetHasBackButton et GetHasBackButton
SetHasNavigationBar et GetHasNavigationBar
SetBackButtonTitle et GetBackButtonTitle Professionnel sur iOS uniquement
SetTitleIcon et GetTitleIcon Professionnel sur iOS et Android uniquement
Explorer la mécanique
Les méthodes de navigation de page sont toutes asynchrones et doit être utilisés avec await . La saisie semi-
automatique n’indique pas que navigation entre les pages est terminée, mais uniquement qu’il est sécurisé
examiner la pile de navigation entre les pages.
Lorsqu’une page accède à un autre, la première page obtienne généralement un appel à son OnDisappearing
(méthode) et la deuxième page reçoit un appel à son OnAppearing (méthode). De même, quand une page est
retournée à l’autre, la première page reçoit un appel à son OnDisappearing (méthode) et la deuxième page obtient
généralement un appel à son OnAppearing (méthode). L’ordre de ces appels (et l’achèvement des méthodes
asynchrones qui appelle le volet de navigation) est dépendant de la plate-forme. L’utilisation du mot
« généralement » dans les deux instructions ci-dessus est en raison de la navigation modale-page Android, dans
lequel ces appels de méthode ne se produisent.
En outre, les appels à la OnAppearing et OnDisappearing méthodes n’indiquent pas nécessairement navigation
entre les pages.
Le INavigation interface inclut deux propriétés de collection qui vous permettent d’examiner la pile de navigation :
NavigationStack de type IReadOnlyList<Page> pour la pile non modale
ModalStack de type IReadOnlyList<Page> pour la pile modale
Il est plus sûr d’accéder à ces piles à partir de la Navigation propriété de la NavigationPage (qui doit être le App la
classe MainPage propriété). Il n’est plus sûr examiner ces piles une fois que les méthodes de navigation de page
asynchrone est terminé. Le CurrentPage propriété de la NavigationPage n’indique pas la page actuelle si la page
actuelle est une page modale, mais indique à la place la dernière page non modale.
Le SinglePageNavigation exemple vous permet d’Explorer la navigation entre les pages et les piles et les types
juridiques de navigation de page :
Une page non modale peut naviguer vers une autre page non modale ou une page modale
Une page modale peut uniquement naviguer vers une autre page modale
En appliquant la modalité
Une application utilise une page modale lorsqu’il est nécessaire obtenir des informations à partir de l’utilisateur.
L’utilisateur doit être interdit de retourner à la page précédente jusqu'à ce que cette information est fournie. Sur
iOS, il est facile de fournir un retour bouton et activez-la uniquement lorsque l’utilisateur a fini avec la page. Mais
pour les appareils Android et Windows phone, l’application doit remplacer le OnBackButtonPressed méthode et
retournez true si le programme a géré le retour bouton lui-même, comme illustré dans le ModalEnforcement
exemple.
Le MvvmEnforcement exemple illustre comment cela fonctionne dans un scénario MVVM.
Variations de navigation
Si une page modale particulier peut être accédée à plusieurs fois, il doit conserver les informations afin que
l’utilisateur peut modifier les informations au lieu de taper tous dans une nouvelle fois. Vous pouvez le gérer en
conservant l’instance particulière de la page modale, mais une meilleure approche (en particulier sur iOS )
conserve les informations contenues dans un modèle de vue.
Rendre un menu de navigation
Le ViewGalleryType exemple montre comment utiliser un TableView pour répertorier les éléments de menu.
Chaque élément est associé un Type objet pour une page particulière. Lorsque cet élément est sélectionné, le
programme instancie la page et navigue vers elle.
Le ViewGalleryInst exemple est un peu différente car le menu contient des instances de chaque page plutôt que
des types. Cela permet de conserver les informations à partir de chaque page, mais toutes les pages doivent être
instanciés au démarrage du programme.
Manipulation de la pile de navigation
StackManipulation montre plusieurs fonctions définies par INavigation qui vous permettent de manipuler la
pile de navigation de manière structurée :
RemovePage
InsertPageBefore
PopToRootAsync et PopToRootAsync avec animation facultative
Génération de page dynamique
Le BuildAPage exemple illustre la construction d’une page lors de l’exécution en fonction de l’entrée d’utilisateur.
Modèles de transfert de données

Il est souvent nécessaire de partager des données entre les pages — pour transférer des données vers une page de
navigation et d’une page retourner des données à la page qui l’a appelée. Il existe plusieurs techniques permettant
de le faire.
Arguments de constructeur
Lors de la navigation vers une nouvelle page, il est possible d’instancier la classe de page avec un argument de
constructeur qui permet à la page pour s’initialiser. Le SchoolAndStudents illustre cela. Il est également possible
d’avoir une page naviguée son BindingContext définie par la page qui navigue vers elle.
Propriétés et appels de méthode
Les autres exemples de transfert de données d’Explorer le problème de passer des informations entre les pages
quand une page navigue vers une autre page et inversement. Dans ces discussions, les domestique page accède à
la info page et doit transférer des informations initialisées à la info page. Le info page obtient des informations
supplémentaires à partir de l’utilisateur et transfère les informations à la domestique page.
Le domestique page permettre accéder facilement aux méthodes publiques et les propriétés dans le info page dès
qu’il instancie cette page. Le info page permettre également accéder aux méthodes publiques et les propriétés dans
le domestique page, mais que le choix d’un bon moment pour Ceci peut être difficile. Le DateTransfer1 exemple
fait cela dans son OnDisappearing remplacer. L’inconvénient est que le info page doit connaître le type de la
domestique page.
MessagingCenter
Xamarin.Forms MessagingCenter classe fournit une autre façon pour les deux pages communiquer entre eux. Les
messages sont identifiés par une chaîne de texte et peuvent être accompagnés de n’importe quel objet.
Un programme qui souhaite recevoir des messages à partir d’un type particulier doit s’abonner à eux à l’aide de
MessagingCenter.Subscribe et spécifier une fonction de rappel. Plus tard, il peut se désabonner en appelant
MessagingCenter.Unsubscribe . La fonction de rappel reçoit tout message envoyé à partir du type spécifié avec le
nom spécifié est envoyé via le Send (méthode).
Le DateTransfer2 programme montre comment transférer des données à l’aide du centre de messagerie, mais là
encore, ceci nécessite que le info page connaître le type de la accueil page.
Événements
L’événement est une approche précieuses pour une classe envoyer des informations à une autre classe sans
connaître les type de cette classe. Dans le DateTransfer3 exemple le info classe définit un événement qu’il se
déclenche lorsque les informations sont prêtes. Toutefois, il n’existe aucun emplacement pratique où les le
domestique page pour détacher le Gestionnaire d’événements.
L’intermédiaire de la classe application
Le DateTransfer4 exemple montre comment accéder aux propriétés définies dans le App classe à la fois par le
domestique page et le infopage. Il s’agit d’une bonne solution, mais la section suivante décrit une meilleure
solution.
Passage à un ViewModel
À l’aide d’un ViewModel pour les informations permettant la domestique page et le info page à partager l’instance
de la classe d’informations. Cela est illustré dans le DateTransfer5 exemple.
Enregistrement et restauration de l’état de la page
Le App intermédiaire de la classe ou l’approche ViewModel est idéale lors de l’application doit enregistrer vos
informations si le programme se met en veille pendant que le info page est active. Le DateTransfer6 illustre cela.
Enregistrement et restauration de la pile de navigation
En règle générale, un programme de plusieurs pages qui se met en veille doit accéder à la même page lorsqu’elle
est restaurée. Cela signifie qu’un tel programme doit enregistrer le contenu de la pile de navigation. Cette section
montre comment automatiser ce processus dans une classe conçue à cet effet. Cette classe appelle également les
pages individuelles pour les autoriser à enregistrer et restaurer leur état de la page.
Le Xamarin.FormsBook.Toolkit bibliothèque définit une interface nommée IPersistantPage que les classes
peuvent implémenter pour enregistrer et restaurer des éléments dans le Properties dictionnaire.
Le MultiPageRestorableApp classe dans le Xamarin.FormsBook.Toolkit dérive de la bibliothèque Application .
Vous pouvez ensuite dériver votre App classe MultiPageRestorableApp et effectuer un peu de ménage.
Le StackRestoreDemo illustre l’utilisation de MultiPageRestorableApp .
Quelque chose comme une application de la vie réelle
Le NoteTaker exemple utilise également MultiPageRestorableApp , tout en permettant à l’entrer et de modifier des
notes qui sont enregistrés dans le Properties dictionnaire.
Liens connexes
Navigation hiérarchique
Pages modales
Résumé du chapitre 25. Types de page
Jusqu'à présent, vous avez vu deux classes qui dérivent de Page : ContentPage et NavigationPage . Ce chapitre
présente deux autres :
MasterDetailPage gère les deux pages, un serveur maître et un détail
TabbedPage gère plusieurs pages enfants accédés via les onglets
Ces types de page fournissent les options de navigation plus sophistiquées que la NavagationPage abordés dans
chapitre 24. Navigation entre les pages.
Maître / détail
Le MasterDetailPage définit deux propriétés de type Page : Master et Detail . En règle générale, vous définissez
chacune de ces propriétés pour un ContentPage . Le MasterDetailPage affiche et permet de basculer entre ces deux
pages.
Il existe deux méthodes fondamentales pour basculer entre ces deux pages :
Fractionner où maître et détail sont côte à côte
menu où la page de détails couvre ou couvre partiellement le contrôleur de page
Il existe plusieurs variantes de la menu approche (diapositive, se chevauchent, et échange), mais il s’agit
généralement de plateforme dépendants. Vous pouvez définir le MasterDetailBehavior propriété du
MasterDetailPage à un membre de la MasterBehavior énumération :
Default
Split
SplitOnLandscape
SplitOnPortrait
Popover
Toutefois, cette propriété n’a aucun effet sur les téléphones. Les téléphones ont toujours un comportement de
menu. Seuls les tablettes et les postes de travail windows peuvent avoir un comportement de fractionnement.
Analyse des comportements
Le MasterDetailBehaviors exemple vous permet de faire des essais avec le comportement par défaut sur
différents appareils. Le programme contient deux distinct ContentPage dérivés pour maître et détail (avec un
Title propriété définie sur les deux) et une autre classe qui dérive de MasterDetailPage qui combine les. La page
de détails est placée dans un NavigationPage , car le programme UWP ne fonctionnerait pas sans lui.
Les plateformes Windows 8.1 et Windows Phone 8.1 exigent qu’une image bitmap soit définie sur le Icon
propriété de la page maître.
Retour à l’école
Le SchoolAndDetail exemple adopte une approche un peu différente à construire le programme affiche les
étudiants à partir de la SchoolOfFineArt bibliothèque.
Le Master et Detail propriétés sont définies avec des arborescences d’éléments visuels dans le
SchoolAndDetailPage.xaml fichier, qui dérive de MasterDetailPage . Ceci permet des liaisons de données à définir
entre les pages maître et détail.
Que les fichiers XAML définit également la IsPresented propriété du MasterDetailPage à True . Cela entraîne la
page maître à afficher au démarrage. par défaut, la page de détails s’affiche. Le SchoolAndDetailPage.xaml.cs
fichier définit IsPresented à false lorsqu’un élément est sélectionné à partir de la ListView dans la page maître.
La page de détails s’affiche ensuite :
Votre propre interface utilisateur

Bien que Xamarin.Forms fournit une interface utilisateur pour basculer entre les vues maître et détail, vous pouvez
fournir votre propre. Pour ce faire :
Définir le IsGestureEnabled propriété false pour désactiver le balayage
Remplacer le ShouldShowToolbarButton méthode et retournez false pour masquer les boutons de barre
d’outils de Windows 8.1 et Windows Phone 8.1.
Vous devez ensuite fournir un moyen de basculer entre les pages maître et détail, comme illustré par la
ColorsDetail exemple.
Le MasterDetailTaps exemple montre comment utiliser une autre approche un TapGestureRecognizer sur les
pages maître et détail.
TabbedPage
Le TabbedPage est une collection de pages que vous pouvez passer à l’aide des onglets. Il dérive MultiPage<Page>
et ne définit aucun propriétés ou méthodes publiques qui lui sont propres. MultiPage<T> , toutefois, définit une
propriété :
Children propriété de type IList<T>
Vous renseignez ceci Children collection avec des objets de la page.

Une autre approche vous permet de définir le TabbedPage enfants fonctionne comme un ListView à l’aide de ces
deux propriétés qui génèrent automatiquement des pages à onglets :
ItemsSource de type IEnumerable
ItemTemplate de type DataTemplate
Toutefois, cette approche ne fonctionne pas correctement sur iOS lors de la collection contient plusieurs éléments.
MultiPage<T> définit les propriétés vous permettent d’effectuer le suivi de page qui est actuellement affichée :
CurrentPage de type T , qui fait référence à la page
SelectedItem de type Object , qui fait référence à l’objet dans le ItemsSource collection
MultiPage<T> définit également deux événements :

PagesChanged Lorsque le ItemsSource modifications de la collection
CurrentPageChanged Lorsque la page affichée change
Pages d’onglets discrètes

Le DiscreteTabbedColors exemple se compose de trois pages à onglets qui affichent les couleurs de trois façons
différentes. Chaque onglet est un ContentPage dérivé, puis le TabbedPage dérivé DiscreteTabbedColorsPage.xaml
combine les trois pages.
Pour chaque page qui s’affiche dans un TabbedPage , le Title propriété est requise pour spécifier le texte dans
l’onglet, et le Store d’Apple nécessite qu’une icône également être utilisé, par conséquent, le Icon propriété est
définie pour iOS :
Le StudentNotes exemple comporte une page d’accueil qui répertorie tous les étudiants. Lors de l’appui sur un
étudiant, il accède à un TabbedPage dérivé, StudentNotesDataPage , qui intègre trois ContentPage objets dans son
arborescence d’éléments visuels, un d'entre eux permet d’entrer des remarques pour que les élèves.
À l’aide d’un modèle ItemTemplate
Le MultiTabbedColor exemple utilise le NamedColor classe dans le Xamarin.FormsBook.Toolkit bibliothèque.
Le MultiTabbedColorsPage.xaml fichier définit les DataTemplate propriété de TabbedPage vers un début de
l’arborescence d’éléments visuels avec ContentPage qui contient des liaisons aux propriétés de NamedColor (y
compris une liaison à la Title propriété).
Toutefois, cela peut être problématique sur iOS. Quelques-uns des éléments peuvent être affichées, et il n’existe
aucun bon moyen de leur donner des icônes.
Liens connexes
Page maître / détails
Page à onglets
Résumé du chapitre 26. Dispositions personnalisées
Xamarin.Forms inclut plusieurs classes dérivées de Layout<View> :
StackLayout ,
Grid ,
AbsoluteLayout et
RelativeLayout .
Ce chapitre explique comment créer vos propres classes qui dérivent de Layout<View> .
Une vue d’ensemble de mise en page

Il n’existe aucun système centralisé qui gère la disposition de Xamarin.Forms. Chaque élément est chargé de
déterminer ce que sa taille doit être et comment effectuer le rendu de lui-même au sein d’une zone particulière.
Parents et enfants
Chaque élément qui a des enfants est chargé pour le positionnement de ces enfants à l’intérieur de lui-même. Il est
le parent qui détermine la taille adaptée à ses enfants doit être basé sur la taille, il propose disponible et la taille de
l’enfant souhaite être.
Dimensionnement et de positionnement
Disposition commence en haut de l’arborescence d’éléments visuels avec la page et se poursuit dans toutes les
branches. La méthode la plus importante publique dans la disposition est Layout défini par VisualElement .
Chaque élément est parent d’autres appels éléments Layout pour chacun de ses enfants à donner à l’enfant, une
taille et la position par rapport à lui-même sous la forme d’un Rectangle valeur. Ces Layout propagent des
appels dans l’arborescence visuelle.
Un appel à Layout est requis pour un élément à l’écran et les propriétés en lecture seule suivantes à définir. Elles
sont cohérentes avec le Rectangle transmis à la méthode :
Bounds de type Rectangle
X de type double
Y de type double
Width de type double
Height de type double
Avant la Layout appeler, Height et Width comportent des valeurs fictifs –1.
Un appel à Layout déclenche également des appels aux méthodes protégées suivantes :
SizeAllocated , qui appelle
OnSizeAllocated , qui peut être substitué.
Enfin, l’événement suivant sont déclenché :

SizeChanged
Le OnSizeAllocated méthode est substituée par Page et Layout , qui sont les seules deux classes dans
Xamarin.Forms qui peut avoir des enfants. Les appels de méthode substituée
UpdateChildrenLayout pour Page dérivés et UpdateChildrenLayout pour Layout dérivés, qui appelle
LayoutChildren pour Page dérivés et LayoutChildren pour Layout dérivés.
LayoutChildrenappelle ensuite Layout pour chacun des enfants de l’élément. Si au moins un enfant dispose d’un
nouveau Bounds définition, puis l’événement suivant sont déclenché :
LayoutChanged pour Page dérivés et LayoutChanged pour Layout dérivés
Contraintes et des demandes de taille
Pour LayoutChildren intelligemment appeler Layout sur tous ses enfants, il doit connaître un préféré ou
souhaitée taille pour les enfants. Par conséquent, les appels à Layout pour chacun des enfants sont généralement
précédé par des appels à
GetSizeRequest
Une fois que le livre a été publié, le GetSizeRequest méthode a été déconseillée et remplacée par
Measure
Le Measure méthode prend en compte la Margin propriété et comprend un argument de type MeasureFlag , qui a
deux membres :
IncludeMargins
None Pour ne pas inclure les marges
Pour de nombreux éléments, GetSizeRequest ou Measure Obtient la taille native de l’élément à partir de son
convertisseur. Les deux méthodes ont des paramètres pour la largeur et la hauteur contraintes. Par exemple, un
Label utilisera la contrainte de largeur pour déterminer comment encapsuler plusieurs lignes de texte.
Les deux GetSizeRequest et Measure retournent une valeur de type SizeRequest , qui a deux propriétés :
Request de type Size
Minimum de type Size
Très souvent ces deux valeurs sont identiques et le Minimum valeur peut généralement être ignorée.
VisualElement définit également une méthode protégée similaire à GetSizeRequest qui est appelée à partir de
GetSizeRequest :
OnSizeRequest Retourne un SizeRequest valeur

Cette méthode est maintenant déconseillée et remplacée par :
OnMeasure
Chaque classe qui dérive de Layout ou Layout<T> doit substituer OnSizeRequest ou OnMeasure . Il s’agit d’où une
classe de disposition détermine sa propre taille, qui est généralement basé sur la taille de ses enfants, il obtient en
appelant GetSizeRequest ou Measure sur les enfants. Avant et après l’appel OnSizeRequest ou OnMeasure ,
GetSizeRequest ou Measure apporte des ajustements basés sur les propriétés suivantes :
WidthRequest de type double , affecte le Request propriété de SizeRequest

HeightRequest de type double , affecte le Request propriété de SizeRequest
MinimumWidthRequest de type double , affecte le Minimum propriété de SizeRequest
MinimumHeightRequest de type double , affecte le Minimum propriété de SizeRequest
Contraintes infinies
Les arguments de contrainte passés à GetSizeRequest (ou Measure ) et OnSizeRequest (ou OnMeasure ) peut être
infinie (par exemple, les valeurs de Double.PositiveInfinity ). Toutefois, le SizeRequest retourné à partir de ces
méthodes ne peuvent pas contenir des dimensions infinies.
Contraintes infinies indiquent que la taille demandée doit refléter la taille naturelle de l’élément. Un vertical
StackLayout appels GetSizeRequest (ou Measure ) sur ses enfants, avec une contrainte de hauteur infinie. Appelle
une disposition de pile horizontale GetSizeRequest (ou Measure ) sur ses enfants, avec une contrainte de largeur
infinie. Un AbsoluteLayout appels GetSizeRequest (ou Measure ) sur ses enfants, avec des contraintes de la largeur
et hauteur infinies.
Lecture à l’intérieur du processus
Le ExploreChildSize affiche contrainte et la taille de demander des informations pour une disposition simple.
Dérivation à partir de la mise en page

Une classe de disposition personnalisée dérive Layout<View> . Il possède deux responsabilités :
Substituer OnMeasure pour appeler Measure sur les enfants de tous les la disposition. Retourner une taille
demandée pour la disposition lui-même
Substituer LayoutChildren pour appeler Layout sur les enfants de tous les la disposition
Le for ou foreach boucle dans ces remplacements doit ignorer tout enfant dont IsVisible propriété est définie
sur false .
Un appel à OnMeasure n’est pas garanti. OnMeasure ne sera pas appelé si le parent de la disposition est régissant la
taille de la mise en page (par exemple, une disposition qui remplit une page). Pour cette raison, LayoutChildren ne
peuvent pas reposer sur les tailles enfant obtenus au cours de la OnMeasure appeler. Très souvent, LayoutChildren
doit lui-même appeler Measure sur les enfants de la mise en page, ou vous pouvez implémenter une sorte de taille
de la mise en cache logique (décrite ultérieurement).
Un exemple simple
Le VerticalStackDemo exemple contient un simplifiée VerticalStack classe et une démonstration de son
utilisation.
Simplifié de positionnement vertical et horizontal
Un des travaux qui VerticalStack doit effectuer se produit pendant la LayoutChildren remplacer. La méthode
utilise l’enfant HorizontalOptions propriété afin de déterminer comment positionner l’enfant dans son
emplacement dans le VerticalStack . Vous pouvez appeler la méthode statique
Layout.LayoutChildIntoBoundingRect . Cette méthode appelle Measure sur l’enfant et utilise son HorizontalOptions
et VerticalOptions propriétés pour positionner l’enfant dans le rectangle spécifié.
Invalidation
Souvent une modification de propriété d’un élément sur comment cet élément apparaît dans la disposition. La
disposition doit être rendus non valide pour déclencher une nouvelle disposition.
VisualElement définit une méthode protégée InvalidateMeasure , qui est généralement appelée par le
Gestionnaire de modification de propriété de n’importe quelle propriété pouvant être liée dont la modification
affecte la taille de l’élément. Le InvalidateMeasure méthode déclenche un MeasureInvalidated événement.
Le Layout classe définit une méthode protégée similaire nommée InvalidateLayout , qui une Layout dérivé doit
appeler pour toute modification qui affecte la façon dont il positionne et redimensionne ses enfants.
Certaines règles de codage des dispositions
1. Propriétés définies par Layout<T> dérivés doivent être assorties de propriétés pouvant être liées et les
gestionnaires de modification de propriété doivent appeler InvalidateLayout .
2. Un Layout<T> dérivé qui définit les propriétés pouvant être liées attachées doit substituer OnAdded pour
ajouter un gestionnaire de modification de propriété à ses enfants et OnRemoved pour supprimer les
Gestionnaire. Le gestionnaire doit vérifier pour les modifications dans ces attachés propriétés pouvant être
liées et répondre en appelant InvalidateLayout .
3. Un Layout<T> dérivée qui implémente un cache de tailles d’enfants doit substituer InvalidateLayout et
OnChildMeasureInvalidated et effacer le cache lorsque ces méthodes sont appelées.
Une disposition avec des propriétés

Le WrapLayout classe dans le Xamarin.FormsBook.Toolkit suppose que tous ses enfants sont la même taille et
les enfants est renvoyé à partir d’une ligne (ou colonne) à l’autre. Il définit un Orientation propriété comme
StackLayout , et ColumnSpacing et RowSpacing propriétés telles que Grid , et il met en cache les tailles d’enfant.
Le PhotoWrap exemple met un WrapLayout dans un ScrollView pour l’affichage des photos en stock.
Aucune dimension sans contrainte autorisée !
Le UniformGridLayout dans le Xamarin.FormsBook.Toolkit bibliothèque est destinée à afficher tous ses enfants
en lui-même. Par conséquent, il ne peut pas traiter avec des dimensions sans contrainte et lève une exception si un
est rencontré.
Le PhotoGrid illustre UniformGridLayout :
Enfants qui se chevauchent

Un Layout<T> dérivé peut se chevaucher ses enfants. Toutefois, les enfants sont rendus dans leur ordre dans le
Children collection et pas l’ordre dans lequel leurs Layout méthodes sont appelées.
Le Layout classe définit deux méthodes qui vous permettent de déplacer un enfant au sein de la collection :
LowerChild Pour déplacer un enfant au début de la collection
RaiseChild Pour déplacer un enfant à la fin de la collection
Pour les enfants qui se chevauchent, enfants à la fin de la collection s’affichent visuellement au-dessus enfants au
début de la collection.
Le OverlapLayout classe dans le Xamarin.FormsBook.Toolkit bibliothèque définit une propriété jointe pour
indiquer l’ordre de rendu et permettra ainsi à un de ses enfants à afficher sur les autres. Le StudentCardFile
illustre cela :
Plus attaché propriétés pouvant être liées
Le CartesianLayout classe dans le Xamarin.FormsBook.Toolkit bibliothèque définit des propriétés pouvant être
liées attachées pour spécifier deux Point valeurs et un valeur d’épaisseur et manipule BoxView éléments qui
ressemble à celle des lignes.
Le UnitCube exemple qui utilise pour dessiner un cube 3D.
Mise en page et LayoutTo
Un Layout<T> dérivé peut appeler LayoutTo plutôt que Layout pour animer la disposition. Le
AnimatedCartesianLayout classe pour cela et le AnimatedUnitCube illustre cela.
Liens connexes
Création de dispositions personnalisées
Résumé du chapitre 27. Renderers personnalisés
NOTE
Un élément Xamarin.Forms comme Button est rendu avec un bouton spécifique à la plateforme encapsulé dans
une classe nommée ButtonRenderer . Voici le version iOS de ButtonRenderer , le version Android du
ButtonRenderer et le version UWP de ButtonRenderer .
Ce chapitre explique comment vous pouvez écrire vos propres convertisseurs pour créer des vues personnalisées
qui mappent aux objets spécifiques à la plateforme.
La hiérarchie de classe complète

Il existe quatre assemblys qui contiennent le code spécifique à la plateforme Xamarin.Forms. Vous pouvez afficher
la source sur GitHub à l’aide de ces liens :
Xamarin.Forms.Platform (très petite)
Xamarin.Forms.Platform.iOS
Xamarin.Forms.Platform.Android
Xamarin.Forms.Platform.UAP
NOTE
Le WinRT mentionnés dans le livre des assemblys ne font plus partie de cette solution.
Le PlatformClassHierarchy exemple affiche une hiérarchie de classes pour les assemblys qui sont valides pour la
plateforme en cours d’exécution.
Vous remarquerez une classe importante nommée ViewRenderer . Il s’agit de la classe que vous dérivez de lors de
la création d’un convertisseur spécifique à la plateforme. Il existe en trois versions différentes, car il est lié au
système de vue de la plateforme cible :
IOS ViewRenderer<TView, TNativeView> a des arguments génériques :
TView limité à Xamarin.Forms.View
TNativeView limité à UIKit.UIView
Android ViewRenderer<TView, TNativeView> a des arguments génériques :

TView limité à Xamarin.Forms.View
TNativeView limité à Android.Views.View
La plateforme Windows universelle ViewRenderer<TElement, TNativeElement> a nommé différemment les

arguments génériques :
TElement limité à Xamarin.Forms.View
TNativeElement limité à Windows.UI.Xaml.FrameworkElement
Lorsque vous écrivez un convertisseur, vous serez dérivant une classe de View , puis en écrivant plusieurs
ViewRenderer des classes, une pour chaque plateforme prise en charge. Chaque implémentation propre à la
plateforme référencera une classe native qui dérive du type que vous spécifiez comme le TNativeView ou
TNativeElement paramètre.
Hello, renderers personnalisés !

Le HelloRenderers programme fait référence à une vue personnalisée nommée HelloView dans son App classe.
Le HelloView classe est incluse dans le HelloRenderers de projet et dérive simplement de View .
Le HelloViewRenderer classe dans le HelloRenderers.iOS dérive de projet ViewRenderer<HelloView, UILabel> .
Dans le OnElementChanged override, il crée un iOS native UILabel et appelle SetNativeControl .
Le HelloViewRenderer classe dans le HelloRenderers.Droid dérive de projet ViewRenderer<HelloView, TextView> .
Dans le OnElementChanged override, il crée un Android TextView et appelle SetNativeControl .
Le classe dans le HelloRenderers.UWP et autres projets Windows dérive
HelloViewRenderer
ViewRenderer<HelloView, TextBlock> . Dans le OnElementChanged override, il crée un Windows TextBlock et appelle
SetNativeControl .
Tous les le ViewRendererdérivés contiennent un ExportRenderer attribut sur le niveau de l’assembly qui associe le
HelloView classe avec le particulier HelloViewRenderer classe. Voici comment Xamarin.Forms localise les
convertisseurs dans les projets de plateforme individuels :
Convertisseurs et des propriétés

L’ensemble suivant de convertisseurs implémente le dessin de l’ellipse et se trouve dans les différents projets de la
Xamarin.FormsBook.Platform solution.
Le EllipseView classe se trouve dans le Xamarin.FormsBook.Platform plateforme. La classe est similaire à
BoxView et définit qu’une seule propriété : Color de type Color .
Les convertisseurs peuvent transférer des valeurs de propriétés définies sur un View à l’objet natif en substituant
le OnElementPropertyChanged méthode dans le convertisseur. Dans cette méthode (et, dans la plupart du
convertisseur), deux propriétés sont disponibles :
Element , l’élément Xamarin.Forms
Control , le mode natif ou l’objet de widget ou de contrôle
Les types de ces propriétés sont déterminés par les paramètres génériques à ViewRenderer . Dans cet exemple,
Element est de type EllipseView .
Le OnElementPropertyChanged remplacement peut transférer par conséquent la Color valeur de la Element natif
Control objet, probablement avec un type de conversion. Les convertisseurs de trois sont :
iOS : EllipseViewRenderer , qui utilise un EllipseUIView classe pour l’ellipse.
Android : EllipseViewRenderer , qui utilise un EllipseDrawableView classe pour l’ellipse.
UWP : EllipseViewRenderer , qui peut utiliser le Windows native Ellipse classe.
Le EllipseDemo classe affiche plusieurs de ces EllipseView objets :
Le BouncingBall rebondit un EllipseView désactivé les côtés de l’écran.
Convertisseurs et des événements

Il est également possible pour des convertisseurs générer des événements indirectement. Le StepSlider classe est
semblable à la normale Xamarin.Forms Slider mais permet de spécifier un nombre d’étapes distinctes entre le
Minimum et Maximum valeurs.
Les convertisseurs de trois sont :

iOS : StepSliderRenderer
Android : StepSliderRenderer
UWP : StepSliderRenderer
Les convertisseurs de détecter les modifications apportées au contrôle natif, puis appelez SetValueFromRenderer ,
qui fait référence à une propriété définie dans le StepSlider , une modification apportée à ce qui conduit le
StepSlider pour déclencher un ValueChanged événement.
Le StepSliderDemo exemple illustre ce nouveau curseur.
Liens connexes
Renderers personnalisés
Résumé du chapitre 28. Emplacement et mappages
NOTE
Xamarin.Forms prend en charge un Map élément dérivé View . En raison des exigences de plate-forme spéciales
liées à l’utilisation de cartes, elles sont implémentées dans un assembly distinct, Xamarin.Forms.Maps,
impliquent l’intervention d’un autre espace de noms : Xamarin.Forms.Maps .
Le système de coordonnées géographique

Un système de coordonnées géographiques identifie les positions sur un objet sphérique (ou presque sphérique),
comme la terre. Une coordonnée comprend à la fois un latitude et longitude exprimée en angles.
Un plus grand cercle appelé le equator se trouve à mi-chemin entre deux pôles par le biais duquel l’axe de la terre
s’étend sur le plan conceptuel.
Parallels et latitude
Angle mesuré à l’Équateur à partir du centre des marques de terre Nord ou lignes de latitude égale appelé
parallels. Ces comprises entre 0 degrés à l’Équateur et 90 degrés dans le nord et sud du centre pôles. Par
convention, les latitudes au nord de l’Équateur sont des valeurs positives et celles au sud de l’Équateur sont des
valeurs négatives.
Longitude et méridiens
Moitiés de cercles great depuis le pôle nord au Pôle Sud sont des lignes de longitude égale, également appelés
méridiens. Il s’agit par rapport à du premier méridien de Greenwich en Angleterre. Par convention, longitudes à
l’est des valeurs positives de 0 degrés et 180 degrés et longitudes à l’ouest du premier méridien sont des valeurs
négatives comprises entre 0 degré à –180 degrés.
La projection équirectangulaire
Tout mappage plat de la terre introduit des distorsions. Si toutes les lignes de latitude et longitude sont droits, et si
égales différences dans les angles de latitude et longitude correspondent aux distances égales sur la carte, le
résultat est un projection équirectangulaire. Ce mappage déforme plus près des zones et les pôles, car ils sont
étirées horizontalement.
La projection Mercator
La célèbre projection Mercator tente de compenser l’étirement horizontal en l’étirant également ces zones de
verticalement. Cela entraîne une carte où les zones proches pôles apparaissent bien plus important qu’elles sont
réellement, mais n’importe quel réseau local conforme très près à la zone réelle.
Services de mappage et des vignettes
Services de carte utilisent une variation de la projection Mercator appelée Web Mercator . Les services de mappage
remettre les vignettes de bitmap à un client basé sur l’emplacement et niveau de zoom.
Obtention de l’emplacement de l’utilisateur

Xamarin.Forms Map classes n’incluent pas une fonctionnalité pour obtenir l’emplacement géographique de
l’utilisateur, mais il est souvent souhaitable lors de l’utilisation de cartes, par conséquent, un service de dépendance
doit la gérer.
NOTE
Les applications Xamarin.Forms peuvent utiliser à la place la Geolocation classe inclus dans Xamarin.Essentials.
L’API de traceur emplacement

Le Xamarin.FormsBook.Platform solution contient le code pour une API de traceur emplacement. Le
GeographicLocation structure encapsule une latitude et une longitude. Le ILocationTracker interface définit deux
méthodes pour démarrer et interrompre le dispositif de suivi d’emplacement et un événement lorsqu’un nouvel
emplacement est disponible.
Le Gestionnaire d’emplacement iOS
L’implémentation d’iOS de ILocationTracker est un LocationTracker classe rend utiliser d’iOS
CLLocationManager .
Le Gestionnaire d’emplacement Android

L’implémentation Android de ILocationTracker est un LocationTracker classe qui utilise le Android
LocationManager classe.
Le localisateur de géo UWP

L’implémentation de la plateforme Windows universelle de ILocationTracker est un LocationTracker classe qui
utilise la plateforme Windows universelle Geolocator .
Afficher l’emplacement du téléphone
Le WhereAmI exemple utilise le dispositif de suivi d’emplacement pour afficher l’emplacement du téléphone, à la
fois dans le texte et sur une carte équirectangulaire.
La surcharge de requis
Une certaine surcharge est requise pour WhereAmI à utiliser le dispositif de suivi d’emplacement. Tout d’abord,
tous les projets dans le WhereAmI solution doit disposer de références aux projets correspondants dans
Xamarin.FormsBook.Platformet chaque WhereAmI projet doit appeler le Toolkit.Init (méthode).
Une surcharge supplémentaire spécifique à la plateforme, sous la forme d’autorisations de localisation, est requise.
Autorisation d’emplacement pour iOS
Pour iOS, le info.plist fichier doit inclure les éléments contenant le texte d’une question demandant à l’utilisateur
pour permettre l’obtention de l’emplacement de l’utilisateur.
Autorisations de localisation pour Android
Les applications Android qui obtiennent l’emplacement de l’utilisateur doivent avoir une autorisation
ACCESS_FILE_LOCATION dans le fichier AndroidManifest.xml.
Autorisations de localisation pour la plateforme Windows universelle
Une application de plateforme Windows universelle doit avoir un location fonctionnalité de l’appareil est marqué
dans le fichier Package.appxmanifest.
Utilisation de Xamarin.Forms.Maps
Plusieurs conditions requises sont impliqués dans à l’aide de la Map classe.
Le package NuGet
Le Xamarin.Forms.Maps bibliothèque NuGet doit être ajouté à la solution d’application. Le numéro de version
doit être le même que le Xamarin.Forms package actuellement installé.
L’initialisation de l’ensemble de cartes
Les projets d’application doivent appeler la Xamarin.FormsMaps.Init méthode après avoir effectué un appel à
Xamarin.Forms.Forms.Init .
L’activation des services de mappage

Étant donné que le Map peut obtenir l’emplacement de l’utilisateur, l’application doit obtenir l’autorisation
nécessaire pour l’utilisateur de la manière décrite plus haut dans ce chapitre :
L’activation d’iOS mappe
Une application iOS à l’aide Map a besoin de deux lignes dans le fichier info.plist.
L’activation d’Android mappe
Une clé d’autorisation est nécessaire pour l’utilisation des services de mappage de Google. Cette clé est insérée
dans le AndroidManifest.xml fichier. En outre, le AndroidManifest.xml fichier nécessite manifest balises
nécessaires pour obtenir l’emplacement de l’utilisateur.
L’activation UWP mappe
Une application de plateforme Windows universelle nécessite une clé d’autorisation pour l’utilisation de Bing
Maps. Cette clé est passée en tant qu’argument à la Xamarin.FormsMaps.Init (méthode). L’application doit
également être activée pour les services d’emplacement.
La carte non
Le MapDemos exemple se compose d’un MapsDemoHomePage.xaml fichier et MapsDemoHomePage.xaml.cs
fichier de code-behind Permet d’accéder à différents programmes de démonstration.
Le BasicMapPage.xaml fichier montre comment afficher le Map vue. Par défaut, il affiche la ville de Rome, mais le
mappage peut être manipulé par l’utilisateur.
Pour désactiver le défilement horizontal et vertical, définissez la HasScrollEnabled propriété false . Pour
désactiver le zoom, définissez HasZoomEnabled à false . Ces propriétés peut ne pas fonctionnent sur toutes les
plateformes.
Rues et le Terrain
Vous pouvez afficher différents types de cartes en définissant le Map propriété MapType de type MapType , une
énumération avec trois membres :
Street , la valeur par défaut
Satellite
Hybrid
Le MapTypesPage.xaml fichier montre comment utiliser un bouton radio pour sélectionner le type de carte. Il
utilise le RadioButtonManager classe dans le Xamarin.FormsBook.Toolkit bibliothèque et une classe basée sur le
MapTypeRadioButton.xaml fichier.
Coordonnées de la carte
Un programme peut obtenir la zone actuelle qui le Map affiche via les VisibleRegion propriété. Cette propriété
est pas soutenu par une propriété pouvant être liée, et il n’existe aucun mécanisme de notification pour indiquer
quand elle a changé, donc un programme qui souhaite surveiller la propriété doit probablement utiliser un
minuteur à cet effet.
VisibleRegion est de type MapSpan , une classe avec quatre propriétés en lecture seule :
Center de type Position
LatitudeDegrees de type double , indiquant la hauteur de la zone affichée de la carte
LongitudeDegrees de type double , indiquant la largeur de la zone affichée de la carte
Radius de type Distance , indiquant la taille de la plus grande surface circulaire visible sur la carte
Position et Distance sont les deux structures. Position définit deux propriétés en lecture seule définies via la
Position constructeur:
Latitude
Longitude
Distance vise à fournir une distance centrée sur l’unité par la conversion entre les métriques et les unités en
anglais. Un Distance valeur permettre être créée de plusieurs façons :
Distance constructeur avec une distance en mètres
Distance.FromMeters méthode statique
Distance.FromKilometers méthode statique
Distance.FromMiles méthode statique
La valeur est disponible à partir de trois propriétés :

Meters de type double
Kilometers de type double
Miles de type double
Le MapCoordinatesPage.xaml fichier contient plusieurs Label éléments pour afficher les MapSpan plus
d’informations. Le MapCoordinatesPage.xaml.cs fichier code-behind utilise un minuteur pour conserver les
informations de mise à jour que l’utilisateur manipule la carte.
Extensions de position
Une nouvelle bibliothèque pour ce livre nommé Xamarin.FormsBook.Toolkit.Maps contient des types
spécifiques à la carte mais indépendante de la plateforme. Le PositionExtensions classe a un ToString méthode
pour Position et une méthode pour calculer la distance entre deux Position valeurs.
Définissez un emplacement initial
Vous pouvez appeler la MoveToRegion méthode de Map pour définir par programmation un emplacement et
niveau de zoom sur la carte. L’argument est de type MapSpan . Vous pouvez créer un MapSpan de l’objet à l’aide
d’une des opérations suivantes :
MapSpan constructeur avec un Position et l’intervalle de latitude et longitude
MapSpan.FromCenterAndRadius avec un Position et radius
Il est également possible de créer un nouveau MapSpan à partir d’un à l’aide de méthodes ClampLatitude ou
WithZoom .
Le WyomingPage.xaml fichier et WyomingPage.xaml.cs fichier code-behind montre comment utiliser le

MoveToRegion méthode pour afficher l’état du Wyoming.
Vous pouvez également utiliser le Map constructeur avec un MapSpan objet pour initialiser l’emplacement de la
carte. Le XamarinHQPage.xaml fichier montre comment effectuer cette opération entièrement dans XAML pour
afficher le siège social de Xamarin à San Francisco.
Le zoom dynamique
Vous pouvez utiliser un Slider pour zoomer dynamiquement une carte. Le RadiusZoomPage.xaml fichier et
RadiusZoomPage.xaml.cs fichier code-behind montrent comment modifier le rayon d’une table basée sur la
Slider valeur.
Le LongitudeZoomPage.xaml fichier et LongitudeZoomPage.xaml.cs fichier code-behind afficher une autre

approche qui fonctionne mieux sur Android, mais aucune de ces approches fonctionne correctement sur le
Windows plateformes.
L’emplacement du téléphone
Le IsShowingUser propriété du Map fonctionne un peu différemment sur chaque plateforme en tant que le
ShowLocationPage.xaml fichier montre :
Sur iOS, un point bleu indique l’emplacement du téléphone, mais vous devez accéder manuellement
Sur Android, une icône s’affiche que quand vous appuyez déplace le mappage à l’emplacement du téléphone
La plateforme Windows universelle est similaire à iOS, mais parfois automatiquement accède à l’emplacement
Le MapDemos projet tente de reproduire l’approche Android en premier définissant un bouton basé sur l’icône
en fonction de la MyLocationButton.xaml fichier et MyLocationButton.xaml.cs fichier code-behind.
Le GoToLocationPage.xaml fichier et GoToLocationPage.xaml.cs fichier code-behind Utilisez ce bouton pour
accéder à l’emplacement du téléphone.
Musées de science et codes confidentiels
Enfin, le Map classe définit un Pins propriété de type IList<Pin> . Le Pin classe définit quatre propriétés :
Label de type string , une propriété obligatoire
Address de type string , une adresse explicite facultative
Position de type Position , indiquant où le code confidentiel est affiché sur la carte
Type de type PinType , une énumération, qui n’est pas utilisée
Le MapDemos projet contient le fichier ScienceMuseums.xml, qui répertorie des musées science aux États-Unis,
et Locations et Site classes pour la désérialisation de ces données.
Le ScienceMuseumsPage.xaml fichier et ScienceMuseumsPage.xaml.cs broches d’affichage de fichier code-behind
pour ces musées science dans le mappage. Lorsque l’utilisateur appuie sur un code confidentiel, il affiche l’adresse
et un site Web pour le musée.
La distance entre deux points
Le PositionExtensions classe contient un DistanceTo méthode avec un calcul simplifié de la distance entre deux
emplacements géographiques.
Cela est utilisé dans le LocalMuseumsPage.xaml fichier et LocalMuseumsPage.xaml.cs fichier code-behind pour
afficher également la distance rend au musée à partir de l’emplacement de l’utilisateur :
Le programme montre aussi comment limiter dynamiquement le nombre de codes confidentiels en fonction de
l’emplacement de la carte.
Géocodage et revenir
Le Xamarin.Forms.Maps assembly contient également un Geocoder classe avec un GetPositionsForAddressAsync
méthode convertit une adresse de texte en zéro ou plus possibles géographiques positions et une autre méthode
GetAddressesForPositionAsync qui convertit dans l’autre direction.
Le GeocoderRoundTrip.xaml fichier et GeocoderRoundTrip.xaml.cs fichier code-behind illustrent cette

fonctionnalité.
Liens connexes
Mappage de Xamarin.Forms

Création D'applications Mobiles Avec Xamarin Forms PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Création D'applications Mobiles Avec Xamarin Forms PDF

Uploaded by

Copyright:

Available Formats

Contents

Création d’applications mobiles avec Xamarin.Forms

Téléchargez le livre électronique gratuit

Récapitulatif des chapitres

Téléchargez des chapitres et des résumés

Chapitre 1. Fonctionnement de Télécharger PDF Résumé

Chapitre 2. Anatomie d’une application Télécharger PDF Résumé

Chapitre 3. Détails du texte Télécharger PDF Résumé

Chapitre 4. Défilement de la pile Télécharger PDF Résumé

Chapitre 5. Gestion des tailles Télécharger PDF Résumé

Chapitre 6. Clics de bouton Télécharger PDF Résumé

Chapitre 7. Visual Studio XAML. Code Télécharger PDF Résumé

Chapitre 8. Code et XAML en harmonie Télécharger PDF Résumé

Chapitre 9. Appels d’API de plateforme Télécharger PDF Résumé

Chapitre 10. Extensions de balisage Télécharger PDF Résumé

Chapitre 11. Infrastructure Bindable Télécharger PDF Résumé

Chapitre 12. Styles Télécharger PDF Résumé

Chapitre 13. Bitmaps Télécharger PDF Résumé

Chapitre 14. Disposition absolue Télécharger PDF Résumé

Chapitre 15. L’Interface Interactive Télécharger PDF Résumé

Chapitre 16. Liaison de données Télécharger PDF Résumé

Chapitre 17. Maîtrise de la grille Télécharger PDF Résumé

Chapitre 18. MVVM Télécharger PDF Résumé

Chapitre 19. Vues de collection Télécharger PDF Résumé

Chapitre 20. E/s de fichier et asynchrone Télécharger PDF Résumé

Chapitre 21. Transformations Télécharger PDF Résumé

Chapitre 22. Animation Télécharger PDF Résumé

Chapitre 23. Déclencheurs et Télécharger PDF Résumé

Chapitre 24. Navigation entre les pages Télécharger PDF Résumé

Chapitre 25. Types de page Télécharger PDF Résumé

Chapitre 26. Dispositions personnalisées Télécharger PDF Résumé

Chapitre 27. Renderers personnalisés Télécharger PDF Résumé

Chapitre 28. Emplacement et mappages Télécharger PDF Résumé

Façons dans lequel le livre est obsolète

Développement mobile multiplateforme

Les captures d’écran de gauche à droite affichent un iPhone et un téléphone Android :

Votre environnement de développement

Dans les fichiers

Bibliothèque de classes portable ou SAP ?

Le Device.OnPlatform méthodes, le Device.OS propriété et le TargetPlatform énumération sont tous maintenant

3 a de solution. Définir la marge sur l’étiquette

Solution 5. Centrer le texte dans l’étiquette

Habillage des paragraphes

Couleurs du texte et d’arrière-plan

Il s’agit de tous les double valeurs comprises entre 0 et 1.

Changer les couleurs de l’application

Attributs et les tailles de police

Texte mis en forme

Faire défiler un contenu

Définir le propriété du ScrollView à un membre de la ScrollOrientation propriété, Vertical ,

Le LayoutOptions structure définit deux propriétés :

Un ScrollView dans un StackLayout ?

Plusieurs tailles de Xamarin.Forms ont été rencontrées jusqu'à présent :

Pixels, points, points de distribution, adresses IP dynamiques et DIUs

Tailles de police estimé

Ajustement du texte à la taille disponible

Une horloge de la taille de l’ajustement

Ajustement empirique de texte

Traitement de la, cliquez sur

Bouton de partage clique sur

Gestionnaires d’événements anonyme

Distinction des vues avec des ID

Enregistrer les données temporaires