Partager via

Animations dans une table de montage séquentiel

  • Article

Les animations de tableau séquentiel ne sont pas seulement des animations dans le sens visuel. Une animation storyboarded est un moyen de modifier la valeur d’une propriété de dépendance en tant que fonction du temps. L’une des principales raisons pour lesquelles vous pouvez avoir besoin d’une animation de tableau séquentiel qui ne provient pas de la bibliothèque d’animations consiste à définir l’état visuel d’un contrôle, dans le cadre d’un modèle de contrôle ou d’une définition de page.

Différences avec Silverlight et WPF

Si vous connaissez Microsoft Silverlight ou Windows Presentation Foundation (WPF), lisez cette section ; sinon, vous pouvez l’ignorer.

En général, la création d’animations storyboard dans une application Windows Runtime est semblable à Silverlight ou WPF. Mais il existe un certain nombre de différences importantes :

  • Les animations storyboarded ne sont pas la seule façon d’animer visuellement une interface utilisateur, ni sont-elles nécessairement le moyen le plus simple pour les développeurs d’applications de le faire. Au lieu d’utiliser des animations storyboarded, il est souvent préférable d’utiliser des animations de thème et des animations de transition. Ceux-ci peuvent rapidement créer des animations d’interface utilisateur recommandées sans entrer dans les complexités de la propriété d’animation ciblant. Pour plus d’informations, consultez La vue d’ensemble des animations.
  • Dans Windows Runtime, de nombreux contrôles XAML incluent des animations de thème et des animations de transition dans le cadre de leur comportement intégré. Pour la plupart, les contrôles WPF et Silverlight n’ont pas de comportement d’animation par défaut.
  • Toutes les animations personnalisées que vous créez ne peuvent pas s’exécuter par défaut dans une application Windows Runtime, si le système d’animation détermine que l’animation peut entraîner des performances incorrectes dans votre interface utilisateur. Les animations où le système détermine qu’il peut y avoir un impact sur les performances sont appelées animations dépendantes. Cela dépend du fait que l’horloge de votre animation fonctionne directement sur le thread d’interface utilisateur, qui est également l’endroit où les entrées utilisateur actives et d’autres mises à jour tentent d’appliquer les modifications du runtime à l’interface utilisateur. Une animation dépendante qui consomme des ressources système étendues sur le thread d’interface utilisateur peut rendre l’application non réponse dans certaines situations. Si votre animation provoque une modification de disposition ou peut avoir un impact sur les performances sur le thread d’interface utilisateur, vous devez souvent activer explicitement l’animation pour qu’elle s’exécute. Il s’agit de la propriété EnableDependentAnimation sur des classes d’animation spécifiques. Pour plus d’informations, consultez les animations dépendantes et indépendantes .
  • Les fonctions d’accélération personnalisées ne sont actuellement pas prises en charge dans Windows Runtime.

Définition d’animations storyboarded

Une animation storyboarded est un moyen de modifier la valeur d’une propriété de dépendance en tant que fonction du temps. La propriété que vous animez n’est pas toujours une propriété qui affecte directement l’interface utilisateur de votre application. Toutefois, étant donné que XAML consiste à définir l’interface utilisateur d’une application, il s’agit généralement d’une propriété liée à l’interface utilisateur que vous animez. Par exemple, vous pouvez animer l’angle d’un RotateTransform ou la valeur de couleur de l’arrière-plan d’un bouton.

L’une des principales raisons pour lesquelles vous définissez peut-être une animation storyboarded est que vous êtes un auteur de contrôle ou que vous re-templatez un contrôle et que vous définissez des états visuels. Pour plus d’informations, consultez les animations storyboarded pour les états visuels.

Que vous définissiez des états visuels ou une animation personnalisée pour une application, les concepts et les API des animations de table séquentiel décrites dans cette rubrique s’appliquent principalement à l’une ou l’autre des applications.

Pour être animé, la propriété que vous ciblez avec une animation storyboard doit être une propriété de dépendance. Une propriété de dépendance est une fonctionnalité clé de l’implémentation XAML de Windows Runtime. Les propriétés accessibles en écriture des éléments d’interface utilisateur les plus courants sont généralement implémentées en tant que propriétés de dépendance, afin que vous puissiez les animer, appliquer des valeurs liées aux données ou appliquer un style et cibler la propriété avec un Setter. Pour plus d’informations sur le fonctionnement des propriétés de dépendance, consultez la vue d’ensemble des propriétés de dépendance.

La plupart du temps, vous définissez une animation de tableau séquentiel en écrivant du code XAML. Si vous utilisez un outil tel que Microsoft Visual Studio, il produit le code XAML pour vous. Il est possible de définir une animation storyboarded à l’aide de code également, mais c’est moins courant.

Prenons un exemple simple. Dans cet exemple XAML, la propriété Opacity est animée sur un objet Rectangle particulier.

<Page ...>
  <Page.Resources>
    <!-- Storyboard resource: Animates a rectangle's opacity. -->
    <Storyboard x:Name="myStoryboard">
      <DoubleAnimation
        Storyboard.TargetName="MyAnimatedRectangle"
        Storyboard.TargetProperty="Opacity"
        From="1.0" To="0.0" Duration="0:0:1"/>
    </Storyboard>
  </Page.Resources>

  <!--Page root element, UI definition-->
  <Grid>
    <Rectangle x:Name="MyAnimatedRectangle"
      Width="300" Height="200" Fill="Blue"/>
  </Grid>
</Page>

Identification de l’objet à animer

Dans l’exemple précédent, le storyboard a animé la propriété Opacity d’un Rectangle. Vous ne déclarez pas les animations sur l’objet lui-même. Au lieu de cela, vous effectuez cette opération dans la définition d’animation d’un storyboard. Les storyboards sont généralement définis en XAML qui ne se trouvent pas à proximité immédiate de la définition d’interface utilisateur XAML de l’objet à animer. Au lieu de cela, ils sont généralement configurés en tant que ressource XAML.

Pour connecter une animation à une cible, vous référencez la cible en identifiant son nom de programmation. Vous devez toujours appliquer l’attribut x :Name dans la définition de l’interface utilisateur XAML pour nommer l’objet que vous souhaitez animer. Vous ciblez ensuite l’objet à animer en définissant Storyboard.TargetName dans la définition d’animation. Pour la valeur de Storyboard.TargetName, vous utilisez la chaîne de nom de l’objet cible, qui est ce que vous définissez précédemment et ailleurs avec l’attribut x :Name.

Ciblage de la propriété de dépendance à animer

Vous définissez une valeur pour Storyboard.TargetProperty dans l’animation. Cela détermine quelle propriété spécifique de l’objet ciblé est animée.

Parfois, vous devez cibler une propriété qui n’est pas une propriété immédiate de l’objet cible, mais qui est imbriquée plus profondément dans une relation objet-propriété. Vous devez souvent effectuer cette opération pour explorer un ensemble de valeurs d’objet et de propriété contributeurs jusqu’à ce que vous puissiez référencer un type de propriété qui peut être animé (Double, Point, Color). Ce concept est appelé ciblage indirect, et la syntaxe pour cibler une propriété de cette façon est appelée chemin d’accès de propriété.

Voici un exemple. Un scénario courant pour une animation storyboarded consiste à modifier la couleur d’une partie d’une interface utilisateur ou d’un contrôle d’application afin de représenter que le contrôle est dans un état particulier. Supposons que vous souhaitiez animer le premier plan d’un TextBlock, afin qu’il passe du rouge au vert. Vous vous attendez à ce qu’une ColorAnimation soit impliquée, et c’est correct. Toutefois, aucune des propriétés des éléments d’interface utilisateur qui affectent la couleur de l’objet n’est en fait de type Color. Au lieu de cela, ils sont de type Brush. Par conséquent, ce que vous devez réellement cibler pour l’animation est la propriété Color de la classe SolidColorBrush, qui est un type dérivé de pinceau qui est généralement utilisé pour ces propriétés d’interface utilisateur liées aux couleurs. Voici ce qui ressemble en termes de création d’un chemin de propriété pour le ciblage des propriétés de votre animation :

<Storyboard x:Name="myStoryboard">
  <ColorAnimation
    Storyboard.TargetName="tb1"
    Storyboard.TargetProperty="(TextBlock.Foreground).(SolidColorBrush.Color)"
    From="Red" To="Green"/>
</Storyboard>

Voici comment penser à cette syntaxe en termes de ses parties :

  • Chaque ensemble de parenthèses () entoure un nom de propriété.
  • Dans le nom de la propriété, il y a un point, et ce point sépare un nom de type et un nom de propriété, de sorte que la propriété que vous identifiez est non ambiguë.
  • Le point au milieu, celui qui n’est pas entre parenthèses, est une étape. Cela est interprété par la syntaxe à signifier, prenez la valeur de la première propriété (qui est un objet), pas à pas dans son modèle objet et ciblez une sous-propriété spécifique de la valeur de la première propriété.

Voici une liste des scénarios de ciblage d’animation dans lesquels vous utiliserez probablement le ciblage de propriété indirect et certaines chaînes de chemin d’accès de propriété qui se rapprochent de la syntaxe que vous allez utiliser :

Vous remarquerez que certains de ces exemples utilisent des crochets autour des nombres. Il s’agit d’un indexeur. Il indique que le nom de propriété précédent a une collection en tant que valeur et que vous souhaitez qu’un élément (tel qu’identifié par un index de base zéro) se trouve dans cette collection.

Vous pouvez également animer des propriétés jointes XAML. Placez toujours le nom complet de la propriété jointe entre parenthèses, par exemple (Canvas.Left). Pour plus d’informations, consultez Animation des propriétés jointes XAML.

Pour plus d’informations sur l’utilisation d’un chemin de propriété pour le ciblage indirect de la propriété à animer, consultez la syntaxe du chemin de propriété ou la propriété jointe Storyboard.TargetProperty.

Types d’animations

Le système d’animation Windows Runtime a trois types spécifiques auxquels les animations de tableau séquentiel peuvent s’appliquer :

Il existe également un type d’animation d’objet généralisé pour les valeurs de référence d’objet, que nous aborderons plus tard.

Spécification des valeurs animées

Jusqu’à présent, nous vous avons montré comment cibler l’objet et la propriété à animer, mais n’avons pas encore décrit ce que fait l’animation à la valeur de propriété lorsqu’elle s’exécute.

Les types d’animation que nous avons décrits sont parfois appelés animations From/To/By. Cela signifie que l’animation change la valeur d’une propriété, au fil du temps, en utilisant une ou plusieurs de ces entrées provenant de la définition d’animation :

  • La valeur commence à la valeur From . Si vous ne spécifiez pas de valeur From , la valeur de départ est quelle que soit la valeur que la propriété animée a au moment de l’exécution de l’animation. Il peut s’agir d’une valeur par défaut, d’une valeur d’un style ou d’un modèle, ou d’une valeur spécifiquement appliquée par une définition d’interface utilisateur XAML ou un code d’application.
  • À la fin de l’animation, la valeur est la valeur To .
  • Ou, pour spécifier une valeur de fin par rapport à la valeur de départ, définissez la propriété By . Vous devez définir cette valeur au lieu de la propriété To .
  • Si vous ne spécifiez pas de valeur To ou by , la valeur de fin est quelle que soit la valeur que la propriété animée a au moment de l’exécution de l’animation. Dans ce cas, vous auriez mieux une valeur From , car sinon l’animation ne modifiera pas la valeur du tout ; ses valeurs de début et de fin sont toutes les deux identiques.
  • Une animation a généralement au moins l’un des trois éléments From, By ou To , mais jamais tous les trois.

Examinons l’exemple XAML précédent et examinons à nouveau les valeurs From et To , ainsi que la durée. L’exemple illustre l’animation de la propriété Opacity et le type de propriété Opacity est Double. L’animation à utiliser ici est Donc DoubleAnimation.

From="1.0" To="0.0" spécifie que lorsque l’animation s’exécute, la propriété Opacity démarre à une valeur de 1 et s’anime à 0. En d’autres termes, en termes de signification de ces valeurs doubles à la propriété Opacity, cette animation entraîne le début de l’objet opaque, puis s’est fondu en transparence.

...
<Storyboard x:Name="myStoryboard">
  <DoubleAnimation
    Storyboard.TargetName="MyAnimatedRectangle"
    Storyboard.TargetProperty="Opacity"
    From="1.0" To="0.0" Duration="0:0:1"/>
</Storyboard>
...

Duration="0:0:1" spécifie la durée pendant laquelle l’animation dure, c’est-à-dire la vitesse à laquelle le rectangle est fondu. Une propriété Duration est spécifiée sous la forme d’heures :minutes :secondes. La durée de cet exemple est d’une seconde.

Pour plus d’informations sur les valeurs duration et la syntaxe XAML, consultez Duration.

Remarque

Pour l’exemple que nous avons montré, si vous étiez sûr que l’état de départ de l’objet animé est toujours égal à 1, soit par défaut, soit par un ensemble explicite, vous pourriez omettre la valeur From, l’animation utiliserait la valeur de départ implicite, et le résultat serait le même.

From/To/By sont nullables

Nous avons mentionné précédemment que vous pouvez omettre From, To ou By et donc utiliser des valeurs non animées actuelles comme substituts à une valeur manquante. De, Vers ou Par les propriétés d’une animation ne sont pas du type que vous pouvez deviner. Par exemple, le type de la propriété DoubleAnimation.To n’est pas double. Au lieu de cela, il s’agit d’une valeur Nullable pour Double. Et sa valeur par défaut est Null, et non 0. Cette valeur null est la façon dont le système d’animation distingue que vous n’avez pas spécifiquement défini de valeur pour une propriété From, To ou By . Les extensions de composant Visual C++ (C++/CX) n’ont pas de type Nullable. Elle utilise plutôt IReference.

Autres propriétés d’une animation

Les propriétés suivantes décrites dans cette section sont toutes facultatives en ce qu’elles ont des valeurs par défaut appropriées pour la plupart des animations.

Correction automatique

Si vous ne spécifiez pas autoReverse ou RepeatBehavior sur une animation, cette animation s’exécute une seule fois et s’exécute pour l’heure spécifiée comme durée.

La propriété AutoReverse spécifie si une chronologie est lue dans l’inverse une fois qu’elle atteint la fin de sa durée. Si vous définissez cette valeur sur true, l’animation inverse une fois qu’elle atteint la fin de sa durée déclarée, en remplaçant la valeur de fin (To) par sa valeur de départ (From). Cela signifie que l’animation s’exécute efficacement pendant deux fois le temps de sa durée.

RepeatBehavior

La propriété RepeatBehavior spécifie le nombre de fois qu’une chronologie est lue ou une durée plus longue dans laquelle la chronologie doit se répéter. Par défaut, une chronologie a un nombre d’itérations de « 1x », ce qui signifie qu’elle lit une fois pour sa durée et ne se répète pas.

Vous pouvez entraîner l’exécution de l’animation à plusieurs itérations. Par exemple, une valeur de « 3x » entraîne l’exécution de l’animation trois fois. Vous pouvez également spécifier une durée différente pour RepeatBehavior. Cette durée doit être plus longue que la durée de l’animation elle-même pour être effective. Par exemple, si vous spécifiez un RepeatBehavior de « 0:0:10 », pour une animation dont la durée est « 0:0:2 », cette animation se répète cinq fois. Si ces valeurs ne se divisent pas uniformément, l’animation est tronquée au moment où l’heure RepeatBehavior est atteinte, ce qui peut être partiellement parcouru. Enfin, vous pouvez spécifier la valeur spéciale « Forever », ce qui entraîne l’exécution infinie de l’animation jusqu’à ce qu’elle soit délibérément arrêtée.

Pour plus d’informations sur les valeurs RepeatBehavior et la syntaxe XAML, consultez RepeatBehavior.

FillBehavior="Stop »

Par défaut, lorsqu’une animation se termine, l’animation laisse la valeur de la propriété comme valeur finale To ou By-modified, même après que sa durée soit dépassée. Toutefois, si vous définissez la valeur de la propriété FillBehavior sur FillBehavior.Stop, la valeur de la valeur animée revient à ce que la valeur était avant l’application de l’animation, ou plus précisément à la valeur effective actuelle telle que déterminée par le système de propriétés de dépendance (pour plus d’informations sur cette distinction, consultez la vue d’ensemble des propriétés de dépendance).

BeginTime

Par défaut, BeginTime d’une animation est « 0:0:0 », et commence dès que son storyboard contient des exécutions. Vous pouvez changer cela si le Storyboard contient plusieurs animations et que vous souhaitez décaler les heures de début des autres par rapport à une animation initiale, ou pour créer un court délai délibéré.

SpeedRatio

Si vous avez plusieurs animations dans un Storyboard, vous pouvez modifier le taux de temps d’une ou plusieurs animations par rapport au Storyboard. Il s’agit du Storyboard parent qui contrôle finalement la durée écoulée pendant l’exécution des animations. Cette propriété n’est pas utilisée très souvent. Pour plus d’informations, consultez SpeedRatio.

Définition de plusieurs animations dans un storyboard

Le contenu d’un Storyboard peut être plusieurs définitions d’animation. Vous pouvez avoir plusieurs animations si vous appliquez des animations associées à deux propriétés du même objet cible. Par exemple, vous pouvez modifier les propriétés TranslateX et TranslateY d’une TranslateTransform utilisée comme RenderTransform d’un élément d’interface utilisateur. Cela entraîne la traduction diagonale de l’élément. Vous avez besoin de deux animations différentes pour y parvenir, mais vous souhaiterez peut-être que les animations font partie du même Storyboard , car vous souhaitez toujours que ces deux animations soient exécutées ensemble.

Les animations n’ont pas besoin d’être du même type ou de cibler le même objet. Ils peuvent avoir des durées différentes et ne doivent pas partager de valeurs de propriété.

Lorsque le Storyboard parent s’exécute, chacune des animations au sein s’exécute également.

La classe Storyboard possède en fait beaucoup de mêmes propriétés d’animation que les types d’animation, car les deux partagent la classe de base Timeline. Par conséquent, un Storyboard peut avoir un RepeatBehavior ou un BeginTime. Vous ne les définissez généralement pas sur un Storyboard , sauf si vous souhaitez que toutes les animations contenues aient ce comportement. En règle générale, toute propriété Timeline définie sur un Storyboard s’applique à toutes ses animations enfants. Si nous n’avons pas défini, le Storyboard a une durée implicite calculée à partir de la valeur Durée la plus longue des animations contenues. Une durée définie explicitement sur un Storyboard plus court que l’une de ses animations enfants entraîne la coupure de cette animation, ce qui n’est généralement pas souhaitable.

Un storyboard ne peut pas contenir deux animations qui tentent de cibler et animer la même propriété sur le même objet. Si vous essayez cela, vous obtenez une erreur d’exécution lorsque le storyboard tente d’exécuter. Cette restriction s’applique même si les animations ne se chevauchent pas dans le temps en raison de valeurs et de durées BeginTime délibérément différentes. Si vous souhaitez vraiment appliquer une chronologie d’animation plus complexe à la même propriété dans un seul storyboard, la façon de procéder consiste à utiliser une animation de trame clé. Consultez les animations de fonction d’accélération et d’image clé.

Le système d’animation peut appliquer plusieurs animations à la valeur d’une propriété, si ces entrées proviennent de plusieurs storyboards. L’utilisation de ce comportement délibérément pour exécuter simultanément des storyboards n’est pas courante. Toutefois, il est possible qu’une animation définie par l’application que vous appliquez à une propriété de contrôle modifie la valeur HoldEnd d’une animation qui a été exécutée précédemment dans le cadre du modèle d’état visuel du contrôle.

Définition d’un storyboard en tant que ressource

Un storyboard est le conteneur dans lequel vous placez des objets d’animation. Vous définissez généralement le Storyboard en tant que ressource disponible pour l’objet que vous souhaitez animer, soit dans les ressources au niveau de la page, soit dans Application.Resources.

Cet exemple montre comment l’exemple précédent storyboard serait contenu dans une définition de ressources au niveau de la page, où le storyboard est une ressource clé de la page racine. Notez l’attribut x :Name. Cet attribut est la façon dont vous définissez un nom de variable pour le Storyboard, afin que d’autres éléments en XAML ainsi que du code puissent faire référence au Storyboard ultérieurement.

<Page ...>
  <Page.Resources>
    <!-- Storyboard resource: Animates a rectangle's opacity. -->
    <Storyboard x:Name="myStoryboard">
      <DoubleAnimation
        Storyboard.TargetName="MyAnimatedRectangle"
        Storyboard.TargetProperty="Opacity"
        From="1.0" To="0.0" Duration="0:0:1"/>
    </Storyboard>
  </Page.Resources>
  <!--Page root element, UI definition-->
  <Grid>
    <Rectangle x:Name="MyAnimatedRectangle"
      Width="300" Height="200" Fill="Blue"/>
  </Grid>
</Page>

La définition de ressources à la racine XAML d’un fichier XAML tel que page.xaml ou app.xaml est une pratique courante pour organiser les ressources clé dans votre code XAML. Vous pouvez également factoriser des ressources dans des fichiers distincts et les fusionner dans des applications ou des pages. Pour plus d’informations, consultez les références de ressources ResourceDictionary et XAML.

Remarque

Windows Runtime XAML prend en charge l’identification des ressources à l’aide de l’attribut x :Key ou de l’attribut x :Name. L’utilisation de l’attribut x :Name est plus courante pour un Storyboard, car vous souhaitez la référencer par nom de variable, afin que vous puissiez appeler sa méthode Begin et exécuter les animations. Si vous utilisez l’attribut x :Key, vous devez utiliser des méthodes ResourceDictionary telles que l’indexeur Item pour la récupérer en tant que ressource clé, puis convertir l’objet récupéré en Storyboard pour utiliser les méthodes Storyboard.

Storyboards pour les états visuels

Vous placez également vos animations dans une unité Storyboard lorsque vous déclarez les animations d’état visuel pour l’apparence visuelle d’un contrôle. Dans ce cas, les éléments storyboard que vous définissez entrent dans un conteneur VisualState imbriqué plus profondément dans un style (il s’agit du style qui est la ressource clé). Vous n’avez pas besoin d’une clé ou d’un nom pour votre Storyboard dans ce cas, car il s’agit du VisualState qui a un nom cible que VisualStateManager peut appeler. Les styles des contrôles sont souvent pris en compte dans des fichiers Xaml ResourceDictionary distincts plutôt que placés dans une collection de ressources de page ou d’application. Pour plus d’informations, consultez les animations storyboarded pour les états visuels.

Animations dépendantes et indépendantes

À ce stade, nous devons introduire quelques points importants sur le fonctionnement du système d’animation. En particulier, l’animation interagit fondamentalement avec la façon dont une application Windows Runtime s’affiche à l’écran et comment ce rendu utilise les threads de traitement. Une application Windows Runtime a toujours un thread d’interface utilisateur principal et ce thread est chargé de mettre à jour l’écran avec les informations actuelles. En outre, une application Windows Runtime a un thread de composition, qui est utilisé pour précalculer des dispositions immédiatement avant qu’elles ne soient affichées. Lorsque vous animez l’interface utilisateur, il est possible de provoquer beaucoup de travail pour le thread d’interface utilisateur. Le système doit redessiner de grandes zones de l’écran à l’aide d’intervalles de temps assez courts entre chaque actualisation. Cela est nécessaire pour capturer la dernière valeur de propriété de la propriété animée. Si vous n’êtes pas prudent, il existe un risque qu’une animation puisse rendre l’interface utilisateur moins réactive ou affectera les performances d’autres fonctionnalités d’application qui se trouvent également sur le même thread d’interface utilisateur.

La variété d’animations qui est déterminée à avoir un certain risque de ralentir le thread d’interface utilisateur est appelée animation dépendante. Une animation qui n’est pas soumise à ce risque est une animation indépendante. La distinction entre les animations dépendantes et indépendantes n’est pas seulement déterminée par les types d’animations (DoubleAnimation , et ainsi de suite) comme nous l’avons décrit précédemment. Au lieu de cela, il est déterminé par les propriétés spécifiques que vous animez, et d’autres facteurs tels que l’héritage et la composition des contrôles. Il existe des circonstances où même si une animation modifie l’interface utilisateur, l’animation peut avoir un impact minimal sur le thread d’interface utilisateur et peut être gérée par le thread de composition en tant qu’animation indépendante.

Une animation est indépendante si elle a l’une de ces caractéristiques :

Avertissement

Pour que votre animation soit traitée comme indépendante, vous devez définir Duration="0"explicitement . Par exemple, si vous supprimez Duration="0" de ce code XAML, l’animation est traitée comme dépendante, même si keyTime de l’image est « 0:0:0:0 ».

<Storyboard>
  <DoubleAnimationUsingKeyFrames
    Duration="0"
    Storyboard.TargetName="Button2"
    Storyboard.TargetProperty="Width">
    <DiscreteDoubleKeyFrame KeyTime="0:0:0" Value="200"/>
  </DoubleAnimationUsingKeyFrames>
</Storyboard>

Si votre animation ne répond pas à ces critères, il s’agit probablement d’une animation dépendante. Par défaut, le système d’animation n’exécute pas d’animation dépendante. Ainsi, pendant le processus de développement et de test, vous risquez même de ne pas voir votre animation en cours d’exécution. Vous pouvez toujours utiliser cette animation, mais vous devez activer spécifiquement chacune de ces animations dépendantes. Pour activer votre animation, définissez la propriété EnableDependentAnimation de l’objet d’animation sur true. (Chacun d’eux La sous-classe Chronologie qui représente une animation a une implémentation différente de la propriété, mais elles sont toutes nommées EnableDependentAnimation.)

L’exigence d’activer les animations dépendantes qui tombent sur le développeur d’applications est un aspect de conception conscient du système d’animation et de l’expérience de développement. Nous voulons que les développeurs sachent que les animations ont un coût de performances pour la réactivité de votre interface utilisateur. Les animations mal performantes sont difficiles à isoler et déboguer dans une application à grande échelle. Il est donc préférable d’activer uniquement les animations dépendantes dont vous avez vraiment besoin pour l’expérience de l’interface utilisateur de votre application. Nous ne voulions pas trop facilement compromettre les performances de votre application en raison d’animations décoratives qui utilisent beaucoup de cycles. Pour plus d’informations sur les conseils de performances pour l’animation, consultez Optimiser les animations et les supports.

En tant que développeur d’applications, vous pouvez également choisir d’appliquer un paramètre à l’échelle de l’application qui désactive toujours les animations dépendantes, même ceux où EnableDependentAnimation est vrai. Voir Timeline.AllowDependentAnimations.

Conseil

Si vous utilisez le volet Animation dans Blend pour Visual Studio 2019, chaque fois que vous tentez d’appliquer une animation dépendante à une propriété d’état visuel, les avertissements s’affichent dans le concepteur. Les avertissements ne s’affichent pas dans la sortie de build ou la liste d’erreurs. Si vous modifiez le code XAML manuellement, le concepteur n’affiche pas d’avertissement. Au moment du débogage, la sortie de débogage du volet Sortie affiche un avertissement indiquant que l’animation n’est pas indépendante et qu’elle est ignorée.

Démarrage et contrôle d’une animation

Tout ce que nous vous avons montré jusqu’à présent ne provoque pas réellement l’exécution ou l’application d’une animation ! Tant que l’animation n’est pas démarrée et en cours d’exécution, la valeur change qu’une animation déclare en XAML est latente et ne se produit pas encore. Vous devez démarrer explicitement une animation d’une manière quelconque liée à la durée de vie de l’application ou à l’expérience utilisateur. Au niveau le plus simple, vous démarrez une animation en appelant la méthode Begin sur le Storyboard qui est le parent de cette animation. Vous ne pouvez pas appeler directement des méthodes à partir de XAML. Par conséquent, quoi que vous fassiez pour activer vos animations, vous le ferez à partir du code. Il s’agit soit du code-behind pour les pages ou les composants de votre application, soit la logique de votre contrôle si vous définissez une classe de contrôle personnalisée.

En règle générale, vous allez appeler Begin et laisser l’animation s’exécuter jusqu’à sa fin de durée. Toutefois, vous pouvez également utiliser les méthodes Pause, Resume et Stop pour contrôler le Storyboard au moment de l’exécution, ainsi que d’autres API utilisées pour des scénarios de contrôle d’animation plus avancés.

Lorsque vous appelez Begin sur un storyboard qui contient une animation qui se répète infiniment (RepeatBehavior="Forever"), cette animation s’exécute jusqu’à ce que la page contenant celle-ci soit déchargée, ou que vous appelez spécifiquement Pause ou Stop.

Démarrage d’une animation à partir du code de l’application

Vous pouvez démarrer automatiquement des animations ou en réponse aux actions de l’utilisateur. Pour le cas automatique, vous utilisez généralement un événement de durée de vie d’objet tel que Loaded pour agir comme déclencheur d’animation. L’événement Loaded est un bon événement à utiliser pour cela, car à ce stade, l’interface utilisateur est prête pour l’interaction et l’animation ne sera pas coupée au début, car une autre partie de l’interface utilisateur était toujours en cours de chargement.

Dans cet exemple, l’événement PointerPressed est attaché au rectangle afin que lorsque l’utilisateur clique sur le rectangle, l’animation commence.

<Rectangle PointerPressed="Rectangle_Tapped"
  x:Name="MyAnimatedRectangle"
  Width="300" Height="200" Fill="Blue"/>

Le gestionnaire d’événements démarre le Storyboard (l’animation) à l’aide de la méthode Begin du Storyboard.

myStoryboard.Begin();

myStoryboard().Begin();

myStoryboard->Begin();

myStoryBoard.Begin()

Vous pouvez gérer l’événement Completed si vous souhaitez que d’autres logiques s’exécutent une fois que l’animation a terminé d’appliquer des valeurs. En outre, pour résoudre les problèmes liés aux interactions entre le système de propriétés et les animations, la méthode GetAnimationBaseValue peut être utile.

Conseil

Chaque fois que vous codez pour un scénario d’application où vous démarrez une animation à partir du code de l’application, vous pouvez vérifier à nouveau si une animation ou une transition existe déjà dans la bibliothèque d’animations de votre scénario d’interface utilisateur. Les animations de bibliothèque permettent une expérience d’interface utilisateur plus cohérente dans toutes les applications Windows Runtime et sont plus faciles à utiliser.

 

Animations pour les états visuels

Le comportement d’exécution d’un Storyboard utilisé pour définir l’état visuel d’un contrôle est différent de la façon dont une application peut exécuter un storyboard directement. Comme appliqué à une définition d’état visuel en XAML, le Storyboard est un élément d’un VisualState contenant, et l’état dans son ensemble est contrôlé à l’aide de l’API VisualStateManager. Toutes les animations au sein s’exécutent en fonction de leurs valeurs d’animation et de leurs propriétés chronologie lorsque visualState conteneur est utilisé par un contrôle. Pour plus d’informations, consultez Storyboards pour obtenir des états visuels. Pour les états visuels, le fillBehavior apparent est différent. Si un état visuel est remplacé par un autre état, toutes les modifications de propriété appliquées par l’état visuel précédent et ses animations sont annulées, même si le nouvel état visuel n’applique pas spécifiquement une nouvelle animation à une propriété.

Storyboard et EventTrigger

Il existe un moyen de démarrer une animation qui peut être déclarée entièrement en XAML. Toutefois, cette technique n’est plus largement utilisée. Il s’agit d’une syntaxe héritée de WPF et de versions antérieures de Silverlight avant la prise en charge de VisualStateManager. Cette syntaxe EventTrigger fonctionne toujours en XAML Windows Runtime pour des raisons d’importation/compatibilité, mais ne fonctionne que pour un comportement de déclencheur basé sur l’événement FrameworkElement.Loaded. La tentative de déclenchement d’autres événements lève des exceptions ou échoue à compiler. Pour plus d’informations, consultez EventTrigger ou BeginStoryboard.

Animation des propriétés jointes XAML

Ce n’est pas un scénario courant, mais vous pouvez appliquer une valeur animée à une propriété jointe XAML. Pour plus d’informations sur les propriétés jointes et leur fonctionnement, consultez la vue d’ensemble des propriétés jointes. Le ciblage d’une propriété jointe nécessite une syntaxe de chemin de propriété qui place le nom de propriété entre parenthèses. Vous pouvez animer les propriétés intégrées telles que Canvas.ZIndex à l’aide d’un ObjectAnimationUsingKeyFrames qui applique des valeurs entières discrètes. Toutefois, une limitation existante de l’implémentation XAML Windows Runtime est que vous ne pouvez pas animer une propriété jointe personnalisée.

Plus de types d’animations et étapes suivantes pour en savoir plus sur l’animation de votre interface utilisateur

Jusqu’à présent, nous avons montré les animations personnalisées qui s’animent entre deux valeurs, puis interpolation linéaire des valeurs si nécessaire pendant l’exécution de l’animation. Ces animations sont appelées From/To/By. Mais il existe un autre type d’animation qui vous permet de déclarer des valeurs intermédiaires comprises entre le début et la fin. Ces animations sont appelées animations d’images clés. Il existe également un moyen de modifier la logique d’interpolation sur une animation From/To/By ou une animation de trame clé. Cela implique l’application d’une fonction d’accélération. Pour plus d’informations sur ces concepts, consultez les animations de fonction d’accélération et d’image clé.