Escalabilidad

Cuando desarrolle aplicaciones para varias plataformas de dispositivos móviles diferentes, se enfrentará a los siguientes retos:

• Las plataformas de dispositivos móviles admiten dispositivos con distintas configuraciones de pantalla: tamaño, relación de aspecto, orientación y densidad.
• Las distintas plataformas tienen diferentes convenciones de interfaz de usuario y es necesario satisfacer las expectativas de los usuarios en cada una de ellas.

Qt Quick le permite desarrollar aplicaciones que pueden ejecutarse en distintos tipos de dispositivos, como tabletas y teléfonos móviles. En concreto, pueden adaptarse a distintas configuraciones de pantalla. Sin embargo, siempre es necesario corregir y pulir algunas cosas para crear una experiencia de usuario óptima para cada plataforma de destino.

Hay que tener en cuenta la escalabilidad cuando:

• Quieres desplegar tu aplicación en más de una plataforma de dispositivo, como Android e iOS, o en más de una configuración de pantalla de dispositivo.
• Desea estar preparado para nuevos dispositivos que puedan aparecer en el mercado después de su despliegue inicial.

Para implementar aplicaciones escalables utilizando Qt Quick:

• Diseñe interfaces de usuario utilizando Qt Quick Controls que proporcionan conjuntos de controles de interfaz de usuario.
• Definir diseños utilizando Qt Quick Layouts, que pueden cambiar el tamaño de sus elementos.
• Utilizar property binding para implementar casos de uso no cubiertos por los layouts. Por ejemplo, para mostrar versiones alternativas de imágenes en pantallas con baja y alta densidad de píxeles o adaptar automáticamente los contenidos de la vista según la orientación actual de la pantalla.
• Seleccione un dispositivo de referencia y calcule una relación de escala para ajustar el tamaño de las imágenes y las fuentes y los márgenes al tamaño real de la pantalla.
• Cargue activos específicos de la plataforma mediante selectores de archivos.
• Cargar componentes bajo demanda utilizando un cargador.

Tenga en cuenta los siguientes patrones a la hora de diseñar su aplicación:

• El contenido de una vista puede ser bastante similar en todos los tamaños de pantalla, pero con un área de contenido ampliada. Si utiliza el tipo QML ApplicationWindow de Qt Quick Controls, calculará automáticamente el tamaño de la ventana basándose en los tamaños de sus elementos de contenido. Si utilizas Qt Quick Layouts para posicionar los elementos de contenido, estos cambiarán automáticamente el tamaño de los elementos empujados hacia ellos.
• El contenido de una página completa en un dispositivo más pequeño podría formar un elemento componente de un diseño en un dispositivo más grande. Por lo tanto, considere la posibilidad de convertirlo en un componente independiente (es decir, definido en un archivo QML independiente) y, en el dispositivo más pequeño, la vista contendrá simplemente una instancia de ese componente. En el dispositivo más grande, puede haber espacio suficiente para utilizar cargadores para mostrar elementos adicionales. Por ejemplo, en un visor de correo electrónico, si la pantalla es lo suficientemente grande, puede ser posible mostrar la vista de la lista de correo electrónico y la vista del lector de correo electrónico una al lado de la otra.
• En el caso de los juegos, lo normal es crear un tablero que no se escale, para no ofrecer una ventaja injusta a los jugadores con pantallas más grandes. Una solución es definir una zona segura que se ajuste a la pantalla con la relación de aspecto más pequeña soportada (normalmente, 3:2), y añadir contenido sólo decorativo en el espacio que quedará oculto en una pantalla 4:3 o 16:9.

Cambiar el tamaño de las ventanas de la aplicación de forma dinámica

Qt Quick Controls proporcionan un conjunto de controles de interfaz de usuario para crear interfaces de usuario en Qt Quick. Normalmente, se declara un control ApplicationWindow como elemento raíz de la aplicación. El ApplicationWindow añade comodidad para posicionar otros controles, como MenuBar, ToolBar, y StatusBar de forma independiente de la plataforma. ApplicationWindow utiliza las restricciones de tamaño de los elementos de contenido para calcular las restricciones de tamaño efectivas de la ventana real.

Además de los controles que definen las partes estándar de las ventanas de la aplicación, se proporcionan controles para crear vistas y menús, así como para presentar o recibir información de los usuarios. Puede utilizar Qt Quick Controls Styles para aplicar estilos personalizados a los controles predefinidos.

Qt Quick ControlsAlgunos controles predefinidos, como ToolBar, no proporcionan un diseño propio, sino que es necesario posicionar su contenido. Para ello, puede utilizar Qt Quick Layouts.

Disposición dinámica de los controles de pantalla

Qt Quick Losdiseños permiten disponer los controles de pantalla en filas, columnas o cuadrículas mediante los tipos QML RowLayout, ColumnLayout y GridLayout. Las propiedades de estos tipos QML mantienen la dirección de la disposición y el espacio entre las celdas.

Puede utilizar los tipos QML Qt Quick Layouts para adjuntar propiedades adicionales a los elementos empujados a los layouts. Por ejemplo, puede especificar valores mínimos, máximos y preferidos para la altura, anchura y tamaño de los elementos.

Los diseños garantizan que las interfaces de usuario se escalen correctamente al cambiar el tamaño de las ventanas y pantallas, y que utilicen siempre el máximo espacio disponible.

Un caso de uso específico para el tipo GridLayout es utilizarlo como fila o columna en función de la orientación de la pantalla.

El siguiente fragmento de código utiliza la propiedad flow para establecer el flujo de la cuadrícula de izquierda a derecha (como una fila) cuando la anchura de la pantalla es mayor que la altura de la pantalla y de arriba a abajo (como una columna) en caso contrario:

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"
            }
        }
    }
}

Redimensionar y recalcular constantemente las pantallas tiene un coste de rendimiento. Los dispositivos móviles e integrados pueden no tener la potencia necesaria para recalcular el tamaño y la posición de los objetos animados en cada fotograma, por ejemplo. Si tienes problemas de rendimiento al utilizar layouts, considera la posibilidad de utilizar otros métodos, como los bindings, en su lugar.

Aquí tienes algunas cosas que no debes hacer con los layouts:

• No establezca vínculos con las propiedades x, y, anchura o altura de los elementos de un diseño, ya que esto entraría en conflicto con el objetivo del diseño y, además, provocaría bucles de vinculación.
• No defina funciones JavaScript complejas que se evalúen regularmente. Esto puede afectar al rendimiento, especialmente durante las transiciones animadas.
• No haga suposiciones sobre el tamaño del contenedor ni sobre el tamaño de los elementos secundarios. Intente hacer definiciones de diseño flexibles que puedan absorber cambios en el espacio disponible.
• No utilice disposiciones si desea que el diseño sea perfecto. Los elementos de contenido se redimensionarán y posicionarán automáticamente en función del espacio disponible.

Uso de fijaciones

Si Qt Quick Layouts no se ajusta a sus necesidades, puede recurrir al uso de propiedades vinculadas. La vinculación permite a los objetos actualizar automáticamente sus propiedades en respuesta al cambio de atributos en otros objetos o a la ocurrencia de algún evento externo.

Cuando se asigna un valor a una propiedad de un objeto, se le puede asignar un valor estático o vincularlo a una expresión JavaScript. En el primer caso, el valor de la propiedad no cambiará a menos que se le asigne un nuevo valor. En el segundo caso, se crea un enlace de propiedad y el motor QML actualiza automáticamente el valor de la propiedad cada vez que cambia el valor de la expresión evaluada.

Este tipo de posicionamiento es el más dinámico. Sin embargo, evaluar constantemente expresiones JavaScript tiene un coste de rendimiento.

Puede utilizar bindings para gestionar la densidad de píxeles alta y baja en plataformas que no disponen de soporte automático para ello (como Android, macOS e iOS). El siguiente fragmento de código utiliza la propiedad adjunta Screen.pixelDensity para especificar diferentes imágenes que mostrar en pantallas con densidad de píxeles baja, alta o normal:

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

En Android, macOS e iOS, puedes proporcionar recursos alternativos con resoluciones más altas utilizando el identificador correspondiente (por ejemplo, @2x, @3x o @4x) para iconos e imágenes, y colocarlos en el archivo de recursos. Se seleccionará automáticamente la versión que coincida con la densidad de píxeles de la pantalla.

Por ejemplo, el siguiente fragmento de código intentará cargar artwork@2x.png en pantallas Retina:

Image {
    source: "artwork.png"
}

Gestión de la densidad de píxeles

Algunos tipos QML, como Image, BorderImage, y Text, se escalan automáticamente de acuerdo con las propiedades especificadas para ellos. Si no se especifican la anchura y la altura de una imagen, ésta utiliza automáticamente el tamaño de la imagen de origen, especificado mediante la propiedad source. Por defecto, al especificar la anchura y la altura, la imagen se escala a ese tamaño. Este comportamiento puede cambiarse estableciendo la propiedad fillMode, permitiendo que la imagen se estire y se mosaique en su lugar. Sin embargo, el tamaño original de la imagen puede parecer demasiado pequeño en pantallas con muchos PPP.

BorderImage se utiliza para crear bordes a partir de imágenes escalando o embaldosando partes de cada imagen. Divide una imagen de origen en 9 regiones que se escalan o embaldosan según los valores de sus propiedades. Sin embargo, las esquinas no se escalan en absoluto, lo que puede hacer que los resultados no sean óptimos en pantallas con muchos PPP.

Un tipo QML Text intenta determinar cuánto espacio se necesita y establece las propiedades width y height en consecuencia, a menos que se establezcan explícitamente. La propiedad fontPointSize establece el tamaño de punto de forma independiente del dispositivo. Sin embargo, especificar fuentes en puntos y otros tamaños en píxeles causa problemas, porque los puntos son independientes de la densidad de la pantalla. Un marco alrededor de una cadena que parece correcto en pantallas de baja densidad de PPP es probable que sea demasiado pequeño en pantallas de alta densidad de PPP, haciendo que el texto aparezca recortado.

El nivel de compatibilidad con PPP altos y las técnicas utilizadas por las plataformas compatibles varían de una plataforma a otra. En las siguientes secciones se describen diferentes enfoques para escalar el contenido de la pantalla en pantallas con altos PPP.

Para obtener más información sobre la compatibilidad con PPP altos en Qt y las plataformas compatibles, consulte PPP altos.

Escalado de PPP altos

Si un dispositivo de destino admite el escalado de PPP altos, el sistema operativo proporciona a Qt una relación de escalado que se utiliza para escalar la salida de gráficos.

La ventaja de este enfoque es que los gráficos vectoriales y las fuentes se escalan automáticamente y las aplicaciones existentes tienden a funcionar sin modificaciones. Sin embargo, para los contenidos rasterizados se necesitan recursos alternativos de alta resolución.

El escalado se implementa en las pilas Qt Quick y Qt Widgets, así como en el soporte general de Qt Gui.

Las API gráficas de bajo nivel funcionan en píxeles de dispositivo. Esto incluye el código que utiliza la API OpenGL y el código que utiliza la API QRhi. Por ejemplo, esto significa que un QWindow con un size() de 1280x720 y un QWindow::devicePixelRatio() de 2 tiene un objetivo de renderizado (swapchain) con un tamaño de píxel de dispositivo de 2560x1440.

El SO escala la geometría de ventanas, eventos y escritorio. El plugin de la plataforma Cocoa establece el ratio de escalado como QWindow::devicePixelRatio() o QScreen::devicePixelRatio(), así como en el almacén de respaldo.

Para Qt Widgets, QPainter recoge devicePixelRatio() del almacén de respaldo y lo interpreta como una relación de escala.

Sin embargo, en OpenGL, los píxeles son siempre píxeles del dispositivo. Por ejemplo, la geometría pasada a glViewport() necesita ser escalada por devicePixelRatio().

Los tamaños de fuente especificados (en puntos o píxeles) no cambian y las cadenas conservan su tamaño relativo en comparación con el resto de la interfaz de usuario. Las fuentes se escalan como parte del pintado, de modo que una fuente de tamaño 12 se convierte efectivamente en una fuente de tamaño 24 con un escalado 2x, independientemente de si se especifica en puntos o en píxeles. La unidad px se interpreta como píxeles independientes del dispositivo para garantizar que las fuentes no parezcan más pequeñas en una pantalla de alto PPP.

Cálculo de la relación de escala

Puede seleccionar un dispositivo de PPP altos como dispositivo de referencia y calcular una relación de escala para ajustar los tamaños de imagen y fuente y los márgenes al tamaño real de la pantalla.

El siguiente fragmento de código utiliza los valores de referencia de PPP, altura y anchura del dispositivo Android Nexus 5, el tamaño real de la pantalla devuelto por la clase QRect y el valor lógico de PPP de la pantalla devuelto por el puntero global qApp para calcular una relación de escala para los tamaños y márgenes de las imágenes (m_ratio) y otra para los tamaños de las fuentes (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));

Para obtener una relación de escala razonable, los valores de altura y anchura deben establecerse de acuerdo con la orientación predeterminada del dispositivo de referencia, que en este caso es la orientación vertical.

El siguiente fragmento de código establece la relación de escala de la fuente en 1 si fuera inferior a uno y, por tanto, provocara que los tamaños de fuente fueran demasiado pequeños:

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

Deberías experimentar con los dispositivos de destino para encontrar casos extremos que requieran cálculos adicionales. Algunas pantallas pueden ser demasiado cortas o estrechas para que quepa todo el contenido previsto, por lo que requieren su propio diseño. Por ejemplo, puede que tenga que ocultar o sustituir algunos contenidos en pantallas con relaciones de aspecto atípicas, como 1:1.

La relación de escala puede aplicarse a todos los tamaños en un QQmlPropertyMap para escalar imágenes, fuentes y márgenes:

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)));

Las funciones del siguiente fragmento de código aplican la relación de escala a fuentes, imágenes y márgenes:

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

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

Esta técnica da resultados razonables cuando los tamaños de pantalla de los dispositivos de destino no difieren demasiado. Si las diferencias son enormes, considere la posibilidad de crear varios diseños diferentes con distintos valores de referencia.

Carga de archivos en función de la plataforma

Puede utilizar QQmlFileSelector para aplicar QFileSelector a la carga de archivos QML. Esto le permite cargar recursos alternativos en función de la plataforma en la que se ejecute la aplicación. Por ejemplo, puede utilizar el selector de archivos +android para cargar diferentes archivos de imagen cuando se ejecute en dispositivos Android.

Puedes utilizar selectores de archivos junto con objetos singleton para acceder a una única instancia de un objeto en una plataforma concreta.

Los selectores de archivos son estáticos e imponen una estructura de archivos en la que los archivos específicos de la plataforma se almacenan en subcarpetas con el nombre de la plataforma. Si necesitas una solución más dinámica para cargar partes de tu interfaz de usuario bajo demanda, puedes utilizar un cargador.

Las plataformas de destino pueden automatizar la carga de recursos alternativos para diferentes densidades de visualización de varias maneras. En Android e iOS, el sufijo de nombre de archivo @2x se utiliza para indicar versiones de imágenes con alta densidad de PPP. El tipo QML Image y la clase QIcon cargan automáticamente versiones @2x de imágenes e iconos si se proporcionan. Las clases QImage y QPixmap establecen automáticamente el devicePixelRatio de las versiones @2x de las imágenes en 2, pero es necesario añadir código para utilizar realmente las versiones @2x:

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

Android define tamaños de pantalla generalizados (small, normal, large, xlarge) y densidades (ldpi, mdpi, hdpi, xhdpi, xxhdpi y xxxhdpi) para los que puedes crear recursos alternativos. Android detecta la configuración actual del dispositivo en tiempo de ejecución y carga los recursos apropiados para tu aplicación. Sin embargo, a partir de Android 3.2 (API nivel 13), estos grupos de tamaño son obsoletos en favor de una nueva técnica para la gestión de tamaños de pantalla basado en el ancho de pantalla disponible.

Carga de componentes a petición

Un Loader puede cargar un archivo QML (utilizando la propiedad source ) o un objeto Componente (utilizando la propiedad sourceComponent ). Es útil para retrasar la creación de un componente hasta que sea necesario. Por ejemplo, cuando un componente debe crearse bajo demanda, o cuando un componente no debe crearse innecesariamente por razones de rendimiento.

También puedes utilizar cargadores para reaccionar ante situaciones en las que partes de tu interfaz de usuario no son necesarias en una plataforma concreta, porque la plataforma no soporta alguna funcionalidad. En lugar de mostrar una vista que no es necesaria en el dispositivo en el que se está ejecutando la aplicación, puedes determinar que la vista está oculta y utilizar cargadores para mostrar otra cosa en su lugar.

Cambio de orientación

La propiedad adjunta Screen.orientation contiene la orientación actual de la pantalla, a partir del acelerómetro (si está disponible). En un ordenador de sobremesa, este valor no suele cambiar.

Si primaryOrientation sigue a orientation, significa que la pantalla rota automáticamente todo el contenido que se muestra, dependiendo de cómo sujete el dispositivo. Si la orientación cambia aunque primaryOrientation no cambie, es posible que el dispositivo no rote su propia pantalla. En ese caso, es posible que tenga que utilizar Item.rotation o Item.transform para rotar el contenido.

Las definiciones de página de nivel superior de la aplicación y las definiciones de componentes reutilizables deben utilizar una definición de diseño QML para la estructura del diseño. Esta única definición debe incluir el diseño de la maquetación para distintas orientaciones de dispositivo y relaciones de aspecto. La razón de ello es que el rendimiento durante un cambio de orientación es crítico y, por lo tanto, es una buena idea asegurarse de que todos los componentes necesarios para ambas orientaciones se cargan cuando cambia la orientación.

Por el contrario, debe realizar pruebas exhaustivas si decide utilizar un Loader para cargar QML adicional necesario en orientaciones distintas, ya que esto afectará al rendimiento del cambio de orientación.

Para permitir animaciones de diseño entre las orientaciones, las definiciones de anclaje deben residir dentro del mismo componente contenedor. Por lo tanto, la estructura de una página o un componente debe consistir en un conjunto común de componentes hijos, un conjunto común de definiciones de anclaje y una colección de estados (definidos en StateGroup) que representen las diferentes relaciones de aspecto admitidas por el componente.

Si un componente contenido en una página necesita alojarse en numerosas definiciones de factor de forma diferentes, los estados de diseño de la vista deberían depender de la relación de aspecto de la página (su contenedor inmediato). Del mismo modo, diferentes instancias de un componente pueden estar situadas dentro de numerosos contenedores diferentes en una interfaz de usuario, por lo que sus estados de diseño deben estar determinados por la relación de aspecto de su padre. La conclusión es que los estados de diseño deben seguir siempre la relación de aspecto del contenedor directo (no la "orientación" de la pantalla del dispositivo actual).

Dentro de cada diseño State, debe definir las relaciones entre elementos utilizando definiciones de diseño QML nativas. Para más información, véase más abajo. Durante las transiciones entre los estados (desencadenadas por el cambio de orientación de nivel superior), en el caso de los diseños de anclaje, se pueden utilizar elementos AnchorAnimation para controlar las transiciones. En algunos casos, también puede utilizar un NumberAnimation sobre, por ejemplo, la anchura de un elemento. Recuerde evitar cálculos complejos de JavaScript durante cada fotograma de animación. El uso de definiciones de anclaje simples y animaciones de anclaje puede ayudar con esto en la mayoría de los casos.

Hay algunos casos adicionales a considerar:

• ¿Qué pasa si tiene una sola página que se ve completamente diferente entre horizontal y vertical, es decir, todos los elementos hijos son diferentes? Para cada página, tenga dos componentes hijos, con definiciones de diseño separadas, y haga que uno u otro de los elementos tenga opacidad cero en cada estado. Puede utilizar una animación de fundido cruzado simplemente aplicando una transición NumberAnimation a la opacidad.
• ¿Qué pasa si tienes una sola página que comparte el 30% o más del mismo contenido de diseño entre vertical y horizontal? En ese caso, considere la posibilidad de tener un componente con estados horizontal y vertical, y una colección de elementos child independientes cuya opacidad (o posición) dependa del estado de orientación. Esto le permitirá utilizar animaciones de diseño para los elementos que se comparten entre las orientaciones, mientras que los otros elementos se desvanecen dentro/fuera, o se animan dentro/fuera de la pantalla.
• ¿Qué ocurre si tienes dos páginas en un dispositivo portátil que necesitan estar en pantalla al mismo tiempo, por ejemplo en un dispositivo de mayor factor de forma? En este caso, tenga en cuenta que su componente de vista ya no ocupará toda la pantalla. Por lo tanto, es importante recordar en todos los componentes (en particular, los elementos delegados de la lista) deben depender del tamaño de la anchura del componente que los contiene, no de la anchura de la pantalla. Puede ser necesario establecer la anchura en un manejador Component.onCompleted() en este caso, para asegurarse de que el elemento de lista delegado se ha construido antes de que se establezca el valor.
• ¿Qué pasa si las dos orientaciones ocupan demasiada memoria para tenerlas las dos a la vez en memoria? Utiliza un Loader si es necesario, si no puedes mantener ambas versiones de la vista en memoria a la vez, pero ten cuidado con el rendimiento en la animación cross-fade durante el cambio de orientación. Una solución podría ser tener dos elementos de "pantalla de inicio" que sean hijos de la Página, y luego hacer un fundido cruzado entre ellos durante la rotación. A continuación, puede utilizar un Loader para cargar otro componente hijo que carga los datos del modelo real a otro elemento hijo, y el fundido cruzado a que cuando el Loader ha completado.