Évolutivité

Lorsque vous développez des applications pour plusieurs plateformes d’appareils mobiles différentes, vous êtes confronté aux défis suivants :

• Les plateformes d'appareils mobiles prennent en charge des appareils présentant des configurations d'écran variées : taille, format, orientation et densité.
• Les différentes plateformes ont des conventions d'interface utilisateur distinctes et vous devez répondre aux attentes des utilisateurs sur chacune d'entre elles.

Qt Quick QML vous permet de développer des applications capables de fonctionner sur différents types d’appareils, tels que les tablettes et les téléphones mobiles. Elles peuvent notamment s’adapter à différentes configurations d’écran. Cependant, un certain travail d’ajustement et de peaufinage est toujours nécessaire pour créer une expérience utilisateur optimale sur chaque plateforme cible.

Vous devez tenir compte de l’évolutivité lorsque :

• Vous souhaitez déployer votre application sur plusieurs plateformes d’appareils, telles qu’Android et iOS, ou sur plusieurs configurations d’écran.
• Vous souhaitez vous préparer à l’arrivée de nouveaux appareils susceptibles d’apparaître sur le marché après votre déploiement initial.

Pour mettre en œuvre des applications évolutives à l’aide de Qt Quick:

• Concevez des interfaces utilisateur à l’aide de Qt Quick Controls qui fournissent des ensembles de contrôles d’interface utilisateur.
• Définissez des mises en page à l'aide de Qt Quick Layouts, qui permettent de redimensionner leurs éléments.
• Utilisez la liaison de propriétés pour implémenter des cas d’utilisation non couverts par les mises en page. Par exemple, pour afficher des versions alternatives d’images sur des écrans à faible ou forte densité de pixels, ou pour adapter automatiquement le contenu de la vue en fonction de l’orientation actuelle de l’écran.
• Sélectionnez un appareil de référence et calculez un rapport d’échelle pour ajuster la taille des images et des polices ainsi que les marges à la taille réelle de l’écran.
• Chargez les ressources spécifiques à la plateforme à l’aide de sélecteurs de fichiers.
• Chargez les composants à la demande à l’aide d’un chargeur.

Tenez compte des modèles suivants lors de la conception de votre application :

• Le contenu d’une vue peut être assez similaire sur toutes les tailles d’écran, mais avec une zone de contenu étendue. Si vous utilisez le type QML ` ApplicationWindow ` disponible sur Qt Quick Controls, celui-ci calculera automatiquement la taille de la fenêtre en fonction des tailles de ses éléments de contenu. Si vous utilisez ` Qt Quick Layouts ` pour positionner les éléments de contenu, ceux-ci redimensionneront automatiquement les éléments qui leur sont transmis.
• Le contenu d’une page entière sur un appareil plus petit pourrait constituer un élément composant d’une mise en page sur un appareil plus grand. Par conséquent, envisagez d’en faire un composant distinct (c’est-à-dire défini dans un fichier QML séparé) ; sur l’appareil plus petit, la vue contiendra simplement une instance de ce composant. Sur un appareil plus grand, l’espace disponible peut être suffisant pour utiliser des chargeurs afin d’afficher des éléments supplémentaires. Par exemple, dans une application de lecture d’e-mails, si l’écran est suffisamment grand, il peut être possible d’afficher côte à côte la vue de la liste des e-mails et la vue du lecteur d’e-mails.
• Pour les jeux, vous souhaiterez généralement créer un plateau de jeu qui ne s’adapte pas à la taille de l’écran, afin de ne pas offrir un avantage injuste aux joueurs disposant d’écrans plus grands. Une solution consiste à définir une zone de sécurité adaptée à l’écran présentant le format d’image le plus petit pris en charge (généralement 3:2), et à ajouter du contenu purement décoratif dans l’espace qui sera masqué sur un écran 4:3 ou 16:9.

Redimensionnement dynamique des fenêtres d’application

Qt Quick Controls fournit un ensemble de contrôles d’interface utilisateur permettant de créer des interfaces utilisateur dans Qt Quick. En général, vous déclarez un contrôle « ApplicationWindow » comme élément racine de votre application. Le « ApplicationWindow » facilite le positionnement d’autres contrôles, tels que « MenuBar », « ToolBar » et « StatusBar », de manière indépendante de la plateforme. Le « ApplicationWindow » utilise les contraintes de taille des éléments de contenu comme données d’entrée pour calculer les contraintes de taille effectives de la fenêtre réelle.

Outre les contrôles qui définissent les éléments standard des fenêtres d’application, des contrôles sont fournis pour créer des vues et des menus, ainsi que pour afficher ou recevoir des entrées de la part des utilisateurs. Vous pouvez utiliser les styles «Qt Quick Controls » pour appliquer un style personnalisé aux contrôles prédéfinis.

Qt Quick Controls, tels que l’ ToolBar, ne fournissent pas de mise en page propre, mais vous obligent à positionner leur contenu. Pour cela, vous pouvez utiliser l’ Qt Quick Layouts.

Mise en page dynamique des contrôles d’écran

Qt Quick Layouts fournit des moyens de disposer les contrôles d’écran en ligne, en colonne ou en grille, à l’aide des types QML ` RowLayout`, ` ColumnLayout` et ` GridLayout `. Les propriétés de ces types QML définissent leur sens de disposition et l’espacement entre les cellules.

Vous pouvez utiliser les Qt Quick Layouts types QML pour associer des propriétés supplémentaires aux éléments insérés dans les mises en page. Par exemple, vous pouvez spécifier des valeurs minimales, maximales et préférées pour la hauteur, la largeur et la taille des éléments.

Les mises en page garantissent que vos interfaces utilisateur sont correctement redimensionnées lorsque les fenêtres et les écrans changent de taille, et utilisent toujours au maximum l’espace disponible.

Un cas d’utilisation spécifique du type ` GridLayout ` consiste à l’utiliser comme ligne ou comme colonne en fonction de l’orientation de l’écran.

L'extrait de code suivant utilise la propriété ` flow ` pour définir le sens de la grille de gauche à droite (en tant que ligne) lorsque la largeur de l'écran est supérieure à sa hauteur, et de haut en bas (en tant que colonne) dans le cas contraire :

ApplicationWindow {
    id: root
    visible: true
    width: 480
    height: 620

    GridLayout {
        anchors.fill: parent
        anchors.margins: 20
        rowSpacing: 20
        columnSpacing: 20
        flow:  width > height ? GridLayout.LeftToRight : GridLayout.TopToBottom
        Rectangle {
            Layout.fillWidth: true
            Layout.fillHeight: true
            color: "#5d5b59"
            Label {
                anchors.centerIn: parent
                text: "Top or left"
                color: "white"
            }
        }
        Rectangle {
            Layout.fillWidth: true
            Layout.fillHeight: true
            color: "#1e1b18"
            Label {
                anchors.centerIn: parent
                text: "Bottom or right"
                color: "white"
            }
        }
    }
}

Le redimensionnement et le recalcul constants des écrans ont un coût en termes de performances. Les appareils mobiles et embarqués peuvent ne pas disposer de la puissance nécessaire pour recalculer la taille et la position des objets animés à chaque image, par exemple. Si vous rencontrez des problèmes de performances lors de l'utilisation de mises en page, envisagez plutôt d'utiliser d'autres méthodes, telles que les liaisons.

Voici quelques choses à ne pas faire avec les mises en page :

• N’établissez pas de liaisons avec les propriétés x, y, width ou height des éléments d’une mise en page, car cela irait à l’encontre de l’objectif de la mise en page et provoquerait également des boucles de liaison.
• Ne définissez pas de fonctions JavaScript complexes qui sont évaluées régulièrement. Cela entraînerait une baisse des performances, en particulier lors des transitions animées.
• Ne faites pas d’hypothèses sur la taille du conteneur ou sur celle des éléments enfants. Essayez de créer des définitions de mise en page flexibles, capables de s’adapter aux variations de l’espace disponible.
• N’utilisez pas de mises en page si vous souhaitez que le design soit précis au pixel près. Les éléments de contenu seront automatiquement redimensionnés et positionnés en fonction de l’espace disponible.

Utilisation des liaisons

Si les « Qt Quick Layouts » ne répondent pas à vos besoins, vous pouvez recourir à la liaison de propriétés. La liaison permet aux objets de mettre automatiquement à jour leurs propriétés en réponse à la modification d'attributs d'autres objets ou à la survenue d'un événement externe.

Lorsqu’une valeur est attribuée à la propriété d’un objet, il peut s’agir soit d’une valeur statique, soit d’une liaison à une expression JavaScript. Dans le premier cas, la valeur de la propriété ne changera pas à moins qu’une nouvelle valeur ne lui soit attribuée. Dans le second cas, une liaison de propriété est créée et la valeur de la propriété est automatiquement mise à jour par le moteur QML chaque fois que la valeur de l’expression évaluée change.

Ce type de liaison est le plus dynamique. Cependant, l’évaluation constante d’expressions JavaScript a un coût en termes de performances.

Vous pouvez utiliser des liaisons pour gérer les faibles et fortes densités de pixels sur les plateformes qui ne prennent pas automatiquement en charge cette fonctionnalité (contrairement à Android, macOS et iOS). L’extrait de code suivant utilise la propriété attachée ` Screen.pixelDensity ` pour spécifier différentes images à afficher sur des écrans à faible, forte ou normale densité de pixels :

Image {
    source: {
        if (Screen.pixelDensity < 40)
        "image_low_dpi.png"
        else if (Screen.pixelDensity > 300)
        "image_high_dpi.png"
        else
        "image.png"
        }
    }

Sur Android, macOS et iOS, vous pouvez fournir des ressources alternatives à plus haute résolution en utilisant l’identifiant correspondant (par exemple @2x, @3x ou @4x) pour les icônes et les images, et les placer dans le fichier de ressources. La version correspondant à la densité de pixels de l’écran est automatiquement sélectionnée.

Par exemple, l'extrait de code suivant tentera de charger artwork@2x.png sur les écrans Retina :

Image {
    source: "artwork.png"
}

Gestion de la densité de pixels

Certains types QML, tels que Image, BorderImage et Text, sont automatiquement redimensionnés en fonction des propriétés qui leur sont attribuées. Si la largeur et la hauteur d’une image ne sont pas spécifiées, celle-ci utilise automatiquement la taille de l’image source, définie à l’aide de la propriété source. Par défaut, la spécification de la largeur et de la hauteur entraîne le redimensionnement de l’image à cette taille. Ce comportement peut être modifié en définissant la propriété « fillMode », ce qui permet d’étirer et de mosaïquer l’image à la place. Cependant, la taille d’origine de l’image peut paraître trop petite sur les écrans à haute résolution (DPI).

Un ` BorderImage ` est utilisé pour créer des bordures à partir d’images en redimensionnant ou en répétant des parties de chaque image. Il divise une image source en 9 régions qui sont redimensionnées ou répétées en fonction des valeurs des propriétés. Cependant, les coins ne sont pas du tout redimensionnés, ce qui peut rendre les résultats moins qu’optimaux sur les écrans à haute résolution (DPI élevé).

Le type QML « Text » tente de déterminer l’espace nécessaire et de définir les propriétés ` width ` et ` height ` en conséquence, à moins qu’elles ne soient explicitement définies. La propriété ` fontPointSize ` définit la taille en points de manière indépendante du périphérique. Cependant, spécifier des polices en points et d’autres tailles en pixels pose des problèmes, car les points sont indépendants de la densité d’affichage. Un cadre autour d’une chaîne de caractères qui s’affiche correctement sur des écrans à faible DPI risque de devenir trop petit sur des écrans à haute DPI, ce qui entraînera un rognage du texte.

Le niveau de prise en charge des écrans à haute résolution et les techniques utilisées par les plateformes prises en charge varient d’une plateforme à l’autre. Les sections suivantes décrivent différentes approches pour mettre à l’échelle le contenu à l’écran sur les écrans à haute résolution.

Pour plus d’informations sur la prise en charge des écrans à haute résolution dans Qt et sur les plateformes prises en charge, consultez la section « Haute résolution ».

Mise à l'échelle haute résolution

Si un périphérique cible prend en charge la mise à l’échelle haute résolution, le système d’exploitation fournit à Qt un rapport de mise à l’échelle utilisé pour redimensionner la sortie graphique.

L’avantage de cette approche est que les graphiques vectoriels et les polices s’adaptent automatiquement et que les applications existantes fonctionnent généralement sans modification. Pour le contenu matriciel, des ressources alternatives haute résolution sont toutefois nécessaires.

La mise à l'échelle est implémentée pour les piles « Qt Quick » et « Qt Widgets », ainsi qu’au niveau général dans Qt GUI.

Les API graphiques de bas niveau fonctionnent en pixels de périphérique. Cela inclut le code utilisant l’API OpenGL et celui utilisant l’API QRhi. Par exemple, cela signifie qu’un QWindow dont la résolution d’écran ( size() ) est de 1280x720 et dont la taille de la chaîne d’échange ( QWindow::devicePixelRatio()) est de 2 dispose d’une cible de rendu (swapchain) dont la taille en pixels de périphérique est de 2560x1440.

Le système d’exploitation met à l’échelle la géométrie de la fenêtre, des événements et du bureau. Le plugin de la plateforme Cocoa définit le rapport d’échelle à l’aide de QWindow::devicePixelRatio() ou QScreen::devicePixelRatio(), ainsi que sur le backing store.

Pour ` Qt Widgets`, ` QPainter ` récupère ` devicePixelRatio() ` depuis le magasin de données et l’interprète comme un rapport de mise à l’échelle.

Cependant, dans OpenGL, les pixels sont toujours des pixels de périphérique. Par exemple, la géométrie transmise à glViewport() doit être mise à l'échelle à l'aide de devicePixelRatio().

Les tailles de police spécifiées (en points ou en pixels) ne changent pas et les chaînes de caractères conservent leur taille relative par rapport au reste de l’interface utilisateur. Les polices sont mises à l'échelle lors du traçage, de sorte qu’une police de taille 12 devient effectivement une police de taille 24 avec une mise à l’échelle de 2x, qu’elle soit spécifiée en points ou en pixels. L’unité px est interprétée comme des pixels indépendants du périphérique afin de garantir que les polices n’apparaissent pas plus petites sur un écran à haute résolution (DPI).

Calcul du rapport de mise à l’échelle

Vous pouvez sélectionner un appareil à haute résolution comme appareil de référence et calculer un rapport de mise à l’échelle afin d’ajuster la taille des images et des polices, ainsi que les marges, à la taille réelle de l’écran.

L'extrait de code suivant utilise les valeurs de référence pour le DPI, la hauteur et la largeur de l'appareil Android Nexus 5, la taille réelle de l'écran renvoyée par la classe ` QRect `, ainsi que la valeur de DPI logique de l'écran renvoyée par le pointeur global ` qApp `, afin de calculer un rapport d'échelle pour les tailles d'image et les marges (m_ratio) et un autre pour les tailles de police (m_ratioFont) :

qreal refDpi = 216.;
qreal refHeight = 1776.;
qreal refWidth = 1080.;
QRect rect = QGuiApplication::primaryScreen()->geometry();
qreal height = qMax(rect.width(), rect.height());
qreal width = qMin(rect.width(), rect.height());
qreal dpi = QGuiApplication::primaryScreen()->logicalDotsPerInch();
m_ratio = qMin(height/refHeight, width/refWidth);
m_ratioFont = qMin(height*refDpi/(dpi*refHeight), width*refDpi/(dpi*refWidth));

Pour obtenir un rapport de mise à l'échelle raisonnable, les valeurs de hauteur et de largeur doivent être définies en fonction de l'orientation par défaut de l'appareil de référence, qui est dans ce cas l'orientation portrait.

L’extrait de code suivant définit le rapport de mise à l’échelle des polices à 1 s’il est inférieur à un, ce qui rendrait les tailles de police trop petites :

int tempTimeColumnWidth = 600;
int tempTrackHeaderWidth = 270;
if (m_ratioFont < 1.) {
    m_ratioFont = 1;

Vous devriez tester les appareils cibles afin d’identifier les cas limites nécessitant des calculs supplémentaires. Certains écrans peuvent s’avérer trop courts ou trop étroits pour afficher l’intégralité du contenu prévu et nécessitent donc une mise en page spécifique. Par exemple, vous devrez peut-être masquer ou remplacer certains contenus sur des écrans présentant des formats d’image atypiques, tels que 1:1.

Le rapport de mise à l’échelle peut être appliqué à toutes les tailles d’une page « QQmlPropertyMap » afin de redimensionner les images, les polices et les marges :

m_sizes = new QQmlPropertyMap(this);
m_sizes->insert(QLatin1String("trackHeaderHeight"), QVariant(applyRatio(270)));
m_sizes->insert(QLatin1String("trackHeaderWidth"), QVariant(applyRatio(tempTrackHeaderWidth)));
m_sizes->insert(QLatin1String("timeColumnWidth"), QVariant(applyRatio(tempTimeColumnWidth)));
m_sizes->insert(QLatin1String("conferenceHeaderHeight"), QVariant(applyRatio(158)));
m_sizes->insert(QLatin1String("dayWidth"), QVariant(applyRatio(150)));
m_sizes->insert(QLatin1String("favoriteImageHeight"), QVariant(applyRatio(76)));
m_sizes->insert(QLatin1String("favoriteImageWidth"), QVariant(applyRatio(80)));
m_sizes->insert(QLatin1String("titleHeight"), QVariant(applyRatio(60)));
m_sizes->insert(QLatin1String("backHeight"), QVariant(applyRatio(74)));
m_sizes->insert(QLatin1String("backWidth"), QVariant(applyRatio(42)));
m_sizes->insert(QLatin1String("logoHeight"), QVariant(applyRatio(100)));
m_sizes->insert(QLatin1String("logoWidth"), QVariant(applyRatio(286)));

m_fonts = new QQmlPropertyMap(this);
m_fonts->insert(QLatin1String("six_pt"), QVariant(applyFontRatio(9)));
m_fonts->insert(QLatin1String("seven_pt"), QVariant(applyFontRatio(10)));
m_fonts->insert(QLatin1String("eight_pt"), QVariant(applyFontRatio(12)));
m_fonts->insert(QLatin1String("ten_pt"), QVariant(applyFontRatio(14)));
m_fonts->insert(QLatin1String("twelve_pt"), QVariant(applyFontRatio(16)));

m_margins = new QQmlPropertyMap(this);
m_margins->insert(QLatin1String("five"), QVariant(applyRatio(5)));
m_margins->insert(QLatin1String("seven"), QVariant(applyRatio(7)));
m_margins->insert(QLatin1String("ten"), QVariant(applyRatio(10)));
m_margins->insert(QLatin1String("fifteen"), QVariant(applyRatio(15)));
m_margins->insert(QLatin1String("twenty"), QVariant(applyRatio(20)));
m_margins->insert(QLatin1String("thirty"), QVariant(applyRatio(30)));

Les fonctions de l’extrait de code suivant appliquent le rapport de mise à l’échelle aux polices, aux images et aux marges :

int Theme::applyFontRatio(const int value)
{
    return int(value * m_ratioFont);
}

int Theme::applyRatio(const int value)
{
    return qMax(2, int(value * m_ratio));
}

Cette technique donne des résultats satisfaisants lorsque les tailles d’écran des appareils cibles ne diffèrent pas trop. Si les différences sont importantes, envisagez de créer plusieurs mises en page différentes avec des valeurs de référence différentes.

Chargement des fichiers en fonction de la plateforme

Vous pouvez utiliser l’ QQmlFileSelector pour appliquer une « QFileSelector » au chargement des fichiers QML. Cela vous permet de charger des ressources alternatives en fonction de la plateforme sur laquelle l’application est exécutée. Par exemple, vous pouvez utiliser le sélecteur de fichiers +android pour charger différents fichiers image lors de l’exécution sur des appareils Android.

Vous pouvez utiliser les sélecteurs de fichiers conjointement avec des objets singleton pour accéder à une instance unique d’un objet sur une plateforme donnée.

Les sélecteurs de fichiers sont statiques et imposent une structure de fichiers dans laquelle les fichiers spécifiques à une plateforme sont stockés dans des sous-dossiers portant le nom de la plateforme. Si vous avez besoin d’une solution plus dynamique pour charger des parties de votre interface utilisateur à la demande, vous pouvez utiliser un Loader.

Les plateformes cibles peuvent automatiser le chargement de ressources alternatives pour différentes densités d’affichage de diverses manières. Sur Android et iOS, le suffixe @2x est utilisé pour indiquer les versions à haute résolution (DPI) des images. Le type QML Image et la classe QIcon chargent automatiquement les versions @2x des images et des icônes si elles sont fournies. Les classes ` QImage ` et ` QPixmap ` définissent automatiquement la propriété ` devicePixelRatio ` des versions @2x des images sur ` 2`, mais vous devez ajouter du code pour utiliser effectivement les versions @2x :

if ( QGuiApplication::primaryScreen()->devicePixelRatio() >= 2 ) {
    imageVariant = "@2x";
} else {
    imageVariant = "";
}

Android définit des tailles d'écran généralisées (petite, normale, grande, très grande) et des densités (ldpi, mdpi, hdpi, xhdpi, xxhdpi et xxxhdpi) pour lesquelles vous pouvez créer des ressources alternatives. Android détecte la configuration actuelle de l'appareil lors de l'exécution et charge les ressources adaptées à votre application. Cependant, à partir d'Android 3.2 (niveau d'API 13), ces groupes de tailles sont obsolètes au profit d'une nouvelle technique de gestion des tailles d'écran basée sur la largeur d'écran disponible.

Chargement des composants à la demande

Un composant ( Loader ) peut charger un fichier QML (à l’aide de la propriété ` source `) ou un objet `Component` (à l’aide de la propriété ` sourceComponent `). Cela s’avère utile pour retarder la création d’un composant jusqu’à ce qu’il soit nécessaire. Par exemple, lorsqu’un composant doit être créé à la demande, ou lorsqu’il ne doit pas être créé inutilement pour des raisons de performances.

Vous pouvez également utiliser des chargeurs pour gérer les situations où certaines parties de votre interface utilisateur ne sont pas nécessaires sur une plateforme particulière, car celle-ci ne prend pas en charge certaines fonctionnalités. Au lieu d’afficher une vue qui n’est pas nécessaire sur l’appareil sur lequel l’application s’exécute, vous pouvez décider de masquer cette vue et utiliser des chargeurs pour afficher autre chose à sa place.

Changement d’orientation

La propriété attachée Screen.orientation contient l’orientation actuelle de l’écran, fournie par l’accéléromètre (si disponible). Sur un ordinateur de bureau, cette valeur ne change généralement pas.

Si la propriété associée ` primaryOrientation ` prend la valeur ` orientation`, cela signifie que l’écran fait pivoter automatiquement tout le contenu affiché, en fonction de la façon dont vous tenez l’appareil. Si l’orientation change alors que ` primaryOrientation ` reste inchangée, il se peut que l’appareil ne fasse pas pivoter son propre écran. Dans ce cas, vous devrez peut-être utiliser ` Item.rotation ` ou ` Item.transform ` pour faire pivoter votre contenu.

Les définitions de pages de premier niveau des applications et les définitions de composants réutilisables doivent utiliser une seule définition de mise en page QML pour la structure de mise en page. Cette définition unique doit inclure la conception de la mise en page pour les différentes orientations et formats d’écran des appareils. En effet, les performances lors d’un changement d’orientation sont cruciales ; il est donc recommandé de s’assurer que tous les composants nécessaires aux deux orientations sont chargés au moment du changement d’orientation.

À l’inverse, vous devez effectuer des tests approfondis si vous choisissez d’utiliser une « Loader » pour charger du code QML supplémentaire nécessaire à certaines orientations, car cela affectera les performances lors du changement d’orientation.

Afin de permettre les animations de mise en page entre les orientations, les définitions d’ancrage doivent se trouver au sein du même composant conteneur. Par conséquent, la structure d’une page ou d’un composant doit se composer d’un ensemble commun de composants enfants, d’un ensemble commun de définitions d’ancrage et d’une collection d’états (définis dans une « StateGroup ») représentant les différents formats pris en charge par le composant.

Si un composant contenu dans une page doit être hébergé dans de nombreuses définitions de format différentes, les états de mise en page de la vue doivent alors dépendre du format de la page (son conteneur immédiat). De même, différentes instances d’un composant peuvent se trouver dans de nombreux conteneurs différents au sein d’une interface utilisateur ; leurs états de mise en page doivent donc être déterminés par le format de leur parent. En conclusion, les états de mise en page doivent toujours suivre le format d’image du conteneur direct (et non l’« orientation » de l’écran actuel de l’appareil).

Au sein de chaque é State de mise en page, vous devez définir les relations entre les éléments à l’aide des définitions de mise en page natives de QML. Voir ci-dessous pour plus d’informations. Lors des transitions entre les états (déclenchées par un changement d’orientation au niveau supérieur), dans le cas des mises en page d’ancrage, des éléments ` AnchorAnimation ` peuvent être utilisés pour contrôler les transitions. Dans certains cas, vous pouvez également utiliser une animation « NumberAnimation » (par exemple sur la largeur d’un élément). Veillez à éviter les calculs JavaScript complexes à chaque image de l’ . L’utilisation de définitions d’ancrage simples et d’animations d’ancrage peut vous aider dans la plupart des cas.

Il existe quelques cas supplémentaires à prendre en compte :

• Que faire si vous avez une seule page dont l’apparence diffère complètement entre le mode paysage et le mode portrait, c’est-à-dire que tous les éléments enfants sont différents ? Pour chaque page, prévoyez deux composants enfants, avec des définitions de mise en page distinctes, et faites en sorte que l’un ou l’autre des éléments ait une opacité nulle dans chaque état. Vous pouvez utiliser une animation de fondu enchaîné en appliquant simplement une transition « NumberAnimation » à l’opacité.
• Que faire si vous avez une seule page dont 30 % ou plus du contenu de mise en page est commun aux modes portrait et paysage ? Dans ce cas, envisagez d’utiliser un composant unique comportant des états « paysage » et « portrait », ainsi qu’un ensemble d’éléments enfants distincts dont l’opacité (ou la position) dépend de l’orientation. Cela vous permettra d’utiliser des animations de mise en page pour les éléments communs aux deux orientations, tandis que les autres éléments seront soit mis en avant/retirés progressivement, soit animés pour apparaître/disparaître de l’écran.
• Que faire si vous avez deux pages sur un appareil portable qui doivent s’afficher simultanément à l’écran, par exemple sur un appareil de grand format ? Dans ce cas, notez que votre composant de vue n’occupera plus tout l’écran. Il est donc important de garder à l’esprit que tous les composants (en particulier les éléments délégués de liste) doivent dépendre de la largeur du composant qui les contient, et non de la largeur de l’écran. Il peut être nécessaire de définir la largeur dans un gestionnaire Component.onCompleted() dans ce cas, afin de s’assurer que l’élément délégué de liste a bien été construit avant que la valeur ne soit définie.
• Que faire si les deux orientations occupent trop de mémoire pour être conservées simultanément en mémoire ? Utilisez un « Loader » si nécessaire, si vous ne pouvez pas garder les deux versions de la vue en mémoire en même temps, mais faites attention aux performances de l’animation de fondu enchaîné lors du changement de mise en page. Une solution pourrait consister à disposer de deux éléments « écran de démarrage » enfants de la Page, puis à effectuer un fondu enchaîné entre ceux-ci lors de la rotation. Vous pouvez ensuite utiliser un ` Loader ` pour charger un autre composant enfant qui charge les données réelles du modèle dans un autre élément enfant, puis effectuer un fondu enchaîné vers celui-ci une fois l’ Loader ation terminée.