Vue d’ensemble du langage XAML

Cet article présente le langage XAML et les concepts XAML au public du développeur d’applications Windows Runtime et décrit les différentes façons de déclarer des objets et de définir des attributs en XAML, car il est utilisé pour créer une application Windows Runtime.

Qu’est-ce que le XAML ?

Xaml (Extensible Application Markup Language) est un langage déclaratif. Plus précisément, XAML peut initialiser des objets et définir des propriétés d’objets à l’aide d’une structure de langage qui montre des relations hiérarchiques entre plusieurs objets et une convention de type de stockage qui prend en charge l’extension des types. Vous pouvez créer des éléments d’interface utilisateur visibles dans le balisage XAML déclaratif. Vous pouvez ensuite associer un fichier code-behind distinct pour chaque fichier XAML qui peut répondre aux événements et manipuler les objets que vous déclarez initialement en XAML.

Le langage XAML prend en charge l’échange de sources entre différents outils et rôles dans le processus de développement, comme l’échange de sources XAML entre les outils de conception et un environnement de développement interactif (IDE) ou entre les développeurs principaux et les développeurs de localisation. En utilisant XAML comme format d’échange, les rôles de concepteur et les rôles de développeur peuvent être conservés séparément ou regroupés, et les concepteurs et les développeurs peuvent itérer pendant la production d’une application.

Lorsque vous les voyez dans le cadre de vos projets d’application Windows Runtime, les fichiers XAML sont des fichiers XML avec l’extension de nom de fichier .xaml.

Syntaxe XAML de base

XAML a une syntaxe de base qui s’appuie sur XML. Par définition, le code XAML valide doit également être xml valide. Mais XAML a également des concepts de syntaxe qui ont une signification différente et plus complète tout en étant toujours valides en XML conformément à la spécification XML 1.0. Par exemple, XAML prend en charge la syntaxe des éléments de propriété, où les valeurs de propriété peuvent être définies dans des éléments plutôt que comme valeurs de chaîne dans des attributs ou comme contenu. Pour le code XML standard, un élément de propriété XAML est un élément avec un point dans son nom. Il est donc valide pour le code XML brut, mais n’a pas la même signification.

XAML et Visual Studio

Microsoft Visual Studio vous aide à produire une syntaxe XAML valide, à la fois dans l’éditeur de texte XAML et dans l’aire de conception XAML plus graphiquement orientée. Lorsque vous écrivez du code XAML pour votre application à l’aide de Visual Studio, ne vous inquiétez pas trop de la syntaxe avec chaque séquence de touches. L’IDE encourage la syntaxe XAML valide en fournissant des indicateurs de saisie semi-automatique, affichant des suggestions dans les listes et les listes déroulantes Microsoft IntelliSense, montrant les bibliothèques d’éléments d’interface utilisateur dans la fenêtre Boîte à outils ou d’autres techniques. S’il s’agit de votre première expérience avec XAML, il peut encore être utile de connaître les règles de syntaxe et en particulier la terminologie qui est parfois utilisée pour décrire les restrictions ou les choix lors de la description de la syntaxe XAML dans des références ou d’autres rubriques. Les points corrects de la syntaxe XAML sont abordés dans une rubrique distincte, un guide de syntaxe XAML.

Espaces de noms XAML

En programmation générale, un espace de noms est un concept d’organisation qui détermine la façon dont les identificateurs des entités de programmation sont interprétés. À l’aide d’espaces de noms, un framework de programmation peut séparer les identificateurs déclarés par l’utilisateur des identificateurs déclarés par l’infrastructure, les identificateurs ambigus par le biais des qualifications de l’espace de noms, appliquer des règles pour les noms d’étendue, et ainsi de suite. XAML a son propre concept d’espace de noms XAML qui sert cet objectif pour le langage XAML. Voici comment XAML s’applique et étend les concepts d’espace de noms du langage XML :

• XAML utilise les xmlns d’attribut XML réservés pour les déclarations d’espace de noms. La valeur de l’attribut est généralement un URI (Uniform Resource Identifier), qui est une convention héritée de XML.
• XAML utilise des préfixes dans les déclarations pour déclarer des espaces de noms non par défaut et des utilisations de préfixe dans les éléments et les attributs référencent cet espace de noms.
• XAML a un concept d’espace de noms par défaut, qui est l’espace de noms utilisé lorsqu’aucun préfixe n’existe dans une déclaration ou une utilisation. L’espace de noms par défaut peut être défini différemment pour chaque infrastructure de programmation XAML.
• Les définitions d’espace de noms héritent d’un fichier ou d’une construction XAML, de l’élément parent à l’élément enfant. Par exemple, si vous définissez un espace de noms dans l’élément racine d’un fichier XAML, tous les éléments de ce fichier héritent de cette définition d’espace de noms. Si un élément plus loin dans la page redéfinit l’espace de noms, les descendants de cet élément héritent de la nouvelle définition.
• Les attributs d’un élément héritent des espaces de noms de l’élément. Il est assez rare de voir les préfixes sur les attributs XAML.

Un fichier XAML déclare presque toujours un espace de noms XAML par défaut dans son élément racine. L’espace de noms XAML par défaut définit les éléments que vous pouvez déclarer sans les qualifier par un préfixe. Pour les projets d’application Windows Runtime classiques, cet espace de noms par défaut contient tout le vocabulaire XAML intégré pour Windows Runtime utilisé pour les définitions d’interface utilisateur : les contrôles par défaut, les éléments de texte, les graphiques XAML et les animations, la liaison de données et les types de prise en charge des styles, et ainsi de suite. La plupart des xamls que vous allez écrire pour les applications Windows Runtime pourront ainsi éviter d’utiliser des espaces de noms et des préfixes XAML lors de la référence à des éléments d’interface utilisateur courants.

Voici un extrait de code montrant une racine créée par Page un modèle de la page initiale d’une application (montrant la balise d’ouverture uniquement et simplifiée). Il déclare l’espace de noms par défaut et également l’espace de noms x (que nous allons expliquer ensuite).

<Page
    x:Class="Application1.BlankPage"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
>

Espace de noms XAML du langage XAML

Un espace de noms XAML particulier déclaré dans presque chaque fichier XAML Windows Runtime est l’espace de noms du langage XAML. Cet espace de noms inclut des éléments et des concepts définis par la spécification du langage XAML. Par convention, l’espace de noms XAML du langage XAML est mappé au préfixe « x ». Les modèles de projet et de fichier par défaut pour les projets d’application Windows Runtime définissent toujours à la fois l’espace de noms XAML par défaut (aucun préfixe, juste xmlns=) et l’espace de noms XAML du langage XAML (préfixe « x ») dans le cadre de l’élément racine.

L’espace de noms XAML du langage XAML « x » contient plusieurs constructions de programmation que vous utilisez souvent dans votre code XAML. Voici les plus couramment employées :

D’autres constructions de programmation dans l’espace de noms XAML du langage XAML existent, mais ne sont pas aussi courantes.

Mappage de types personnalisés à des espaces de noms XAML

L’un des aspects les plus puissants du langage XAML est qu’il est facile d’étendre le vocabulaire XAML pour vos applications Windows Runtime. Vous pouvez définir vos propres types personnalisés dans le langage de programmation de votre application, puis référencer vos types personnalisés dans le balisage XAML. La prise en charge de l’extension par le biais de types personnalisés est fondamentalement intégrée au fonctionnement du langage XAML. Les frameworks ou les développeurs d’applications sont responsables de la création des objets de stockage référencés par XAML. Ni les frameworks ni le développeur d’applications ne sont liés par des spécifications de ce que les objets de leurs vocabulaires représentent ou font au-delà des règles de syntaxe XAML de base. (Il existe certaines attentes quant à ce que doivent faire les types d’espaces de noms XAML du langage XAML, mais Windows Runtime fournit toute la prise en charge nécessaire.)

Si vous utilisez XAML pour les types provenant de bibliothèques autres que les bibliothèques principales et les métadonnées Windows Runtime, vous devez déclarer et mapper un espace de noms XAML avec un préfixe. Utilisez ce préfixe dans les utilisations d’éléments pour référencer les types définis dans votre bibliothèque. Vous déclarez des mappages de préfixes en tant qu’attributs xmlns , généralement dans un élément racine, ainsi que les autres définitions d’espace de noms XAML.

Pour définir votre propre définition d’espace de noms qui référence des types personnalisés, vous spécifiez d’abord le mot clé xmlns :, puis le préfixe souhaité. La valeur de cet attribut doit contenir le mot clé using : comme première partie de la valeur. Le reste de la valeur est un jeton de chaîne qui fait référence à l’espace de noms de stockage de code spécifique qui contient vos types personnalisés, par nom.

Le préfixe définit le jeton de balisage utilisé pour faire référence à cet espace de noms XAML dans le reste du balisage dans ce fichier XAML. Caractère deux-points (:) passe entre le préfixe et l’entité à référencer dans l’espace de noms XAML.

Par exemple, la syntaxe d’attribut pour mapper un préfixe myTypes à l’espace de noms myCompany.myTypes est : xmlns:myTypes="using:myCompany.myTypes"et une utilisation d’élément représentative est : <myTypes:CustomButton/>

Pour plus d’informations sur le mappage d’espaces de noms XAML pour les types personnalisés, notamment des considérations spéciales pour les extensions de composant Visual C++ (C++/CX), consultez les espaces de noms XAML et le mappage d’espaces de noms.

Autres espaces de noms XAML

Vous voyez souvent des fichiers XAML qui définissent les préfixes « d » (pour l’espace de noms du concepteur) et « mc » (pour la compatibilité des marques). En règle générale, il s’agit de la prise en charge de l’infrastructure ou de l’activation de scénarios dans un outil au moment du design. Pour plus d’informations, consultez la section « Autres espaces de noms XAML » de la rubrique espaces de noms XAML.

Extensions de balisage

Les extensions de balisage sont un concept de langage XAML qui est souvent utilisé dans l’implémentation XAML de Windows Runtime. Les extensions de balisage représentent souvent un type de « raccourci » qui permet à un fichier XAML d’accéder à une valeur ou un comportement qui ne déclare pas simplement des éléments en fonction des types de stockage. Certaines extensions de balisage peuvent définir des propriétés avec des chaînes simples ou avec des éléments imbriqués supplémentaires, avec l’objectif de rationaliser la syntaxe ou le factoring entre différents fichiers XAML.

Dans la syntaxe d’attribut XAML, les accolades « { » et « } » indiquent une utilisation de l’extension de balisage XAML. Cette utilisation dirige le traitement XAML vers l’échappement du traitement général des valeurs d’attribut comme une chaîne littérale ou une valeur convertible directement par chaîne. Au lieu de cela, un analyseur XAML appelle du code qui fournit un comportement pour cette extension de balisage particulière, et ce code fournit un autre objet ou un autre résultat de comportement que l’analyseur XAML a besoin. Les extensions de balisage peuvent avoir des arguments, qui suivent le nom de l’extension de balisage et qui sont également contenus dans les accolades. En règle générale, une extension de balisage évaluée fournit une valeur de retour d’objet. Pendant l’analyse, cette valeur de retour est insérée dans la position dans l’arborescence d’objets où l’utilisation de l’extension de balisage était dans le code XAML source.

Windows Runtime XAML prend en charge ces extensions de balisage définies sous l’espace de noms XAML par défaut et comprises par l’analyseur XAML Windows Runtime :

• {x :Bind} : prend en charge la liaison de données, qui reporte l’évaluation des propriétés jusqu’au moment de l’exécution en exécutant du code à usage spécial, qu’elle génère au moment de la compilation. Cette extension de balisage prend en charge un large éventail d’arguments.
• {Binding} : prend en charge la liaison de données, qui reporte l’évaluation des propriétés jusqu’au moment de l’exécution en exécutant l’inspection d’objet runtime à usage général. Cette extension de balisage prend en charge un large éventail d’arguments.
• {StaticResource} : prend en charge le référencement des valeurs de ressources définies dans un ResourceDictionary. Ces ressources peuvent se trouver dans un autre fichier XAML, mais doivent finalement être accessibles par l’analyseur XAML au moment du chargement. L’argument d’une {StaticResource} utilisation identifie la clé (le nom) d’une ressource clé dans un ResourceDictionary.
• {ThemeResource} : similaire à {StaticResource} mais peut répondre aux modifications de thème au moment de l’exécution. {ThemeResource} apparaît assez souvent dans les modèles XAML par défaut Windows Runtime, car la plupart de ces modèles sont conçus pour assurer la compatibilité avec l’utilisateur qui change le thème pendant l’exécution de l’application.
• {TemplateBinding} : cas spécial de {Binding} qui prend en charge les modèles de contrôle en XAML et leur utilisation éventuelle au moment de l’exécution.
• {RelativeSource} : active une forme particulière de liaison de modèle où les valeurs proviennent du parent modèle.
• {CustomResource} : pour les scénarios de recherche de ressources avancés.

Windows Runtime prend également en charge l’extension de balisage {x :Null}. Vous utilisez cette option pour définir des valeurs Nullables sur Null en XAML. Par exemple, vous pouvez l’utiliser dans un modèle de contrôle pour un CheckBox, qui interprète null comme un état de vérification indéterminé (déclencheur de l’état visuel « Indéterminé »).

Une extension de balisage retourne généralement une instance existante à partir d’une autre partie du graphique d’objet pour l’application ou reporte une valeur à l’exécution. Étant donné que vous pouvez utiliser une extension de balisage comme valeur d’attribut et que c’est l’utilisation classique, vous voyez souvent des extensions de balisage fournissant des valeurs pour les propriétés de type référence qui ont peut-être besoin d’une syntaxe d’élément de propriété.

Par exemple, voici la syntaxe permettant de référencer un réutilisable Style à partir d’un ResourceDictionary: <Button Style="{StaticResource SearchButtonStyle}"/>. Il Style s’agit d’un type référence, pas d’une valeur simple. Par conséquent, sans l’utilisation {StaticResource} , vous auriez besoin d’un <Button.Style> élément de propriété et d’une <Style> définition dans celui-ci pour définir la FrameworkElement.Style propriété.

En utilisant des extensions de balisage, chaque propriété définie en XAML est potentiellement définie dans la syntaxe d’attribut. Vous pouvez utiliser la syntaxe d’attribut pour fournir des valeurs de référence pour une propriété, même si elle ne prend pas en charge une syntaxe d’attribut pour l’instanciation d’objet direct. Vous pouvez également activer un comportement spécifique qui reporte l’exigence générale que les propriétés XAML soient remplies par des types valeur ou par des types de référence nouvellement créés.

Pour illustrer, l’exemple XAML suivant définit la valeur de la propriété d’un Border à l’aide de la FrameworkElement.Style syntaxe d’attribut. La FrameworkElement.Style propriété prend une instance de la Windows.UI.Xaml.Style classe, un type de référence qui par défaut n’a pas pu être créé à l’aide d’une chaîne de syntaxe d’attribut. Dans ce cas, par contre, l’attribut fait référence à une extension de balisage particulière, StaticResource. Lorsque cette extension de balisage est traitée, elle retourne une référence à un élément Style qui a été défini précédemment en tant que ressource clé dans un dictionnaire de ressources.

<Canvas.Resources>
  <Style TargetType="Border" x:Key="PageBackground">
    <Setter Property="BorderBrush" Value="Blue"/>
    <Setter Property="BorderThickness" Value="5"/>
  </Style>
</Canvas.Resources>
...
<Border Style="{StaticResource PageBackground}">
  ...
</Border>

Vous pouvez imbriquer des extensions de balisage. L'extension de balisage la plus profonde est évaluée en premier.

En raison des extensions de balisage, vous avez besoin d’une syntaxe spéciale pour une valeur littérale « { » dans un attribut. Pour plus d’informations, consultez le guide de syntaxe XAML.

Événements

XAML est un langage déclaratif pour les objets et leurs propriétés, mais inclut également une syntaxe permettant d’attacher des gestionnaires d’événements à des objets dans le balisage. La syntaxe d’événement XAML peut ensuite intégrer les événements déclarés XAML par le biais du modèle de programmation Windows Runtime. Vous spécifiez le nom de l’événement en tant que nom d’attribut sur l’objet où l’événement est géré. Pour la valeur d’attribut, vous spécifiez le nom d’une fonction de gestionnaire d’événements que vous définissez dans le code. Le processeur XAML utilise ce nom pour créer une représentation déléguée dans l’arborescence d’objets chargé et ajoute le gestionnaire spécifié à une liste de gestionnaires interne. Presque toutes les applications Windows Runtime sont définies par des sources de balisage et de code-behind.

Voici un exemple simple. La Button classe prend en charge un événement nommé Click. Vous pouvez écrire un gestionnaire pour Click qui exécute du code qui doit être appelé une fois que l’utilisateur clique sur le bouton. En XAML, vous spécifiez Click en tant qu’attribut sur le bouton. Pour la valeur d’attribut, fournissez une chaîne qui correspond au nom de la méthode de votre gestionnaire.

<Button Click="showUpdatesButton_Click">Show updates</Button>

Lorsque vous compilez, le compilateur s’attend maintenant à ce qu’une méthode nommée showUpdatesButton_Click soit définie dans le fichier code-behind, dans l’espace de noms déclaré dans la valeur x :Class de la page XAML. En outre, cette méthode doit satisfaire le contrat délégué pour l’événement Click . Par exemple :

namespace App1
{
    public sealed partial class MainPage: Page {
        ...
        private void showUpdatesButton_Click (object sender, RoutedEventArgs e) {
            //your code
        }
    }
}

' Namespace included at project level
Public NotInheritable Class MainPage
    Inherits Page
        ...
        Private Sub showUpdatesButton_Click (sender As Object, e As RoutedEventArgs e)
            ' your code
        End Sub
    ...
End Class

namespace winrt::App1::implementation
{
    struct MainPage : MainPageT<MainPage>
    {
        ...
        void showUpdatesButton_Click(Windows::Foundation::IInspectable const&, Windows::UI::Xaml::RoutedEventArgs const&);
    };
}

// .h
namespace App1
{
    public ref class MainPage sealed {
        ...
    private:
        void showUpdatesButton_Click(Object^ sender, RoutedEventArgs^ e);
    };
}

Dans un projet, le code XAML est écrit en tant que fichier .xaml et vous utilisez le langage que vous préférez (C#, Visual Basic, C++/CX) pour écrire un fichier code-behind. Lorsqu’un fichier XAML est compilé dans le cadre d’une action de génération pour le projet, l’emplacement du fichier code-behind XAML pour chaque page XAML est identifié en spécifiant un espace de noms et une classe comme attribut x :Class de l’élément racine de la page XAML. Pour plus d’informations sur le fonctionnement de ces mécanismes en XAML et leur relation avec les modèles de programmation et d’application, consultez La vue d’ensemble des événements et des événements routés.

Dictionnaires de ressources

La création d’une ResourceDictionary tâche est une tâche courante qui est généralement effectuée en créant un dictionnaire de ressources en tant que zone d’une page XAML ou d’un fichier XAML distinct. Les dictionnaires de ressources et la façon de les utiliser sont un domaine conceptuel plus vaste qui se trouve en dehors de l’étendue de cette rubrique. Pour plus d’informations, consultez les références de ressources ResourceDictionary et XAML.

XAML et XML

Le langage XAML est fondamentalement basé sur le langage XML. Mais XAML étend considérablement le code XML. En particulier, il traite le concept de schéma tout à fait différemment en raison de sa relation avec le concept de type de stockage, et ajoute des éléments de langage tels que les membres attachés et les extensions de balisage. xml :lang est valide en XAML, mais influence le runtime plutôt que le comportement d’analyse et est généralement alias vers une propriété au niveau de l’infrastructure. Pour en savoir plus, voir FrameworkElement.Language. xml :base est valide dans le balisage, mais les analyseurs l’ignorent. xml :space est valide, mais n’est pertinent que pour les scénarios décrits dans la rubrique XAML et espace blanc . L’attribut d’encodage est valide en XAML. Seuls les encodages UTF-8 et UTF-16 sont pris en charge. L’encodage UTF-32 n’est pas pris en charge.

Sensibilité de la casse en XAML

XAML respecte la casse. Il s’agit d’une autre conséquence du code XAML basé sur xml, qui respecte la casse. Les noms des éléments et attributs XAML respectent la casse. La valeur d’un attribut est potentiellement sensible à la casse ; cela dépend de la façon dont la valeur d’attribut est gérée pour des propriétés particulières. Par exemple, si la valeur d’attribut déclare un nom de membre d’une énumération, le comportement intégré qui convertit une chaîne de nom de membre pour retourner la valeur de membre d’énumération n’est pas sensible à la casse. En revanche, la valeur de la propriété Name et les méthodes utilitaires pour utiliser des objets basés sur le nom déclaré par la propriété Name , traitent la chaîne de nom comme respectant la casse.

Namescopes XAML

Le langage XAML définit un concept de namescope XAML. Le concept de portée de nom XAML influence la façon dont les processeurs XAML doivent traiter la valeur des éléments x :Name ou Name appliqués aux éléments XAML, en particulier les étendues dans lesquelles les noms doivent être basés sur des identificateurs uniques. Les portées de noms XAML sont abordées plus en détail dans une rubrique distincte ; consultez les portées de noms XAML.

Rôle du code XAML dans le processus de développement

XAML joue plusieurs rôles importants dans le processus de développement d’applications.

• XAML est le format principal pour déclarer l’interface utilisateur et les éléments d’une application dans cette interface utilisateur, si vous programmez en C#, Visual Basic ou C++/CX. En règle générale, au moins un fichier XAML dans votre projet représente une métaphore de page dans votre application pour l’interface utilisateur initialement affichée. Des fichiers XAML supplémentaires peuvent déclarer des pages supplémentaires pour l’interface utilisateur de navigation. D’autres fichiers XAML peuvent déclarer des ressources, telles que des modèles ou des styles.
• Vous utilisez le format XAML pour déclarer des styles et des modèles appliqués aux contrôles et à l’interface utilisateur d’une application.
• Vous pouvez utiliser des styles et des modèles pour la création de modèles de contrôles existants ou si vous définissez un contrôle qui fournit un modèle par défaut dans le cadre d’un package de contrôle. Lorsque vous l’utilisez pour définir des styles et des modèles, le code XAML approprié est souvent déclaré en tant que fichier XAML discret avec une ResourceDictionary racine.
• XAML est le format courant pour la prise en charge du concepteur de la création de l’interface utilisateur et l’échange de la conception de l’interface utilisateur entre différentes applications de concepteur. Plus particulièrement, le code XAML de l’application peut être échangé entre différents outils de conception XAML (ou fenêtres de conception dans les outils).
• Plusieurs autres technologies définissent également l’interface utilisateur de base en XAML. En relation avec LE XAML windows Presentation Foundation (WPF) et le XAML Microsoft Silverlight, le code XAML pour Windows Runtime utilise le même URI pour son espace de noms XAML par défaut partagé. Le vocabulaire XAML pour Windows Runtime se chevauche considérablement avec le vocabulaire XAML-for-UI également utilisé par Silverlight et dans une légère mesure par WPF. Par conséquent, XAML promeut un chemin de migration efficace pour l’interface utilisateur initialement définie pour les technologies précurseurs qui ont également utilisé XAML.
• XAML définit l’apparence visuelle d’une interface utilisateur et un fichier code-behind associé définit la logique. Vous pouvez ajuster la conception de l’interface utilisateur sans apporter de modifications à la logique dans le code-behind. XAML simplifie le flux de travail entre les concepteurs et les développeurs.
• En raison de la richesse du concepteur visuel et de la prise en charge de l’aire de conception pour le langage XAML, XAML prend en charge le prototypage rapide de l’interface utilisateur dans les premières phases de développement.

En fonction de votre propre rôle dans le processus de développement, vous risquez de ne pas interagir avec XAML beaucoup. Le degré d’interaction avec les fichiers XAML dépend également de l’environnement de développement que vous utilisez, que vous utilisiez des fonctionnalités d’environnement de conception interactives telles que des boîtes à outils et des éditeurs de propriétés, ainsi que l’étendue et l’objectif de votre application Windows Runtime. Néanmoins, il est probable que lors du développement de l’application, vous allez modifier un fichier XAML au niveau de l’élément à l’aide d’un éditeur de texte ou XML. À l’aide de ces informations, vous pouvez modifier en toute confiance le code XAML dans une représentation texte ou XML et conserver la validité des déclarations et des objectifs de ce fichier XAML lorsqu’il est consommé par des outils, des opérations de compilation de balisage ou la phase d’exécution de votre application Windows Runtime.

Optimiser votre code XAML pour les performances de chargement

Voici quelques conseils pour définir des éléments d’interface utilisateur en XAML à l’aide des meilleures pratiques en matière de performances. La plupart de ces conseils concernent l’utilisation de ressources XAML, mais sont répertoriés ici dans la vue d’ensemble générale du code XAML pour des raisons pratiques. Pour plus d’informations sur les ressources XAML, consultez les références de ressources ResourceDictionary et XAML. Pour obtenir d’autres conseils sur les performances, y compris le code XAML qui illustre explicitement certaines des mauvaises pratiques de performances que vous devez éviter dans votre code XAML, consultez Optimiser votre balisage XAML.

• Si vous utilisez souvent le même pinceau de couleur dans votre code XAML, définissez une SolidColorBrush ressource plutôt que d’utiliser une couleur nommée comme valeur d’attribut à chaque fois.
• Si vous utilisez la même ressource sur plusieurs pages d’interface utilisateur, envisagez de Resources la définir plutôt que sur chaque page. À l’inverse, si une seule page utilise une ressource, ne la définissez pas dans Application.Resources et définissez-la uniquement pour la page qui en a besoin. Cela convient à la fois pour le factoring XAML lors de la conception de votre application et pour les performances pendant l’analyse XAML.
• Pour les ressources que votre application packages, recherchez les ressources inutilisées (une ressource qui a une clé, mais il n’existe aucune référence StaticResource dans votre application qui l’utilise). Supprimez-les de votre code XAML avant de publier votre application.
• Si vous utilisez des fichiers XAML distincts qui fournissent des ressources de conception (MergedDictionaries), envisagez de commenter ou de supprimer des ressources inutilisées de ces fichiers. Même si vous disposez d’un point de départ XAML partagé que vous utilisez dans plusieurs applications ou qui fournit des ressources courantes pour toutes vos applications, il s’agit toujours de votre application qui empaquette les ressources XAML chaque fois et doit potentiellement les charger.
• Ne définissez pas d’éléments d’interface utilisateur dont vous n’avez pas besoin pour la composition et utilisez les modèles de contrôle par défaut dans la mesure du possible (ces modèles ont déjà été testés et vérifiés pour les performances de charge).
• Utilisez des conteneurs tels que Border des surdraws délibérés d’éléments d’interface utilisateur. En fait, ne dessinez pas le même pixel plusieurs fois. Pour plus d’informations sur overdraw et sur la façon de le tester, consultez DebugSettings.IsOverdrawHeatMapEnabled.
• Utilisez les modèles d’éléments par défaut pour ListView ou GridView; ceux-ci ont une logique présentateur spéciale qui résout les problèmes de performances lors de la génération de l’arborescence visuelle pour un grand nombre d’éléments de liste.

Déboguer XAML

Étant donné que XAML est un langage de balisage, certaines des stratégies classiques de débogage dans Microsoft Visual Studio ne sont pas disponibles. Par exemple, il n’existe aucun moyen de définir un point d’arrêt dans un fichier XAML. Toutefois, il existe d’autres techniques qui peuvent vous aider à déboguer des problèmes liés aux définitions d’interface utilisateur ou à d’autres marques XAML pendant que vous développez votre application.

En cas de problème avec un fichier XAML, le résultat le plus courant est que certains systèmes ou votre application lèvent une exception d’analyse XAML. Chaque fois qu’il existe une exception d’analyse XAML, le code XAML chargé par l’analyseur XAML n’a pas pu créer une arborescence d’objets valide. Dans certains cas, par exemple, lorsque le code XAML représente la première « page » de votre application chargée en tant que visuel racine, l’exception d’analyse XAML n’est pas récupérable.

XAML est souvent modifié dans un IDE tel que Visual Studio et l’une de ses surfaces de conception XAML. Visual Studio peut souvent fournir une validation au moment du design et une vérification des erreurs d’une source XAML lors de sa modification. Par exemple, il peut s’afficher « quiggles » dans l’éditeur de texte XAML dès que vous tapez une valeur d’attribut incorrecte, et vous n’aurez même pas besoin d’attendre un passage de compilation XAML pour voir que quelque chose ne va pas avec votre définition d’interface utilisateur.

Une fois que l’application s’exécute réellement, si des erreurs d’analyse XAML n’ont pas été détectées au moment de la conception, celles-ci sont signalées par le Common Language Runtime (CLR) en tant que XamlParseException. Pour plus d’informations sur ce que vous pouvez faire pour une instance XamlParseException au moment de l’exécution, consultez Gestion des exceptions pour les applications Windows Runtime en C# ou Visual Basic.

Pour plus d’informations sur le débogage d’une application Windows Runtime, consultez Démarrer une session de débogage.