跳转到主要内容

屏幕概念

从“@site/components/Figure”导入图片；

在TouchGFX应用中，可以有任意数量的“屏幕”（下面的示例有两个屏幕）。 TouchGFX中的屏幕是UI元素（小工具）及其相关业务逻辑的逻辑分组。 屏幕包含两个类：包含该屏幕上显示的所有小工具的View类，以及包含该屏幕的业务逻辑的Presenter类。

主视图（屏幕 1）
设置视图（屏幕 2）

您可以选择在单个屏幕的背景下实现整个应用（意味着只有一个View和一个Presenter），但我们建议将UI的不相关部分分割成不同屏幕，原因有两个：

  1. TouchGFX包含存储器分配方案，可自动分配大多数RAM占用量大的屏幕所需的必要RAM。 只会分配必要的量，此RAM块将在应用中的所有屏幕之间重复使用。
  2. 有多个屏幕会使UI代码的维护容易得多。

定义屏幕​

关于应如何将应用划分成多个屏幕，并没有具体的规则，但有特定的指南，也许能帮助您决定应当用哪些屏幕构成您的特定应用。 在视觉和功能上无关的UI区域应保存在不同屏幕中。

如果是十分简单的有主温度读出显示屏和配置菜单的恒温器应用，建议创建“主屏幕”用于温度读出，并创建“设置屏幕”用于显示配置菜单。

主屏幕的视图将包含用于背景图像的小工具，几个显示温度的文本区和一个用于切换至配置菜单的按钮。 另一方面，用于配置的视图可能包含显示配置选项列表和不同背景图像的小工具。 如果配置菜单能够编辑许多不同类型的设置（日期、名称和键盘、温度、单位等），此屏幕的复杂性将大幅提升。

主屏幕的视图将包含用于背景图像的小工具，几个显示温度的文本区和一个用于切换至配置菜单的按钮。 但随着项目的进展，这是您将学到的东西。

当前活动屏幕​

由于 TouchGFX 为屏幕分配内存的方式（只为最大的 View 和最大的 Presenter 分配），一次只能有一个 View 和一个 Presenter 处于活动状态。 因此，如果您的恒温器应用程序正在显示温度读数，那么配置菜单屏幕不会在任何地方运行，实际上甚至没有分配。

如果从“后端”（所有执行恒温器实际工作的非UI代码）或硬件外设接收到事件，则可以将这些事件传递给当前活动屏幕。

由于一些事件将只与应用中的特定屏幕有关，因此这提供了有效的隔离方式。 例如，只有主屏幕才能处理通知当前温度变化的已接收事件（将更新显示当前温度的文本区），而由于当前温度未显示在配置屏幕上，配置屏幕可以直接丢弃此无关事件。

TouchGFX中的Model-View-Presenter​

TouchGFX 遵循 Model-View-Presenter Design Pattern描述的Model-View-Presenter 设计模式。 TouchGFX 屏幕概念通过继承自 TouchGFX 中的 View 和 Presenter 类的类与整个 Model-View-Presenter 架构联系在一起。 因此，在TouchGFX Designer中将新屏幕添加到应用时，会创建新的特定View类和Presenter类以代表该特定屏幕。

TouchGFX应用中MVP类的内容和责任如下。

Model​

Model 类是一个永远存在的单类，它有两个用途：

  1. 保存UI的状态信息。 在切换屏幕时，View和Presenter的分配会被清除，因此它们不能用于存储在屏幕转换时应当保留的信息。 为此，使用Mode保存信息l。
  2. 作为面向后端系统的接口，向/从当前活动屏幕发送事件。

Model类是自动设置的，具有指向当前活动Presenter的指针。 当Model中发生变化时，将变化通知当前活动Presenter。 这是通过应用中ModelListener接口中的方法来完成的。

TouchGFX Designer生成的新应用将自动拥有可直接供UI使用的Model类。

View​

View类（或者更具体地说，派生自TouchGFX View类的类）包含了该视图中显示的控件作为成员对象。 它还包含setupScreen和tearDownScreen函数，当进入/退出该屏幕时，会自动调用它们。 通常会在setupScreen函数中配置控件。

View还将包含指向相关Presenter的指针。 该指针通过框架自动设置。 使用此指针，您可以将 UI 事件（如按钮单击）传达给 Presenter。

Presenter​

您的 Presenter 类（同样，一个派生自 TouchGFX Presenter 类的类）负责当前活动屏幕的业务逻辑。 它将接收来自模型的“后端”事件，以及来自视图的 UI 事件，并决定采取何种行动。 例如，如果从 Model 接收到警报事件，Presenter 可能决定告诉 View 应该显示警报弹出对话框。