CAknViewAppUi 和CAknAppUi

最新推荐文章于 2024-09-25 11:34:05 发布

kelio

最新推荐文章于 2024-09-25 11:34:05 发布

阅读量975

点赞数

分类专栏： symbian 文章标签： application symbian ui mvc 框架 class

symbian 专栏收录该内容

57 篇文章 0 订阅

订阅专栏

CAknViewAppUi 和CAknAppUi

一：

CAknAppUi和CAknViewAppUi不是决定单视图和多视图的因素. CAknViewAppUi确实是为多视图设计的,与CAknAppUi相比,里面多了多个视图的管理,相互切换以及一些事件回调,是S60的新多视图结构.但使用CAknAppUi也同样能实现多视图,因为其还是具备控件栈,可以容纳多个视图.但此时个视图间的切换激活等机制需要自己实现.相比较而言,若使用CAknAppUi,且自己实现多视图管理,则视图类仅一个即可(从CCoeControl派生);若使用CAknViewAppUi,则是系统结构, CAknViewAppUi已实现多视图管理,但每个视图一般来说有两个类来实现,代码关系复杂些。

二：

Symbian的应用程序由两个逻辑部分组成Engine和UI。Engine描述的是数据和算法，UI描述的是屏幕和行为展现。一个Avkon应用程序可以通过3种途径来实现：传统的Symbian OS体系结构，对话框体系结构，视图体系结构。

从图中我们可以看到：
CAknApplication
启动应用程序框架对象
初始化应用程序框架(Avkon)
定义应用程序属性
创建一个Document对象

CAknDocument
创建CAknAppUi控制器类
CAknDocument是App Document的基类。默认情况下，它提供了Document文件的创建和访问。这是经典的Avkon应用程序模式。

CAknAppUi / CAknViewAppUi
在这个模型里面扮演了主要控制器的角色。
The choice of the base class depends on the application architecture （不明白什么意思？@_@）
控制应用程序的主要事件：菜单事件，焦点改变事件，环境变化事件
命令模型
提供按钮和状态面板的范围能力
视图的切换响应
在一个非常简单的应用程序中，这个类包含了应用程序的模型实现。but typically the model is a separate engine owned and controlled by this class（不是很清楚？@_@）.
在视图体系中，这部分的控制逻辑被放在CAknView类中。

View是一个UI控制器
显示模型的应用程序状态
接收用户输入
通知控制器相关事件
观察模型改变并更新屏幕

应用程序Engine
表现应用程序的状态和数据
封装非UI依赖的功能
有自己的库实现
常用的非UI的功能，如网络，数据库等
由Document或AppUI直接控制。

三：

开发symbian的GUI应用是有模板的，用Carbide C++的工程向导可以自动生成程序的基本框架。不过可能与安装的SDK版本有关，我现在只能生成一个AppUi一个Container的常规模板(以前用2nd FP3时还可以生成多个view多个container的视图模板)。

　　不管是哪一种模板，它们共同的部分是入口函数、Application和Document。即以下三个文件是所有工程都具有的：

　　1)有一个与工程同名的cpp文件，它只提供了两个全局函数，是程序执行的入口，负责创造Application。这个文件我们不用管它。

　　2)有一个以工程名+Application命名的类，派生于CAknApplication，它负责创建文档类并提供应用的UID。一般情况下它也不需要我们操心，但是因为它提供了一个函数OpenIniFileLC，如果我们需要在启动程序时加载ini文件中的配置，可以重载它。

　　3)有一个以工程名+Document命名的类，派生于CAknDocument，它负责创建Ui类，同样一般情况我们不管它，但是它也提供了一个函数OpenFileL，如果需要加载普通文件，也可以重载它。

　　下面来看看两种模板的不同点吧。

　　一. 基于CCoeControl的常规模式

　　这种模式的特点是一个AppUi类并且对应一个Container类。

　　它在上述三个文件以外，还有下面两个文件：

　　4)有一个以工程名+AppUi命名的类，派生于CAknAppUi，它主要的工作是负责用户接口(所谓的UI)并且创建Container类，所以它是我们关注的重点之一。

　　它最重要的成员函数是HandleCommandL，这个函数来自于CEikAppUi类，负责处理各种命名/事件。

　　有两个函数DynInitMenuBarL和DynInitMenuPaneL,如果需要动态更改菜单的项目，可以重载它们。

　　HandleKeyEventL函数则可以在需要自己处理键盘事件时重载一下。

　　此外，这个AppUi还提供一些比较常用的函数，比如：

　　Document() 可以获取Document对象指针。

　　Application() 可以获取Application对象指针。

　　StatusPane() 可以获取状态栏的指针。

　　Cba() 可以获取控制栏的指针。

　　5)有一个以工程名+Container命名的类，派生于CCoeControl，它负责内容的展示，也是我们关注的重点。

　　如果需要在界面上增加控件类类的东西，都是在这个类中实现，总的来说，它负责所有与界面展示相关的东西。

　　它有一个Draw函数，但是如果我们是通过控件来展示信息，则这个函数里的代码似乎与我们关系不大，除非我们的界面完全是靠画出来的。

　　另两个函数ComponentControl和CountComponentControls分别获取控件与获取控件个数，在依赖于控件展示的GUI应用中则更为重要。

　　因为它实现了接口MCoeControlObserver，所以函数HandleControlEventL也需要实现一下。

　　利用它的成员iCoeEnv可以取到AppUi类的指针，不过需要强制转型一下，如：STATIC_CAST(CiMusicAppUi*,iCoeEnv->AppUi())->...

　　二. 基于CAknView的MVC模式

　　这种模式的特点是在AppUi类与Container类之间增加一个AppView的类，即一个AppUi对象，N个AppView和N个Container。

　　除了公共的三个文件以外，它包括的文件有：

　　4) 有一个以工程名+AppUi命名的类，派生于CAknViewAppUi类，其实也是间接派生于CAknAppUi类，它的工作职责与常规模式中的AppUi类也基本相同。

　　唯一的区别在于它不是直接创建Container类，而是创建AppView类，并且是创建多个AppView类。同时它还需要负责将创建的view加入视图栈里AddViewL。

    CiMusicViewMusic* view1 = new (ELeave) CiMusicViewMusic;
CleanupStack::PushL( view1 );
view1->ConstructL();
AddViewL( view1 );    // transfer ownership to CAknViewAppUi
CleanupStack::Pop(); // view1

CiMusicViewFavt* view2 = new (ELeave) CiMusicViewFavt;
CleanupStack::PushL( view2 );
view2->ConstructL();
AddViewL( view2 );    // transfer ownership to CAknViewAppUi
CleanupStack::Pop(); // view2

CiMusicViewWeb* view3 = new (ELeave) CiMusicViewWeb;
CleanupStack::PushL( view3 );
view3->ConstructL();
AddViewL( view3 );    // transfer ownership to CAknViewAppUi
CleanupStack::Pop(); // view3

this->ActivateLocalViewL(KViewMusicId);

　　5)有多个以工程名+View命名的类，派生于CAknView类。它负责分担AppUi部分事件的处理，所以，它也有HandleCommandL函数。

　　此外，它的DoActivateL和DoDeactivate两个函数在当前视图激活或失活时被调用，需要重载一下。

　　在激活时，需要创建视图对应的Container类，并且调用Container的SetMopParent为自己，还要在上层的AppUi中将这个Container加入栈中。一般代码如下：

iContainer = new (ELeave) CiMusicContainerFavt;
iContainer->SetMopParent(this);
iContainer->ConstructL( AppUi()->ApplicationRect() );
iContainer->listType=type;
AppUi()->AddToStackL( *this, iContainer );

　　注意，它的AppUi()可以得到它的上层的AppUi对象指针。

　　失活时则正好相反，需要　　

if ( iContainer )
...{
AppUi()->RemoveFromViewStack( *this, iContainer );
}
delete iContainer;
iContainer = NULL;

　　6)有多个以工程名+Container命名的类，派生于CCoeControl并实现接口MCoeControlObserver，所以它的行为与常规模式中的Container类似。

　　这种模式可以有效地组织应用程序，根据应用的多个功能界面切割成数个模块(视图)。由多个AppView来分担AppUi中的事件处理，负责自己这个视图下的具体行为与显示。

　　各个视图之间的切换也很简单：

　　STATIC_CAST(CiMusicAppUi*,iCoeEnv->AppUi())->ActivateLocalViewL(KViewMusicId);

　　[补充]

　　三比较两种模式

　　有些教材还提出过对话框模式，但是我觉得那似乎不太实用，也没注意过它的结构组成。

　　对比上述两种架构模板，很显然，第二种基于视图的模板应该更有实用性一点，除非程序实在简单。

　　不过，这里的“视图”很容易让人产生误解。一般我们说MVC的时候，模型-视图-控制器，但是这里的AppView其实对应的控制器，而Container对应的则是视图。