doc_TheScreenConceptandModel-View-Presenter.md

The Screen Concept and Model-View-Presenter

• 번역 원문 링크
• 네이버 카페 전자공작 HID님 번역글 링크
• QT vs MVP

The Screen Concept and Model-View-Presenter (번역 : GUI 프로젝틔 컨셉과 MVP 기술)

• 이 글에서는 Microsoft사의 MVP기술과 TouchGFX 플랫폼이 동작하는 원리에 대하여 기술합니다.
• 당장에 성과가 필요할때 읽기보다는 좀더 기술의 근본적 원리에 대하여 궁금한 분들이 읽으실때 도움이 됩니다.

1. The Screen concept (스크린의 기획/컨셉)

RAM 사용이 적다는 장점과 전체적인 구조에 대하여 설명합니다

• TouchGFX 응용 프로그램에서는 "화면"을 얼마든지 가질 수 있습니다. TouchGFX의 화면은 UI 요소 (위젯)와 관련 비즈니스 논리의 논리적 그룹입니다. 화면은이 화면에 표시되는 모든 위젯을 포함하는 View 클래스와이 화면에 대한 비즈니스 로직을 포함하는 Presenter의 두 클래스로 구성됩니다.

• 단일 화면의 컨텍스트 내에서 전체 응용 프로그램을 구현하도록 선택할 수 있지만 (뷰와 발표자가 하나만 있음을 의미) UI의 관련이없는 부분을 다른 화면으로 분할하는 것이 좋습니다.

  1. TouchGFX는 가장 많은 RAM을 소비하는 화면에 필요한 RAM을 자동으로 할당하는 메모리 할당 체계를 포함합니다. 이 양만 할당되며이 RAM 블록은 응용 프로그램의 모든 화면에서 재사용됩니다.
  2. 여러 화면이 있으면 UI 코드를 훨씬 쉽게 관리 할 수 ​​있습니다.

2. Defining screens (스크린 정의하기)

스크린을 어떻게 구성하면 좋고 기능에 대하여 알려줍니다

• 응용 프로그램을 화면으로 나누는 방법에 대한 정확한 규칙은 없지만 특정 응용 프로그램을 구성 할 화면을 결정하는 데 도움이되는 특정 지침이 있습니다.
• 시각적 및 기능적으로 관련이없는 UI 영역은 다른 화면에 유지해야합니다. 주 온도 판독 값 디스플레이와 구성 메뉴가있는 매우 간단한 온도 조절기 응용 프로그램을 고려할 경우 온도 판독 값에 대한 "메인 화면"과 구성 메뉴를 표시하기위한 "설정 화면"을 만드는 것이 좋습니다.
• 메인 화면의보기에는 배경 이미지 용 위젯, 온도를 표시하기위한 몇 가지 텍스트 영역 및 구성 메뉴로 전환하기위한 버튼이 있습니다
• 반면에 구성보기에는 구성 옵션 목록과 다른 배경 이미지를 표시하는 위젯이 포함되어있을 수 있습니다.
• 구성 메뉴에서 다양한 유형의 설정 (날짜, 키보드 이름, 온도, 단위 등)을 편집 할 수있는 경우이 화면이 크게 복잡해집니다.
• 이 경우 구성 메뉴를 전체 메뉴 옵션 트리를 표시하는 하나의 화면과 특정 값을 편집하기위한 다른 화면으로 세분화하는 것이 좋습니다.
• 그러나 이것은 프로젝트가 진행됨에 따라 배울 것입니다.
• TouchGFX는 C ++로 구현되므로 화면에서 객체 지향 패러다임을 활용할 수 있습니다.
• 예를 들어 모든 화면의 상단에 현재 시간, 배터리 잔량 등을 표시하는 상태 표시 줄이 표시되어야하는 경우 상태 표시 줄 만 포함 된 기본 보기 클래스를 만들고, 보기 에서 상태 표시 줄 기능이 자동으로 모든 보기를 가져 오도록 할 수 있습니다.

3. Currently active screen

한번에 하나만의 View와 Presenter만 할당하는 장점(리스소 절약, 이벤트 콜백 함수 버리기)에 대한 설명입니다

• TouchGFX가 screen(가장 큰 View와 가장 큰 Presenter를 위한 할당)의 메모리를 할당하는 방식 때문에 한 번에 하나의 View와 하나의 Presenter만 활성화 될 수 있습니다.
• 따라서 온도 조절 장치가 온도 값을 표시하는 경우 설정 메뉴 화면은 어디에서도 실행되지 않고 심지어는 할당되지도 않습니다.
• "backend"(온도 조절 장치의 실제 작업을 수행하는 모든 비 UI 코드) 또는 hardware peripherals에서 수신 된 이벤트는 현재 active screen으로 위임될 수 있습니다.
• 일부 이벤트는 특정 screen에만 관계되므로 이에 미치는 영향을 효과적으로 분리 할 수 ​​있습니다.
• 예를 들어, 현재 온도 변화를 알려주는 이벤트가 수신되면 main screen(현재 온도를 나타내는 text area을 업데이트하는)에서만 처리 될 수 있지만, 온도가 표시되지 않는 설정 screen은 이 이벤트와 관계가 없으므로 이벤트를 간단히 폐기 할 수 있습니다.

4. Model-View-Presenter

MVP 구조에 대한 M, V, P 각각 요소에 대한 설명입니다

• Model-View-Presenter(MVP)는 UI 응용 프로그램에서 담당 임무를 나누는 일반적인 방법입니다.
• 그래픽 요소 UI 설정, 변경 사항 대응 및 UI status의 영구적인 유지 문제를 구분합니다.
• 다음은 TouchGFX screen 개념이 전체 Model-View-Presenter 아키텍처와 어떻게 연결되는지를 나타낸 그림입니다.

4.1 Model

Model 클래스는 항상 살아 있고 두 가지 목적을 갖는 단독 개체(singleton)입니다.

• UI에 대한 상태 정보를 저장합니다. View와 Presenter는 화면을 전환 할 때 할당이 해제되므로 화면 전환을 거쳐서 유지해야 하는 정보를 저장하는 데 사용할 수 없습니다. 대신 Model을 사용합니다.
• 백엔드 시스템에 대한 인터페이스로 작동하여 현재 활성 screen에서 이벤트를 전달합니다.
• Model 클래스는 현재 활성화 된 presenter에 대해 포인터를 갖도록 자동으로 설정됩니다.
• Model에서 변화가 발생하면 현재 활성화 된 presenter에게 변화가 통보됩니다. 이 작업은 응용 프로그램의 ModelListener 인터페이스에 있는 메소드를 통해 수행됩니다.
• Model 클래스, 백엔드와 현재 screen 사이의 통신 방법에 대한 더 자세한 정보와 예제는 다음 문서를 참조 : Connecting the UI to your system

4.2 View

View 클래스(좀더 정확하게는 TouchGFX View 클래스에서 파생된 사용자 정의 클래스)에는 멤버 객체로 이 view에 표시되는 위젯이 포함되어 있습니다.

• 또한 이 screen에 들어가거나 나올 때 자동으로 호출되는 함수 setupScreen와 tearDownScreen함수 가 포함되어 있습니다.
• 일반적으로 setupScreen함수에서 위젯을 구성하게 됩니다.
• View에는 연결된 Presenter에 대한 포인터도 포함됩니다. 이 포인터는 framework에 의해 자동으로 설정됩니다.
• 이 포인터를 사용하여 버튼 클릭과 같은 UI 이벤트를 Presenter에 전달할 수 있습니다.

4.3 Presenter

Presenter 클래스(TouchGFX Presenter 클래스에서 파생된 사용자 정의 클래스)는 현재 활성 screen의 비즈니스 논리를 담당합니다.

• Presenter 클래스는 View의 UI 이벤트와 Model의 "백엔드"이벤트를 수신하고 취할 조치를 결정합니다. 예를 들어 Model로부터 알람 이벤트가 수신되면, Presenter는 View에 알람 팝업 대화 상자를 표시해야 한다고 결정할 수 있습니다.

어플리케이션 프로그래머 관점에서 본 QT와 MVP 비교

• (역주) 경쟁 플랫폼 QT에서는 시그널-슬롯 통신 및 콜백함수 메커니즘으로 GUI 프레임워크가 동작했다면 MVP 에서는 View 클래스에서 GUI의 보여지는 부분을 담당하고, Presenter가 리소스 최적화, Model에서 프로젝트의 Object를 담당하는것으로 생각됩니다.

5. Screen Transitions

• TouchGFX는 한 화면에서 다른 화면으로의 전환을 애니메이션으로 만들 수있는 화면 전환 메커니즘을 가지고 있습니다.
• 기본 전환은 NoTransition으로 한 화면에서 다른 화면으로 즉시 전환하는 것이며, SlideTransition은 가로 또는 세로로 새 화면에서 다른 화면으로 슬라이드합니다.
• 필요한 경우 아주 쉽게 사용자 정의 전환을 만들 수 있습니다.