Évolutivité

Lorsque vous développez des applications pour plusieurs plates-formes d'appareils mobiles différentes, vous devez relever les défis suivants :

• Les plates-formes d'appareils mobiles prennent en charge des appareils dont les configurations d'écran varient : taille, rapport d'aspect, orientation et densité.
• Les conventions d'interface utilisateur varient d'une plateforme à l'autre et vous devez répondre aux attentes des utilisateurs sur chaque plateforme.

Qt Quick Les applications mobiles vous permettent de développer des applications qui peuvent fonctionner sur différents types d'appareils, tels que les tablettes et les téléphones. Elles peuvent notamment s'adapter à différentes configurations d'écran. Toutefois, un certain nombre de corrections et de perfectionnements sont toujours nécessaires pour créer une expérience utilisateur optimale pour chaque plateforme cible.

Vous devez prendre en compte l'évolutivité lorsque

• Vous souhaitez déployer votre application sur plusieurs plateformes, telles qu'Android et iOS, ou sur plusieurs configurations d'écran.
• Vous voulez être prêt pour les nouveaux appareils qui pourraient apparaître sur le marché après votre déploiement initial.

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

• Concevoir des interfaces utilisateur à l'aide de Qt Quick Contrôles qui fournissent des ensembles de contrôles d'interface utilisateur.
• Définir des dispositions à l'aide de Qt Quick Dispositions, qui peuvent redimensionner leurs éléments.
• Utilisez la liaison de propriétés pour mettre en œuvre des cas d'utilisation non couverts par les dispositions. 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électionner un appareil de référence et calculer un rapport d'échelle pour ajuster la taille des images et des polices ainsi que les marges à la taille réelle de l'écran.
• Charger des ressources spécifiques à une plate-forme à l'aide de sélecteurs de fichiers.
• Charger des 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 élargie. Si vous utilisez le type QML ApplicationWindow de Qt Quick Controls, il calculera automatiquement la taille de la fenêtre en fonction de la taille des éléments de son contenu. Si vous utilisez Qt Quick Layouts pour positionner les éléments de contenu, ils redimensionneront automatiquement les éléments qui leur sont rattachés.
• Le contenu d'une page entière sur un petit appareil peut constituer un élément d'une mise en page sur un appareil plus grand. Il faut donc envisager d'en faire un composant distinct (c'est-à-dire défini dans un fichier QML distinct) et, dans le petit appareil, la vue contiendra simplement une instance de ce composant. Sur un appareil plus grand, il peut y avoir suffisamment d'espace pour utiliser des chargeurs afin d'afficher des éléments supplémentaires. Par exemple, dans une visionneuse de courrier électronique, si l'écran est suffisamment grand, il peut être possible d'afficher côte à côte la vue de la liste de courrier électronique et la vue du lecteur de courrier électronique.
• Pour les jeux, vous voudrez généralement créer un plateau de jeu qui n'est pas mis à l'échelle, afin de ne pas donner un avantage injuste aux joueurs sur des écrans plus grands. Une solution consiste à définir une zone de sécurité adaptée à l'écran ayant le plus petit rapport hauteur/largeur pris en charge (généralement, 3:2), et à ajouter dans cet espace un contenu uniquement décoratif qui sera masqué sur un écran 4:3 ou 16:9.

Redimensionnement dynamique des fenêtres d'application

Qt Quick Lescontrôles fournissent un ensemble de contrôles d'interface utilisateur pour créer des interfaces utilisateur dans Qt Quick. En règle générale, vous déclarez un contrôle ApplicationWindow comme élément racine de votre application. Le contrôle ApplicationWindow permet de positionner d'autres contrôles, tels que MenuBar, ToolBar et StatusBar, de manière indépendante de la plate-forme. Le ApplicationWindow utilise les contraintes de taille des éléments de contenu pour calculer les contraintes de taille effectives de la fenêtre réelle.

Outre les contrôles qui définissent les parties standard des fenêtres d'application, des contrôles sont fournis pour créer des vues et des menus, ainsi que pour présenter ou recevoir des données de la part des utilisateurs. Vous pouvez utiliser Qt Quick Controls Styles pour appliquer un style personnalisé aux contrôles prédéfinis.

Qt Quick Les contrôles, tels que le ToolBar, ne fournissent pas de présentation propre, mais nécessitent que vous positionniez leur contenu. Pour ce faire, vous pouvez utiliser Qt Quick Layouts.

Disposition dynamique des contrôles d'écran

Qt Quick Lesmises en page permettent de disposer les contrôles d'écran dans une ligne, une colonne ou une grille, à l'aide des types QML RowLayout, ColumnLayout et GridLayout. Les propriétés de ces types QML définissent la direction de la disposition et l'espacement entre les cellules.

Vous pouvez utiliser les types QML Qt Quick Layouts pour attacher des propriétés supplémentaires aux éléments poussés vers les layouts. Par exemple, vous pouvez spécifier des valeurs minimales, maximales et préférentielles pour la hauteur, la largeur et la taille des éléments.

Les modèles garantissent que vos interfaces utilisateur sont correctement dimensionnées lorsque les fenêtres et les écrans sont redimensionnés et qu'elles utilisent toujours le maximum d'espace disponible.

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

L'extrait de code suivant utilise la propriété flow pour définir le flux 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 intégrés peuvent ne pas avoir 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 lorsque vous utilisez des présentations, envisagez plutôt d'utiliser d'autres méthodes, telles que les liaisons.

Voici quelques précautions à ne pas prendre avec les présentations :

• Ne pas établir de liaisons avec les propriétés x, y, width ou height des éléments d'une présentation, car cela entrerait en conflit avec l'objectif de la présentation et provoquerait des boucles de liaison.
• Ne définissez pas de fonctions JavaScript complexes qui sont régulièrement évaluées. Cela entraînerait des performances médiocres, en particulier lors des transitions animées.
• Ne faites pas d'hypothèses sur la taille du conteneur ou sur la taille des éléments enfants. Essayez de définir des mises en page flexibles, capables d'absorber les changements dans l'espace disponible.
• N'utilisez pas de mise en page si vous voulez que la conception soit parfaite au pixel près. Les éléments de contenu seront automatiquement redimensionnés et positionnés en fonction de l'espace disponible.

Utilisation de liens

Si les mises en page Qt Quick ne répondent pas à vos besoins, vous pouvez vous rabattre sur l'utilisation de la liaison de propriétés. La liaison permet aux objets de mettre automatiquement à jour leurs propriétés en réponse à la modification des attributs d'autres objets ou à l'apparition d'un événement externe.

Lorsqu'une valeur est attribuée à la propriété d'un objet, elle peut être soit statique, soit liée à 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 positionnement est le plus dynamique. Cependant, l'évaluation constante des expressions JavaScript a un coût en termes de performances.

Vous pouvez utiliser des bindings pour gérer les densités de pixels faibles et élevées sur les plateformes qui ne les prennent pas automatiquement en charge (comme Android, macOS et iOS). L'extrait de code suivant utilise la propriété Screen.pixelDensity attached pour spécifier différentes images à afficher sur des écrans à densité de pixels faible, élevée ou normale :

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 avec des résolutions plus élevées 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 qui correspond à la densité de pixels de l'écran est automatiquement sélectionnée.

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

Image {
    source: "artwork.png"
}

Gestion de la densité des pixels

Certains types QML, tels que Image, BorderImage et Text, sont automatiquement mis à l'échelle 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, elle utilise automatiquement la taille de l'image source, spécifiée à l'aide de la propriété source. Par défaut, la spécification de la largeur et de la hauteur entraîne la mise à l'échelle de l'image à cette taille. Ce comportement peut être modifié en définissant la propriété fillMode, ce qui permet d'étirer l'image et de la mettre en mosaïque. Cependant, la taille originale de l'image peut apparaître trop petite sur les écrans à haute résolution.

Le site BorderImage est utilisé pour créer des bordures à partir d'images en mettant à l'échelle ou en mosaïque des parties de chaque image. Il divise une image source en 9 régions qui sont mises à l'échelle ou en mosaïque en fonction des valeurs des propriétés. Cependant, les coins ne sont pas mis à l'échelle du tout, ce qui peut rendre les résultats moins optimaux sur les écrans à haut DPI.

Un type QML Text tente de déterminer l'espace nécessaire et définit 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 des points indépendamment de l'appareil. Cependant, le fait de 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 semble correct sur les écrans à faible DPI est susceptible de devenir trop petit sur les écrans à DPI élevé, ce qui entraîne une coupure du texte.

Le niveau de prise en charge des ppp élevés et les techniques utilisées par les plates-formes prises en charge varient d'une plate-forme à l'autre. Les sections suivantes décrivent différentes approches de la mise à l'échelle du contenu de l'écran sur les écrans à haute résolution.

Pour plus d'informations sur la prise en charge des hauts DPI dans Qt et les plates-formes prises en charge, voir High DPI.

Mise à l'échelle des écrans à haute résolution

Si un périphérique cible prend en charge la mise à l'échelle High DPI, le système d'exploitation fournit à Qt un rapport d'échelle qui est utilisé pour mettre à l'échelle la sortie graphique.

L'avantage de cette approche est que les graphiques vectoriels et les polices se mettent à l'échelle automatiquement et que les applications existantes ont tendance à fonctionner 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 que pour le support général de Qt GUI.

Les API graphiques de bas niveau fonctionnent en pixels. Cela inclut le code qui utilise l'API OpenGL et le code qui utilise l'API QRhi. Par exemple, cela signifie qu'un site QWindow avec un size() de 1280x720 et un QWindow::devicePixelRatio() de 2 a une cible de rendu (swapchain) avec une taille de pixel de périphérique de 2560x1440.

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

Pour Qt Widgets, QPainter récupère devicePixelRatio() dans le backing store et l'interprète comme un rapport d'échelle.

Cependant, dans OpenGL, les pixels sont toujours des pixels de périphérique. Par exemple, la géométrie passée à glViewport() doit être mise à l'échelle par 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 dans le cadre de la peinture, de sorte qu'une police de taille 12 devient effectivement une police de taille 24 avec une mise à l'échelle de 2 fois, 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 à DPI élevé.

Calcul du rapport d'échelle

Vous pouvez sélectionner un périphérique à DPI élevé comme périphérique de référence et calculer un rapport d'échelle pour ajuster la taille et les marges des images et des polices à 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 et la valeur logique du DPI de l'écran renvoyée par le pointeur global qApp pour calculer un rapport d'échelle pour la taille et les marges des images (m_ratio) et un autre pour la taille des polices (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 d'é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, dans ce cas, est l'orientation portrait.

L'extrait de code suivant définit le rapport d'échelle des polices à 1 s'il est inférieur à un et que la taille des polices devient trop petite :

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

Vous devriez expérimenter avec les appareils cibles pour trouver des cas limites qui nécessitent des calculs supplémentaires. Certains écrans peuvent être trop courts ou trop étroits pour contenir tout le contenu prévu et nécessitent donc leur propre mise en page. Par exemple, il peut être nécessaire de masquer ou de remplacer certains contenus sur des écrans présentant des rapports d'aspect atypiques, tels que 1:1.

Le rapport d'échelle peut être appliqué à toutes les tailles dans une page QQmlPropertyMap pour mettre à l'échelle 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 d'é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 raisonnables 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 plate-forme

Vous pouvez utiliser le site QQmlFileSelector pour appliquer une QFileSelector au chargement des fichiers QML. Cela vous permet de charger des ressources alternatives en fonction de la plate-forme sur laquelle l'application est exécutée. Par exemple, vous pouvez utiliser le sélecteur de fichier +android pour charger différents fichiers d'image lorsque l'application est exécutée sur des appareils Android.

Vous pouvez utiliser les sélecteurs de fichiers avec des objets singleton pour accéder à une instance unique d'un objet sur une plateforme particulière.

Les sélecteurs de fichiers sont statiques et appliquent 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 chargeur.

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 de nom de fichier @2x est utilisé pour indiquer les versions DPI élevées 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 le devicePixelRatio des versions @2x des images sur 2, mais vous devez ajouter du code pour utiliser réellement les versions @2x :

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

Android définit des tailles d'écran généralisées (petit, normal, grand, xlarge) 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 au moment de l'exécution et charge les ressources appropriées pour votre application. Cependant, à partir d'Android 3.2 (API level 13), ces groupes de taille sont obsolètes en faveur d'une nouvelle technique de gestion des tailles d'écran basée sur la largeur disponible de l'écran.

Chargement de composants à la demande

Une page Loader peut charger un fichier QML (à l'aide de la propriété source ) ou un objet Component (à l'aide de la propriété sourceComponent ). Cette fonction est 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'un composant ne doit pas être créé inutilement pour des raisons de performances.

Vous pouvez également utiliser les chargeurs pour réagir à des situations où des parties de votre interface utilisateur ne sont pas nécessaires sur une plateforme particulière, parce que celle-ci ne prend pas en charge certaines fonctionnalités. Au lieu d'afficher une vue qui n'est pas nécessaire sur le périphérique sur lequel l'application est exécutée, vous pouvez déterminer que la vue est cachée et utiliser les chargeurs pour afficher quelque chose d'autre à sa place.

Changement d'orientation

La propriété Screen.orientation attached contient l'orientation actuelle de l'écran, fournie par l'accéléromètre (s'il est disponible). Sur un ordinateur de bureau, cette valeur ne change généralement pas.

Si primaryOrientation suit orientation, cela signifie que l'écran fait automatiquement pivoter tout le contenu affiché, en fonction de la façon dont vous tenez l'appareil. Si l'orientation change alors que primaryOrientation ne change pas, 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 et les définitions de composants réutilisables doivent utiliser une définition de mise en page QML pour la structure de la mise en page. Cette définition unique doit inclure la conception de la mise en page pour des orientations et des rapports d'aspect différents. La raison en est que les performances lors d'un changement d'orientation sont critiques et qu'il est donc judicieux de s'assurer que tous les composants nécessaires aux deux orientations sont chargés lors du changement d'orientation.

Au contraire, vous devez effectuer des tests approfondis si vous choisissez d'utiliser un site Loader pour charger des éléments QML supplémentaires qui sont nécessaires dans des orientations distinctes, car cela affectera les performances du changement d'orientation.

Afin de permettre des animations de mise en page entre les orientations, les définitions des ancres doivent résider dans le même composant contenant. Par conséquent, la structure d'une page ou d'un composant doit être constituée 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 StateGroup) représentant les différents rapports d'aspect pris en charge par le composant.

Si un composant contenu dans une page doit être hébergé dans de nombreuses définitions de facteurs de forme différents, les états de présentation de la vue doivent dépendre du rapport d'aspect de la page (son conteneur immédiat). De même, différentes instances d'un composant peuvent être situées dans de nombreux conteneurs différents dans une interface utilisateur, et ses états de présentation doivent donc être déterminés par le rapport hauteur/largeur de son parent. La conclusion est que les états de présentation doivent toujours suivre le rapport d'aspect du conteneur direct (et non l'"orientation" de l'écran de l'appareil actuel).

Dans chaque mise en page State, vous devez définir les relations entre les éléments à l'aide des définitions natives de la mise en page QML. Voir ci-dessous pour plus d'informations. Lors des transitions entre les états (déclenchées par le changement d'orientation au niveau supérieur), dans le cas des dispositions d'ancrage, les éléments AnchorAnimation peuvent être utilisés pour contrôler les transitions. Dans certains cas, vous pouvez également utiliser NumberAnimation pour contrôler, par exemple, la largeur d'un élément. N'oubliez pas d'éviter les calculs JavaScript complexes à chaque image de l'animation. L'utilisation de définitions d'ancres et d'animations d'ancres simples permet d'y parvenir dans la plupart des cas.

Il y a quelques autres cas à prendre en considération :

• Que se passe-t-il si vous avez une page unique dont l'aspect est complètement différent selon qu'elle est en mode paysage ou portrait, c'est-à-dire si tous les éléments enfants sont différents ? Pour chaque page, ayez 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 se passe-t-il si vous avez une page unique qui partage 30 % ou plus du même contenu de mise en page entre le portrait et le paysage ? Dans ce cas, envisagez d'avoir un composant avec des états paysage et portrait, et une collection d'éléments enfants distincts dont l'opacité (ou la position) dépend de l'état de l'orientation. Cela vous permettra d'utiliser des animations de mise en page pour les éléments qui sont partagés entre les orientations, tandis que les autres éléments sont soit fondus, soit animés à l'écran ou en dehors de l'écran.
• Que se passe-t-il si vous avez deux pages sur un appareil portable qui doivent être à l'écran en même temps, par exemple sur un appareil de plus grande taille ? Dans ce cas, vous remarquerez que votre composant de visualisation n'occupera plus tout l'écran. Il est donc important de se rappeler que tous les composants (en particulier les éléments de la liste déléguée) doivent dépendre de la largeur du composant qui les contient, et non de la largeur de l'écran. Dans ce cas, il peut être nécessaire de définir la largeur dans un gestionnaire Component.onCompleted(), afin de s'assurer que le délégué de l'élément de liste a été construit avant que la valeur ne soit définie.
• Que se passe-t-il si les deux orientations prennent trop de place en mémoire pour les avoir toutes les deux en mémoire en même temps ? 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 attention aux performances de l'animation de fondu-enchaîné pendant le changement de disposition. Une solution pourrait être d'avoir deux éléments "splash screen" qui sont des enfants de la page, puis de faire un fondu enchaîné entre eux pendant la rotation. Vous pouvez ensuite utiliser un site Loader pour charger un autre composant enfant qui charge les données du modèle dans un autre élément enfant, puis effectuer un fondu enchaîné entre ces deux éléments lorsque le site Loader est terminé.