Skalierbarkeit

Wenn Sie Anwendungen für verschiedene Plattformen mobiler Geräte entwickeln, stehen Sie vor folgenden Herausforderungen:

• Plattformen für mobile Geräte unterstützen Geräte mit unterschiedlichen Bildschirmkonfigurationen: Größe, Seitenverhältnis, Ausrichtung und Bildschirmauflösung.
• Verschiedene Plattformen haben unterschiedliche UI-Konventionen, und Sie müssen die Erwartungen der Nutzer auf jeder Plattform erfüllen.

Qt Quick ermöglicht es Ihnen, Anwendungen zu entwickeln, die auf verschiedenen Gerätetypen wie Tablets und Smartphones ausgeführt werden können. Insbesondere sind sie in der Lage, unterschiedliche Bildschirmkonfigurationen zu verarbeiten. Es sind jedoch immer gewisse Anpassungen und Feinarbeiten erforderlich, um für jede Zielplattform ein optimales Benutzererlebnis zu schaffen.

Sie müssen die Skalierbarkeit berücksichtigen, wenn:

• Sie Ihre Anwendung auf mehr als einer Geräteplattform, wie z. B. Android und iOS, oder für mehr als eine Bildschirmkonfiguration bereitstellen möchten.
• Sie möchten auf neue Geräte vorbereitet sein, die nach Ihrer ersten Bereitstellung möglicherweise auf den Markt kommen.

So implementieren Sie skalierbare Anwendungen mit Qt Quick:

• Entwerfen Sie Benutzeroberflächen mithilfe von Qt Quick Controls , die eine Reihe von UI-Steuerelementen bereitstellen.
• Definieren Sie Layouts mithilfe von Qt Quick Layouts, deren Elemente in der Größe angepasst werden können.
• Nutzen Sie Eigenschaftsbindungen, um Anwendungsfälle zu implementieren, die nicht durch die Layouts abgedeckt sind. Beispielsweise um alternative Versionen von Bildern auf Bildschirmen mit niedriger und hoher Pixeldichte anzuzeigen oder den Inhalt der Ansicht automatisch an die aktuelle Bildschirmausrichtung anzupassen.
• Wählen Sie ein Referenzgerät aus und berechnen Sie einen Skalierungsfaktor, um Bild- und Schriftgrößen sowie Ränder an die tatsächliche Bildschirmgröße anzupassen.
• Laden Sie plattformspezifische Assets mithilfe von Dateiauswahlfeldern.
• Laden Sie Komponenten bei Bedarf mithilfe eines Loaders.

Berücksichtigen Sie beim Entwerfen Ihrer Anwendung die folgenden Muster:

• Der Inhalt einer Ansicht kann auf allen Bildschirmgrößen recht ähnlich sein, jedoch mit einem erweiterten Inhaltsbereich. Wenn Sie den QML-Typ „ ApplicationWindow “ aus Qt Quick Controls verwenden, berechnet dieser automatisch die Fenstergröße auf der Grundlage der Größen seiner Inhaltselemente. Wenn Sie „ Qt Quick Layouts “ zur Positionierung der Inhaltselemente verwenden, passen diese die Größe der an sie übergebenen Elemente automatisch an.
• Der Inhalt einer gesamten Seite auf einem kleineren Gerät könnte auf einem größeren Gerät ein Bestandteil eines Layouts sein. Ziehen Sie daher in Betracht, daraus eine separate Komponente zu machen (d. h. in einer separaten QML-Datei definiert), und auf dem kleineren Gerät enthält die Ansicht dann einfach eine Instanz dieser Komponente. Auf dem größeren Gerät ist möglicherweise genügend Platz vorhanden, um mithilfe von Ladebalken zusätzliche Elemente anzuzeigen. In einem E-Mail-Viewer ist es beispielsweise möglich, bei ausreichender Bildschirmgröße die E-Mail-Listenansicht und die E-Mail-Lesansicht nebeneinander darzustellen.
• Bei Spielen ist es in der Regel sinnvoll, ein Spielfeld zu erstellen, das nicht skaliert wird, um Spielern mit größeren Bildschirmen keinen unfairen Vorteil zu verschaffen. Eine Lösung besteht darin, einen Sicherheitsbereich zu definieren, der auf den Bildschirm mit dem kleinsten unterstützten Seitenverhältnis (in der Regel 3:2) passt, und rein dekorative Inhalte in den Bereich einzufügen, der auf einem 4:3- oder 16:9-Bildschirm ausgeblendet wird.

Dynamische Größenanpassung von Anwendungsfenstern

Qt Quick ControlsQt Quick bietet eine Reihe von UI-Steuerelementen zum Erstellen von Benutzeroberflächen. In der Regel deklarieren Sie ein „ ApplicationWindow “-Steuerelement als Stammelement Ihrer Anwendung. Das „ ApplicationWindow “ erleichtert die plattformunabhängige Positionierung anderer Steuerelemente wie „ MenuBar “, „ ToolBar “ und „StatusBar“. Das „ ApplicationWindow “ verwendet die Größenbeschränkungen der Inhaltselemente als Eingabe bei der Berechnung der effektiven Größenbeschränkungen des eigentlichen Fensters.

Neben Steuerelementen, die Standardbestandteile von Anwendungsfenstern definieren, stehen Steuerelemente zur Erstellung von Ansichten und Menüs sowie zur Darstellung oder Entgegennahme von Benutzereingaben zur Verfügung. Mit „Qt Quick Controls -Stilen“ können Sie den vordefinierten Steuerelementen benutzerdefinierte Stile zuweisen.

Qt Quick Controls, wie beispielsweise der „ ToolBar “, bieten kein eigenes Layout, sondern erfordern, dass Sie deren Inhalte positionieren. Hierfür können Sie „ Qt Quick Layouts “ verwenden.

Dynamisches Anordnen von Bildschirmsteuerelementen

Qt Quick Layouts bieten Möglichkeiten, Bildschirmsteuerelemente mithilfe der QML-Typen „ RowLayout “, „ ColumnLayout “ und „ GridLayout “ in einer Zeile, Spalte oder einem Raster anzuordnen. Die Eigenschaften dieser QML-Typen legen die Ausrichtungsrichtung und den Abstand zwischen den Zellen fest.

Sie können die Qt Quick Layouts QML-Typen nutzen, um den an die Layouts übergebenen Elementen zusätzliche Eigenschaften zuzuweisen. So können Sie beispielsweise Mindest-, Höchst- und bevorzugte Werte für Höhe, Breite und Größe der Elemente festlegen.

Die Layouts stellen sicher, dass Ihre Benutzeroberflächen bei einer Größenänderung von Fenstern und Bildschirmen korrekt skaliert werden und stets den maximal verfügbaren Platz nutzen.

Ein konkreter Anwendungsfall für den Typ „ GridLayout “ besteht darin, ihn je nach Bildschirmausrichtung als Zeile oder Spalte zu verwenden.

Der folgende Codeausschnitt verwendet die Eigenschaft „ flow “, um den Fluss des Rasters von links nach rechts (als Zeile) festzulegen, wenn die Bildschirmbreite größer ist als die Bildschirmhöhe, und andernfalls von oben nach unten (als Spalte):

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

Die ständige Größenanpassung und Neuberechnung von Bildschirmen geht mit Leistungseinbußen einher. Mobile und eingebettete Geräte verfügen möglicherweise nicht über die erforderliche Rechenleistung, um beispielsweise die Größe und Position animierter Objekte für jedes Einzelbild neu zu berechnen. Sollten bei der Verwendung von Layouts Leistungsprobleme auftreten, sollten Sie stattdessen andere Methoden wie beispielsweise Bindungen in Betracht ziehen.

Hier sind einige Dinge, die Sie bei Layouts vermeiden sollten:

• Verwenden Sie keine Bindungen an die Eigenschaften `x`, `y`, `width` oder `height` von Elementen in einem Layout, da dies dem Zweck des Layouts zuwiderläuft und zudem Bindungsschleifen verursachen würde.
• Definieren Sie keine komplexen JavaScript-Funktionen, die regelmäßig ausgewertet werden. Dies führt zu Leistungseinbußen, insbesondere bei animierten Übergängen.
• Machen Sie keine Annahmen über die Größe des Containers oder über die Größe von untergeordneten Elementen. Versuchen Sie, flexible Layout-Definitionen zu erstellen, die Änderungen des verfügbaren Platzes auffangen können.
• Verwenden Sie keine Layouts, wenn Sie ein pixelgenaues Design wünschen. Inhaltselemente werden je nach verfügbarem Platz automatisch in ihrer Größe angepasst und positioniert.

Verwendung von Bindungen

Wenn „ Qt Quick Layouts “ Ihren Anforderungen nicht entsprechen, können Sie stattdessen auf Eigenschaftsbindungen zurückgreifen. Durch Bindungen können Objekte ihre Eigenschaften automatisch aktualisieren, wenn sich Attribute anderer Objekte ändern oder ein externes Ereignis eintritt.

Wenn einer Eigenschaft eines Objekts ein Wert zugewiesen wird, kann dies entweder ein statischer Wert sein oder die Eigenschaft kann an einen JavaScript-Ausdruck gebunden werden. Im erstgenannten Fall ändert sich der Wert der Eigenschaft nicht, solange der Eigenschaft kein neuer Wert zugewiesen wird. Im letzteren Fall wird eine Eigenschaftsbindung erstellt, und der Wert der Eigenschaft wird von der QML-Engine automatisch aktualisiert, sobald sich der Wert des ausgewerteten Ausdrucks ändert.

Diese Art der Bindung ist am dynamischsten. Die ständige Auswertung von JavaScript-Ausdrücken geht jedoch mit Leistungseinbußen einher.

Sie können Bindungen verwenden, um niedrige und hohe Pixeldichte auf Plattformen zu handhaben, die dies nicht automatisch unterstützen (wie es bei Android, macOS und iOS der Fall ist). Der folgende Codeausschnitt nutzt die angehängte Eigenschaft „ Screen.pixelDensity “, um unterschiedliche Bilder für die Anzeige auf Bildschirmen mit niedriger, hoher oder normaler Pixeldichte festzulegen:

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

Unter Android, macOS und iOS können Sie alternative Ressourcen mit höheren Auflösungen bereitstellen, indem Sie für Symbole und Bilder die entsprechende Kennung (z. B. @2x, @3x oder @4x) verwenden und diese in der Ressourcendatei ablegen. Die Version, die der Pixeldichte des Bildschirms entspricht, wird automatisch zur Verwendung ausgewählt.

Der folgende Codeausschnitt versucht beispielsweise, auf Retina-Displays die Datei „artwork@2x.png“ zu laden:

Image {
    source: "artwork.png"
}

Umgang mit der Pixeldichte

Einige QML-Typen, wie z. B. „ Image “, „ BorderImage “ und „ Text “, werden automatisch entsprechend den für sie angegebenen Eigenschaften skaliert. Wenn Breite und Höhe eines Bildes nicht angegeben sind, wird automatisch die Größe des Quellbildes verwendet, die über die Eigenschaft „ source “ festgelegt wird. Standardmäßig führt die Angabe von Breite und Höhe dazu, dass das Bild auf diese Größe skaliert wird. Dieses Verhalten lässt sich durch Setzen der Eigenschaft „ fillMode “ ändern, wodurch das Bild stattdessen gestreckt und gekachelt wird. Allerdings kann die ursprüngliche Bildgröße auf Bildschirmen mit hoher DPI-Auflösung zu klein erscheinen.

Ein „ BorderImage “ wird verwendet, um aus Bildern Rahmen zu erstellen, indem Teile jedes Bildes skaliert oder gekachelt werden. Dabei wird ein Quellbild in 9 Bereiche unterteilt, die entsprechend den Eigenschaftswerten skaliert oder gekachelt werden. Die Ecken werden jedoch überhaupt nicht skaliert, was auf Bildschirmen mit hoher DPI-Auflösung zu suboptimalen Ergebnissen führen kann.

Ein QML-Typ „ Text “ versucht zu ermitteln, wie viel Platz benötigt wird, und legt die Eigenschaften „ width “ und „ height “ entsprechend fest, sofern diese nicht explizit festgelegt sind. Die Eigenschaft „ fontPointSize “ legt die Punktgröße geräteunabhängig fest. Die Angabe von Schriftarten in Punkten und anderen Größen in Pixeln führt jedoch zu Problemen, da Punkte unabhängig von der Bildschirmauflösung sind. Ein Rahmen um eine Zeichenfolge, der auf Bildschirmen mit niedriger DPI-Auflösung korrekt aussieht, wird auf Bildschirmen mit hoher DPI-Auflösung wahrscheinlich zu klein, was dazu führt, dass der Text abgeschnitten wird.

Der Umfang der High-DPI-Unterstützung und die von den unterstützten Plattformen verwendeten Techniken variieren von Plattform zu Plattform. In den folgenden Abschnitten werden verschiedene Ansätze zur Skalierung von Bildschirminhalten auf Bildschirmen mit hoher DPI beschrieben.

Weitere Informationen zur Unterstützung hoher DPI-Auflösungen in Qt und den unterstützten Plattformen finden Sie unter „High DPI“.

Skalierung bei hoher DPI

Wenn ein Zielgerät die Skalierung bei hoher DPI unterstützt, stellt das Betriebssystem Qt einen Skalierungsfaktor zur Verfügung, der zur Skalierung der Grafikausgabe verwendet wird.

Der Vorteil dieses Ansatzes besteht darin, dass Vektorgrafiken und Schriftarten automatisch skaliert werden und bestehende Anwendungen in der Regel ohne Änderungen funktionieren. Für Rasterinhalte sind jedoch hochauflösende alternative Ressourcen erforderlich.

Die Skalierung ist für die Stacks „ Qt Quick “ und „ Qt Widgets “ implementiert und wird zudem allgemein in Qt GUI unterstützt.

Grafik-APIs auf niedriger Ebene arbeiten mit Gerätepixeln. Dazu gehören Code, der die OpenGL-API verwendet, sowie Code, der die „ QRhi “-API nutzt. Das bedeutet beispielsweise, dass ein „ QWindow “ mit einer „ size() “ von 1280x720 und einem „ QWindow::devicePixelRatio()“ von 2 ein Renderziel (Swapchain) mit einer Gerätepixelgröße von 2560x1440 hat.

Das Betriebssystem skaliert Fenster-, Ereignis- und Desktop-Geometrie. Das Cocoa-Plattform-Plugin legt das Skalierungsverhältnis als „ QWindow::devicePixelRatio “ () oder „ QScreen::devicePixelRatio “ () fest, ebenso wie im Backing Store.

Bei „ Qt Widgets “ übernimmt „ QPainter “ den Wert „ devicePixelRatio() “ aus dem Backing Store und interpretiert ihn als Skalierungsverhältnis.

In OpenGL sind Pixel jedoch immer Gerätepixel. Beispielsweise muss die an `glViewport()` übergebene Geometrie mit `devicePixelRatio()` skaliert werden.

Die angegebenen Schriftgrößen (in Punkten oder Pixeln) ändern sich nicht, und Zeichenfolgen behalten ihre relative Größe im Vergleich zum Rest der Benutzeroberfläche bei. Schriftarten werden im Rahmen der Darstellung skaliert, sodass eine Schriftart der Größe 12 bei einer 2-fachen Skalierung effektiv zu einer Schriftart der Größe 24 wird, unabhängig davon, ob sie in Punkten oder in Pixeln angegeben ist. Die Einheit „px“ wird als geräteunabhängige Pixel interpretiert, um sicherzustellen, dass Schriftarten auf einem Display mit hoher DPI-Auflösung nicht kleiner erscheinen.

Berechnung des Skalierungsverhältnisses

Sie können ein Gerät mit hoher DPI-Auflösung als Referenzgerät auswählen und ein Skalierungsverhältnis berechnen, um Bild- und Schriftgrößen sowie Ränder an die tatsächliche Bildschirmgröße anzupassen.

Der folgende Codeausschnitt verwendet Referenzwerte für DPI, Höhe und Breite des Android-Geräts Nexus 5, die von der Klasse ` QRect ` zurückgegebene tatsächliche Bildschirmgröße sowie den vom globalen Zeiger ` qApp ` zurückgegebenen logischen DPI-Wert des Bildschirms, um ein Skalierungsverhältnis für Bildgrößen und Ränder (m_ratio) sowie ein weiteres für Schriftgrößen (m_ratioFont) zu berechnen:

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

Für ein sinnvolles Skalierungsverhältnis müssen die Werte für Höhe und Breite entsprechend der Standardausrichtung des Referenzgeräts festgelegt werden, in diesem Fall also im Hochformat.

Der folgende Codeausschnitt legt das Skalierungsverhältnis für Schriftarten auf „ 1 “ fest, falls es kleiner als eins wäre und die Schriftgrößen dadurch zu klein würden:

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

Sie sollten mit den Zielgeräten experimentieren, um Randfälle zu finden, die zusätzliche Berechnungen erfordern. Manche Bildschirme sind möglicherweise einfach zu kurz oder zu schmal, um den gesamten geplanten Inhalt darzustellen, und erfordern daher ein eigenes Layout. Beispielsweise müssen Sie möglicherweise einige Inhalte auf Bildschirmen mit atypischen Seitenverhältnissen, wie z. B. 1:1, ausblenden oder ersetzen.

Der Skalierungsfaktor kann auf alle Größen in einem „ QQmlPropertyMap “ angewendet werden, um Bilder, Schriftarten und Ränder zu skalieren:

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

Die Funktionen im folgenden Codeausschnitt wenden das Skalierungsverhältnis auf Schriftarten, Bilder und Ränder an:

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

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

Diese Technik liefert zufriedenstellende Ergebnisse, wenn sich die Bildschirmgrößen der Zielgeräte nicht allzu stark unterscheiden. Bei großen Unterschieden sollten Sie in Erwägung ziehen, mehrere verschiedene Layouts mit unterschiedlichen Referenzwerten zu erstellen.

Plattformabhängiges Laden von Dateien

Sie können das „ QQmlFileSelector “ verwenden, um beim Laden von QML-Dateien eine plattformabhängige Skalierung ( QFileSelector ) anzuwenden. Dies ermöglicht es Ihnen, je nach der Plattform, auf der die Anwendung ausgeführt wird, alternative Ressourcen zu laden. Beispielsweise können Sie den Dateiauswähler „ +android “ verwenden, um beim Ausführen auf Android-Geräten verschiedene Bilddateien zu laden.

Sie können Dateiauswahlfelder zusammen mit Singleton-Objekten verwenden, um auf einer bestimmten Plattform auf eine einzelne Instanz eines Objekts zuzugreifen.

Dateiauswähler sind statisch und erzwingen eine Dateistruktur, bei der plattformspezifische Dateien in Unterordnern gespeichert werden, die nach der jeweiligen Plattform benannt sind. Wenn Sie eine dynamischere Lösung benötigen, um Teile Ihrer Benutzeroberfläche bedarfsgerecht zu laden, können Sie einen Loader verwenden.

Die Zielplattformen können das Laden alternativer Ressourcen für unterschiedliche Bildschirmauflösungen auf verschiedene Weise automatisieren. Unter Android und iOS wird das Dateinamenssuffix @2x verwendet, um Bilder mit hoher DPI-Auflösung zu kennzeichnen. Der QML-Typ „ Image “ und die Klasse „ QIcon “ laden automatisch @2x-Versionen von Bildern und Symbolen, sofern diese vorhanden sind. Die Klassen „ QImage “ und „ QPixmap “ setzen die Eigenschaft „ devicePixelRatio “ der @2x-Versionen von Bildern automatisch auf „ 2 “, aber Sie müssen Code hinzufügen, um die @2x-Versionen tatsächlich zu verwenden:

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

Android definiert allgemeine Bildschirmgrößen (small, normal, large, xlarge) und Bildschirmauflösungen (ldpi, mdpi, hdpi, xhdpi, xxhdpi und xxxhdpi), für die Sie alternative Ressourcen erstellen können. Android erkennt die aktuelle Gerätekonfiguration zur Laufzeit und lädt die entsprechenden Ressourcen für Ihre Anwendung. Ab Android 3.2 (API-Level 13) sind diese Größengruppen jedoch veraltet und werden durch eine neue Technik zur Verwaltung von Bildschirmgrößen auf Basis der verfügbaren Bildschirmbreite ersetzt.

Komponenten nach Bedarf laden

Ein „ Loader “ kann eine QML-Datei (mithilfe der Eigenschaft „ source “) oder ein „Component“-Objekt (mithilfe der Eigenschaft „ sourceComponent “) laden. Dies ist nützlich, um die Erstellung einer Komponente aufzuschieben, bis sie benötigt wird. Beispielsweise wenn eine Komponente bedarfsgesteuert erstellt werden soll oder wenn eine Komponente aus Leistungsgründen nicht unnötig erstellt werden soll.

Sie können Loader auch nutzen, um auf Situationen zu reagieren, in denen Teile Ihrer Benutzeroberfläche auf einer bestimmten Plattform nicht benötigt werden, da die Plattform bestimmte Funktionen nicht unterstützt. Anstatt eine Ansicht anzuzeigen, die auf dem Gerät, auf dem die Anwendung läuft, nicht benötigt wird, können Sie festlegen, dass die Ansicht ausgeblendet wird, und mithilfe von Loadern an ihrer Stelle etwas anderes anzeigen.

Wechsel der Ausrichtung

Die angehängte Eigenschaft „ Screen.orientation “ enthält die aktuelle Ausrichtung des Bildschirms, die vom Beschleunigungssensor (sofern vorhanden) ermittelt wird. Auf einem Desktop-Computer ändert sich dieser Wert in der Regel nicht.

Wenn „ primaryOrientation “ dem Wert „ orientation “ entspricht, bedeutet dies, dass der Bildschirm alle angezeigten Inhalte automatisch dreht, je nachdem, wie Sie das Gerät halten. Wenn sich die Ausrichtung ändert, obwohl sich „ primaryOrientation “ nicht ändert, dreht das Gerät sein eigenes Display möglicherweise nicht. In diesem Fall müssen Sie möglicherweise „ Item.rotation “ oder „ Item.transform “ verwenden, um Ihre Inhalte zu drehen.

Definitionen für oberste Seitenebenen von Anwendungen sowie Definitionen wiederverwendbarer Komponenten sollten eine einzige QML-Layoutdefinition für die Layoutstruktur verwenden. Diese einzige Definition sollte das Layoutdesign für verschiedene Geräteausrichtungen und Seitenverhältnisse enthalten. Der Grund dafür ist, dass die Leistung während eines Ausrichtungswechsels entscheidend ist; daher ist es ratsam, sicherzustellen, dass alle Komponenten, die für beide Ausrichtungen benötigt werden, bereits geladen sind, wenn sich die Ausrichtung ändert.

Im Gegensatz dazu sollten Sie gründliche Tests durchführen, wenn Sie sich dafür entscheiden, eine „ Loader “ zu verwenden, um zusätzliches QML zu laden, das in den verschiedenen Ausrichtungen benötigt wird, da dies die Leistung beim Wechsel der Ausrichtung beeinträchtigt.

Um Layout-Animationen zwischen den Ausrichtungen zu ermöglichen, müssen sich die Ankerdefinitionen innerhalb derselben übergeordneten Komponente befinden. Daher sollte die Struktur einer Seite oder einer Komponente aus einem gemeinsamen Satz von untergeordneten Komponenten, einem gemeinsamen Satz von Ankerdefinitionen und einer Sammlung von Zuständen (definiert in einem „ StateGroup “) bestehen, die die verschiedenen von der Komponente unterstützten Seitenverhältnisse darstellen.

Wenn eine in einer Seite enthaltene Komponente in zahlreichen verschiedenen Formfaktor-Definitionen gehostet werden muss, sollten die Layout-Zustände der Ansicht vom Seitenverhältnis der Seite (ihr unmittelbarem Container) abhängen. Ebenso können sich verschiedene Instanzen einer Komponente in zahlreichen verschiedenen Containern einer Benutzeroberfläche befinden, weshalb ihre Layout-Zustände durch das Seitenverhältnis ihres übergeordneten Elements bestimmt werden sollten. Daraus folgt, dass Layoutzustände stets dem Seitenverhältnis des direkten Containers folgen sollten (nicht der „Ausrichtung“ des aktuellen Gerätebildschirms).

Innerhalb jedes Layout State s sollten Sie die Beziehungen zwischen Elementen mithilfe nativer QML-Layoutdefinitionen festlegen. Weitere Informationen finden Sie weiter unten. Bei Übergängen zwischen den Zuständen (ausgelöst durch eine Änderung der Ausrichtung auf oberster Ebene) können im Falle von Anker-Layouts „ AnchorAnimation “-Elemente verwendet werden, um die Übergänge zu steuern. In einigen Fällen können Sie auch ein „ NumberAnimation “ (z. B. auf die Breite eines Elements) verwenden. Achten Sie darauf, komplexe JavaScript-Berechnungen während jedes Animationsframes zu vermeiden. Die Verwendung einfacher Ankerdefinitionen und Ankeranimationen kann in den meisten Fällen dabei helfen.

Es gibt noch einige weitere Fälle zu berücksichtigen:

• Was ist, wenn Sie eine einzelne Seite haben, die im Quer- und Hochformat völlig unterschiedlich aussieht, d. h., alle untergeordneten Elemente sind unterschiedlich? Richten Sie für jede Seite zwei untergeordnete Komponenten mit separaten Layout-Definitionen ein und stellen Sie sicher, dass jeweils eines der Elemente in jedem Zustand eine Deckkraft von Null hat. Sie können eine Überblendanimation verwenden, indem Sie einfach einen „ NumberAnimation “-Übergang auf die Deckkraft anwenden.
• Was ist, wenn Sie eine einzelne Seite haben, bei der im Hoch- und Querformat 30 % oder mehr des Layoutinhalts identisch sind? In diesem Fall sollten Sie eine Komponente mit den Zuständen „Querformat“ und „Hochformat“ sowie eine Sammlung separater untergeordneter Elemente in Betracht ziehen, deren Deckkraft (oder Position) vom Ausrichtungszustand abhängt. So können Sie Layout-Animationen für die Elemente verwenden, die in beiden Ausrichtungen gemeinsam genutzt werden, während die anderen Elemente entweder ein- und ausgeblendet oder auf den Bildschirm hinein- bzw. von diesem heraus animiert werden.
• Was ist, wenn Sie auf einem Handheld-Gerät zwei Seiten haben, die gleichzeitig auf dem Bildschirm angezeigt werden müssen, zum Beispiel auf einem Gerät mit größerem Formfaktor? Beachten Sie in diesem Fall, dass Ihre Ansichtskomponente nicht mehr den gesamten Bildschirm einnimmt. Daher ist es wichtig zu beachten, dass alle Komponenten (insbesondere Delegate-Elemente von Listen) von der Breite der umgebenden Komponente abhängen sollten, nicht von der Bildschirmbreite. In diesem Fall kann es erforderlich sein, die Breite in einem `Component.onCompleted()`-Handler festzulegen, um sicherzustellen, dass das Delegate-Element der Liste bereits erstellt wurde, bevor der Wert gesetzt wird.
• Was ist, wenn die beiden Ausrichtungen zu viel Speicherplatz beanspruchen, um sie gleichzeitig im Speicher zu halten? Verwenden Sie bei Bedarf einen „ Loader “, wenn Sie nicht beide Versionen der Ansicht gleichzeitig im Speicher halten können, aber achten Sie auf die Leistung der Überblendanimation während des Layoutwechsels. Eine Lösung könnte darin bestehen, zwei „Splash-Screen“-Elemente als untergeordnete Elemente der Seite zu verwenden und während der Rotation zwischen diesen überblenden. Anschließend können Sie mit einem „ Loader “ eine weitere untergeordnete Komponente laden, die die eigentlichen Modelldaten in ein anderes untergeordnetes Element lädt, und zu diesem überblenden, sobald die „ Loader “ abgeschlossen ist.