스크린 개념

'@site/components/Figure'에서 그림 가져오기

TouchGFX 애플리케이션에서는 "스크린" 수의 제한이 없습니다(아래 스크린이 2개인 예시 참조). TouchGFX에서 스크린이란 UI 요소(위젯)와 여기에 연결된 비즈니스 로직의 논리적인 그룹을 말합니다. 스크린은 두 개의 클래스 구성되는데, 하나는 이 스크린에 표시되는 모든 위젯이 포함된 View 클래스이고, 나머지 하나는 이 스크린에 사용되는 비즈니스 로직이 포함된 Presenter 클래스입니다.

메인 뷰(스크린 1)

설정 뷰(스크린 2)

단일 스크린(하나의 View와 하나의 Presenter로 구성)의 context 내에서 전체 애플리케이션을 실행하도록 선택할 수도 있지만 UI에서 관련이 없는 요소를 여러 스크린으로 분할하는 것이 좋은데, 그 이유는 다음과 같습니다.

1. TouchGFX에는 RAM을 가장 많이 사용하는 스크린에 필요한 RAM을 자동으로 할당하는 메모리 할당 기법이 적용되어 있습니다. 여기에 필요한 용량만 할당되고, 이후에는 애플리케이션의 모든 스크린에 걸쳐 RAM 블록이 재사용됩니다.
2. 스크린이 여러 개이면 UI 코드를 훨씬 쉽게 관리할 수 있습니다.

스크린 정의

애플리케이션을 여러 스크린으로 분할하는 데 정해진 규칙은 없지만 특정 애플리케이션을 구성할 스크린을 결정하는 데 도움이 될 수 있는 가이드라인이 있습니다. 시각적으로나 기능적으로 관련 없는 UI 영역은 다른 스크린에 포함시켜 구분하는 것이 좋습니다.

온도를 판독하는 메인 디스플레이와 구성 메뉴, 두 가지로 매우 단순한 온도 조절 애플리케이션을 개발하고자 할 경우에는 온도 판독을 위한 “메인 스크린”과 구성 메뉴 표시를 위한 “설정 스크린”을 생성하는 것이 좋습니다.

메인 스크린의 View에는 배경 이미지로 사용할 위젯, 온도를 나타내는 텍스트 영역, 그리고 구성 메뉴로 전환할 수 있는 버튼이 포함됩니다. 반면 구성 View는 구성 옵션 목록을 비롯해 여러 가지 배경 이미지를 나타내는 위젯이 포함될 가능성이 높습니다. 구성 메뉴에서 여러 가지 유형의 설정(날짜, 키보드가 포함된 이름, 온도, 단위 등)을 편집할 수 있도록 만들면 스크린이 너무 복잡해집니다.

이러한 경우에는 구성 메뉴를 스크린 2개로 분할하여 하나는 전체 메뉴 옵션 트리를 나타내는 스크린으로, 나머지 하나는 특정 값을 편집하는 스크린으로 사용하는 것이 유리합니다. 이러한 방법은 프로젝트가 진행되면서 자연스럽게 알 수 있습니다.

현재 활성화된 스크린

TouchGFX에서 스크린에 메모리를 할당하는 방식(사용량이 가장 많은 View와 Presenter에만 할당) 때문에 한 번에 활성화할 수 있는 View와 Presenter는 1개로 제한됩니다. 따라서 온도 조절 애플리케이션에 온도 수치가 표시되는 경우에는 구성 메뉴 스크린이 어디에서도 실행되지 않으며 메모리가 할당되지도 않습니다.

“백엔드”(실제로 온도 조절을 담당하는 UI가 아닌 코드)에서, 혹은 하드웨어 주변 장치에서 이벤트가 수신될 경우, 현재 활성화된 스크린으로 수신된 이벤트를 위임할 수 있습니다.

이벤트 중에는 특정 애플리케이션 스크린에 한해 유효한 이벤트가 있기 때문에 이렇게 하면 관심 영역을 유용하게 분리할 수 있습니다. 예를 들어 현재 온도의 변화를 알리는 이벤트가 수신되면 메인 스크린에서만 해당 이벤트를 처리할 수 있는 반면(현재 온도를 나타내는 텍스트 영역 업데이트), 구성 스크린에서는 현재 온도를 표시하지 않기 때문에 이를 관련 없는 이벤트로 단순히 무시하게 됩니다.

TouchGFX의 Model-View-Presenter

TouchGFX는 Model-View-Presenter 설계 패턴에 기술된 Model-View-Presenter(MVP) 설계 패턴을 따릅니다. TouchGFX 스크린 개념은 TouchGFX의 View 및 Presenter 클래스에서 상속하는 클래스를 통해 전체적인 Model-View-Presenter 아키텍처와 연결됩니다. 따라서 TouchGFX Designer에서 애플리케이션에 새 스크린을 추가하면 특정 View 클래스와 Presenter 클래스가 새롭게 생성되어 해당 스크린을 표시합니다.

TouchGFX 애플리케이션에서 MVP 클래스의 내용과 책임은 다음과 같습니다.

Model

Model 클래스는 항상 활성화 상태를 유지하는 하나밖에 없는 클래스로, 여기에는 다음과 같은 두 가지 목적이 있습니다.

1. UI 상태 정보를 저장합니다. 스크린이 전환되면 View와 Presenter가 할당 해제되므로 스크린 전환 시 유지해야 할 정보를 저장하지 못하게 됩니다. 따라서 Model을 사용하여 정보를 저장합니다.
2. 백엔드 시스템을 향한 인터페이스 역할을 하여 현재 활성화된 스크린과 이벤트를 주고받습니다.

Model 클래스는 현재 활성화된 Presenter에 대한 포인터를 갖도록 자동으로 설정됩니다. 따라서 Model에 변경 사항이 생기면 현재 활성화된 Presenter에 변경 사실이 통지됩니다. 이는 애플리케이션의 ModelListener 인터페이스에서 메소드를 통해 이루어집니다.

Designer에서 새롭게 생성되는 애플리케이션에는 UI에서 언제든지 사용할 수 있도록 Model 클래스가 자동으로 할당됩니다.

View

View 클래스(더 정확하게는 TouchGFX View 클래스에서 파생되는 클래스)는 이 view에서 멤버 객체로 표시되는 위젯으로 구성됩니다. 또한 setupScreen 함수와 tearDownScreen 함수가 포함되어 스크린 전환 시 자동으로 호출됩니다. 일반적으로 위젯은 setupScreen 함수에서 구성합니다.

또한 View에는 연관된 Presenter에 대한 포인터도 포함됩니다. 이 포인터는 프레임워크에서 자동으로 설정됩니다. 이 포인터를 사용하면 버튼 클릭과 같은 UI 이벤트를 Presenter에 알릴 수 있습니다.

Presenter

Presenter 클래스(마찬가지로 TouchGFX Presenter클래스에서 파생된 클래스)는 현재 활성화된 스크린의 비즈니스 로직을 담당합니다. Model에서 “백엔드” 이벤트를, 그리고 View에서 UI 이벤트를 수신하여 실행할 액션을 결정합니다. 이 포인터를 사용하면 버튼 클릭과 같은 UI 이벤트를 Presenter에 알릴 수 있습니다.