手机应用开发集成开发环境应用程序设计初步.ppt

上传人:本田雅阁 文档编号:3180836 上传时间:2019-07-21 格式:PPT 页数:41 大小:309.51KB
返回 下载 相关 举报
手机应用开发集成开发环境应用程序设计初步.ppt_第1页
第1页 / 共41页
手机应用开发集成开发环境应用程序设计初步.ppt_第2页
第2页 / 共41页
手机应用开发集成开发环境应用程序设计初步.ppt_第3页
第3页 / 共41页
手机应用开发集成开发环境应用程序设计初步.ppt_第4页
第4页 / 共41页
手机应用开发集成开发环境应用程序设计初步.ppt_第5页
第5页 / 共41页
点击查看更多>>
资源描述

《手机应用开发集成开发环境应用程序设计初步.ppt》由会员分享,可在线阅读,更多相关《手机应用开发集成开发环境应用程序设计初步.ppt(41页珍藏版)》请在三一文库上搜索。

1、手机应用开发 集成开发环境 应用程序设计初步,王旭,开发环境介绍1,SDK 安装目录类似E:Symbian7.0sSeries60_v21_C 除了盘符,尽量不要更改目录名称。 演示不同版本,不同类别的SDK安装目录情况,开发环境2,VC环境演示 Carbide菜单项说明 编辑界面 运行界面 程序精灵介绍,应用程序设计,OS的图形支撑架构 应用程序Framework的介绍 应用程序结构 应用程序初始化过程 重要的AppUi方法 设计应用程序UI 分离UI与引擎 良好的程序行为,OS的图形支撑架构,图形架构介绍1,GDI定义绘图基本元素和与设备无关需要的所有支持,BITGDI处理屏幕上窗口与屏幕

2、外位图之间的位图传送,字体和位图服务器管理字体和位图,窗口服务器支持用户交互,根据面向使用者友好的原则管理屏幕、指针、键盘等导航设备,提供图形设备的共享。CONE则在底层提供了各种设备交互的控制。,图形架构介绍2,UI名称变迁 Eikon-Aikon-Uikon-Ckon、Avkon、Qikon、Pikon CONE:控件环境(CONtrol Environment)的缩写,这个组件里的类提供了用户交互处理和创建用户图形接口的框架 APPARC:应用程序架构 APPlication ARChitecture,这个组件里的类提供了基本的应用程序框架和通过文件服务器维护应用数据的框架,应用程序Fr

3、amework图示,应用程序Framework描述,底层是两个基本的系统组件CONE和APPARC 第二层是Uikon组件,这是个多功能的通用设备无关的框架实现,它是一个面向所有的Symbian平台提供通用UI库的层次 第三层是Avkon,它提供了核心的S60界面功能,如菜单支持,这个层次是纯粹为了符合S60的规范实现,我们的程序应该总是从这个层次开始继承。 第四层是应用层,它的功能是在S60的基类上实现自己的应用需求,应用程序Framework描述2,第一个层次的多数类都仅仅是定义了调用Framework的接口API,第二层增加了一个通用的Symbian系统实现,以共享的供给其他的各种UI系

4、统使用,第三层增加了按照S60规范调用框架的实现,第四层才是客户的应用实现。,应用程序ARChitecture描述,应用程序架构是指组成应用程序所用到的应用框架类的集合。应用程序可以基于各种不同的UI需求来采用不同的系统架构。 核心应用程序类提供了用户接口展示信息,以及与使用者进行交互,提供了各种用户初始化事件的响应方法(用户的键盘动作),提供了各种系统初始化事件的响应方法(窗口重绘事件),提供了保存和恢复应用数据的方法,提供了framework可调用的应用唯一标识,提供了应用程序关于自己的描述信息(图标,名称等),应用程序架构元素,应用框架类提供的功能封装进了以下四个类中: 应用程序类 文档

5、类 应用程序UI类 应用程序视图类,应用程序ARChitecture元素说明,应用程序类:是60系列应用程序框架的启动对象,它定义应用程序的属性。用于创建文档,在最简单的情况下,必须定义的唯一属性是应用程序的唯一性标识符,就是UID 文档类;用来存储应用程序的持久性数据,如果应用程序是基于文件的,则文档类负责恢复和保存应用程序的数据,如果应用程序不是基于文件,也必须有一个文档类的实例,不过它除了创建应用程序UI以外不会完成更多的事情,这种情况下,可以说使用文档类的唯一理由是被用来加载AppUi类 。 应用程序UI类:这是个完全不可见的类,它创建一个应用程序视图,用来处理绘图和基于屏幕的交互,它

6、提供了处理菜单项产生的命令的手段 应用程序视图类:这是个具体控件,它用于在屏幕上显示应用数据,并允许用户与之交互,最简单的情况下应用视图只提供在屏幕上绘图的途径,应用程序ARChitecture说明,应用程序ARChitecture说明,在S60中,应用架构中的四个类都是从Avkon中的基类集成而来的,这些基类又从Uikon派生而来。 如果是产生用于其他UI系统的应用程序,继承的路线会有所不同,如UIQ系统则从Qikon继承,应用初始化过程,应用程序初始化说明,图示说明了构建一个最小的S60应用程序所需要被创建的方法 所有的S60UI应用程序都必须实现一个全局函数E32DLL(),进入应用程序

7、初始化的第一步,该函数被Framework调用,这个函数叫做DLL入口点,任何的S60应用程序都是一个多态DLL。 初始化的第二步是Framework会调用NewApplication(),这是GUI应用程序DLL唯一exported的函数,它创建了一个应用类的实例,并返回一个指针。 Framework调用AppDllUid()会返回一个应用程序的UID,这个必须返回在MMP文件定义的标识,被用来确定是否该应用的实例在运行。 应用启动过程还允许Framework获得新创建的Document和AppUi类的指针。注意,为了能够处理应用程序需要的文件,Document也获得了应用程序实例的指针,重

8、要的AppUi方法,HandleKeyEventL() HandleForegroundEventL() HandleSystemEventL() HandleApplicationSpecificEventL() HandleCommandL(),重要的AppUi方法,HandleKeyEventL的作用是处理用户的按键事件 HandleForegroundEventL当应用程序发生切换被放到前台或者被移入后台运行的时候被调用 HandleSystemEventL用于传递窗口服务器产生的事件 HandleApplicationSpecificEventL可以完成自定义的消息通知,默认的实现是

9、处理颜色模式改变的通知 HandleCommandL()提供处理用户选定菜单项的事件处理,设计应用程序UI,Traditional Symbian os control-based Dialog-based Avkon view-Switching,传统的controlbased结构,传统的Symbian OS应用程序是用继承自CCoeControl的自定义视图控件来编写的。这些自定义视图控件被放置于应用程序控件堆栈中,作为应用程序的各种视图。可以根据应用程序提供相应功能的需要或创建或清除、或显示或隐藏这些控件。 这种方法非常适用于Avkon中的各种应用程序。因为许多现有的Avkon应用程序都

10、是基于以传统方法编写的用户界面,所以遵循与Avkon相同的风格会比较恰当。 这是一种构建应用程序用户界面的最灵活的方法。就视图结构来说其主要缺点是:它没有使用系统提供的视图管理系统。同时,这也是它的主要优点,因为View Architecture(视图结构)视图管理系统存在很多限制。,dialogbased结构,使用对话框结构就意味:应用程序中使用的显示视图都是从对话框类继承,而且主视图就是一个运行中的对话框。对话框结构的应用也可以做的相当复杂,我没可以使用用多页对话框给出一个符合S60风格的用户界面视图。 使用对话框的一个好处是可以在资源文件中修改内容和布局,而不需要重写任何C+代码。 如果

11、不仔细编写代码,嵌套的对话框会占用相当多的堆栈空间。 Avkon具有内置于多页面对话框中的自动状态窗格处理功能。这与传统结构和视图结构都不同,在其他两种情况下,用户必须通过应用代码自行管理窗格切换的状态。,View的说明,从view本身的概念看,可以说view就是是模型数据在屏幕上的展现,它并不是一个特定的结构方法,一个view实际上是一个或者多个UI控件按照一定层次进行展现的结果 “Avkon View”其实指的是一个在服务端注册的类,它能够控制view的实例初始化和析构,但是它实际上不会真实的控制自己的行为,可以形容为它拥有一个容器控件去创建一个可视区域,viewbase结构,从Symbi

12、an OS 6.0版开始,Avkon 已经修改了视图结构,变得更适用于60系列的各种应用。视图结构应用允许应用程序中的视图在系统中注册,从而被其他应用从外部进行调用。 视图结构即可以用于不提供外部应用使用的应用,也可以用于提供外部调用视图的应用。 使用视图结构的应用程序运行中只有一个视图是处于活动状态,其他的视图处于非激活状态。 ,当应用程序中的另一个视图被激活时,当前视图就被置于非活动状态。如果一个视图处于非活动状态,该试图中的任何菜单、对话框,或内嵌的活动应用都会被关闭。 如果应用完全控制自己的视图切换,它就可以让用户决定如何处理(如保存或丢弃数据)视图切换。如果允许外部程序使用自己的视图

13、,应用中的视图就必须能自己保存数据状态以便让用户能在以后恢复这些数据。 注意,从一个应用程序切换出来,然后又返回到该程序(没有用到视图激活功能)是不会在应用程序内造成视图的激活及去激活的 。,选择合适的应用程序结构1,是否已经有可以提供导航功能和显示特性的用户界面? 如果存在这样的程序,并且编制良好,那么针对自己的目标需要修改源程序可能是最便利的方式。这意味着将使用现成的结构,这种结构很可能就是传统的Symbian OS控件结构。可能需要对解读现有程序代码的运行机制花费一些时间。然而,大部分的引擎交互和出错处理代码都是现成可用的,使得整个应用程序用户界面的开发工作变得比较简单。 导航结构是否构

14、成循环? 如果该应用程序各视图之间的导航路线不形成一个循环结构,也许就比较适合使用对话框结构。简单情况下,如果可以在各个视图间直接导航,就可以把这些视图编制成同一个对话框中的多个不同页面,选择合适的应用程序结构2,应用程序的所有屏幕都类似对话框吗? 如果应用程序的每个屏幕都可以用对话框布局来编制,那么就考虑为这个屏幕使用对话框。注意:如果某个屏幕只包含一个选择列表,那么就将其编制成仅含有一个选择列表的对话框。 该应用程序要求在顶层处理不同种类数据的多个视图吗? 如果确定需要处理多种数据的多个视图,就不应该对话框结构。相应的选择使用传统结构或视图结构,因为它们较擅长与引擎通信。,选择合适的应用程

15、序结构3,外部应用程序是否需要切换该应用的不同视图? 向外部应用提供多种不同视图的应用主要以视图结构编制。如果正在策划应用程序用户界面,请考虑视图结构。否则就查一下是否可以改编现有代码。注意,如果需要在外部进程嵌入运行,该显示页面应该在一个可以被该外部文件链接的DLL文件中实现。 要求所有应用视图退出时都不会丢失用户数据吗? 视图结构的应用必须能处理自己的视图因外部应用而导致的意外去激活情况。这种问题仅出现于当外部应用能使用这些视图时。如果应用视图不能被自动去激活,就考虑传统结构或对话框结构。另一种选择是:把视图结构作为消息传递系统使用,让应用程序用户界面以更传统的风格只从事视图管理。,选择合

16、适的应用程序结构4,外部应用程序需要与该应用中的数据进行复杂的交互吗? 如果外部应用程序需要与该应用的数据进行复杂的交互,就需要有一个客户端/服务器系统。这样需要提供其他方法切换视图并传递数据,使用视图结构的就不一定会方便了(注意,客户端/服务器系统可以与这三种结构中的任何一种一起工作) 应用中只存在单一的综合主视图 ? 如果不是,尽量使用传统方法,因为对话框结构不能处理这种布局,也没有必要使用视图结构。,分离UI和引擎1,通过程序方法确保应用用户接口被清晰的与底层功能分离,可以保证非UI部分的应用代码具有充分的移植能力,这是为什么我们需要把UI和引擎看作两个单独应用控件的原因。 UI代码展现

17、的是解释应用数据和允许用户的操作,UI部分通常提供了进入,编辑和删除数据的能力,对任何UI代码来说实际上实现了两个接口:处理用户输入、传送用户请求到引擎。,UI和引擎的分离2,引擎由应用数据,管理处理数据的算法,实现持久化的程序组成。 所有的应用都应该通过这种方法清晰的分解。无论在CLASS还是组件层次上,开发者都应该清晰的分离这两个部分。在应用组件的层次上,可以把引擎封装为单独的DLL,或者封装为单独的exe文件,这样可以服务于多个不同的应用。,UI和引擎分离的原因,良好程序设计的基本要求就包括避免组件之间的无谓依赖 可以最大化提高组件代码重用 单独分离引擎代码可以提高系统应用的灵活性。特别

18、是如果使用单独的DLL来封装引擎代码,就可以通过它自己的API被其他任何需要的UI层代码使用,UI和引擎分离影响,带来额外的开发工作,增加了开发编码的复杂性,增加了编码时间 便于进行应用的测试工作 可以节约项目后期对系统进行维护的难度,降低维护需要的费用 由于通常的项目只有20是UI代码,大量引擎代码不需要修改对目标运行平台的迁移带来很大的便利。,良好的应用程序行为,采取怀疑一切的态度和批判的眼光进行开发工作 处理窗口服务器产生的事件 总是优雅的退出 保存数据前检查磁盘的空间大小 其他的部分,采取怀疑一切的态度和批判的眼光进行开发工作,进行设计和编写程序的时候,你需要带着怀疑的态度。总是考虑你

19、的应用将在你不期望的环境中,总是在意料之外的时候,总是在非常少见的情况下运转。带着批判的眼光来审视你的所有代码,经常问自己:如果内存不足,我的应用会如何,如果我的应用被放到后台会如何,如果电池突然用光,我的应用会如何,在所有的这些环境下,你都应该将尽可能好的结果留给用户,而且不能影响其他应用程序或者OS的运作。,处理窗口服务器产生的事件,有几种不同的窗口服务器事件,如键盘事件,系统事件,后台事件,他们都需要被恰当的处理。AppUi类有几个函数会被窗口服务器的各种事件调用,你如何重载这些函数是由自己确定的,但是以下的细节提出了一些场景下的处理方法建议。应用程序可能随时获得或者失去焦点,不论失去还

20、是得到焦点,HandleForegroundEventL()方法都会被调用,这个方法会使用一个单实例的Boolean变量保存状态。当应用切换到后台,我们应该建立一个可恢复的状态,挂起进程和保存数据,因为系统的处理能力必须为前台程序服务,应用必须切换用户接口,如果后台程序还在继续运行,则会导致运行性能上的损失,而且后台运行的程序可能在资源不足的情况下被系统自动关闭,如果不保存数据就无法保持一个稳定的可恢复状态。用户输入也必须被正确处理,当用户在界面上执行一个动作,一个事件将会发送给拥有窗口的应用,这种情况可能存在几种不同的事件,好的处理行为不但要考虑你期望的按键,也必须考虑那些你不希望出现的情况

21、。,总是优雅的退出,退出应该是明确的被用户或者系统执行,在很多情况下, HandleCommandL()会接收到一个EEikCmdExit 命令,这个是程序保存应用数据的最后机会,收到这个命令后程序必须尽快释放不再使用的系统资源。有可能在你的应用程序结束之前,整个系统已经关闭,你必须考虑这种突然的关闭对应用数据的影响,考虑当程序突然中断将发生什么,如果是正在后台运行,则不会发生数据丢失的情况,因为HandleForegroundEventL()会在这时候强制保存数据,但是如果用户正在进行操作,突然中断将会导致用户的最新数据丢失,一个改变的方法是每次用户操作结束都进行数据保存,但是这样可能会带来

22、应用性能的影响,所以,设计程序的时候,需要注意运行性能和数据安全是两个有冲突的方面,实际应用需要考虑业务需求在性能和数据安全之间取得一定的平衡。,保存数据前检查磁盘的空间大小,必须合理的执行保存数据动作,当文件系统太满,这将会对系统性能带来负面的影响,因此,所有应用都必须在提交内存数据前检查可用的磁盘资源来防止这样的情况发生,其他需要注意的地方,文件系统当使用文件,应当尽量减少文件打开、读、写操作,一次写入比较大的数据块,一次性写入大块的持久性数据比分多次写入一些小块的数据效率更高,还有记得检查剩余空间的大小 系统看门狗这是S60的一些子系统,它们会在任何时候要求应用程序退出,例如outofm

23、emeory 看门狗 我们需要保留EEikCmdExit 命令来响应系统产生的退出请求,当我们的应用收到这个系统的退出请求,除了保存数据以外,都应该不通过界面确认步骤直接退出,对这紧急退出消息的响应不应当让用户作出选择。 硬编码和魔法数字应当避免所有这样类似的开销。例如常常被硬编码的路径、关键码、计数变量。应当使用AknUtils API CompleteWithAppPath() ,使用头文件来共享常量,使用资源文件来提供用户可见的文本。 定时器不要使用持续的的定时器,比5秒一次更高频率的定时器会频繁从设备底层产生中断,导致耗电量大增。当程序被带入后台运行的时候,记得停止所有的定时器并暂停应用。 活动对象和响应如果应用挂起,或者其他不响应超过10秒,那么view服务器应该关闭他,因此,应该确保你没有使用长时间运行的活动对象,今天的课程结束了 !,其他信息,课程:手机应用开发 联系方法: 邮箱: MSN: ,

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 其他


经营许可证编号:宁ICP备18001539号-1