WO2012113231A1 - 终端及其进行业务处理的方法 - Google Patents

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

Info

Publication number
WO2012113231A1
WO2012113231A1 PCT/CN2011/080369 CN2011080369W WO2012113231A1 WO 2012113231 A1 WO2012113231 A1 WO 2012113231A1 CN 2011080369 W CN2011080369 W CN 2011080369W WO 2012113231 A1 WO2012113231 A1 WO 2012113231A1
Authority
WO
WIPO (PCT)
Prior art keywords
application
module
terminal
sub
display
Prior art date
Application number
PCT/CN2011/080369
Other languages
English (en)
French (fr)
Inventor
赵占雄
Original Assignee
中兴通讯股份有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 中兴通讯股份有限公司 filed Critical 中兴通讯股份有限公司
Publication of WO2012113231A1 publication Critical patent/WO2012113231A1/zh

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/451—Execution arrangements for user interfaces

Definitions

  • the present invention relates to the field of communications, and in particular to a terminal and a method for performing service processing thereof.
  • the binary operating environment (Brew) of Qualcomm platform is a binary operating environment based on Qualcomm platform. Both static and dynamic applications are supported. Developers can develop mobile applications based on the Brew interface, and the final released application runs on the Brew platform.
  • the Brew platform supports static applications that participate in platform compilation, as well as dynamic loading of Qualcomm platform dynamic application files (MOD). From Brew 4.0, Brew has a new member of the Qualcomm Brew Platform Display Control System (BUIW). : BUIW regulates the development of the mobile application of the original Brew platform to a certain extent.
  • BUIW Qualcomm Brew Platform Display Control System
  • BUIW is similar to giving developers a graphical processing framework (GUI) architecture on the Brew platform.
  • GUI graphical processing framework
  • the concept of a window-like control (Form) and Qualcomm Brew platform control (Widget) on the Qualcomm Brew platform has entered the scope of discussion and has become the basic boundary for everyone's division of labor. It is precisely because of the refinement of the division of labor that the developer's work is more professional, and the final product quality is higher.
  • BUIW is just a very basic GUI-like framework, there is no guidance on how to develop an application, that is, BUIW just makes the display part change.
  • a terminal including: a separation module configured to perform user interaction (UI) separation on a terminal architecture; an application module configured to process an UI separated application; a display module, configured to Process the display after the UI is separated.
  • UI user interaction
  • the separation module is further configured to perform UI separation on the architecture of the terminal according to a schema division of a model, a control, and a view (MVC).
  • the application module comprises a main model (UModel) sub-module, a main control (UController) sub-module and a main view (UView) sub-module: the UModel sub-module is configured to set the application; the UController sub-module a module, configured to receive data initiated by the application, and indicate the application according to the data initiated by the application; the UView sub-module is configured to display the application, and feed back data input by the outside world to the application The UModel submodule.
  • the UModel sub-module includes an AModel unit, an AController unit, and an AView unit according to an MVC architecture: the AModel unit is configured to set the application. Data, and setting a manner of interaction with the AController unit; the AController unit, configured to set execution control of the application and business logic of the application, and set between the AModel unit and the AView unit The AView unit is configured to set the display and input of the application.
  • the UController sub-module is further configured to determine that the data initiated by the application is incorrect when the display corresponding to the data initiated by the application is found.
  • the UView sub-module is further configured to display the application by using a platform control (Widget) of a Brew Platform Display Control System (BUIW).
  • the display module comprises: a window design component sub-module, configured to design a graphic framework of the application; a BUIW support sub-module, configured to provide a Brew platform required to generate the application; a code generation component A submodule, set to generate a display code of the Form of the application.
  • the terminal comprises a terminal based on a binary operating environment (Brew) of the Qualcomm platform.
  • a method for performing service processing by using the foregoing terminal includes: separating a module of a terminal to perform user interaction (UI) separation on an architecture of the terminal; and processing, by the application module of the terminal, the UI is separated Application; the display module of the terminal processes the display after the UI is separated.
  • the separation module of the terminal performs user interaction UI separation on the architecture of the terminal of the binary operating environment (Brew) based on the Qualcomm platform, including: the separation module of the terminal according to the model, the control, the view (MVC)
  • the architecture partitioning separates the UI of the terminal architecture.
  • the application module of the terminal separately processes the UI separated application, including: the application module is divided into a main model (UModel) sub-module, a main control (UController) sub-module, and a main view (UView) sub-module.
  • the UModel sub-module of the application module sets the application
  • the UController sub-module of the application module receives the data initiated by the application, and indicates the application according to the data initiated by the application, where the application
  • the UView sub-module of the module displays the application and feeds back data input by the outside world to the UModel sub-module.
  • the UModel sub-module of the application module sets the application
  • the method includes: the UModel sub-module includes an AModel unit, an AController unit, and a slave view (AView) according to an MVC architecture. a unit, where the AModel unit sets data related to the application, and sets a mode of interaction with the AController unit; the AController unit sets execution control of the application and business logic of the application, and settings and The interaction between the AModel unit and the AView unit; the AView unit sets the display and input of the application.
  • the separation module of the terminal performs UI separation on the architecture of the terminal, and the application module of the terminal processes the application after the UI is separated, and the display module of the terminal processes the display after the UI separation, and separates the application part from the display part. And separately handle the separated application and display, to avoid the display part that appears when the two are mixed together, and the application part is still very chaotic, improve the code quality of the application and the display implementation part, if necessary, code reconstruction is also required. It only needs to build the code of the application or display part separately, and does not need to be completely rebuilt, which can save a lot of resources in the post-maintenance process.
  • FIG. 1 is a schematic structural diagram of a terminal according to an embodiment of the present invention
  • FIG. 2 is a flowchart of performing service processing by a terminal according to an embodiment of the present invention
  • FIG. 3 is a UI separation performed by a terminal according to an embodiment of the present invention
  • Schematic diagram of the architecture of the terminal 4 is a schematic diagram of an architecture of a terminal partitioned by using an MVC architecture according to an embodiment of the present invention
  • FIG. 5 is a schematic structural diagram of dividing a UModel sub-module according to an MVC architecture according to an embodiment of the present invention
  • FIG. 7 is a schematic structural diagram of a display module according to an embodiment of the present invention
  • FIG. 8 is a schematic structural diagram of a display design component according to an embodiment of the present invention
  • the embodiment of the present invention provides a terminal, which is generally a terminal of a binary operating environment Brew based on a Qualcomm platform, and a schematic structural diagram thereof is shown in FIG. 1 , including: a separation module 101, which is set to be The architecture of the terminal performs user interaction UI separation; the application module 102 is configured to process the UI separated application; and the display module 103 is configured to process the UI separated display.
  • a separation module 101 which is set to be The architecture of the terminal performs user interaction UI separation
  • the application module 102 is configured to process the UI separated application
  • the display module 103 is configured to process the UI separated display.
  • the separation module of the terminal performs UI separation on the architecture of the terminal, and the application module of the terminal processes the application after the UI is separated, and the display module of the terminal processes the display after the UI separation, and separates the application part from the display part. And separately processing the separated application and display, avoiding the display part that appears when the two are mixed together becomes clear and the application part is still very chaotic, improving the application and the display implementation part Code quality, if you need to refactor the code, you only need to build the code of the application or display part separately. It does not need to be completely rebuilt, which can save a lot of resources in the post-maintenance process.
  • the terminal adopts the structure shown in FIG.
  • Step S202 The separation module of the terminal pairs the terminal based on the Brew The UI performs the UI separation;
  • a schematic diagram of an architecture of a terminal that performs UI separation may also be as shown in FIG. 3, including UI control, BUIW-based UI display, and UI definition part, where the UI definition part may include data (Model). , logic (Controller), display (View) three parts.
  • the separation module describes the UI separation of the architecture of the Brew-based terminal.
  • the UI separation may be performed in multiple ways, for example, according to different user types, according to the network, or according to other networks.
  • the feature or basis is divided.
  • the embodiment of the present invention provides that: the separation module is further configured to perform UI separation on the architecture of the terminal according to the architecture division of MVC (model, view, control).
  • MVC model, view, control
  • a schematic diagram of an architecture of a terminal partitioned by an architecture of MVC may be as shown in FIG. 4.
  • the application module 102 includes a main model (UModel) submodule 401, a main control (UController) submodule 402, and Main view (UView) submodule 403:
  • the UModel sub-module 401 is configured to set an application;
  • the UController sub-module 402 is configured to receive data initiated by the application, and indicate an application according to the data initiated by the application;
  • the UView sub-module 403 is configured to display an application and feed back data input by the outside world to the UModel sub-module 401.
  • the setting application is to define an application, and related parameters such as data and model of the application are defined.
  • the meanings of the subsequent settings in this document are also the same as the definition.
  • the terminal may utilize the architecture of the MVC architecture to divide the sub-module, and may also use the MVC architecture to divide the sub-module.
  • the UModel sub-module may be in accordance with the MVC shelf.
  • the structure is divided. For the structure after division, please refer to Figure 5:
  • the UModel submodule 401 includes a slave model (AModel) unit 501, a slave control (AController) unit 502, and a slave view (AView) unit 503 divided according to the architecture of the MVC:
  • the AModel unit 501 is configured to set data related to the application, and set a mode of interaction with the AController unit 502;
  • the AController unit 502 is configured to set the execution logic of the application and the business logic of the application, and set the interaction with the AModel unit 502 and the AView unit 503;
  • the AModel of the application is designed for data, and the data processing of the application can be performed. Functions such as serialization are organized in AModel.
  • AModel only needs to define the interaction with AController without worrying about the use of data.
  • the application's AController only needs to care about the application-related messages, platform interaction messages, and the interactions defined with AModek AView. That is to say, the application's AController only manages the good news and bridges the AModek AView.
  • the AView of the application is responsible for defining how the data is displayed and input is obtained, and there is no need to manage how the data is processed. After the application is defined, it is displayed under the UI separation system. Under the system of UI separation, it is also the architecture of MVC.
  • the definition of application is UModel.
  • UController which is responsible for receiving the data display instructions defined by the application's AView, and then determines to make the correct display. UController looks up the display of the corresponding request, and if it finds the display, it is wrong.
  • the UView which uses BUIW's Widget for display, has input feedback capabilities. That is to say, interactive actions can be fed back to the UModel.
  • the UI separation system separates complex business logic from display.
  • the embodiment of the present invention applies the architecture of the MVC to the application and display, and divides the original application implementation. According to the idea of MVC, the data, logic and display of the application are effectively segmented, so that the overall implementation is simplified. That is to say, the original code is divided into Model, View, and Controller. Each part has interaction and independence. It makes the problem positioning and modification easy, and code reconstruction becomes possible.
  • the code of the original Brew application development is very complex, and most of the processing is in the application's event handler.
  • the invention adopts the MVC architecture to perform hierarchical division, which can make the event processing of the application become readable.
  • Each application consists of three levels of Mode View Controller, which we later use to represent AMode AView AController.
  • the AModel includes all the data involved in the application
  • AView defines the application display and input
  • AController includes the application's execution control
  • the architecture for UI separation is also an MVC structure, which also includes three levels of Modek View Controller, which are represented by UModek UView and UController.
  • UModel is the definition of the application, UView is displayed using BUIW, and UController includes control of display and application interaction.
  • the designer can design a structure with clear structure, improve the code quality of the application and the display implementation part, and if the code reconstruction is needed, only the code of the application or the display part needs to be separately constructed, All reconstruction is required, and a lot of resources can be saved in the post-maintenance process.
  • the UController sub-module 402 can also be configured to determine the data error initiated by the application when the display corresponding to the data initiated by the application is found.
  • the UView sub-module 403 can also be configured to display the application using the BUIW's Widget.
  • the display module 103 may include: a window Form design component sub-module 701, which is set as a graphic framework for designing an application;
  • the BUIW support sub-module 702 is configured to provide a Brew platform required to generate an application; a code generation component sub-module 703, which is set to generate a display code of the application's Form.
  • a visual design tool based on the UI separation system.
  • the visual design tool is based on BUIW, and includes a Form (a window-like component of BUIW) design component and a code generation component.
  • the Form design component is implemented using a Java-based open source IDE environment (Eclipse) and an Eclipse-based Graphic Design Framework (GEF).
  • the embodiment of the invention combines GEF and BUIW to realize the visual interface design of the Brew platform.
  • GEF's tool definitions can be implemented in accordance with BUIW's Form and Widget definitions.
  • GEF uses Draw2D (a GUI in a Java environment) as the basic GUI.
  • Draw2D itself does not have a very clear control definition, and can override the drawing method to meet the needs of BUIW.
  • the code generation component generates code based on the current design. Because the basic design is the UView part, the code generation is mainly to generate the display code of the Form.
  • the design component will generate the display method according to the definition. If there is no AView applied The definition of the design component will generate the definition and display method of the application's AView. See Figure 8 for an illustration of the Form design component of an embodiment of the present invention.
  • the technical solutions provided by the embodiments of the present invention have positive effects on the development, design, and implementation of the Brew application. In terms of development and design, because of the high cohesion and low coupling, the design difficulty is reduced, and the development efficiency can be provided, and the reliability is improved to some extent.
  • the technical solution provided by the embodiment of the present invention may be divided into three parts: a BUIW extension, an MVC code framework, and a Form design component.
  • BUIW extension it is necessary to use BUIW to realize the requirements of View in the UI separation system.
  • BUIW gives developers a basic framework and also provides the foundation for extensions.
  • UView the Form must be expanded. One is to define a uniform display interface for the Form, and the other is to define a unified input interface for the Form. This way UController can interact with UModel and UView. That is, Form needs to add two methods, ShowForm and Getlnput.
  • the Form interface can be defined as:
  • UController can be considered for UView and AView design, UController creates and displays UView according to AView, and can manage UView at the same time. This way UController can extend the BUIW RootForm from the code structure.
  • One of the key extensions of the code is to extend the original HandleEvent mechanism to implement Getlnput on the basis of the original. Event occurrences require user interaction input via Getlnput.
  • AModel defines the data required by the application and supports interaction with AController. From the code structure, it is necessary to support the general ModelChange, ModelNotify and other mechanisms.
  • AController is handling the basic events of the application and needs to be adjusted with UView.
  • AView defines the display based on the application. From the code structure, you can design an XML template based on the data of the current application and then design the code, or you can automatically generate it through the Form design component.
  • the content format of AView and UView communication is basically defined as follows:
  • Form design component Another part of the Form design component is code generation, which is also critical to supporting the MVC code framework. There is already a communication definition before design, and the design tool naturally does not generate communication interaction part code. If there is no communication definition, the design tool will generate the communication interaction code and XML template, and generate the corresponding AModel part code. Naturally, UView generates the ShowForm and Getlnput part of the code, including how to display the Form and how to feed back. The more complete the code template provided by the Form design component, the better the code generated corresponding to the MVC code structure, and of course the benefits of the present invention can be better embodied and amplified.
  • the separation module of the terminal performs UI separation on the architecture of the terminal
  • the application module of the terminal processes the application after separation of the UI
  • the terminal The display module processes the display after the UI is separated, separates the application part from the display part, and separately processes the separated application and display, so that the display part that appears when the two are mixed together becomes clear and the application part is still very chaotic.
  • modules or steps of the present invention can be implemented by a general-purpose computing device, which can be concentrated on a single computing device or distributed over a network composed of multiple computing devices. Alternatively, they may be implemented by program code executable by the computing device so that they may be stored in the storage device by the computing device, or they may be separately fabricated into individual integrated circuit modules, or Multiple modules or steps are made into a single integrated circuit module. Thus, the invention is not limited to any specific combination of hardware and software.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Human Computer Interaction (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • User Interface Of Digital Computer (AREA)
  • Stored Programmes (AREA)

Abstract

本发明公开了一种终端及其进行业务处理的方法，终端包括：分离模块，设置为对终端的体系结构进行UI分离；应用模块，设置为处理UI分离后的应用；显示模块，设置为处理UI分离后的显示。采用本发明能够解决BUIW中应用及显示实现部分的代码质量不高，并且代码重构的难度非常的大，导致Brew应用的后期维护难度非常的大，很多情况都是牵一发而动全身，浪费大量的资源的问题。

Description

终端及其进行业务处理的方法 技术领域 本发明涉及通信领域， 具体而言， 涉及一种终端及其进行业务处理的方法。 背景技术 高通平台的二进制运行环境 （Brew) 是一个基于高通平台的二进制运行环境。 可以支持静态和动态应用。 开发人员可以基于 Brew接口进行手机应用的开发， 最 后发布的应用运行于 Brew平台之上。 Brew平台支持参与平台编译的静态应用， 也 支持动态加载高通平台动态应用文件 （MOD) 方式。 从 Brew 4.0以后 Brew有了新成员高通 Brew平台显示控件系统（BUIW)。： BUIW 在一定程度上规范了原来 Brew平台手机应用的开发。 BUIW类似于给开发人员提供 了一个 Brew平台上的图形处理框架 （GUI)架构。 有了 BUIW以后让 Brew平台的 应用开发难度有所下降， 开发人员的分工更加清晰。 高通 Brew平台的类似窗口的 控件 （Form)、 高通 Brew平台控件 （Widget) 的概念进入了大家讨论的范畴， 同时 也成了大家分工的基本界限。也正是因为分工的细化， 让开发人员的工作更加专业， 也使最终的产品质量更高。 虽然 Brew增加了新秀 BUIW提供了更好的应用开发支持， 但是 BUIW也只是 一个非常基本的类似 GUI的框架，对于用户如何进行一个应用的开发没有任何指导， 也就是说 BUIW只是让显示部分变的清晰而应用部分还是非常混乱。 Brew的结构复 杂程度还是非常的高， 导致应用及显示实现部分的代码质量不高， 并且代码重构的 难度非常的大。 这种情况下导致 Brew应用的后期维护难度非常的大， 很多情况都 是牵一发而动全身， 浪费大量的资源。 针对相关技术中 BUIW中应用及显示实现部分的代码质量不高， 并且代码重构 的难度非常的大， 这种情况下导致 Brew应用的后期维护难度非常的大， 很多情况 都是牵一发而动全身， 浪费大量的资源的问题， 目前尚未提出有效的解决方案。 发明内容 本发明旨在提供一种终端及其进行业务处理的方法， 以解决 BUIW中应用及显 示实现部分的代码质量不高， 并且代码重构的难度非常的大， 这种情况下导致 Brew 应用的后期维护难度非常的大， 很多情况都是牵一发而动全身， 浪费大量的资源的 问题。 根据本发明的一个方面， 提供了一种终端， 包括： 分离模块， 设置为对终端的 体系结构进行用户交互 （UI) 分离； 应用模块， 设置为处理 UI 分离后的应用； 显 示模块， 设置为处理 UI分离后的显示。 较优的， 所述分离模块还设置为按照模型、 控制、 视图 （MVC) 的架构划分对 所述终端的体系结构进行 UI分离。 较优的， 所述应用模块包括主模型 （UModel) 子模块、 主控制 （UController) 子模块和主视图 （UView) 子模块： 所述 UModel子模块， 设置为设置所述应用； 所述 UController子模块， 设置为接收所述应用发起的数据， 根据所述应用发起的数 据对所述应用做出指示； 所述 UView子模块， 设置为显示所述应用， 并将外界经自 身输入的数据反馈至所述 UModel子模块。 较优的， 所述 UModel子模块包括按照 MVC的架构划分的从模型 （AModel) 单元、 从控制 （AController) 单元和从视图 （AView) 单元： 所述 AModel单元， 设 置为设置所述应用涉及的数据， 以及设置与所述 AController单元间的交互方式； 所 述 AController单元， 设置为设置所述应用的执行控制和所述应用的业务逻辑， 以及 设置与所述 AModel单元、 所述 AView单元间的交互； 所述 AView单元， 设置为设 置所述应用的显示和输入。 较优的，所述 UController子模块还设置为查找到所述应用发起的数据对应的显 示时， 判断所述应用发起的数据错误。 较优的， 所述 UView子模块还设置为利用 Brew平台显示控件系统 （BUIW) 的平台控件 （Widget) 显示所述应用。 较优的， 所述显示模块包括： 窗口 （Form) 设计组件子模块， 设置为设计所述 应用的图形框架； BUIW支撑子模块， 设置为提供生成所述应用所需的 Brew平台； 代码生成组件子模块， 设置为生成所述应用的 Form的显示代码。 较优的， 所述终端包括基于高通平台的二进制运行环境 （Brew) 的终端。 根据本发明的另一方面，提供了一种利用上述终端进行业务处理的方法，包括: 终端的分离模块对终端的体系结构进行用户交互 （UI) 分离； 所述终端的应用模块 处理 UI分离后的应用； 所述终端的显示模块处理 UI分离后的显示。 较优的， 所述终端的分离模块对基于高通平台的二进制运行环境 （Brew) 的终 端的体系结构进行用户交互 UI分离， 包括： 所述终端的分离模块按照模型、 控制、 视图 （MVC) 的架构划分对所述终端的体系结构进行 UI分离。 较优的， 所述终端的应用模块单独处理 UI分离后的应用， 包括： 所述应用模块 被划分为主模型（UModel)子模块、主控制（UController)子模块和主视图（UView) 子模块， 其中， 所述应用模块的 UModel 子模块设置所述应用， 所述应用模块的 UController子模块接收所述应用发起的数据， 根据所述应用发起的数据对所述应用 做出指示， 所述应用模块的 UView子模块显示所述应用， 并将外界经自身输入的数 据反馈至所述 UModel子模块。 较优的， 所述应用模块的 UModel子模块设置所述应用， 包括： 所述 UModel 子模块包括按照 MVC的架构划分的从模型（AModel)单元、 从控制（ AController) 单元和从视图 （AView) 单元， 其中， 所述 AModel单元设置所述应用涉及的数据， 以及设置与所述 AController单元间的交互方式； 所述 AController单元设置所述应 用的执行控制和所述应用的业务逻辑， 以及设置与所述 AModel单元、 所述 AView 单元间的交互； 所述 AView单元设置所述应用的显示和输入。 在本发明实施例中，终端的分离模块对终端的体系结构进行 UI分离，终端的应 用模块处理 UI分离后的应用， 终端的显示模块处理 UI分离后的显示， 将应用部分 与显示部分进行分离， 并分别处理分离后的应用和显示， 避免两者混合在一起时出 现的显示部分变的清晰而应用部分还是非常混乱情况， 提高应用及显示实现部分的 代码质量， 若需要进行代码重构也只需要单独构建应用或显示部分的代码， 不需要 全部重建， 在后期维护过程中能够节省大量的资源。 附图说明 此处所说明的附图用来提供对本发明的进一步理解， 构成本申请的一部分， 本 发明的示意性实施例及其说明用于解释本发明， 并不构成对本发明的不当限定。 在 附图中： 图 1是根据本发明实施例的终端的结构示意图； 图 2是根据本发明实施例的终端进行业务处理的流程图； 图 3是根据本发明实施例的终端进行了 UI分离的终端的体系结构的示意图; 图 4是根据本发明实施例的采用 MVC的架构划分的终端的体系结构的示意图； 图 5是根据本发明实施例的对 UModel子模块按照 MVC的架构进行划分的结 构示意图； 图 6是根据本发明实施例的对终端及其内部结构均按照 MVC的架构进行划分 的结构示意图； 图 7是根据本发明实施例的显示模块的结构示意图； 图 8是根据本发明实施例的 Form设计组件的结构示意图。 具体实施方式 下面将参考附图并结合实施例， 来详细说明本发明。 下文中将参考附图并结合实施例来详细说明本发明。 需要说明的是， 在不冲突 的情况下， 本申请中的实施例及实施例中的特征可以相互组合。 相关技术中提到， 虽然 Brew增加了新秀 BUIW提供了更好的应用开发支持， 但是 BUIW也只是一个非常基本的类似 GUI的框架，对于用户如何进行一个应用的 开发没有任何指导， 也就是说 BUIW只是让显示部分变的清晰而应用部分还是非常 混乱。 Brew的结构复杂程度还是非常的高， 导致应用及显示实现部分的代码质量不 高， 并且代码重构的难度非常的大。 这种情况下导致 Brew应用的后期维护难度非 常的大， 很多情况都是牵一发而动全身， 浪费大量的资源。 为解决上述技术问题， 本发明实施例提供了一种终端， 该终端通常是采用基于 高通平台的二进制运行环境 Brew的终端， 其结构示意图如图 1所示， 包括： 分离模块 101， 设置为对终端的体系结构进行用户交互 UI分离； 应用模块 102， 设置为处理 UI分离后的应用； 显示模块 103， 设置为处理 UI分离后的显示。 在本发明实施例中，终端的分离模块对终端的体系结构进行 UI分离，终端的应 用模块处理 UI分离后的应用， 终端的显示模块处理 UI分离后的显示， 将应用部分 与显示部分进行分离， 并分别处理分离后的应用和显示， 避免两者混合在一起时出 现的显示部分变的清晰而应用部分还是非常混乱情况， 提高应用及显示实现部分的 代码质量， 若需要进行代码重构也只需要单独构建应用或显示部分的代码， 不需要 全部重建， 在后期维护过程中能够节省大量的资源。 在本发明实施例中， 若终端采用如图 1所示的结构， 则可以按图 2所示流程图 对于终端涉及业务的业务进行相应处理： 步骤 S202、 终端的分离模块对基于 Brew的终端的体系结构进行 UI分离； 步骤 S204、 终端的应用模块处理 UI分离后的应用； 步骤 S206、 终端的显示模块处理 UI分离后的显示。 在一个实施例中，进行了 UI分离的终端的体系结构的示意图也可以如图 3所示， 包括 UI控制、基于 BUIW的 UI显示以及 UI定义部分， 其中 UI定义部分中可以包 括数据 （Model)、 逻辑 （Controller)、 显示 （View) 三部分。 实施时， 步骤 S202中记载了分离模块对基于 Brew的终端的体系结构进行 UI 分离， UI分离的方式可以有多种， 例如按不同的用户类型进行划分， 按所处网络进 行划分， 或者按其他的特点或依据进行划分， 较优的， 本发明实施例提出： 分离模 块还设置为按照 MVC (模型、 视图、 控制） 的架构划分对终端的体系结构进行 UI 分离。 在一个实施例中，采用 MVC的架构划分的终端的体系结构的示意图可以如图 4 所示， 应用模块 102 中包括可以包括主模型 （UModel ) 子模块 401、 主控制 (UController) 子模块 402和主视图 （UView) 子模块 403 :
UModel子模块 401， 设置为设置应用； UController子模块 402， 设置为接收应用发起的数据， 根据应用发起的数据对 应用做出指示；
UView子模块 403，设置为显示应用，并将外界经自身输入的数据反馈至 UModel 子模块 401。 在本发明实施例中， 设置应用也即是定义应用， 对应用的数据、 模型等参数进 行相关的定义， 本文中后续的设置的含义也与定义相同。 在一个实施例中， 终端可以利用 MVC的架构划分的自身的体系结构， 也可以 利用 MVC的架构对子模块进行划分， 例如， 可以对 UModel子模块按照 MVC的架 构进行划分， 划分后的结构请参见图 5:
UModel子模块 401包括按照 MVC的架构划分的从模型 （AModel) 单元 501、 从控制 （AController) 单元 502和从视图 （AView) 单元 503 :
AModel单元 501， 设置为设置应用涉及的数据， 以及设置与 AController单元 502间的交互方式；
AController单元 502， 设置为设置应用的执行控制和应用的业务逻辑， 以及设 置与 AModel单元 502、 AView单元 503间的交互；
AView单元 503， 设置为设置应用的显示和输入。 本发明实施例中， 若对终端及其内部结构均按照 MVC的架构进行划分， 其结 构示意图及具体连接关系如图 6所示： 应用的 AModel专为数据而设计， 可以把应用的数据处理、 串行化等功能都整 理在 AModel来实现。 同时 AModel只需要定义好与 AController的交互而不需要关 心数据的使用。应用的 AController只需要关心与应用相关的消息、平台交互的消息， 以及定义好与 AModek AView的交互。 也就是说应用的 AController只管理好消息 和做好 AModek AView的桥梁，不需要关心数据如何保存、如何显示。应用的 AView 负责定义数据如何显示和输入获取， 不需要管数据如何处理。 应用定义完毕就放在 UI分离的体系下进行显示。 在 UI分离的体系下面也是 MVC的架构， 应用的定义 就是 UModel了。 UController, 负责接收应用的 AView定义的数据显示指导， 然后 判断做出正确的显示。 UController查找对应请求的显示， 如果找到显示的则错误。
UView, 就是利用 BUIW的 Widget进行显示， 同时具有输入反馈能力。 就是说交互 的动作可以反馈给 UModel。 综上可知， UI分离体系就是把复杂的业务逻辑和显示分开处理。 简单来说就是 本发明实施例将 MVC的架构应用于应用和显示， 将原来混在一起的应用实现进行 分割。 按照 MVC的思想把应用的数据、 逻辑、 显示进行有效分割， 让整体实现简 化。 也就是原来揉在一起的代码进行了 Model、 View、 Controller的划分， 各个部分 有交互同时也具备独立性， 让问题定位、 修改变的容易， 代码重构变成了可能。 原来的 Brew应用开发的代码复杂程度非常高， 大部分处理都在应用的事件处 理函数里面， 有可能一个事件处理函数就上万行。 可以说开发人员在开发的时候就 是一个面， 毫无层次结构。 本发明采用 MVC架构进行层次上的划分， 可以让应用的事件处理变的可以阅 读。 每一个应用都由 Mode View Controller三个层次组成， 后面我们用 AMode AView AController来表示。 AModel包括了应用涉及的所有数据、 AView定义应用 显示和输入、 AController包括应用的执行控制、 应用的业务逻辑。 对于 UI分离的 体系结构也是一个 MVC的结构， 同样包括 Modek View Controller三个层次， 后 面我们用 UModek UView、 UController来表示。 UModel就是应用的定义、 UView 利用 BUIW进行显示、 UController包括了显示和应用交互的控制。 基于本发明实施例提供的 UI分离体系， 设计人员可以设计出结构清晰的架构， 提高应用及显示实现部分的代码质量， 若需要进行代码重构也只需要单独构建应用 或显示部分的代码， 不需要全部重建， 在后期维护过程中能够节省大量的资源。 在一个实施例中， UController子模块 402还可以设置为查找到应用发起的数据 对应的显示时， 判断应用发起的数据错误。 在一个实施例中， UView子模块 403还可以设置为利用 BUIW的 Widget显示 应用。 在一个实施例中， 如图 7所示， 显示模块 103可以包括： 窗口 Form设计组件子模块 701， 设置为设计应用的图形框架；
BUIW支撑子模块 702， 设置为提供生成应用所需的 Brew平台； 代码生成组件子模块 703， 设置为生成应用的 Form的显示代码。 为实现显示模块的处理，本发明实施例还提出基于 UI分离体系的可视化设计工 具， 可视化设计工具以 BUIW为基础， 包括 Form (BUIW的一个类似窗口的组件） 设计组件、 代码生成组件。
Form设计组件利用基于 Java的开源 IDE环境 （Eclipse)和一个基于 Eclipse的 图形设计框架 （GEF) 可以实现。 本发明实施例将 GEF与 BUIW进行结合， 实现 Brew平台的可视化界面设计。 GEF的工具定义可以按照 BUIW的 Form、 Widget的 定义来实现。 同时 GEF利用了 Draw2D (—个 Java环境下的 GUI) 做基础 GUI, Draw2D本身并没有非常明确的控件定义，可以重载绘制方法来满足 BUIW的需求。 代码生成组件根据当前设计的情况进行代码生成。 因为设计的基本是 UView部分， 所以代码生成主要是生成 Form的显示代码。 如果在设计前已经存在应用的 AView 的显示定义，那么设计组件会根据定义进行显示方法的生成。如果没有应用的 AView 的定义， 设计组件将生成应用的 AView的定义和显示方法。 本发明实施例 Form设 计组件图示参见图 8。 综上所述， 采用本发明实施例提供的技术方案， 在 Brew应用的开发设计以及 实现都有着积极的效果。 从开发设计方面来说， 因为是高内聚低耦合， 所以降低了 设计难度， 同时可以提供开发效率， 而且一定程度的提高了可靠性。 在具体实施方面， 可以将本发明实施例提供的技术方案分为 BUIW扩展、 MVC 代码框架、 Form设计组件三个部分进行描述。 首先， BUIW扩展方面，需要利用 BUIW实现 UI分离体系中 View的需求。 BUIW 给了开发人员一个基本的框架，同时也提供了扩展的基础。为了满足 UView的需求， 必现对 Form进行扩展。 一是给 Form定义统一的显示接口， 二是给 Form定义统一 的输入获取的接口。 这样 UController可以实现 UModel和 UView的交互。 也就是 Form需要增加 ShowForm和 Getlnput两个方法。 可以把 Form接口定义为：
AEEINTERFACE(ISampleForm) {
INHERIT_IForm(ISampleForm);\ int (*ShowForm)( ISampleForm *po, AECHAR *inputDef);\ int (*GetInput)( ISampleForm *po, AEEEvent evt, uintl6 wParam, uint32 dwParam, AECHAR *outputDef)
当然上面定义只是本发明实施例为阐述而设计的样例， 一个 Form接口定义可 能会更加复杂。 然后， 再看一下 MVC代码框架。 上面已经对 UView做了基本的描述， 可以说 在 UView定义统一的接口后就为 UController的正常运行提供了保障。 为了更好的 体现本发明实施例的优势， MVC的代码框架也比较重要。 MVC的代码框架要求 、 V、 C的实现要分开， 可以在独立的文件中实现。 UModek UController^ UView基 本按照 Brew的要求进行定义， 符合 Brew的 ClassID管理机制， 可以实现 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通信的内容格式基本定义如下：
<?xml version:" 1.0" encoding= "UTF-8 " ?>
<form classid=0xl23456 appclassid=0x654321>
<data name="datal" type="text"> <value> 1 </ value>
</data>
<data name="data2" type="select"> <items>
<item name="iteml " key="key 1 "/item> ...
</items>
<value>key 1 </ value>
</data>
</form> 上面同样是为了阐述本发明实施例而设计的样例。 最后， 来看一下 Form设计组件。 前面也对 Form设计组件的功能和基本的设计 进行了描述。这里也是建议使用 Eclipse实现 Form设计组件， 因为在 Eclipse下面有 比较丰富的设计框架。 GEF就是比较优秀的可视化设计框架， 以 DraW2D为基础， 整个设计框架速度比较让人满意。 本发明实施例旨在将 GEF应用于 Brew, 为 Brew 提供全新的可视化设计思路。在实际使用 GEF的时候需要根据我们平台当前的情况 进行 GEF工具的定义， 同时也可以根据当前 BUIW的情况进行可视化设计的约束。 Form设计组件还有一个部分就是代码生成， 这个对于支持 MVC代码框架也比较关 键。 在设计前已经有了通信定义， 设计工具自然不会生成通信交互部分代码。 如果 没有通信定义， 设计工具将生成通信交互代码和 XML模板， 同时生成对应 AModel 部分代码。自然对 UView生成 ShowForm和 Getlnput部分代码，包括如何显示 Form 和如何反馈输入。 Form设计组件提供的代码模板越完备产生的代码对应 MVC的代 码结构支持的越好， 当然也可以更好的体现和放大本发明的益处。 上面从三个方面描述了本发明实施例的实施情况，整体也是在体现利用 UI分离 体系结构实现应用设计的简化， 设计人员在设计的过程中不再找到不到重点。 从以上的描述中， 可以看出， 本发明实现了如下技术效果： 在本发明实施例中，终端的分离模块对终端的体系结构进行 UI分离，终端的应 用模块处理 UI分离后的应用， 终端的显示模块处理 UI分离后的显示， 将应用部分 与显示部分进行分离， 并分别处理分离后的应用和显示， 避免两者混合在一起时出 现的显示部分变的清晰而应用部分还是非常混乱情况， 提高应用及显示实现部分的 代码质量， 若需要进行代码重构也只需要单独构建应用或显示部分的代码， 不需要 全部重建， 在后期维护过程中能够节省大量的资源。 显然， 本领域的技术人员应该明白， 上述的本发明的各模块或各步骤可以用通 用的计算装置来实现， 它们可以集中在单个的计算装置上， 或者分布在多个计算装 置所组成的网络上， 可选地， 它们可以用计算装置可执行的程序代码来实现， 从而 可以将它们存储在存储装置中由计算装置来执行， 或者将它们分别制作成各个集成 电路模块， 或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样， 本发明不限制于任何特定的硬件和软件结合。 以上所述仅为本发明的优选实施例而已， 并不用于限制本发明， 对于本领域的 技术人员来说， 本发明可以有各种更改和变化。 凡在本发明的精神和原则之内， 所 作的任何修改、 等同替换、 改进等， 均应包含在本发明的保护范围之内。

Claims

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

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201110046797.5A CN102109953B (zh) 2011-02-25 2011-02-25 终端及其进行业务处理的方法
CN201110046797.5 2011-02-25

Publications (1)

Publication Number Publication Date
WO2012113231A1 true WO2012113231A1 (zh) 2012-08-30

Family

ID=44174132

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2011/080369 WO2012113231A1 (zh) 2011-02-25 2011-09-29 终端及其进行业务处理的方法

Country Status (2)

Country Link
CN (1) CN102109953B (zh)
WO (1) WO2012113231A1 (zh)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102109953B (zh) * 2011-02-25 2015-01-28 中兴通讯股份有限公司 终端及其进行业务处理的方法
CN102955688A (zh) * 2011-08-23 2013-03-06 上海无戒空间信息技术有限公司 一种用户图像控件的处理方法

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1908894A (zh) * 2005-08-04 2007-02-07 腾讯科技（深圳）有限公司 基于Brew的一种动态用户界面的体系结构和实现方法
CN101136924A (zh) * 2007-09-29 2008-03-05 中兴通讯股份有限公司 一种下一代网络中主叫身份标识显示的方法
CN201234320Y (zh) * 2008-05-30 2009-05-06 中兴通讯股份有限公司 一种手机电视终端
CN102109953A (zh) * 2011-02-25 2011-06-29 中兴通讯股份有限公司 终端及其进行业务处理的方法

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7581204B2 (en) * 2004-06-01 2009-08-25 Sap Ag Dynamic contexts
KR100678023B1 (ko) * 2006-02-15 2007-02-02 삼성전자주식회사 이동통신 단말기의 부팅시간 단축 방법
CN101807162B (zh) * 2010-03-25 2013-08-07 青岛海信电器股份有限公司 降低嵌入式软件系统模块耦合度的方法和嵌入式软件系统

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1908894A (zh) * 2005-08-04 2007-02-07 腾讯科技（深圳）有限公司 基于Brew的一种动态用户界面的体系结构和实现方法
CN101136924A (zh) * 2007-09-29 2008-03-05 中兴通讯股份有限公司 一种下一代网络中主叫身份标识显示的方法
CN201234320Y (zh) * 2008-05-30 2009-05-06 中兴通讯股份有限公司 一种手机电视终端
CN102109953A (zh) * 2011-02-25 2011-06-29 中兴通讯股份有限公司 终端及其进行业务处理的方法

Also Published As

Publication number Publication date
CN102109953B (zh) 2015-01-28
CN102109953A (zh) 2011-06-29

Similar Documents

Publication Publication Date Title
US11429353B1 (en) Dynamic service provisioning using templatized infrastructure resources
CN106775744B (zh) 一种生成静态库的方法和装置
CN106982266A (zh) 一种自动化部署集群的方法和装置
US10372443B2 (en) Multi-platform pattern-based user interfaces
WO2013007141A1 (zh) 面向业务模型的软件运行平台及其运行方式
US20120124553A1 (en) Status management for phased implementation of configuration changes
CN103927163A (zh) 插件框架处理装置及插件系统
CN104714823B (zh) 基于OpenStack的新建主机配置方法
CN111767090A (zh) 小程序的启动方法、装置、电子设备以及存储介质
CN103150154A (zh) 一种应用程序插件的实现方法及装置
CN111966462A (zh) 一种混合云管理系统
Wizenty et al. Magma: Build management-based generation of microservice infrastructures
Nguyen et al. Using microservices for non-intrusive customization of multi-tenant SaaS
WO2012113231A1 (zh) 终端及其进行业务处理的方法
CN110716975A (zh) 一种数据接口生成方法以及数据接口共享平台
CN112558968B (zh) 一种资源树视图的生成方法、装置、设备及存储介质
CN107346217B (zh) 一种云硬盘管理方法、云计算管理平台及虚拟化平台
CN103809951A (zh) 一种基于flex技术图形化服务编排和管理装置
Miravet et al. Framework for the declarative implementation of native mobile applications
WO2016201813A1 (zh) 一种基于Android的动态布局方法及系统
US20140181783A1 (en) Component integration by distribution of schema definition on heterogenous platforms
CN112130888A (zh) 应用程序更新的方法、装置、设备和计算机存储介质
CN102236510B (zh) 一种利用超级任务栏控制即时通信软件的方法及设备
CN110764864A (zh) 一种基于Terraform的可视化资源编排方法
JP2010049439A (ja) ソフトウェアモデルを用いたシステム構築方法およびモデリング装置

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 11859430

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 11859430

Country of ref document: EP

Kind code of ref document: A1