基于S60的应用程序架构(一个同事的总结文章,简单认识)

基于S60的应用程序架构

所谓“应用程序架构”是指应用程序框架类的集合。 基于所需的UI设计，应用程序可以具有不同的架构，但是每种架构都有一些公共部分，称为“核心应用程序类”

1. 基础部分

（1）核心应用程序类.

所有的S60 UI应用程序都具有一些基本功能：

l         提供一个用户界面，用于显示信息并允许用户进行交互

l         响应各种用户启动的事件，比如用户选择一个菜单项

l         响应系统启动的不同事件，比如导致屏幕重绘的window服务器事件

l         能够保存和恢复应用程序数据

l         可以唯一性的向框架标志自身

l         向框架提供有关应用程序的描述性信息，比如图标和标题等

这些类是：视图（View）、文档（Document）、应用程序（Application）、应用程序UI（Application UI）。

[ 注:  一个程序只能有一个文档，可以有多个视图 ]

（2）应用程序初始化

必须创建下面的每个方法，才能提供的S60应用程序：

a、  所有S60 UI都实现一个全局函数E32DLL（），当应用程序启动时，框架将首先调用该函数，该函数也称为DLL入口点，应用程序必须存在该函数。(每个S60 UI 应用程序都是一个多态DLL)。

b、  由框架调用NewApplication（），该函数是由DLL导出的唯一函数。

c、  创建应用程序类的一个实例，并返回它的指针，以后框架使用该指针完成应用程序的创建。

d、 由框架调用AppDllUid（）返回应用程序的UID。该函数必须返回在 .mmp文件中指定的值，并且可用于确定应用程序的实例是否正在运行。

e、 框架获取指向新创建Document类的指针，CreateDocumentL（）。(  用NewL（）具体去创建)

f、 获取AppUi类的指针，CreateAppUiL（）。  由(new （Eleave）CAppUi（）具体创建)

到此一个 基本的框架就创建完毕。

（3）重要的AppUi方法：

AppUi提供了许多方法，框架可以调用这些方法通知每个应用程序各种事件。

  a.  HandKeyEvent（）用于处理用户按键

 b.     HandleForegroundEventL（）当应用程序切换到前台或从前台切换到后台时调用该函数，默认的实现可以处理键盘焦点的改变。

c .     HandleSystemEventL（）传递由窗口服务器生成的事件

d      HandleApplicationSpecificEventL（）可以自己定义的自定义事件的通知。默认的实现可以处理颜色方案改变的通知。

e       HandleCommandL（）用于处理用户选择的菜单项

（4）设计应用程序UI

关于术语“视图（view）”：

a       “视图”是概念性的术语，含义是“数据模型在屏幕上的表示”，实际上由一个或多个从CcoeControl派生而来的UI控件实现视图，这些控件按层次结构进行组织。父控件通常被称为容器（Container），除了用于实现视图的父控件，这种控件被称为对话框（Dialog）

b         在Avkon视图切换架构中，术语“Avkon视图”指的是系统范围内的View服务器注册的类，它控制视图的实例化和析构。

2、常见的symbian应用程序架构：

每种架构都提供了设计应用程序UI的不同方法――所有的架构都提供了提交“视图”或应用程序数据可视化表示的方法，同时提供了一种用户用来与架构进行交互的机制。

基于对话框的架构和传统的基于Symbian OS的架构虽不相同，但和Avkon视图切换架构相比，这两种架构彼此更为类似。原因是：

a      它们的特征是它们用于生成视图的UI控件类型。

b       架构上几乎相同。也就是说，在这两种设计中，AppUi类简单地“拥有”视图控件，因此负责直接管理它们。

而Avkon视图切换架构从根本上不同于这两种方法，它的视图切换由系统范围地View服务器来完成。

（1）基于控件的传统Symbian OS控件

这些控件总是从CcoeControl直接继承，用于表示从CcoeControl直接继承的试图类的标准术语是“容器”。

关于“CcoeControl”：可以将CcoeControl认为是一个空的帐篷。通过继承这个类，可以创建各种各样的自定义控件，自定义控件的功能和复杂性只受到程序员能力和想象力的限制。这种灵活性的唯一不利之处是，控件确实类似于一个空帐篷，因为需要进行许多编码工作来提供重要的功能。在处理视图切换方面，AppUi负责处理用户发出的视图切换请求。随后，AppUi最终的行为类似于一个巨大的开关，用于根据用户或系统的输入来激活或禁止容器。

注意：Container类从CcoeControl派生而来，CcoeControl是所有控件的基类。

在自己的容器类中必须实现从CcoeControl继承出来的四个方法，框架将调用所有这些方法：

A        SizeChanged（）允许控件响应控件大小的改变

b        Draw（）绘制控件

c        CountComponentControls（）返回控件拥有的控件数量

d        ComponentControl（）对于容器拥有的每一个控件，框架调用该方法获取。

在AppUi类中按照如下代码构造容器：

void ChelloWorldAppUi:::Control()

{

BaseControlL();

IAppContainer=ChelloWorldContainer::NewL(ClientRect());

IAppContainer->SetMopParent(this); //在控件之间建立父子关系，在容器上调用此方法。

AddToStackL(iAppContainer); //将Container推入到控件栈顶，例如可以接收键事件
}

注意：如果使用这种架构实现带有多个视图的应用程序，则通过使用AddToStackL（）和RemoveFromStackL（）在不同的容器之间切换。

（2）基于对话框的架构

它不同于传统Symbian OS架构的是，它拥有的控件直接从对话框类家族继承而来。

对话框的主要优点是：相对于直接从CcoeControl派生而来的控件，它需要较少的开发工作，因为它们自动管理子控件的布局。

在AppUi类中完成构造和运行：

void CsimpleDlgAppUi::ConstructL()

{

BaseConstructL();

IAppDialog=new(ELeave) CsimpleDlgDialog;

IAppDialog->SetMopParent(this);

IAppDialog->ExecuteLD (R_SIMPLEDLG_DIALOG);

AddToStackL(iAppDialog);

}

因为对话框是无模式的，ExecuteLD（）将在调用后立刻返回。必须使用AddToStackL（）将对话框添加到控件栈中，因为无模式的对话框无法自己完成这项工作。

还有，必须在AppUi的析构函数中销毁该对话框：

CsimpleDlgAppUi::~CsimpleDlgAppUi()

{

if(iAppDialog)

{

RemoveFromStack(iAppDialog);

delete iAppDialog;

}
}