JP2006260440A - Application system for portable terminal - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide an application system of a portable terminal of module configuration, for implementing a rich control process such as switching between a plurality of screens to improve productivity in development or maintainability, in a platform such as an BREW(R). <P>SOLUTION: The application system for a portable terminal, comprises: a means for storing applet structure; an event handler 12 referring to the applet structure and executing an application process depending on event codes, when an event code is called as an argument from an AEE (application execution environment) 1; and a screen unit event handler 13 referring to the applet structure and executing an application process in screen units depending on event codes, when an event code is called as an argument from the event handler. <P>COPYRIGHT: (C)2006,JPO&NCIPI

Description

  The present invention relates to an application system for a portable terminal, and more particularly to a module structure suitable for switching screens of an application system operating on a platform such as BREW (registered trademark).

  As application platforms equipped with a common API (Application Program Interface) for mobile terminals, JAVA (registered trademark), BREW (registered trademark) (Binary Runtime Environment for Wireless), and the like are known. Among these, BREW (registered trademark) is a wireless application platform for a CDMA mobile phone announced by Qualcomm in January 2001, and is lightweight (it operates lightly with a small amount of memory) and has high expandability ( Third party can extend BREW API), high degree of freedom (can directly control the hardware function API of the mobile device, and can be partially programmed using the knowledge of the assembler), high openness (from Qualcomm) The kit includes a source program for porting BREW (registered trademark), and network adaptability (flexible network programming is possible because the TCP / IP communication protocol can be used). In recent years, instead of JAVA (registered trademark) It is becoming popular as a platform that.

  With reference to FIG. 4, an operation scheme of the application system on BREW (registered trademark) will be schematically described.

  1) When the user selects and launches a desired BREW (registered trademark) application system icon, the BREW (registered trademark) execution environment, AEE (Application Execution Environment), is booted. Call the strap function.

  2) The bootstrap function creates an applet structure in association with the event handler function that defines the processing of the application system.

  3) When the user operates the mobile terminal, AEE calls an event handler function with an event code corresponding to the user operation as an argument.

  4) The called event handler function executes an application process corresponding to the event code with reference to the applet structure.

  Conventional application systems for mobile terminals are limited to relatively simple screen configurations and control processes. For example, there are few applications that execute processing by switching a large number of screens. The scale of application systems has been increasing, and an increasing number of applications have been implemented with rich control processing such as switching of many screens.

  However, a platform such as BREW (registered trademark) has a flat module structure in which all processing corresponding to the contents of the application is described in a single event handler function. In a single event handler function, conditional branching by push button type, conditional branching by screen type, etc. must be described together, and the control flow becomes very complicated. Problems arise.

  Furthermore, when developing an application system with such a flat module structure by multiple people, multiple people code the same event handler function in parallel (that is, the development unit or maintenance unit is the entire application system). Therefore, version management to synchronize each changed part becomes very complicated, and the variable in the event handler function is shared between developers, and its misuse (for example, There is also a problem that a variable is likely to be initialized accidentally).

  Therefore, the present invention has a new module structure that can realize rich control processing such as switching of a large number of screens on a platform such as BREW (registered trademark) and can further improve development productivity and maintainability. An object is to provide a portable terminal application system.

  The application system of the present invention refers to a means for storing an applet structure and, when called from an AEE (Application Execution Environment) with an event code as an argument, refers to the applet structure in accordance with the event code. Event handler that executes the application process, and when called from the event handler with an event code as an argument, a screen-by-screen event handler that executes application processing in screen units according to the event code with reference to the applet structure, It is provided with.

  Preferably, in addition, when called by means of means for defining a class defining a screen unit information and a screen unit event handler and an event code related to a screen operation accompanied by a screen transition from the event handler as an argument, the screen after the transition Generating means for generating an instance P of the class corresponding to the event handler, and when the event handler is called from the AEE as an argument with an event code related to a screen operation not accompanied by a screen transition, the event handler uses the event code as an argument. A screen unit event handler defined by P is called.

  A framework system of the present invention is a framework system for developing an application system having a screen unit event handler that executes application processing in units of screens, and has a function of storing an applet structure and information in units of screens. And when the event code is called from AEE (Application Execution Aviation) as an argument, the function that defines the class that defines the event handler for each screen, and according to the event code by referring to the applet structure When called by an event handler function that executes application processing and an event code related to a screen operation involving screen transition by the event handler function, an instance P of the class corresponding to the screen after the transition is generated The event handler function is a screen unit event handler defined by the instance P using the event code as an argument when the event code is called from the AEE as an argument with respect to a screen operation that does not involve screen transition. It is characterized by calling.

  The control method of the present invention is a control method for an application system of a portable terminal, and when an AEE (Application Execution Aviation) calls an event handler with an event code as an argument, the event handler A process for executing an application process according to an event code with reference to an applet structure for the system, and when the event handler calls a screen unit event handler with the event code as an argument, the screen unit event handler And an application process for each screen according to the event code with reference to the applet structure for

  The control method of the present invention can be implemented by executing the information processing program of the present invention on a computer. The information processing program of the present invention can be installed or loaded on a computer through various media such as a CD-ROM, a magnetic disk, a semiconductor memory, and a communication network.

  According to the present invention, on a platform such as BREW (registered trademark), rich control processing such as switching of many screens can be realized, and development productivity and maintainability can be improved.

  The configuration and operation of the embodiment of the present invention will be described below with reference to the drawings. FIG. 1 is a block diagram showing a module structure of BREW (registered trademark) AEE1 and BREW (registered trademark) application system 2 operating on a mobile phone terminal according to an embodiment of the present invention.

  BREW (registered trademark) AEE1 is a BREW (registered trademark) execution environment, which has functions for performing OS level task management, file management, and the like, and provides an API for using the functions, devices, and the like of AEE1. In principle, AEE1 is mounted on a terminal of a mobile phone terminal manufacturer that uses an IC chip of Qualcomm, which is the developer of BREW (registered trademark).

  The BREW (registered trademark) application system 2 of the present embodiment includes a BREW (registered trademark) applet function 10, a bootstrap function 20, a class definition function 30 that stores a panel class and a screen class of each screen, a screen generation function 40, and an applet. The MIF function 50 etc. which memorize | stores the meta information regarding are comprised. Each of these functions is realized as functional means by the CPU executing a program stored in the memory of the mobile phone terminal (see FIG. 1).

  The BREW (registered trademark) applet means 10 includes a storage means 11 for storing an applet structure, an AEE event handler 12, a screen unit event handler 13, and the like.

  The applet structure is a structure for the BREW (registered trademark) applet to store data, and stores global variables and the like in the applet. The specific configuration of the applet structure can be determined according to the design.

  When the AEE event handler 12 is called from the AEE 1 with an applet structure or event code as an argument, the AEE event handler 12 refers to the applet structure and executes application processing according to the event code. The specific configuration of the application process can be determined according to the design.

  When called from the AEE event handler 12 with an applet structure or event code as an argument, the screen unit event handler 13 refers to the applet structure and executes application processing in units of screens according to the event code. Screen-by-screen application processing can also be defined according to the design.

  The bootstrap means 20 is a function that is called when the user selects and activates the BREW (registered trademark) applet icon, and is associated with the AEE event handler 12 of the activated BREW (registered trademark) applet. An applet structure of the BREW (registered trademark) applet is created (that is, an area of the applet structure is secured on the memory to realize the storage unit 11).

  The class definition means 30 defines and stores a panel class as a structure that stores variables (global variables) and methods common to a plurality of screens among information managed in units of screens. Examples of common methods such as text control variables for managing input objects, etc., and menu control variables for managing button objects, etc., are common to multiple screens. A function that moves to an input object specified by a variable can be considered.

  In addition, the class definition unit 30 uses a screen class (for example, a menu screen class, a search) for each screen as a structure that stores variables (local variables) and methods used individually on each screen among information managed in units of screens. Define screen class, registered screen class, etc.) and store them. The screen class is defined as a child class whose parent is the panel class.

  When the screen generation unit 40 is called from the AEE event handler 12 with the event code related to the applet structure and the screen transition as an argument, the screen generation unit 40 refers to the applet structure and the class definition unit 30 to display the screen class of the screen after the transition. Instance P is generated. The method defined by this instance P functions as the screen unit event handler 13 corresponding to the screen after the transition.

  The MIF means 50 stores a class ID for identifying an applet, the name and type of the applet, icon information, and the like.

  As described above, the BREW (registered trademark) application system 2 of the present embodiment is the same as the conventional one in that the storage unit 11 that stores the applet structure, the AEE event handler 12, the bootstrap unit 20, the MIF unit 50, and the like are provided. However, it is different from the conventional module configuration in that it further includes a screen unit event handler 13, a class definition means 30, and a screen generation means 40.

  Hereinafter, the flow of processing in the BREW (registered trademark) application system 2 of the present embodiment will be described with reference to the flowcharts of FIGS. In addition, each process (including the partial process to which the code | symbol is not provided) can be arbitrarily changed in order within the range which does not produce contradiction in the processing content, or can be performed in parallel.

(Activation of application system 2: Fig. 2)
When the user selects an icon and executes a BREW (registered trademark) applet activation operation (S100), the AEE 1 refers to the MIF means 50 to obtain a class ID corresponding to the selected icon, and The bootstrap means 20 corresponding to the icon is called with the ID as an argument (S101).

  The bootstrap means 20 that has been called determines whether or not the class ID received as an argument matches the class ID of the AEE event handler corresponding to the bootstrap means 20 (S102). A value is returned (S103).

  On the other hand, if they match, the applet structure of the BREW (registered trademark) applet is created in association with the AEE event handler 12 of the BREW (registered trademark) applet specified (that is, activated) by the class ID. Then, the SUCCESS value is returned to AEE1 (S104).

  When the return value from the bootstrap means 20 is a SUCCESS value, the AEE 1 calls the AEE event handler 12 with the created applet structure and the event code indicating the applet start as arguments (S105).

  When the AEE event handler 12 is called with an event code indicating the start of an applet as an argument, the AEE event handler 12 calls the screen generating means 40 with the event code indicating the start of the applet as an argument (S106).

  When the screen generation unit 40 is called with an event code indicating the start of an applet as an argument, the screen generation unit 40 refers to the class definition unit 30 and generates an instance P of the screen class of the initial screen, and transmits necessary information to the variable of the instance P. And return a true value (S107).

  When the return value from the screen generation means 40 is a true value, the AEE event handler 12 uses the event code indicating the start of the applet as an argument as a method (screen unit corresponding to the currently displayed screen). The event handler 13) is called (S108).

  When called with an event code indicating the start of an applet as an argument, the screen unit event handler 13 executes processing for displaying a predetermined initial screen (for example, calls a corresponding screen display function) (S109).

  Thus, the application system 2 is activated, and the process proceeds to the following user operation.

(Processing according to user operation: FIG. 3)
When the user performs a predetermined operation such as pressing a hard key of a mobile phone or selecting a button displayed by software (S200), AEE1 uses an applet structure and an event code corresponding to the user operation as an argument as an AEE event. The handler 12 is called (S201).

  When the AEE event handler 12 is called from AEE1, the event code of the argument is an event code related to a screen operation with screen transition (event code with transition) or an event code related to a screen operation without screen transition (no transition) Event code) is determined (S202).

  When the event code of the argument is an event code with transition, the AEE event handler 12 calls the screen generation means 40 using the event code with transition as an argument (S203).

  When called with an event code with transition as an argument, the screen generation unit 40 refers to the class definition unit 30, generates an instance P of the screen class of the screen after the transition, and supplies necessary information to the variable of the instance P. And return a true value (S204).

  When the return value from the screen generating means 40 is a true value, the AEE event handler 12 uses a transition event code or the like as an argument to specify a method (screen unit event handler corresponding to the currently displayed screen). 13) is called (S205).

  When called by the event code with transition as an argument, the screen unit event handler 13 executes processing for displaying the corresponding screen (screen after transition) (for example, calls the corresponding screen display function) (S206). ).

  On the other hand, when the event code of the argument is a transitionless event code, the AEE event handler 12 uses the transitionless event code or the like as an argument to specify a method (screen unit event handler corresponding to the currently displayed screen). 13) is called (S207).

  When called from the AEE event handler 12 with no transition event code or the like as an argument, the screen unit event handler 13 refers to the applet structure and executes screen unit application processing corresponding to the no transition event code ( S208).

  Although not shown in FIG. 3, when the AEE event handler 12 is called from the AEE 1 as an argument with an event code other than the screen operation (for example, APP_RESUME), a predetermined value corresponding to the event code is determined according to the design. Execute the process.

  As described above, in this embodiment, a screen class for each screen inherited with the panel class as a parent is prepared, and the screen unit event handler 13 defined as a method of the screen class is used according to the display processing and operation of each screen. Therefore, the processing related to each screen can be encapsulated and separated from the AEE event handler. As a result, the flow of control can be simplified even with rich control processing such as switching of a large number of screens, and productivity and maintainability when developing an application system can be greatly improved.

  In addition, the processing related to each screen is encapsulated, so even when multiple people are jointly developing, development and maintenance work can be performed in parallel on a screen-by-screen basis. By using variables, misuse of variables can be avoided, and in this respect, productivity and maintainability when developing an application system can be greatly improved.

(Other)
The present invention is not limited to the above-described embodiment, and can be variously modified and applied.

  For example, although the above embodiment has been described on the assumption that BREW (registered trademark) is used as a platform, the present invention is not limited to such a configuration, and a flat module structure similar to BREW (registered trademark) is used. If the platform is adopted, the same effects as those of the above-described embodiment can be obtained by applying the present invention.

  In the above embodiment, BREW (registered trademark) applet means 10 (storage means 11 for storing the applet structure, AEE event handler 12, screen unit event handler 13, etc.), bootstrap means 20, class definition means 30, screen The generation means 40, the MIF means 50, etc. are grasped and explained as the BREW (registered trademark) application system 2, but the function for storing the applet structure, the AEE event handler function, the bootstrap means function, the class definition Understanding the function, screen generation function, etc. as a framework system that provides a framework for developing screen-based event handlers that define specific processing of applications (designing screen class definitions for each screen) You can also.

It is a block diagram which shows the module structure of AEE1 and application system 2 which concern on embodiment of this invention. It is a flowchart for demonstrating the flow of a process in an application system. It is a flowchart for demonstrating the flow of a process in an application system. It is a figure explaining the operation | movement scheme of the conventional BREW (trademark).

Explanation of symbols

  1 BREW (registered trademark) AEE, 2 BREW (registered trademark) application system, 10 BREW (registered trademark) applet means, 11 storage means for storing applet structure, 12 AEE event handler, 13 screen unit event handler, 20 bootstrap Means, 30 class definition means, 40 screen generation means, 50 MIF means

Claims (5)

Means for storing an applet structure;
When called from AEE (Application Execution Environment) with an event code as an argument, an event handler that refers to the applet structure and executes application processing according to the event code;
An application system comprising: a screen unit event handler that, when called from the event handler with an event code as an argument, executes application processing in units of screens according to the event code with reference to the applet structure . Furthermore, means for defining a class that defines screen unit information and screen unit event handlers;
A generation means for generating an instance P of the class corresponding to the screen after the transition when the event handler is called as an argument with an event code related to the screen operation accompanied by the screen transition;
When the event handler is called from AEE as an argument with an event code related to a screen operation not accompanied by a screen transition, the event handler calls a screen unit event handler defined by the instance P with the event code as an argument. The application system according to claim 1. A framework system for developing an application system having a screen unit event handler that executes screen unit application processing.
The ability to store applet structures;
A function that defines a class that defines screen unit information and screen unit event handlers,
When called from AEE (Application Execution Environment) with an event code as an argument, an event handler function that executes application processing according to the event code with reference to the applet structure;
A generation function that generates an instance P of the class corresponding to the screen after the transition when the event handler function is called as an argument an event code related to a screen operation involving a screen transition,
When the event handler function is called from AEE as an argument with an event code related to a screen operation not accompanied by a screen transition, the event handler function calls a screen unit event handler defined by the instance P with the event code as an argument. Framework system. A method for controlling an application system of a mobile terminal,
When AEE (Application Execution Environment) calls an event handler with an event code as an argument, the event handler refers to the applet structure for the application system and performs application processing according to the event code. A process to perform;
When the event handler calls a screen unit event handler with the event code as an argument, the screen unit event handler refers to an applet structure for the application system and executes application processing in units of screens according to the event code And a control method comprising:   An information processing program for causing a computer to execute the control method according to claim 4.

Images