WO2012079318A1

WO2012079318A1 - Method and system for displaying native user interface

Info

Publication number: WO2012079318A1
Application number: PCT/CN2011/072150
Authority: WO
Inventors: 苟定勇
Original assignee: 中兴通讯股份有限公司
Priority date: 2010-12-17
Filing date: 2011-03-25
Publication date: 2012-06-21
Also published as: CN102033774A

Abstract

The present invention provides a method and system for displaying a native user interface (UI). The method comprises: A Java Application sends UI display information to the Java Virtual Machine, wherein said UI display information comprises UI display commands. Said Java Virtual Machine transparently transmits said UI display information to a native UI interface. Said native UI interface displays a native UI according to said UI display information. The invention promotes the performance capability of the Java Application Program without relying on Java Runtime Environment or class library for extended application programming interface (API) on a target terminal, and improves the development efficiency.

Description

Local user interface display method and system

TECHNICAL FIELD The present invention relates to the field of communications, and in particular to a local interface display method and system. BACKGROUND OF THE INVENTION In a Java ME running environment, a Java application (referred to as a MIDlet) is subject to

Java standard application program interface (API) and Java virtual machine restrictions, the work interface is limited to the inside of the virtual machine. For example, instant messaging applications (such as popular IM, QQ, MSN on the market) and applications such as Email can't display online icons or indicate new messages/new messages through the interface, using body-based and local applications. There are some gaps in the program. In addition, for weather-like applications, news applications can be scrolled in a partial window on the standby screen. If you use a Java application, you usually don't have this performance. These limitations of Java applications limit its use and partially offset the cross-platform common benefits of Java applications. In response to these problems, the Java ME runtime environment can be enhanced by using the Java extension API. FIG. 1 is a schematic diagram of implementing an enhanced interface display effect according to the related art. As shown in FIG. 1 , a general extended API mode needs to modify a Java running environment, and an extended API class is added in a Java running environment; After the class is compiled, it needs to be provided to third-party vendors for development and joint debugging in the form of API library or directly integrated into the mobile terminal. At the same time, MIDlet needs to refer to these new extended API class libraries during development and development. As a result, MIDlet development is affected by the development of mobile Java runtime environment, and the risk of progress is increased. Because these extension classes need to interact with local platforms or local applications, the process of porting interfaces obviously requires a certain amount of development work. Similar technologies include the Nokia UI, the Sprint Extension API, and more. The advantage of this approach is that the API is provided in a more standardized way to accommodate complex needs. The disadvantage of extending API classes is that applications that use these APIs either rely on the extended API class library or rely on the Java runtime environment of the target mobile terminal and cannot run in other situations. If the functionality of the extended API class must be supported by the native platform, the MIDlet can only be developed and debugged on the target mobile terminal. If there is no API class library in the development environment, the MIDlet runtime will have a "class not found" problem and cannot be compiled. In most cases, mobile terminals and MIDlets are developed by different vendors. The development and debugging of MIDLet depends on the mobile terminal Java runtime environment, and the development progress will be affected. This situation is more prominent for mobile terminal manufacturers who are taking a customized route for large-scale operators. Because In this case, the MIDlet is usually developed by different third-party vendors, and the requirements of each operator are different. Therefore, the progress coordination between the mobile terminal manufacturer and the third-party MIDlet developer is more difficult. SUMMARY OF THE INVENTION The present invention is directed to a local interface display method and system to solve the problem that the local interface display method in the related art depends on the Java runtime environment of the target terminal or the extended API class library, which affects the development efficiency. An aspect of the present invention provides a local interface display method, including: a Java application sends interface display information to a Java virtual machine, where the interface display information includes: an interface display command; the Java virtual machine will display the interface The display information is transparently transmitted to the local interface interface; the local interface interface displays the local interface according to the interface display information.

The sending, by the Java application, the interface display information to the Java virtual machine includes: the Java application transmitting the interface display information to the Java virtual machine through a standard API. The standard API includes a platformRequest function, and the sending, by the Java application, the interface display command to the Java virtual machine through a standard application program interface API includes: the Java application using the interface display information as a parameter of the platformRequest function , and call the platformRequest function. The Java application uses the interface display information as a parameter of the platformRequest function, including: a parameter format negotiated with the local interface interface, and the Java application constructs the interface display information into a parameter of the platformRequest function. In the case that the Java virtual machine does not support the parameter format, the method further includes: the Java virtual machine throwing an exception indication, and the Java application captures and ignores processing the abnormality indication. The interface display information further includes an extension flag corresponding to the local interface display. Before the Java virtual machine transparently transmits the interface display information to the local interface interface, the method further includes: the Java virtual machine determining to receive the Whether the extended flag in the interface display information is the same as the extended flag corresponding to the local interface display, and if so, the subsequent processing is continued. The interface display information further includes: an interface display parameter corresponding to the interface display command. In a case where the content included in the interface display information exceeds one item, the included content is separated by a preset separator. Another aspect of the present invention provides a local interface display system, including: a Java application processor, configured to send interface display information to a Java virtual machine, where the interface display information includes: an interface display command; The virtual machine is configured to transparently transmit the interface display information to the local interface interface, and the local interface interface is configured to perform local interface display according to the interface display information. The Java application processor is configured to send the interface display command to the Java virtual machine via a standard API. With the present invention, after the Java application sends the interface display information to the Java virtual machine, the Java virtual machine transparently transmits the interface display information to the local interface interface, so that the local interface interface performs the local interface.

The Java runtime environment supports the extended API class library, which affects the development efficiency. It improves the performance of the Java application, and does not depend on the Java runtime environment of the target terminal or the extended API class library, which improves the development efficiency. BRIEF DESCRIPTION OF THE DRAWINGS The accompanying drawings, which are set to illustrate,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,, 1 is a schematic diagram of an enhanced interface display effect according to the related art; FIG. 2 is a flowchart of a local interface display method according to an embodiment of the present invention; FIG. 3 is a flowchart of the present invention. FIG. 4 is a schematic diagram of a method for implementing an enhanced interface display effect according to the first embodiment of the present invention; FIG. 5 is a diagram showing a local interface display method according to Embodiment 2. A schematic diagram applied to a mobile terminal. BEST MODE FOR CARRYING OUT THE INVENTION Hereinafter, the present invention will be described in detail with reference to the accompanying drawings. It should be noted that the embodiments in the present application and the features in the embodiments may be combined with each other without conflict. 2 is a flowchart of a local interface display method according to an embodiment of the present invention. The method includes: Step S202: The Java application sends the interface display information to the Java virtual machine, where the interface display information includes: an interface display command; S204: The Java virtual machine transparently transmits the interface display information to the local interface interface. In step S206, the local interface interface displays the local interface according to the interface display information. Through the above method, it is not necessary to provide support for the extended API class library in the development environment of the Java application development. When the Java application is executed on the target terminal, the local platform of the target terminal is not required to support the extended API class library, and the solution is solved. The local interface display method in the related art depends on the development environment or the Java runtime environment of the target terminal, and the support of the extended API class library causes problems affecting the development efficiency, improves the performance capability of the Java application, and does not depend on the target terminal. The Java runtime environment or development environment supports the extended API class library and improves development efficiency. In practical applications, Java applications can send interface display information to the Java virtual machine through standard APIs. The method only needs to display information through the interface of the standard API, and the Java virtual machine can identify and process the API without any problem, thereby transparently transmitting the interface display information carried therein to the local interface interface. Since the standard API can be supported in all Java runtime environments and MIDlet development environments, this approach no longer relies on extending the API library. Preferably, the above standard API can be implemented by using the platformRequest function, and the Java application uses the interface display information as a parameter of the platformRequest function, and invokes

platformRequest function. The method uses the platformRequest function of the MIDP2.0 standard to extend the parameter format of the MIDP2.0 standard, and supports the Java application to pass the display requirements of its local interface through the MIDP standard interface function, interact with the local platform and the local application, and improve the performance capability of the MIDlet. Improve the user experience. Considering that the call parameter of the platformRequest function is a URL, in the process of using the interface display information as a parameter of the platformRequest function, the Java application can construct the interface display information into the parameters of the platformRequest function according to the parameter format negotiated with the local interface interface. In order to facilitate the development and debugging of the main functions of the Java application, it is considered that the display of the interface does not affect the implementation of these main functions. Therefore, the Java virtual machine on the development terminal does not support the parameter expansion of the standard API in this embodiment during development. The format, ie, the connection type identifier ( Scheme ) in the URL is not supported, the Java virtual machine can throw an exception indication, and the Java application captures and ignores the handling exception indication. This method brings great convenience to the development of Java applications and improves the efficiency of development. In order to facilitate the processing of the Java virtual machine, the interface display information may further include an extension flag corresponding to the local interface display, and the Java virtual machine determines to receive the interface display information before the Java virtual machine transparently transmits the interface display information to the local interface interface. Whether the extended flag is the same as the extended flag corresponding to the local interface display, and if so, the subsequent processing is continued; otherwise, the subsequent processing is performed according to the received extended flag (for example, tel: corresponds to making a call, http: // corresponds Called in the browser). Preferably, the above interface display information may further include: an interface display parameter corresponding to the interface display command. The parameter can be combined with the corresponding interface display command to jointly provide the displayed content to the local interface interface, so that the local interface interface control performs corresponding display. In order to facilitate the local interface interface or the Java virtual machine to parse the received string, if the interface display information contains more than one item, the content may be separated by a preset separator. 3 is a structural block diagram of a local interface display system according to an embodiment of the present invention. As shown in FIG. 3, the method includes: a Java application processor 32 configured to send interface display information to a Java virtual machine 34, where the interface displays The information includes: an interface display command; the Java virtual machine 34 is configured to transparently transmit the interface display information to the local interface interface 36; the local interface interface 36 is configured to display the local interface according to the interface display information. Preferably, the Java application processor 32 can send an interface display command to the Java virtual machine 34 via a standard API. The embodiment 1-3 described below combines the technical solutions of the above plurality of preferred embodiments. Embodiment 1 FIG. 4 is a schematic diagram of a method for implementing an enhanced interface display effect according to the first embodiment of the present invention. As shown in FIG. 4, the method only needs to increase the implementation of the platformRequest in the migration implementation layer; MIDlet development You only need to use the platformRequest parameter format as agreed. Now, you don't have to wait for the extended API library. Compared with the usual extension method, there are two main differences: one is to use the standard platfomiRequest interface, and there is only one interface function; the other is to skip the modification of the Java runtime environment, and the MIDlet directly conforms to the format definition of the migration layer. That's it. The method is essentially encapsulated and transparently transmitted by means of the parameters of the standard API; the Java virtual machine running environment only needs to be slightly extended once, and the future expansion does not need to modify the Java virtual machine running environment. Based on the platfromRequest function already in the Java ME specification MIDP2.0, the parameter extension is extended, the extended command and the extended parameter format are defined, the MIDlet is supported to interact with the local application or the standby interface, and the icon display and partial of the status bar and the standby interface are completed. The window displays refresh and other functions to improve the performance of the MIDlet. The native platform application is only responsible for interface control, and the displayed content is provided by the Java application. At the same time, platfomiRequest belongs to the MIDP2.0 standard API, and the Java runtime environment of various mobile terminals can be supported. Since the platfomiRequest function itself is a canonical API, all MIDlet development environments should be supported, and there is no problem with compiling and debugging. In the MIDP standard, the parameter of the platfomiRequest function is a string whose content is usually dialed a telephone number (like "tel: +8613800138000"), or access to a specified web page via an HTTP browser (like "http: //www.google.com" )„ The platfomiRequest function in the MIDP 2.0 specification defines the following: public final boolean platformRequest(String URL) throws javax.microedition.io.ConnectionNotFoundException The key here is to construct the URL, which is to build Command and parameter string. As a preferred implementation, you can use platformRequestC "extension flag + extended command + variable length and number of extended parameters, ;;), as follows:

1. Define the extension flag. The extension flag has no other restrictions except that it cannot conflict with the content of the existing standard. For example, it can be defined as zte://. The flag is first judged in the Java virtual machine, for example, tel: a call corresponding to the MIDP standard, and http:// corresponds to a browser call of the MIDP standard. If an extension flag is detected, it is determined that further processing is required, and the virtual machine transparently transmits the parameter string to the local interface interface. 2. Define an extension command. The command format requires the Java application to negotiate with the local interface interface in order to properly complete the parsing of the request command and subsequent parameters. Commands include, but are not limited to, "Set New Message Icon", "Set Current Temperature", etc., which are completely defined as needed.

3, define the extended parameters. The extended parameters must match the corresponding "extension commands" and are designed as needed.

4. Define the extended parameter separator. Since the parameter of the platformRequest is just a string, you need to define a suitable delimiter between the multiple extension parameters. The typical delimiter can be, but is not limited to, & or? .扩展 Expanding in this way, MIDlet development and debugging is simpler than using the Java extension class. It is convenient from both application development and Java runtime environment development. The specific reasons are as follows:

(1) When developing applications, the entire code can be written without special API support, and can be developed on any manufacturer's mobile terminal or simulator. During development, for the platform request parameter format that is not supported by the mobile terminal or the simulator Java runtime environment, the virtual machine throws a ConnectionNotFoundException, and the MIDlet only needs to catch the exception and ignore it. Since the extension function belongs to the MIDlet and the mobile terminal local platform/local application interaction, it is the icing on the cake. If the functions are not implemented on the simulator or the development mobile terminal, the main function development and debugging are not affected. When the MIDlet is developed, you can see the real effect by running on the target mobile terminal. (2) For the Java runtime environment, the local interaction functions vary widely, and different platform implementations may be different. In addition, the customization components have a greater impact. However, the call from the Java virtual machine has only one interface: platformRequest (so, this preferred interface allows the method to have cross-platform advantages). The local porting interface layer corresponding to the Java runtime environment is parameter parsing and concrete implementation, and this piece can be completely separated from the core part of the Java virtual machine. The virtual machine part does not need to be modified, and the customization and code maintenance are more convenient. . When the project requires the MIDlet and the mobile terminal to add a new function through cooperation, the two aspects of development can be carried out independently, and finally the simple joint debugging can be. Embodiment 2 FIG. 5 is a schematic diagram of applying the local interface display method to a mobile terminal according to Embodiment 2. As shown in FIG. 5, each application is extended by using the platformRequest parameter, and the reference layer is parsed in the migration layer. The number format distinguishes the location to which the target interface belongs, and then displays the corresponding content to the target location, thereby completing the function of the Java application controlling the local interface display. For example: The instant messaging application displays the status icon of the user "online" or "offline" on the top bar interface of the mobile phone through the "online status update"message; the weather application uses the "weather information update" message, in the window of the standby interface 1 The latest weather forecast information is displayed inside; the news reading application scrolls through the news headline content in the window 2 of the standby interface. Embodiment 3 Since there is only one platformRequest function, a string URL can have an unlimited number of formats. The specific embodiments are described herein by way of example only, and are not intended to be construed as limiting. Take the instant messaging application IM as an example, set the online ^ in the top bar of the mobile terminal! State icon, described in the Java language, the statement that the request parameter URL consists of is as follows:

URL = "zte:〃 SET PRESENCE ICON" + ":" + "icon=" + status; In the string URL, zte:〃 is an extension flag indicating that the URL is a ZTE extension API call request. The uppercase string separated by a colon SET_PRESENCE_ICON represents the "extension command" that the request is executed. The remaining string after the colon is an extended parameter, status is an integer, representing the icon number, and the MIDlet and the platform developer are required to negotiate the corresponding icon number. In addition to the top bar display icon, the standby interface can also pop up a prompt box to prompt the IM to receive the status of the new message, and use multiple & extended parameters to separate them. The Java statement is as follows:

URL = "zte:〃 SET POPUP" + ":" +

"msnNew=" + msnNewMsgCount + "&" +

"aolNew=" + aolNewMsgCount + "&" +

"yahooNew=" + yahooNewMsgCount; The parameter format listed here is used to describe the command format for interaction between the MIDlet and the local interface. For the MIDlet, call the platfromRequest form: Try{ platformRequest(URL);

}catch(ConnectionNotFoundException ex) { } Calls the platformRequestO function and ignores the thrown exception. It can be seen from the above description that the solution provided by the above embodiment has low technical complexity and is simple and easy to implement. In practice, the required functionality can be easily implemented and easily extended. After the virtual machine integrates the extended flag recognition, the subsequent extended command tampering does not require any changes to the Java virtual machine core code, and only needs to be tampered with at the migration layer and the local layer. Therefore, this method is especially suitable for the outsourcing of the JVM operating environment (for example, the mobile terminal manufacturer outsources the Java modules provided by other companies in binary form), and the mobile terminal manufacturer basically does not need the JVM provider to modify the JVM core module. For a large number of operators customized mobile terminal projects and more pre-installed third-party Java applications, the overall development and debugging efficiency is significantly improved. Obviously, those skilled in the art should understand that the above 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 particular combination of hardware and software. The above description is only the preferred embodiment of the present invention, and is not intended to limit the present invention, and various modifications and changes can be made to the present invention. Any modifications, equivalent substitutions, improvements, etc. made within the scope of the present invention are intended to be included within the scope of the present invention.

Claims

Claim

1. A local interface display method, including:

The Java application sends the interface display information to the Java virtual machine, where the interface display information includes: an interface display command;

The Java virtual machine transparently transmits the interface display information to the local interface interface; the local interface interface performs local interface display according to the interface display information.

2. The method according to claim 1, wherein the sending, by the Java application, the interface display information to the Java virtual machine comprises:

The Java application sends the interface display information to the Java virtual machine via a standard application interface API.

3. The method of claim 2, wherein the standard API comprises a platformRequest function, and the sending, by the Java application, the interface display command to the Java virtual machine via a standard API comprises:

The Java application uses the interface display information as a parameter of the platformRequest function and invokes the platformRequest function.

The method according to claim 3, wherein the Java application uses the interface display information as a parameter of the platformRequest function, including:

The Java application constructs the interface display information into parameters of the platformRequest function according to a parameter format negotiated with the local interface interface.

5. The method of claim 4, wherein, in the case that the Java virtual machine does not support the parameter format, the method further includes:

The Java virtual machine throws an exception indication that the Java application captures and ignores processing the exception indication.

The method of claim 1, wherein the interface display information further comprises an extension flag corresponding to the local interface display, before the Java virtual machine transparently transmits the interface display information to the local interface interface, Also includes: The Java virtual machine determines whether the extended flag in the interface display information is the same as the extended flag corresponding to the local interface display, and if so, continues the subsequent processing.

The method according to claim 1, wherein the interface display information further comprises: an interface display parameter corresponding to the interface display command.

The method according to any one of claims 1 to 7, wherein, in a case where the content included in the interface display information exceeds one item, the included content is separated by a preset separator open.

9. A local interface display system, comprising:

The Java application processor is configured to send the interface display information to the Java virtual machine, where the interface display information includes: an interface display command;

The Java virtual machine is configured to transparently transmit the interface display information to the local interface, and the local interface interface is configured to perform local interface display according to the interface display information. The system of claim 9, wherein the Java application processor is configured to send the interface display command to the Java virtual machine via a standard application interface API.