[번역] Qt 5.12 Best Practices for QML and Qt Quick

Qt 5.12 > All Qt Overviews > Best Practices > 3. Best Practices for QML and Qt Quick

QML과 Qt Quick이 제공하는 이점에도 불구하고 어떤 상황에선 문제가 발생하기도 한다. 다음 sections에선 몇 가지 the best practices를 설명한다. 이는 applications 개발에 도움이 될 것이다.

Custom UI Controls

유연하고 세련된 UI는 오늘날 application 성공의 key이다. QML은 이를 만족한다. Qt는 세련된 look의 UI를 만드는데 필요한 기본 UI controls을 제공한다. Custom UI control을 만들기 전에 기본 UI controls를 확인하기를 권한다.

Qt Quick 자체에서 제공되는 기본 UI controls 외에도, Qt Quick Controls2가 제공하는 다양한 UI controls set이 있으며 별다른 변경없이 대부분의 common use cases를 커버할 수 있다 더불어 customization도 가능하다. 특히, Qt Quick Controls 2는 styling options를 제공하는데, 이는 최신 UI design trends를 따른다. UI controls가 needs를 충족하지 못할 경우에만 custom control을 만들 것을 권한다.

->  QML 칭찬. 유연하며 세련되고 다양한 기본 UI controls가 제공되는데 이걸로 어지간한 것은 다 만들 수 있다. 싫으면 customization도 가능하다.

Bundle Application Resources

대부분 applications는 풍부한 user experience를 제공하기 위해 images나 icons같은 resources을 사용하는데 종종 target OS에 따라 resources를 사용할 수 없는 문제가 발생한다. 대중적인 OS는 엄격한 보안 정책을 가지며 file system 접근을 제한한다. 이 때문에 Resources를 load하기가 어렵다. Qt는 해결방안으로 독자적인 resource system을 제공한다. Resources를 application binary안에 built-in 시키는 것이다. 결과적으로 target OS에 관계없이 resources에 접근할 수 있다.

예를 들어, 아래 directory structure에 대해 생각해보자.

.pro 파일에 다음 구문을 작성하여 resources가 built-in 되도록 한다.

더 편리하게 wildcard syntax를 이용해서 여러 파일을 한 번에 추가할 수도 있다.

이 방법은 resources가 몇 개 안될 때 편리하다. 하지만, new file이 RESOURCES에 추가될 때 마다 RESOURCES에 있는 모든 the other files 또한 recompile해야한다. 이는 files를 많이 가지고 있는 application일수록 비효율적이다. 해결 방법은 resource type에 따라 다른 qrc file로 분리하는 것이다. 예를 들어, 위의 snippet은 아래와 같이 바꿀 수 있다.

(* qml.qrc, images.qrc)

이제 QML file이 변경될 때마다 변경된 파일들만 recompile하면 된다.

때때로 resource system에서 관리하는 특정 file에 많은 control이 필요할 때가 있다. 예를 들어, image2.png 파일에 alias가 필요하다면 명시적인 qrc file로 전환할 필요가 있다. 이와 관련한 상세 내용은 Creating Resource Files에서 확인한다.

Separate UI from Logic

많은 application 개발자의 목표 중 하나는 관리가 용이한 application을 만드는 것이다. 이를 이루는 방법 중 하나는 user interface를 business logic으로부터 분리하는 것이다. 아래에서 applications의 UI를 QML로 작성해야 하는 몇 가지 이유를 설명한다.

>  UI 정의엔 declarative languages가 매우 적합하다.

>  QML code는 C++보다 구문이 짧고 type에 엄격하지 않기 때문에 쓰기가 쉽다. 이는 또한, prototype 작성에 좋고 designer와 협업하기에 좋다.

>  QML에서 java script를 쉽게 사용할 수 있어 Events에 respond할 수 있다.

Type에 엄격한 C++은 application’s logic에 적합하다. 이는 일반적으로 QML보다 C++에서 더 빠른 복잡한 계산이나 데이터 처리와 같은 작업을 수행한다.

Qt는 QML과 C++ code를 integrate하기 위한 다양한 접근법을 제공한다. 전형적인 use case로는user interface에 data list를 보여주는 case가 있다. 만약 data set이 static, simple, small 하다면 QML에서 작성한 model로도 충분하다.

다음 snippet은 QML에서 model을 작성한 예시이다.

Data set의 크기가 크거나 자주 변경된다면 C++을 사용해라.

Interacting with QML from C++

비록 Qt는 C++에서 QML을 조작할 수 있도록 허용하지만 꼭 그렇게 해야만 하는 것은 아니다. 이유를 설명하기 위해 간단한 예를 확인해보자.

Pulling References from QML

Settings page를 위한 UI를 아래와 같이 작성했다고 가정한다.

예시의 button이 click될 때 C++에서 임의의 처리를 하기를 원한다고 하자. C++의 objects처럼 QML의 objects도 change signals를 emit할 수 있다. C++에서 위의 button object를 찾기 위해 button에 “objectName”을 할당해야 한다.

그러면, C++에서 object를 찾을 수 있고 object의 change signal에 callback을 연결할 수 있다.

이 방법으로 QML objects의 reference를 “pulled”할 수 있다. 이 방법의 문제점은 C++ logic layer가 QML presentation layer에 의존한다는 점이다. 만약, QML을 refactoring하는 과정에서 “objectName”이 변경되는 등의 결과로 C++에서 QML object를 찾는 구문이 깨질 수 있다.

-> 위 예제 실행시 에러가 난다. key는 아래의 #include "main.moc"이다. QObject를 상속받은 class를 별도 파일로 구현하면 에러가 나지 않는다.

Pushing References to QML

QML Refactoring이 C++ Refactoring보다 쉽다. 그래서 유지보수의 고통을 줄이기 위해 C++ types이 QML types을 모르게 만들어야 한다. 이는 C++ types의 references를 QML로 “pushing”하는 방법으로 해결할 수 있다.

이후 QML에서 C++의 slot을 직접적으로 호출하게 한다.

이 방법으로 C++는 나중에 QML이 refactoring하더라도 unchanged 할 수 있다.

위의 예시에선 C++ object를 QML에 push하기위해 root context의 context property로 해당 object를 set했다. 이렇게 하면 the engine에 의해 load되는 모든 components에서 해당 property를 사용할 수 있다. QML이 load되자마자 사용 가능해야 하는 경우 context properties를 유용하게 사용할 수 있다. 이는 QML에서 instantiated되면 안 된다.

C++ types를 QML에 노출시키기 위해 어떤 방법을 사용하는 것이 좋은 지 Choosing the Correct Integration Method Between C++ and QML에서 설명한다.

Using Qt Quick Layouts

Qt는 layout안에 있는 Qt Quick items을 배치하기 위해 Qt Quick Layouts를 제공한다. item positioners와 다르게 Qt Quick Layouts는 window resize시에 children도 resize할 수 있다. 이는 대게 좋은 선택지가 되지만 사용시 아래와 같은 참고 사항이 있다.

Dos

>  Layout item의 size를 정해야 하는 데 parent가 Non-Layout이라면 anchors, width, height properties를 사용하라.

>  Layout 바로 아래의 children을 배치하기위해 property를 attach한 Layout을 사용해라.

Don’ts

>  Items의 implicit size가 만족스럽지 않은 경우에만 Layout의 preferred sizes를 사용하라.

>  Layout 바로 아래의 children에 anchors를 사용하지 마라. 그 대신, Layout.preferredWidth, Layout.preferredHeight을 사용하라.

> 

Note: Layouts과 anchors는 instantiation시 더 많은 memory와 시간을 필요로 한다. List나 table delegates, styles에서 이런 것을 사용하지 않도록 유의하라. 이경우 간단하게 x, y, width, height properties를 사용하는 것이 좋다.

Type Safety

QML에서 properties를 선언할 때 “var” type을 사용하면 쉽고 편하다.

하지만, 이런 사용은 몇 가지 단점이 있다.

>  만약, 변수에 잘못된 type의 값이 할당되면 error report는 사용문이 아닌 선언문을 가리킨다. 즉, 오류 추적이 어렵다.

>  위에서 언급된 것과 같은 error를 잡기 위한 정적 분석이 불가하다.

>  코드를 읽는 이가 property의 type을 분명히 알기 어렵다.

가능한한 실제 type을 사용하도록 하라.

Performance

QML과 Qt Quick의 performance를 위한 정보는 Performance Considerations And Suggestions에 있다.

Tools and Utilities

QML과 Qt Quick을 더 쉽게 사용하게 해주는 tools와 utilities에 대한 정보는 Qt Quick Tools and Utilities를 참조하라.

Scene Graph

Qt Quick’s scene graph에 대한 정보는 Qt Quick Scene Graph를 참조하라.

Scalable User Interfaces

Display resolutions가 향상될수록 scalable application UI는 더욱 중요하다. 이를 위한 한 방법은 screen resolutions마다 UI의 copies를 준비해서 가능한 resolution에 따라 적절한 UI를 load하는 것이다. 이는 비록 잘 동작하겠지만 유지보수에 overhead를 더한다.

Qt는 더 나은 solution을 제공하며 이를 따를 것을 권한다.

>  Qt Quick Layouts module이나 anchors를 사용하라.

>  Visual item에 명확한 width, height의 값을 설정하지 마라.

>  Application이 지원하는 display resolution 마다 images와 icons 같은 resources를 제공하라. Qt Quick Controls 2 gallery example은 qt-log.png 파일을 @2x, @3x, @4x resolutions 마다 제공한다. 이는 application이 더 높은 품질의 해상도를 제공할 수 있도록 한다. Qt는 high DPI scaling feature를 명시적으로 enable한 경우 자동으로 주어진 display에 적합한 image를 선택한다.

>  작은 icon은 SVG images를 사용하라. 큰 이미지를 SVG로 하면 render 속도가 느리지만 작은 이미지는 괜찮다. Vector 이미지와 Bitmap 이미지는 resolution에 따라 여러 이미지를 제공할 필요가 없다.

>  “Font Awesome”과 같은 font-based icons를 사용하라. 이는 모든 display resolution에 따라 크기 변환이 가능하며 colorization도 가능하다. Qt Quick Controls 2의 Text Editor example이 이를 잘 보여준다.

이제 제공되는 display resolution에 따라 크기를 변환할 수 있다.