BREW编程经验——Dialog机制的使用方式.doc

中兴通讯研发过程成功案例内部公开BREW编程经验Dialog机制的使用手机事业部软件二部 范忠锋2005年09月【摘要】在BREW内部机制的研究一文中，已经就Dialog的事件传递方式做了描述，但这种默认的方式来处理事件，往往会使编程人员迷失在复杂的事件流程中，程序的缺陷数上升，不易维护。本文归纳总结P600大项目中部分开发人员对Dialog的几种使用Dialog的方式做一个总结，希望对今后仍然希望使用Dialog机制的软件设计人员有一定的提示。【关键词】BREW应用、Dialog机制一、问题的提出在BREW内部机制的研究一文中，对Dialog的默认的事件传递流程已经做了详细的描述，但在实际开发中，我们发现，如果采用这种默认方式设计模块，则存在如下弊端：1 在模块设计中存在困难。对事业的处理的设计很混乱。2 在代码编写中需要额外的开销。需要在应用中处理事件时，再次判断程序状态，而不能使用Dialog自身的处理过程来保持状态。3 代码维护过程存在困难。如果在代码维护中出现缺陷，不容易定位；即使定位后，不太容易修改；如果代码维护人员不是当初的开发人员，则很难上手，需要一段比较长的事件来理解代码逻辑。为了解决以上问题，我们整理了一下的编码建议。二、解决思路Dialog的事件的缺省流程BREW的Dialog机制的默认事件流程有如下限定：1 使用BREW应用的Dialog堆栈来管理Dialog，不再单独实现Diaog堆栈的管理。2 使用IDIALOG_SetEventHandler将用户定义的Dialog事件处理函数关联到对应的Dialog上。3 在资源文件中，定义了每个Dialog所包含的控件。处理如图1：图 缺省的Dialog事件流程图改进1：由Dialog来加载控件基于以下理由，我们不再使用资源文件来固定的产生代码中使用的控件：1 有些界面的控件数是不确定的；2 很多界面的控件数目较多，不能在一屏显示完全，需要翻页显示，但Dialog不支持虚拟屏幕的控件拜访。模块设计人员需要在Dialog的处理函数中自己来控制屏幕滚动，缺省的控件创建方式已经没有必要。3 利于资源的分离。由于资源文件中的控件只能使用本资源中的图片和文字，因此无法支持多语言的模块开发。4 资源文件中定义的控件，在创建Dialog时载入，没有源代码。经过试验，控件切换的顺序是不可控的。修改后，的流程如图2。该流程描述有如下限定：1 使用BREW应用的Dialog堆栈来管理Dialog，不再单独实现Diaog堆栈的管理。2 使用IDIALOG_SetEventHandler将用户定义的Dialog事件处理函数关联到对应的Dialog上。3 不在资源文件中定义Dialog所包含的控件。图 改进控件的使用后的事件流程图该事件流程的该经，确实使得代码有一定的复杂性，但使得整个事件流程是可控的。另外，这个过程还需要有一些公共过程的支撑。以菜单控件为例，现在P600系列中的使用统一的数据定义方式来定义菜单结构，然后通过BuildMenu的过程在构建菜单。改进2：让Dialog接收到所有的事件改进后的流程如图3。该流程描述有如下限定：1 使用BREW应用的Dialog堆栈来管理Dialog，不再单独实现Diaog堆栈的管理。2 不使用IDIALOG_SetEventHandler将关联用户实现的事件处理到Dialog上。但仍然使用数组记录每个Dialog的对应处理函数，在应用收到事件后，优先将事件分发给当前激活的Dialog的事件处理函数。3 不在资源文件中定义Dialog所包含的控件。这样的该经是基于以下理由是：集中每个界面的事件处理。避免了以前一个处理状态下的事件，有些在Dialog处理函数中处理，有些在应用中处理。每个Dialog真正的和状态对应起来。由于设计思路的清晰，使得后续代码的维护很有好处。图 改进Dialog事件处理后的流程图三、实践情况改进1的方案在P600系列机型的实现过程中，已经成为标准过程。改进2的方案在P600系列机型的部分模块中运用。四、效果评价总的来说，改进2的实现方案相对以前的方案来说，有如下优点：1 设计思路清晰；2 模块实现时，所有事件的流程都是受控的；3 代码更加容易维护，特别是维护工作移交时。五、推广建议建议在后续开发中，如果仍然需要选用D