Symbian应用程序常用架构

原创 2007年09月20日 13:53:00
所谓“应用程序架构”是指应用程序框架类的集合 基于所需的UI设计,应用程序可以具有稍微不同的架构,但是每种架构都有一些公共部分,称为“核心应用程序类”
一、先看一下基础部分,具体架构在第二部分介绍
(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()。
f、   NewL()具体去创建
g、 矿见获取AppUi类的指针,CreateAppUiL()。
h、 由new (Eleave)CappUi()具体创建。
这样一个最简短直观的框架就创建完毕。
(3)重要的AppUi方法:
AppUi提供了许多方法,框架可以调用这些方法通知每个应用程序各种事件。
l         HandKeyEvent()用于处理用户按键
l         HandleForegroundEventL()当应用程序切换到前台或从前台切换到后台时调用该函数,默认的实现可以处理键盘焦点的改变。
l         HandleSystemEventL()传递由窗口服务器生成的事件
l         HandleApplicationSpecificEventL()可以自己定义的自定义事件的通知。默认的实现可以处理颜色方案改变的通知。
l         HandleCommandL()用于处理用户选择的菜单项
(4)设计应用程序UI
关于术语“视图(view)”:
l         “视图”是概念性的术语,含义是“数据模型在屏幕上的表示”,实际上由一个或多个从CcoeControl派生而来的UI控件实现视图,这些控件按层次结构进行组织。父控件通常被称为容器(Container),除了用于实现视图的父控件,这种控件被称为对话框(Dialog)
l         在Avkon视图切换架构中,术语“Avkon视图”指的是系统范围内的View服务器注册的类,它控制视图的实例化和析构。
二、常见的symbian应用程序架构:
每种架构都提供了设计应用程序UI的不同方法――所有的架构都提供了提交“视图”或应用程序数据可视化表示的方法,同时提供了一种用户用来与架构进行交互的机制。
先简单认识一下:基于对话框的架构和传统的基于Symbian OS的架构虽不相同,但和Avkon视图切换架构相比,这两种架构彼此更为类似。原因是:
l         它们的特征是它们用于生成视图的UI控件类型。
l         架构上几乎相同。也就是说,在这两种设计中,AppUi类简单地“拥有”视图控件,因此负责直接管理它们。
而Avkon视图切换架构从根本上不同于这两种方法,它的视图切换由系统范围地View服务器来完成。
(1)       基于控件的传统Symbian OS控件
这些控件总是从CcoeControl直接继承,用于表示从CcoeControl直接继承的试图类的标准术语是“容器”。
关于“CcoeControl”:
可以将CcoeControl认为是一个空的帐篷。通过继承这个类,可以创建各种各样的自定义控件,自定义控件的功能和复杂性只受到程序员能力和想象力的限制。这种灵活性的唯一不利之处是,控件确实类似于一个空帐篷,因为需要进行许多编码工作来提供重要的功能。
在处理视图切换方面,AppUi负责处理用户发出的视图切换请求。随后,AppUi最终的行为类似于一个巨大的开关,用于根据用户或系统的输入来激活或禁止容器。
注意:Container类从CcoeControl派生而来,CcoeControl是所有控件的基类。
在自己的容器类中必须实现从CcoeControl中的四个方法,框架将调用所有这些方法:
l         SizeChanged()允许控件响应控件大小的改变
l         Draw()绘制控件
l         CountComponentControls()返回控件拥有的控件数量
l         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;
}
}
 
(3)       Avkon视图切换架构
比前两种都复杂,引入另一个类作为AppUi和容器之间的媒介。另外,AppUi类从CAknViewAppUi继承,而不是继承于CaknAppUi。
前两个架构,AppUi直接负责处理视图切换,它必须管理视图提交控件的实例化、删除和显示。但是,基于CaknView的类在这方面可以很明显地减少AppUi地任务。
AppUi仍然处理视图切换的请求,但现在,并不是删除旧的容器并实例化新的容器,AppUi只需要调用它的其中一个特殊视图激活函数,如ActiveViewL()。这些特殊的CaknViewAppUi函数向View服务器提交一个激活请求,然后通过基于CaknView的相关类中的激活/禁止成员函数,View服务器显式地协调当前视图地禁止和所请求视图的激活。
 
这种架构所需的一般特性如下:
l         必须设计应用程序,使每个CAknView派生的Avkon视图拥有一个容器,然后AppUi拥有每个Avkon视图。
l         必须从CaknViewAppUi派生应用程序的AppUi,而不是从CAknView派生,这是因为前者提供了注册、激活和禁止Avkon视图的方法。
l         必须在View服务器中注册所有的Avkon视图。
l         Avkon视图具有激活/禁止成员函数,View服务器可以直接调用这些函数。必须重写这些函数,提供从属容器的正确处理。
View服务器最主要的原则:确定在任意给定时刻,每个应用程序中只有一个Avkon视图被激活。Avkon视图通过两个UIDView服务器唯一性的标志自己:一个UID用于标志拥有该视图的应用程序,另一个UID用于在该应用程序中唯一标志该视图。
对于每个基于CAknView的类,需要实现的激活/禁止函数是:DoActiveL()DoDeactivate(),这些函数负责实例化和显示或者删除Avkon视图拥有的UI控件。
View服务器将主动调用DeactivateView(),从而强制遵循每个应用程序中只有一个激活视图的规则。
 
如何使用Avkon视图切换架构:
l         使用这种架构时,必须结合使用CaknViewAppUi和CAknView类。每个Avkon类都从CAknView派生而来,并且必须包含一个Id()函数,从而系统可以标志这个类。它也必须实现DoActivateL()和DoDeactivateL()函数。此外,它还必须实现HandleForegroundEventL()、HandleCommandL()和HandleStatusPaneSizeChange()函数,用于处理各种事件。
l         用户请求激活视图时,View服务器将调用DoActivateL()。该函数的目的是实例化并显示提交视图的控件。
注意:在DoDeactivateL()之前可以多次调用DoActivateL()。
l         将要禁止Avkon视图时,则会调用DoDeactivateL(),该函数负责销毁它的控件。当应用程序退出时,或者激活相同应用程序的另一个视图时,将禁止视图。该函数绝对不能异常退出。
l         只有在激活Avkon视图时才会调用HandleForegroundEventL(),即在调用DoActivateL()和DoDeactivateL()之间。当视图到达前台时,接收HandleForegroundEventLEtrue,当从前台移除视图时,将接收HandleForegroundEventLEfalse。程序员可能希望使用这种方法来设置焦点或控制屏幕更新。
视图菜单生成一条命令时,调用HandleCommandL(),因为状态面板改变而使客户矩形大小改变时,则调用HandleStatusPaneSizeChange()
 
为了让Avkon视图定义它自己的软键和菜单资源,可以在资源文件(.rss)中创建一个AVKON_VIEW资源,然后将资源ID传递到视图的BaseConstructL()函数中。
通常在AppUi对象的ConstructL()方法中构造应用程序中的所有Avkon视图。使用AddViewL()在View服务器中注册这些Avkon视图,最终通过设置默认的视图来激活初始视图,使用方法SetDefaultViewL()
注意:不是由Avkon视图处理的命令被传递到AppUi,AppUiHandleCommandL()方法里,只进行视图间切换的命令。本地视图切换或者是应用程序拥有的视图切换,这些工作都通过引用目标Avkon视图的UID来执行。
为了执行外部视图切换,则需要调用CcoeAppUi::ActivateViewL()函数,提供一个包含目标应用程序UID和目标视图UID的TVWsViewId。如:
const Tuid KphoneBookUid={0x101f4cce} ;// from PbkUID.h
const Tuid kphoneBookContactViewUid={1};
ActivateViewL(TvwsViewId(KphoneBookUid,KPhoneBookContactViewUid));
注意:如果自己的程序中的某部分视图能够被其他程序使用,那么我们必须通过导出为头文件来发布应用程序UID和视图UID。
 
三、选择适当的应用程序架构
(1)使用Avkon视图切换架构
大多数情况下,这种架构是最佳的架构,但它也具有局限性,如:视图切换方案没有任何内置的方法来保存视图切换的上下文。也就是说,没有提供用于定位到前面激活视图的机制,没有类似于浏览器上后退功能的按钮的功能。但是DoActivateL()确实收到了前面激活视图的标志符,因此可以自定义后退按钮功能。
(2)使用基于控件的传统symbian OS架构:
l         程序可能只需要一个视图
l         应用程序具有UI控件,必须保证这些UI控件的私有性。
l         如果是将应用程序从不同的symbian OS平台移植到series 60。
(3)使用基于对话框的架构
可以在资源文件中定义控件,让对话框自动处理布局和绘画,这比实现自定义绘画行为更为容易。仅当应用程序的视图之间没有任何循环导航路径时,才可以对这种应用程序使用“基于对话框”的方法。
 

相关文章推荐

Symbian/Android/iOS/WM应用程序开发感受对比

前后参与过Symbian/Android/iOS/WM的程序开发,在这里列一下各个平台程序开发感受对比。Symbian:1. Symbian开发的配套文档比较差。虽然也有Symbian SDK配套的文...

Symbian 应用程序中的UID

转自Liquns BLOG Symbian UID Classificationsymbian 应用程序主要由UID来标识,在V9.0以后,UID可以分为两类:受保护(protected)和未受保护(...

Symbian应用程序更换系统控件背景

很多开发者都会为界面、控件而发愁。其中,对系统控件的运用是开发者纠结最多的问题。每个平台都有自己的系统控件,系统控件是由系统开发商开发的,各个方面都很成熟,节省开发时间。但也有很严重的问题,如:界面陈...

Symbian OS:MVC 设计模式在 SymbianOS 应用程序中的应用分析

简介          MVC设计模式是在20世纪80年代发明的一种软件设计模式,至今已被广泛使用,后来被推荐为 Sun 公司 J2EE 平台的设计模式。     随着Web应用的商业逻辑包含...

android与symbian应用程序框架

  • 2013年05月20日 16:24
  • 179KB
  • 下载

Series 60应用程序开发(symbian).rar

  • 2007年09月25日 23:37
  • 3.26MB
  • 下载

应用程序架构本质,第 1 部分: 关于需求建模您所需要了解的所有内容

确定需求可能是非常困难的。通常,现有应用程序的操作包含了业务流程的各种需求,使其成为了设计或者实现更改的等价物。例如,“我们需要向表 XYZ 中添加一列以存储客户代码”,这一需求并没有说明为什么需要这...

Series 60应用程序开发(symbian).pdf

  • 2009年02月16日 14:30
  • 4.7MB
  • 下载

浅谈单片机应用程序架构(转载)

本人经过摸索实验,并总结,大致应用程序的架构有三种: 1. 简单的前后台顺序执行程序,这类写法是大多数人使用的方法,不需用思考程序的具体架构,直接通过执行顺序编写应用程序即可。 2. 时间片轮询法,此...
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:Symbian应用程序常用架构
举报原因:
原因补充:

(最多只允许输入30个字)