확장성

여러 가지 서로 다른 모바일 기기 플랫폼용 애플리케이션을 개발할 때 다음과 같은 과제에 직면하게 됩니다:

• 모바일 기기 플랫폼은 화면 크기, 종횡비, 방향, 밀도 등 다양한 화면 구성을 가진 기기를 지원합니다.
• 플랫폼마다 UI 규칙이 다르기 때문에 각 플랫폼에서 사용자의 기대에 부응해야 합니다.

Qt Quick 이를 통해 태블릿이나 핸드셋과 같은 다양한 유형의 기기에서 실행될 수 있는 애플리케이션을 개발할 수 있습니다. 특히, 서로 다른 화면 구성에도 대응할 수 있습니다. 그러나 각 대상 플랫폼에 대해 최적의 사용자 경험을 제공하려면 항상 어느 정도의 수정과 다듬기가 필요합니다.

다음과 같은 경우 확장성을 고려해야 합니다:

• 애플리케이션을 Android 및 iOS와 같은 두 개 이상의 기기 플랫폼이나, 두 가지 이상의 기기 화면 구성에 배포하려는 경우
• 초기 배포 후 시장에 출시될 수 있는 새로운 기기에 대비하고자 할 때.

다음과 같이 확장 가능한 애플리케이션을 구현하려면 Qt Quick:

• UI 컨트롤 세트를 제공하는 Qt Quick Controls 를 사용하여 UI를 설계합니다.
• 항목의 크기를 조정할 수 있는 Qt Quick Layouts를 사용하여 레이아웃을 정의하십시오. 이 레이아웃은 항목의 크기를 조정할 수 있습니다.
• 레이아웃으로 처리할 수 없는 사용 사례를 구현하려면 속성 바인딩을 사용하십시오. 예를 들어, 픽셀 밀도가 낮거나 높은 화면에서 이미지의 대체 버전을 표시하거나, 현재 화면 방향에 따라 뷰 내용을 자동으로 조정하는 경우 등이 있습니다.
• 참조 기기를 선택하고, 실제 화면 크기에 맞춰 이미지 및 글꼴 크기와 여백을 조정하기 위한 확대/축소 비율을 계산합니다.
• 파일 선택기를 사용하여 플랫폼별 자산을 로드합니다.
• Loader를 사용하여 필요에 따라 컴포넌트를 로드하십시오.

애플리케이션을 설계할 때 다음 패턴을 고려하십시오:

• 모든 화면 크기에서 뷰의 콘텐츠는 상당히 유사할 수 있지만, 콘텐츠 영역이 확장될 수 있습니다. Qt Quick Controls 의 ` ApplicationWindow ` QML 유형을 사용하면 콘텐츠 항목의 크기를 기반으로 창 크기를 자동으로 계산합니다. Qt Quick Layouts 를 사용하여 콘텐츠 항목의 위치를 지정하면, 해당 항목에 삽입된 항목의 크기가 자동으로 조정됩니다.
• 작은 기기에서 전체 페이지를 구성하는 콘텐츠는 큰 기기의 레이아웃에서 하나의 컴포넌트 요소가 될 수 있습니다. 따라서 이를 별도의 컴포넌트(즉, 별도의 QML 파일에 정의된)로 만드는 것을 고려하십시오. 그러면 작은 기기에서는 뷰가 단순히 해당 컴포넌트의 인스턴스를 포함하게 됩니다. 더 큰 기기의 경우, 로더를 사용하여 추가 항목을 표시할 수 있을 만큼 충분한 공간이 있을 수 있습니다. 예를 들어, 이메일 뷰어의 경우 화면이 충분히 크다면 이메일 목록 보기와 이메일 읽기 보기를 나란히 표시할 수 있습니다.
• 게임의 경우, 화면이 큰 사용자에게 불공정한 이점을 주지 않도록 일반적으로 크기가 조정되지 않는 게임 보드를 만드는 것이 좋습니다. 한 가지 해결책은 지원되는 가장 작은 화면비(일반적으로 3:2)에 맞는 안전 영역을 정의하고, 4:3 또는 16:9 화면에서는 숨겨지는 공간에 장식용 콘텐츠만 추가하는 것입니다.

애플리케이션 창 크기 동적 조정

Qt Quick ControlsQt Quick 에서 사용자 인터페이스를 생성하기 위한 일련의 UI 컨트롤을 제공합니다. 일반적으로 애플리케이션의 루트 항목으로 ` ApplicationWindow ` 컨트롤을 선언합니다. ` ApplicationWindow `는 ` MenuBar`, ` ToolBar`, `StatusBar`와 같은 다른 컨트롤을 플랫폼에 구애받지 않는 방식으로 배치하는 데 편의를 제공합니다. ` ApplicationWindow `는 실제 창의 유효한 크기 제약 조건을 계산할 때 콘텐츠 항목의 크기 제약 조건을 입력으로 사용합니다.

애플리케이션 창의 표준 구성 요소를 정의하는 컨트롤 외에도, 뷰와 메뉴를 생성하거나 사용자로부터 입력을 수신 및 표시하기 위한 컨트롤이 제공됩니다. Qt Quick Controls Styles를 사용하여 미리 정의된 컨트롤에 사용자 지정 스타일을 적용할 수 있습니다.

Qt Quick Controls ToolBar 와 같은 컨트롤은 자체 레이아웃을 제공하지 않으며, 사용자가 직접 콘텐츠의 위치를 지정해야 합니다. 이를 위해 를 사용할 수 있습니다. Qt Quick Layouts

화면 컨트롤의 동적 레이아웃 설정

Qt Quick LayoutsRowLayout, ColumnLayout 및 GridLayout QML 유형을 사용하여 화면 컨트롤을 행, 열 또는 그리드 형태로 배치할 수 있는 방법을 제공합니다. 이러한 QML 유형의 속성에는 레이아웃 방향과 셀 간 간격이 저장됩니다.

다음 Qt Quick Layouts QML 유형을 사용하여 레이아웃에 추가된 항목에 추가 속성을 부여할 수 있습니다. 예를 들어, 항목의 높이, 너비 및 크기에 대한 최소값, 최대값 및 선호값을 지정할 수 있습니다.

레이아웃은 창과 화면의 크기가 조정될 때 UI가 적절하게 조정되도록 보장하며, 항상 사용 가능한 공간을 최대한 활용합니다.

GridLayout 유형의 구체적인 사용 사례로는 화면 방향에 따라 행 또는 열로 사용하는 것이 있습니다.

다음 코드 스니펫은 ` flow ` 속성을 사용하여 화면 너비가 화면 높이보다 클 때는 그리드의 흐름을 왼쪽에서 오른쪽(행)으로, 그렇지 않은 경우에는 위에서 아래(열)로 설정합니다:

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

화면 크기를 지속적으로 조정하고 재계산하는 작업은 성능상의 부담을 초래합니다. 예를 들어, 모바일 및 임베디드 기기는 매 프레임마다 애니메이션 객체의 크기와 위치를 재계산하는 데 필요한 성능을 갖추지 못할 수 있습니다. 레이아웃을 사용할 때 성능 문제가 발생한다면, 대신 바인딩과 같은 다른 방법을 고려해 보십시오.

레이아웃을 사용할 때 피해야 할 사항들은 다음과 같습니다:

• 레이아웃 내 항목의 x, y, width 또는 height 속성에 바인딩을 설정하지 마십시오. 이는 레이아웃의 목적과 상충될 뿐만 아니라 바인딩 루프를 유발할 수 있습니다.
• 정기적으로 평가되는 복잡한 자바스크립트 함수를 정의하지 마십시오. 이는 특히 애니메이션 전환 중에 성능 저하를 유발합니다.
• 컨테이너 크기나 자식 항목의 크기에 대해 가정하지 마십시오. 사용 가능한 공간의 변화를 유연하게 수용할 수 있는 레이아웃 정의를 만들도록 노력하십시오.
• 픽셀 단위의 완벽한 디자인을 원한다면 레이아웃을 사용하지 마십시오. 콘텐츠 항목은 사용 가능한 공간에 따라 크기가 자동으로 조정되고 배치됩니다.

바인딩 사용

Qt Quick Layouts 가 요구 사항에 맞지 않는 경우, 속성 바인딩을 대신 사용할 수 있습니다. 바인딩을 사용하면 객체가 다른 객체의 속성 변경이나 외부 이벤트 발생에 반응하여 자신의 속성을 자동으로 업데이트할 수 있습니다.

객체의 속성에 값이 할당될 때, 정적 값을 할당하거나 JavaScript 표현식에 바인딩할 수 있습니다. 전자의 경우, 해당 속성에 새로운 값이 할당되지 않는 한 속성의 값은 변경되지 않습니다. 후자의 경우, 속성 바인딩이 생성되며, 평가된 표현식의 값이 변경될 때마다 QML 엔진에 의해 속성의 값이 자동으로 업데이트됩니다.

이러한 방식이 가장 동적입니다. 하지만 자바스크립트 표현식을 지속적으로 평가하면 성능상의 비용이 발생합니다.

바인딩을 사용하면 (Android, macOS, iOS와 같이) 자동으로 지원되지 않는 플랫폼에서 낮은 픽셀 밀도와 높은 픽셀 밀도를 처리할 수 있습니다. 다음 코드 스니펫은 ` Screen.pixelDensity ` 부착 속성을 사용하여 낮은, 높은 또는 일반적인 픽셀 밀도를 가진 화면에 표시할 서로 다른 이미지를 지정합니다:

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

Android, macOS 및 iOS에서는 아이콘과 이미지에 해당하는 식별자(예: @2x, @3x 또는 @4x)를 사용하여 더 높은 해상도의 대체 리소스를 제공하고, 이를 리소스 파일에 배치할 수 있습니다. 화면의 픽셀 밀도와 일치하는 버전이 자동으로 선택되어 사용됩니다.

예를 들어, 다음 코드 스니펫은 Retina 디스플레이에서 artwork@2x.png을 불러오려고 시도합니다:

Image {
    source: "artwork.png"
}

픽셀 밀도 처리

Image, BorderImage, Text 와 같은 일부 QML 유형은 해당 유형에 지정된 속성에 따라 자동으로 크기가 조정됩니다. Image의 너비와 높이가 지정되지 않은 경우, source 속성을 통해 지정된 원본 이미지의 크기를 자동으로 사용합니다. 기본적으로 너비와 높이를 지정하면 이미지가 해당 크기로 크기가 조정됩니다. 이 동작은 ` fillMode ` 속성을 설정하여 변경할 수 있으며, 이를 통해 이미지를 늘리거나 타일링할 수 있습니다. 그러나 DPI가 높은 디스플레이에서는 원본 이미지 크기가 너무 작게 보일 수 있습니다.

BorderImage 는 각 이미지의 일부를 확대/축소하거나 타일링하여 이미지로 테두리를 만드는 데 사용됩니다. 이 유형은 소스 이미지를 9개의 영역으로 분할한 후, 속성 값에 따라 각 영역을 확대/축소하거나 타일링합니다. 그러나 모서리 부분은 전혀 확대/축소되지 않으므로, 고해상도(고 DPI) 디스플레이에서는 결과가 최적이 아닐 수 있습니다.

Text QML 타입은 필요한 공간을 파악하여, 명시적으로 설정되지 않은 경우 width 및 height 속성을 그에 따라 설정하려고 시도합니다. fontPointSize 속성은 디스플레이 밀도와 무관하게 포인트 크기를 설정합니다. 그러나 포인트 단위로 글꼴을 지정하고 다른 크기를 픽셀 단위로 지정하면 문제가 발생합니다. 포인트는 디스플레이 밀도와 무관하기 때문입니다. 저 DPI 디스플레이에서는 정상적으로 보이는 문자열 주위의 테두리가 고 DPI 디스플레이에서는 너무 작아져 텍스트가 잘릴 가능성이 높습니다.

고해상도(High DPI) 지원 수준과 지원되는 플랫폼에서 사용하는 기술은 플랫폼마다 다릅니다. 다음 섹션에서는 고해상도 디스플레이에서 화면 내용을 확장하는 다양한 접근 방식을 설명합니다.

Qt 및 지원되는 플랫폼에서의 고해상도(High DPI) 지원에 대한 자세한 내용은 ‘High DPI’를 참조하십시오.

고 DPI 스케일링

대상 기기가 고해상도(High DPI) 스케일링을 지원하는 경우, 운영 체제는 그래픽 출력을 스케일링하는 데 사용되는 스케일링 비율을 Qt에 제공합니다.

이 접근 방식의 장점은 벡터 그래픽과 글꼴이 자동으로 크기가 조정되고, 기존 애플리케이션을 수정하지 않고도 작동하는 경향이 있다는 것입니다. 그러나 래스터 콘텐츠의 경우 고해상도 대체 리소스가 필요합니다.

스케일링은 Qt Quick 및 Qt Widgets 스택에 구현되어 있으며, Qt GUI에서도 일반적으로 지원됩니다.

저수준 그래픽 API는 디바이스 픽셀 단위로 작동합니다. 여기에는 OpenGL API를 사용하는 코드와 QRhi API를 사용하는 코드가 포함됩니다. 예를 들어, size() 가 1280x720이고 QWindow::devicePixelRatio()이 2인 QWindow 의 경우, 렌더 타겟(스왑체인)의 디바이스 픽셀 크기는 2560x1440이 됩니다.

OS는 창, 이벤트 및 데스크탑 지오메트리를 스케일링합니다. Cocoa 플랫폼 플러그인은 스케일링 비율을 QWindow::devicePixelRatio() 또는 QScreen::devicePixelRatio()로 설정하며, 백킹 스토어에서도 동일하게 설정합니다.

Qt Widgets 의 경우, QPainter 은 백킹 스토어에서 devicePixelRatio() 를 가져와 이를 스케일링 비율로 해석합니다.

그러나 OpenGL에서 픽셀은 항상 디바이스 픽셀입니다. 예를 들어, glViewport()로 전달되는 지오메트리는 devicePixelRatio()에 따라 스케일링되어야 합니다.

지정된 글꼴 크기(포인트 또는 픽셀 단위)는 변하지 않으며, 문자열은 나머지 UI와 비교하여 상대적인 크기를 유지합니다. 글꼴은 렌더링 과정에서 크기가 조정되므로, 포인트로 지정되었든 픽셀로 지정되었든 상관없이 12포인트 글꼴은 2배 스케일링을 적용하여 사실상 24포인트 글꼴이 됩니다. px 단위는 고해상도(DPI) 디스플레이에서 글꼴이 더 작게 표시되지 않도록 하기 위해 장치 독립 픽셀(device independent pixels)로 해석됩니다.

확대/축소 비율 계산

하나의 고해상도(DPI) 기기를 기준 기기로 선택하여, 이미지 및 글꼴 크기와 여백을 실제 화면 크기에 맞게 조정하기 위한 확대/축소 비율을 계산할 수 있습니다.

다음 코드 스니펫은 Nexus 5 Android 기기의 DPI, 높이 및 너비 참조 값, ` QRect ` 클래스에서 반환된 실제 화면 크기, 그리고 ` qApp ` 전역 포인터에서 반환된 화면의 논리적 DPI 값을 사용하여 이미지 크기와 여백(m_ratio)에 대한 배율과 글꼴 크기(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));

적절한 스케일링 비율을 얻으려면 높이 및 너비 값을 참조 기기의 기본 방향(이 경우 세로 방향)에 따라 설정해야 합니다.

다음 코드 스니펫은 글꼴 확대/축소 비율이 1보다 작아 글꼴 크기가 너무 작아지는 경우, 해당 비율을 1 로 설정합니다:

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

대상 기기를 직접 테스트해 보며 추가 계산이 필요한 극단적인 사례를 찾아보아야 합니다. 일부 화면은 계획된 모든 콘텐츠를 담기에는 너무 짧거나 좁아서 별도의 레이아웃이 필요할 수 있습니다. 예를 들어, 1:1과 같이 비정형적인 화면 비율을 가진 화면에서는 일부 콘텐츠를 숨기거나 대체해야 할 수도 있습니다.

QQmlPropertyMap 내의 모든 크기에 스케일링 비율을 적용하여 이미지, 글꼴 및 여백을 조정할 수 있습니다:

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

다음 코드 스니펫의 함수는 글꼴, 이미지 및 여백에 확대/축소 비율을 적용합니다:

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

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

이 기법은 대상 기기의 화면 크기가 크게 다르지 않을 때 합리적인 결과를 제공합니다. 차이가 매우 큰 경우에는 서로 다른 기준값을 가진 여러 가지 레이아웃을 만드는 것을 고려해 보십시오.

플랫폼에 따라 파일 불러오기

QQmlFileSelector 을 사용하여 QML 파일 로딩에 조건부 리소스 로딩( QFileSelector )을 적용할 수 있습니다. 이를 통해 애플리케이션이 실행되는 플랫폼에 따라 대체 리소스를 로드할 수 있습니다. 예를 들어, +android 파일 선택기를 사용하여 Android 기기에서 실행될 때 다른 이미지 파일을 로드할 수 있습니다.

파일 선택기를 싱글톤 객체와 함께 사용하여 특정 플랫폼에서 객체의 단일 인스턴스에 접근할 수 있습니다.

파일 선택기는 정적이며, 플랫폼별 파일이 해당 플랫폼 이름을 딴 하위 폴더에 저장되는 파일 구조를 따릅니다. 필요에 따라 UI의 일부를 동적으로 불러오려면 Loader를 사용할 수 있습니다.

대상 플랫폼은 다양한 디스플레이 밀도에 맞춰 대체 리소스를 여러 방식으로 자동으로 로드할 수 있습니다. Android 및 iOS에서는 @2x 파일명 접미사를 사용하여 고해상도(high DPI) 버전의 이미지를 나타냅니다. Image QML 유형과 QIcon 클래스는 @2x 버전의 이미지와 아이콘이 제공될 경우 이를 자동으로 로드합니다. QImage 및 QPixmap 클래스는 @2x 버전의 이미지에 대한 devicePixelRatio 값을 자동으로 2 로 설정하지만, @2x 버전을 실제로 사용하려면 코드를 추가해야 합니다:

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

Android는 대체 리소스를 생성할 수 있는 일반화된 화면 크기(small, normal, large, xlarge)와 밀도(ldpi, mdpi, hdpi, xhdpi, xxhdpi, xxxhdpi)를 정의합니다. Android는 실행 시 현재 기기 구성을 감지하여 애플리케이션에 적합한 리소스를 로드합니다. 하지만 Android 3.2(API 레벨 13)부터는 사용 가능한 화면 너비를 기반으로 화면 크기를 관리하는 새로운 기술이 도입됨에 따라 이러한 크기 그룹은 더 이상 사용되지 않습니다.

요청 시 컴포넌트 불러오기

Loader 는 QML 파일( source 속성 사용)이나 Component 객체( sourceComponent 속성 사용)를 로드할 수 있습니다. 이는 컴포넌트가 필요할 때까지 생성을 지연시키는 데 유용합니다. 예를 들어, 컴포넌트를 필요에 따라 동적으로 생성해야 하거나, 성능상의 이유로 불필요하게 컴포넌트가 생성되지 않도록 해야 할 때입니다.

또한 특정 플랫폼에서 일부 기능을 지원하지 않아 UI의 일부가 필요하지 않은 상황에 대응하기 위해 로더를 사용할 수도 있습니다. 애플리케이션이 실행되는 기기에서 필요하지 않은 뷰를 표시하는 대신, 해당 뷰를 숨긴 것으로 처리하고 로더를 사용하여 그 자리에 다른 내용을 표시할 수 있습니다.

화면 방향 전환

Screen.orientation 부착 속성에는 가속도계(사용 가능한 경우)에서 얻은 화면의 현재 방향이 포함됩니다. 데스크톱 컴퓨터에서는 이 값이 일반적으로 변하지 않습니다.

primaryOrientation 가 orientation 를 따르는 경우, 이는 사용자가 기기를 잡는 방식에 따라 화면에 표시된 모든 콘텐츠가 자동으로 회전됨을 의미합니다. primaryOrientation 가 변경되지 않았음에도 방향이 변경된다면, 기기가 자체 디스플레이를 회전시키지 않을 수 있습니다. 이 경우, Item.rotation 또는 Item.transform 를 사용하여 콘텐츠를 회전시켜야 할 수 있습니다.

애플리케이션 최상위 페이지 정의와 재사용 가능한 컴포넌트 정의에서는 레이아웃 구조를 위해 하나의 QML 레이아웃 정의를 사용해야 합니다. 이 단일 정의에는 서로 다른 기기 방향과 화면 비율에 대한 레이아웃 디자인이 모두 포함되어야 합니다. 그 이유는 화면 방향 전환 시 성능이 매우 중요하기 때문이며, 따라서 방향이 변경될 때 두 방향 모두에 필요한 모든 컴포넌트가 로드되도록 하는 것이 좋습니다.

반대로, 별도의 방향에서 필요한 추가 QML을 로드하기 위해 Loader 를 사용하기로 선택한 경우, 이는 방향 변경 성능에 영향을 미치므로 철저한 테스트를 수행해야 합니다.

방향 간 레이아웃 애니메이션을 활성화하려면 앵커 정의가 동일한 포함 컴포넌트 내에 위치해야 합니다. 따라서 페이지나 컴포넌트의 구조는 공통 자식 컴포넌트 세트, 공통 앵커 정의 세트, 그리고 컴포넌트가 지원하는 다양한 화면 비율을 나타내는 상태 모음( StateGroup 에서 정의됨)으로 구성되어야 합니다.

페이지 내에 포함된 컴포넌트가 여러 가지 서로 다른 폼 팩터 정의에서 호스팅되어야 하는 경우, 뷰의 레이아웃 상태는 페이지(그 직속 컨테이너)의 종횡비에 따라 결정되어야 합니다. 마찬가지로, 컴포넌트의 서로 다른 인스턴스가 UI 내의 여러 가지 서로 다른 컨테이너에 위치할 수 있으므로, 해당 컴포넌트의 레이아웃 상태는 부모의 종횡비에 따라 결정되어야 합니다. 결론적으로, 레이아웃 상태는 항상 직접적인 컨테이너의 종횡비(현재 기기 화면의 “방향”이 아님)를 따라야 합니다.

각 레이아웃 State 내에서, 네이티브 QML 레이아웃 정의를 사용하여 항목 간의 관계를 정의해야 합니다. 자세한 내용은 아래를 참조하십시오. 상태 간 전환(최상위 수준의 방향 변경에 의해 트리거됨) 중에, 앵커 레이아웃의 경우 AnchorAnimation 요소를 사용하여 전환을 제어할 수 있습니다. 경우에 따라 항목의 너비 등에 대해 NumberAnimation 를 사용할 수도 있습니다. 애니메이션의 각 프레임마다 복잡한 JavaScript 계산을 수행하지 않도록 주의하십시오. 대부분의 경우 간단한 앵커 정의와 앵커 애니메이션을 사용하는 것이 도움이 됩니다.

고려해야 할 몇 가지 추가적인 경우가 있습니다:

• 가로 모드와 세로 모드에서 완전히 다르게 보이는, 즉 모든 자식 항목이 서로 다른 단일 페이지가 있다면 어떻게 해야 할까요? 각 페이지마다 별도의 레이아웃 정의를 가진 두 개의 자식 컴포넌트를 두고, 각 상태에서 항목 중 하나의 불투명도를 0으로 설정하십시오. 불투명도(opacity)에 ‘ NumberAnimation ’ 전환 효과를 적용하기만 하면 크로스 페이드 애니메이션을 구현할 수 있습니다.
• 세로 모드와 가로 모드 간에 레이아웃 콘텐츠의 30% 이상이 공통인 단일 페이지가 있다면 어떻게 해야 할까요? 이 경우, 가로 및 세로 모드를 모두 지원하는 하나의 컴포넌트와, 방향 상태에 따라 불투명도(또는 위치)가 달라지는 별도의 자식 항목 모음을 사용하는 것을 고려해 보세요. 이렇게 하면 방향 간에 공유되는 항목에는 레이아웃 애니메이션을 적용하고, 나머지 항목은 페이드 인/아웃하거나 화면 안팎으로 이동하는 애니메이션을 적용할 수 있습니다.
• 예를 들어 화면 크기가 큰 기기와 같이, 휴대용 기기에서 두 페이지를 동시에 화면에 표시해야 하는 경우는 어떻게 해야 할까요? 이 경우 뷰 컴포넌트가 더 이상 전체 화면을 차지하지 않는다는 점에 유의해야 합니다. 따라서 모든 컴포넌트(특히 목록 델리게이트 항목)는 화면 너비가 아닌, 포함된 컴포넌트의 너비 크기에 따라 결정되어야 한다는 점을 기억하는 것이 중요합니다. 이 경우, 값이 설정되기 전에 목록 항목 델리게이트가 생성되었는지 확인하기 위해 Component.onCompleted() 핸들러에서 너비를 설정해야 할 수도 있습니다.
• 두 가지 방향의 뷰를 동시에 메모리에 유지하기에는 메모리 용량이 너무 부족한 경우에는 어떻게 해야 할까요? 두 버전의 뷰를 동시에 메모리에 유지할 수 없다면 필요에 따라 Loader 를 사용하되, 레이아웃 전환 시 크로스 페이드 애니메이션의 성능 저하를 주의해야 합니다. 한 가지 해결책은 Page의 자식인 두 개의 “스플래시 스크린” 항목을 준비해 두고, 회전 시 이 두 항목 간에 크로스 페이드 효과를 적용하는 것입니다. 그런 다음 Loader 를 사용하여 실제 모델 데이터를 다른 자식 Item에 로드하는 또 다른 자식 컴포넌트를 불러오고, Loader 가 완료되면 해당 항목으로 크로스 페이드 전환할 수 있습니다.