终端及其进行业务处理的方法

1.一种业务处理装置，位于终端中，其特征在于，所述业务处理装置包括：
分离模块，用于终端的体系结构进行用户交互UI分离，其中，所述分离模块用于按照模型、控制、视图MVC的架构划分对所述终端的体系结构进行UI分离；
应用模块，用于处理UI分离后的应用；
显示模块，用于处理UI分离后的显示；
其中，所述应用模块包括主模型UModel子模块、主控制UController子模块和主视图UView子模块：
所述UModel子模块，用于设置所述应用；
所述UController子模块，用于接收所述应用发起的数据，根据所述应用发起的数据对所述应用做出指示；
所述UView子模块，用于显示所述应用，并将外界经自身输入的数据反馈至所述UModel子模块。
2.根据权利要求1所述的业务处理装置，其特征在于，所述UModel子模块包括按照MVC的架构划分的从模型AModel单元、从控制AController单元和从视图AView单元：
所述AModel单元，用于设置所述应用涉及的数据，以及设置与所述AController单元间的交互方式；
所述AController单元，用于设置所述应用的执行控制和所述应用的业务逻辑，以及设置与所述AModel单元、所述AView单元间的交互；
所述AView单元，用于设置所述应用的显示和输入。
3.根据权利要求1或2所述的业务处理装置，其特征在于，所述UController子模块还用于查找到所述应用发起的数据对应的显示时，判断所述应用发起的数据错误。
4.根据权利要求1或2所述的业务处理装置，其特征在于，所述UView子模块还用于利用Brew平台显示控件系统BUIW的平台控件Widget显示所述应用。
5.根据权利要求1或2所述的业务处理装置，其特征在于，所述显示模块包括：
窗口Form设计组件子模块，用于设计所述应用的图形框架；
BUIW支撑子模块，用于提供生成所述应用所需的Brew平台；
代码生成组件子模块，用于生成所述应用的Form的显示代码。
6.根据权利要求1或2所述的业务处理装置，其特征在于，所述终端包括基于高通平台的二进制运行环境Brew的终端。
7.一种业务处理方法，其特征在于，包括：
终端的分离模块对终端的体系结构进行用户交互UI分离，其中，所述终端的分离模块按照模型、控制、视图MVC的架构划分对所述终端的体系结构进行UI分离；
所述终端的应用模块处理UI分离后的应用；
所述终端的显示模块处理UI分离后的显示；
其中，所述终端的应用模块单独处理UI分离后的应用，包括：所述应用模块被划分为主模型UModel子模块、主控制UController子模块和主视图UView子模块，其中，所述应用模块的UModel子模块设置所述应用，所述应用模块的UController子模块接收所述应用发起的数据，根据所述应用发起的数据对所述应用做出指示，所述应用模块的UView子模块显示所述应用，并将外界经自身输入的数据反馈至所述UModel子模块。
8.根据权利要求7所述的方法，其特征在于，所述应用模块的UModel子模块设置所述应用，包括：
所述UModel子模块包括按照MVC的架构划分的从模型AModel单元、从控制AController单元和从视图AView单元，其中，所述AModel单元设置所述应用涉及的数据，以及设置与所述AController单元间的交互方式；所述AController单元设置所述应用的执行控制和所述应用的业务逻辑，以及设置与所述AModel单元、所述AView单元间的交互；
所述AView单元设置所述应用的显示和输入。

终端及其进行业务处理的方法\n技术领域\n[0001] 本发明涉及通信领域，具体而言，涉及一种终端及其进行业务处理的方法。\n背景技术\n[0002] 高通平台的二进制运行环境Brew是一个基于高通平台的二进制运行环境。可以支持静态和动态应用。开发人员可以基于Brew接口进行手机应用的开发，最后发布的应用运行于Brew平台之上。Brew平台支持参与平台编译的静态应用，也支持动态加载高通平台动态应用文件MOD方式。\n[0003] 从Brew 4.0以后Brew有了新成员高通Brew平台显示控件系统BUIW。BUIW在一定程度上规范了原来Brew平台手机应用的开发。BUIW类似于给开发人员提供了一个Brew平台上的图形处理框架GUI架构。有了BUIW以后让Brew平台的应用开发难度有所下降，开发人员的分工更加清晰。高通Brew平台的类似窗口的控件Form、高通Brew平台控件Widget的概念进入了大家讨论的范畴，同时也成了大家分工的基本界限。也正是因为分工的细化，让开发人员的工作更加专业，也使最终的产品质量更高。\n[0004] 虽然Brew增加了新秀BUIW提供了更好的应用开发支持，但是BUIW也只是一个非常基本的类似GUI的框架，对于用户如何进行一个应用的开发没有任何指导，也就是说BUIW只是让显示部分变的清晰而应用部分还是非常混乱。Brew的结构复杂程度还是非常的高，导致应用及显示实现部分的代码质量不高，并且代码重构的难度非常的大。这种情况下导致Brew应用的后期维护难度非常的大，很多情况都是牵一发而动全身，浪费大量的资源。\n[0005] 针对相关技术中BUIW中应用及显示实现部分的代码质量不高，并且代码重构的难度非常的大，这种情况下导致Brew应用的后期维护难度非常的大，很多情况都是牵一发而动全身，浪费大量的资源的问题，目前尚未提出有效的解决方案。\n发明内容\n[0006] 本发明旨在提供一种终端及其进行业务处理的方法，以解决BUIW中应用及显示实现部分的代码质量不高，并且代码重构的难度非常的大，这种情况下导致Brew应用的后期维护难度非常的大，很多情况都是牵一发而动全身，浪费大量的资源的问题。\n[0007] 根据本发明的一个方面，提供了一种终端，包括：分离模块，用于对终端的体系结构进行用户交互UI分离；应用模块，用于处理UI分离后的应用；显示模块，用于处理UI分离后的显示。\n[0008] 较优的，所述分离模块还用于按照模型、控制、视图MVC的架构划分对所述终端的体系结构进行UI分离。\n[0009] 较优的，所述应用模块包括主模型UModel子模块、主控制UController子模块和主视图UView子模块：所述UModel子模块，用于设置所述应用；所述UController子模块，用于接收所述应用发起的数据，根据所述应用发起的数据对所述应用做出指示；所述UView子模块，用于显示所述应用，并将外界经自身输入的数据反馈至所述UModel子模块。\n[0010] 较优的，所述UModel子模块包括按照MVC的架构划分的从模型AModel单元、从控制AController单元和从视图AView单元：所述AModel单元，用于设置所述应用涉及的数据，以及设置与所述AController单元间的交互方式；所述AController单元，用于设置所述应用的执行控制和所述应用的业务逻辑，以及设置与所述AModel单元、所述AView单元间的交互；所述AView单元，用于设置所述应用的显示和输入。\n[0011] 较优的，所述UController子模块还用于查找到所述应用发起的数据对应的显示时，判断所述应用发起的数据错误。\n[0012] 较优的，所述UView子模块还用于利用Brew平台显示控件系统BUIW的平台控件Widget显示所述应用。\n[0013] 较优的，所述显示模块包括：窗口Form设计组件子模块，用于设计所述应用的图形框架；BUIW支撑子模块，用于提供生成所述应用所需的Brew平台；代码生成组件子模块，用于生成所述应用的Form的显示代码。\n[0014] 较优的，所述终端包括基于高通平台的二进制运行环境Brew的终端。\n[0015] 根据本发明的另一方面，提供了一种利用上述终端进行业务处理的方法，包括：终端的分离模块对终端的体系结构进行用户交互UI分离；所述终端的应用模块处理UI分离后的应用；所述终端的显示模块处理UI分离后的显示。\n[0016] 较优的，所述终端的分离模块对基于高通平台的二进制运行环境Brew的终端的体系结构进行用户交互UI分离，包括：所述终端的分离模块按照模型、控制、视图MVC的架构划分对所述终端的体系结构进行UI分离。\n[0017] 较优的，所述终端的应用模块单独处理UI分离后的应用，包括：所述应用模块被划分为主模型UModel子模块、主控制UController子模块和主视图UView子模块，其中，所述应用模块的UModel子模块设置所述应用，所述应用模块的UController子模块接收所述应用发起的数据，根据所述应用发起的数据对所述应用做出指示，所述应用模块的UView子模块显示所述应用，并将外界经自身输入的数据反馈至所述UModel子模块。\n[0018] 较优的，所述应用模块的UModel子模块设置所述应用，包括：所述UModel子模块包括按照MVC的架构划分的从模型AModel单元、从控制AController单元和从视图AView单元，其中，所述AModel单元设置所述应用涉及的数据，以及设置与所述AController单元间的交互方式；所述AController单元设置所述应用的执行控制和所述应用的业务逻辑，以及设置与所述AModel单元、所述AView单元间的交互；所述AView单元设置所述应用的显示和输入。\n[0019] 在本发明实施例中，终端的分离模块对终端的体系结构进行UI分离，终端的应用模块处理UI分离后的应用，终端的显示模块处理UI分离后的显示，将应用部分与显示部分进行分离，并分别处理分离后的应用和显示，避免两者混合在一起时出现的显示部分变的清晰而应用部分还是非常混乱情况，提高应用及显示实现部分的代码质量，若需要进行代码重构也只需要单独构建应用或显示部分的代码，不需要全部重建，在后期维护过程中能够节省大量的资源。\n附图说明\n[0020] 此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：\n[0021] 图1是根据本发明实施例的终端的结构示意图；\n[0022] 图2是根据本发明实施例的终端进行业务处理的流程图；\n[0023] 图3是根据本发明实施例的终端进行了UI分离的终端的体系结构的示意图；\n[0024] 图4是根据本发明实施例的采用MVC的架构划分的终端的体系结构的示意图；\n[0025] 图5是根据本发明实施例的对UModel子模块按照MVC的架构进行划分的结构示意图；\n[0026] 图6是根据本发明实施例的对终端及其内部结构均按照MVC的架构进行划分的结构示意图；\n[0027] 图7是根据本发明实施例的显示模块的结构示意图；\n[0028] 图8是根据本发明实施例的Form设计组件的结构示意图。\n具体实施方式\n[0029] 下面将参考附图并结合实施例，来详细说明本发明。\n[0030] 下文中将参考附图并结合实施例来详细说明本发明。需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。\n[0031] 相关技术中提到，虽然Brew增加了新秀BUIW提供了更好的应用开发支持，但是BUIW也只是一个非常基本的类似GUI的框架，对于用户如何进行一个应用的开发没有任何指导，也就是说BUIW只是让显示部分变的清晰而应用部分还是非常混乱。Brew的结构复杂程度还是非常的高，导致应用及显示实现部分的代码质量不高，并且代码重构的难度非常的大。这种情况下导致Brew应用的后期维护难度非常的大，很多情况都是牵一发而动全身，浪费大量的资源。\n[0032] 为解决上述技术问题，本发明实施例提供了一种终端，该终端通常是采用基于高通平台的二进制运行环境Brew的终端，其结构示意图如图1所示，包括：\n[0033] 分离模块101，用于对终端的体系结构进行用户交互UI分离；\n[0034] 应用模块102，用于处理UI分离后的应用；\n[0035] 显示模块103，用于处理UI分离后的显示。\n[0036] 在本发明实施例中，终端的分离模块对终端的体系结构进行UI分离，终端的应用模块处理UI分离后的应用，终端的显示模块处理UI分离后的显示，将应用部分与显示部分进行分离，并分别处理分离后的应用和显示，避免两者混合在一起时出现的显示部分变的清晰而应用部分还是非常混乱情况，提高应用及显示实现部分的代码质量，若需要进行代码重构也只需要单独构建应用或显示部分的代码，不需要全部重建，在后期维护过程中能够节省大量的资源。\n[0037] 在本发明实施例中，若终端采用如图1所示的结构，则可以按图2所示流程图对于终端涉及业务的业务进行相应处理：\n[0038] 步骤S202、终端的分离模块对基于Brew的终端的体系结构进行UI分离；\n[0039] 步骤S204、终端的应用模块处理UI分离后的应用；\n[0040] 步骤S206、终端的显示模块处理UI分离后的显示。\n[0041] 在一个实施例中，进行了UI分离的终端的体系结构的示意图也可以如图3所示，包括UI控制、基于BUIW的UI显示以及UI定义部分，其中UI定义部分中可以包括数据Model、逻辑Controller、显示View三部分。\n[0042] 实施时，步骤S202中记载了分离模块对基于Brew的终端的体系结构进行UI分离，UI分离的方式可以有多种，例如按不同的用户类型进行划分，按所处网络进行划分，或者按其他的特点或依据进行划分，较优的，本发明实施例提出：分离模块还用于按照MVC(模型、视图、控制)的架构划分对终端的体系结构进行UI分离。\n[0043] 在一个实施例中，采用MVC的架构划分的终端的体系结构的示意图可以如图4所示，应用模块102中包括可以包括主模型UModel子模块401、主控制UController子模块\n402和主视图UView子模块403：\n[0044] UModel子模块401，用于设置应用；\n[0045] UController子模块402，用于接收应用发起的数据，根据应用发起的数据对应用做出指示；\n[0046] UView子模块403，用于显示应用，并将外界经自身输入的数据反馈至UModel子模块401。\n[0047] 在本发明实施例中，设置应用也即是定义应用，对应用的数据、模型等参数进行相关的定义，本文中后续的设置的含义也与定义相同。\n[0048] 在一个实施例中，终端可以利用MVC的架构划分的自身的体系结构，也可以利用MVC的架构对子模块进行划分，例如，可以对UModel子模块按照MVC的架构进行划分，划分后的结构请参见图5：\n[0049] UModel子模块401包括按照MVC的架构划分的从模型AModel单元501、从控制AController单元502和从视图AView单元503：\n[0050] AModel单元501，用于设置应用涉及的数据，以及设置与AController单元502间的交互方式；\n[0051] AController单元502，用于设置应用的执行控制和应用的业务逻辑，以及设置与AModel单元502、AView单元503间的交互；\n[0052] AView单元503，用于设置应用的显示和输入。\n[0053] 本发明实施例中，若对终端及其内部结构均按照MVC的架构进行划分，其结构示意图及具体连接关系如图6所示：\n[0054] 应用的AModel专为数据而设计，可以把应用的数据处理、串行化等功能都整理在AModel来实现。同时AModel只需要定义好与AController的交互而不需要关心数据的使用。应用的AController只需要关心与应用相关的消息、平台交互的消息，以及定义好与AModel、AView的交互。也就是说应用的AController只管理好消息和做好AModel、AView的桥梁，不需要关心数据如何保存、如何显示。应用的AView负责定义数据如何显示和输入获取，不需要管数据如何处理。应用定义完毕就放在UI分离的体系下进行显示。在UI分离的体系下面也是MVC的架构，应用的定义就是UModel了。UController，负责接收应用的AView定义的数据显示指导，然后判断做出正确的显示。UController查找对应请求的显示，如果找到显示的则错误。UView，就是利用BUIW的Widget进行显示，同时具有输入反馈能力。就是说交互的动作可以反馈给UModel。\n[0055] 综上可知，UI分离体系就是把复杂的业务逻辑和显示分开处理。简单来说就是本发明实施例将MVC的架构应用于应用和显示，将原来混在一起的应用实现进行分割。按照MVC的思想把应用的数据、逻辑、显示进行有效分割，让整体实现简化。也就是原来揉在一起的代码进行了Model、View、Controller的划分，各个部分有交互同时也具备独立性，让问题定位、修改变的容易，代码重构变成了可能。\n[0056] 原来的Brew应用开发的代码复杂程度非常高，大部分处理都在应用的事件处理函数里面，有可能一个事件处理函数就上万行。可以说开发人员在开发的时候就是一个面，毫无层次结构。\n[0057] 本发明采用MVC架构进行层次上的划分，可以让应用的事件处理变的可以阅读。\n每一个应用都由Model、View、Controller三个层次组成，后面我们用AModel、AView、AController来表示。AModel包括了应用涉及的所有数据、AView定义应用显示和输入、AController包括应用的执行控制、应用的业务逻辑。对于UI分离的体系结构也是一个MVC的结构，同样包括Model、View、Controller三个层次，后面我们用UModel、UView、UController来表示。UModel就是应用的定义、UView利用BUIW进行显示、UController包括了显示和应用交互的控制。\n[0058] 基于本发明实施例提供的UI分离体系，设计人员可以设计出结构清晰的架构，提高应用及显示实现部分的代码质量，若需要进行代码重构也只需要单独构建应用或显示部分的代码，不需要全部重建，在后期维护过程中能够节省大量的资源。\n[0059] 在一个实施例中，UController子模块402还可以用于查找到应用发起的数据对应的显示时，判断应用发起的数据错误。\n[0060] 在一个实施例中，UView子模块403还可以用于利用BUIW的Widget显示应用。\n[0061] 在一个实施例中，如图7所示，显示模块103可以包括：\n[0062] 窗口Form设计组件子模块701，用于设计应用的图形框架；\n[0063] BUIW支撑子模块702，用于提供生成应用所需的Brew平台；\n[0064] 代码生成组件子模块703，用于生成应用的Form的显示代码。\n[0065] 为实现显示模块的处理，本发明实施例还提出基于UI分离体系的可视化设计工具，可视化设计工具以BUIW为基础，包括Form(BUIW的一个类似窗口的组件)设计组件、代码生成组件。\n[0066] Form设计组件利用基于Java的开源IDE环境Eclipse和一个基于Eclipse的图形设计框架GEF可以实现。本发明实施例将GEF与BUIW进行结合，实现Brew平台的可视化界面设计。GEF的工具定义可以按照BUIW的Form、Widget的定义来实现。同时GEF利用了Draw2D(一个Java环境下的GUI)做基础GUI，Draw2D本身并没有非常明确的控件定义，可以重载绘制方法来满足BUIW的需求。代码生成组件根据当前设计的情况进行代码生成。\n因为设计的基本是UView部分，所以代码生成主要是生成Form的显示代码。如果在设计前已经存在应用的AView的显示定义，那么设计组件会根据定义进行显示方法的生成。如果没有应用的AView的定义，设计组件将生成应用的AView的定义和显示方法。本发明实施例Form设计组件图示参见图8。\n[0067] 综上所述，采用本发明实施例提供的技术方案，在Brew应用的开发设计以及实现都有着积极的效果。从开发设计方面来说，因为是高内聚低耦合，所以降低了设计难度，同时可以提供开发效率，而且一定程度的提高了可靠性。\n[0068] 在具体实施方面，可以将本发明实施例提供的技术方案分为BUIW扩展、MVC代码框架、Form设计组件三个部分进行描述。\n[0069] 首先，BUIW扩展方面，需要利用BUIW实现UI分离体系中View的需求。BUIW给了开发人员一个基本的框架，同时也提供了扩展的基础。为了满足UView的需求，必现对Form进行扩展。一是给Form定义统一的显示接口，二是给Form定义统一的输入获取的接口。\n这样UController可以实现UModel和UView的交互。也就是Form需要增加ShowForm和Getlnput两个方法。可以把Form接口定义为：\n[0070] AEEINTERFACE(ISampleForm){\n[0071] INHERIT_IForm(ISampleForm)；\\n[0072] int(＊ShowForm)(ISampleForm＊po，AECHAR＊inputDef)；\[0073] int(＊Getlnput)(ISampleForm＊po，AEEEvent evt，uint16[0074] wParam，uint32dwParam，AECHAR\n[0075] ＊outputDef)\n[0076] }\n[0077] 当然上面定义只是本发明实施例为阐述而设计的样例，一个Form接口定义可能会更加复杂。\n[0078] 然后，再看一下MVC代码框架。上面已经对UView做了基本的描述，可以说在UView定义统一的接口后就为UController的正常运行提供了保障。为了更好的体现本发明实施例的优势，MVC的代码框架也比较重要。MVC的代码框架要求M、V、C的实现要分开，可以在独立的文件中实现。UModel、UController、UView基本按照Brew的要求进行定义，符合Brew的ClasslD管理机制，可以实现Class的静态、动态加载。前面也有描述UView在具体实现的过程中需要注意增加扩展实现。UController可以考虑是针对UView和AView进行设计，UController根据AView创建和显示UView，同时可以对UView进行管理。这样从代码结构来说UController可以对BUIW的RootForm进行扩展。其中代码方面关键的一个扩展是将原来的HandleEvent机制进行了扩展，在原来的基础上配合实现Getlnput。事件发生需要通过Getlnput获取用户交互输入。AModel定义应用需要的数据，同时支持和AController的交互。从代码结构上面来说必需支持一般的ModelChange、ModelNotify等机制。AController在处理应用的基本事件，同时需要配合UView进行调整。从代码来说事件发生的时候不是调用HandleEvent而是调用Getlnput来进行事件传递。如果UView的交互不改变数据就获取不到输入。AView根据应用的情况定义显示内容。从代码结构上来说可以根据当前应用的数据设计XML模板然后设计代码，也可以通过Form设计组件自动生成。AView和UView通信的内容格式基本定义如下：\n[0079] <？xml version＝″1.0″encoding＝″UTF-8″？>\n[0080]

\n[0081] \n[0082] 1\n[0083] \n[0084] \n[0085] \n[0086] \n[0087] \n[0088] key1\n[0089] \n[0090]

\n[0091] 上面同样是为了阐述本发明实施例而设计的样例。\n[0092] 最后，来看一下Form设计组件。前面也对Form设计组件的功能和基本的设计进行了描述。这里也是建议使用Eclipse实现Form设计组件，因为在Eclipse下面有比较丰富的设计框架。GEF就是比较优秀的可视化设计框架，以Draw2D为基础，整个设计框架速度比较让人满意。本发明实施例旨在将GEF应用于Brew，为Brew提供全新的可视化设计思路。在实际使用GEF的时候需要根据我们平台当前的情况进行GEF工具的定义，同时也可以根据当前BUIW的情况进行可视化设计的约束。Form设计组件还有一个部分就是代码生成，这个对于支持MVC代码框架也比较关键。在设计前已经有了通信定义，设计工具自然不会生成通信交互部分代码。如果没有通信定义，设计工具将生成通信交互代码和XML模板，同时生成对应AModel部分代码。自然对UView生成ShowForm和Getlnput部分代码，包括如何显示Form和如何反馈输入。Form设计组件提供的代码模板越完备产生的代码对应MVC的代码结构支持的越好，当然也可以更好的体现和放大本发明的益处。\n[0093] 上面从三个方面描述了本发明实施例的实施情况，整体也是在体现利用UI分离体系结构实现应用设计的简化，设计人员在设计的过程中不再找到不到重点。\n[0094] 从以上的描述中，可以看出，本发明实现了如下技术效果：\n[0095] 在本发明实施例中，终端的分离模块对终端的体系结构进行UI分离，终端的应用模块处理UI分离后的应用，终端的显示模块处理UI分离后的显示，将应用部分与显示部分进行分离，并分别处理分离后的应用和显示，避免两者混合在一起时出现的显示部分变的清晰而应用部分还是非常混乱情况，提高应用及显示实现部分的代码质量，若需要进行代码重构也只需要单独构建应用或显示部分的代码，不需要全部重建，在后期维护过程中能够节省大量的资源。\n[0096] 显然，本领域的技术人员应该明白，上述的本发明的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而可以将它们存储在存储装置中由计算装置来执行，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本发明不限制于任何特定的硬件和软件结合。\n[0097] 以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。