Method for managing java applications
专利汇可以提供Method for managing java applications专利检索，专利查询，专利分析的服务。并且A method for managing JAVA applications executable in a user device provides an expandability for and a continuity between JAVA applications by changing states of the JAVA applications in execution and sharing information between the JAVA applications.，下面是Method for managing java applications专利的具体信息内容。
What is claimed is:
This application claims the benefit of Korean Patent Application No. 10-2009-0014161 filed on Feb. 20, 2009, which is hereby incorporated for reference.
1. Field of the Invention
The present invention relates to a method for managing JAVA applications executable in a user device.
2. Description of the Related Art
Conventional televisions or conventional DVD players are only capable of playing audio/video data. However, latest digital televisions and blu-ray players are capable of providing an environment for executing applications.
Latest mobile communication terminals are also capable of providing the environment.
The applications executable in user devices such as the digital televisions, blu-ray players and mobile communication terminal is usually created using JAVA language (hereinafter referred to as “JAVA application”) and provided to the user device in a byte code format.
Operations such as a start and an end of the application and an access to system resources are carried out between the application and an operating system on which the application is executed.
An application model defines how the application should be managed and also defines roles of the operating system and the application.
JAVA Specifications such as J2ME (JAVA 2 Platform Micro Edition) and J2SE (JAVA 2 Platform Sun Edition) currently supports various application models. Applet and Xlet are examples of the application model.
Sun Microsystems provides Xlet for executing the JAVA application in an embedded device such as the digital television. While Applet is an embedded application which is executed in a browser, Xlet is an embedded application executed in the embedded device.
Generally, one JAVA application is executed and displayed on a single screen of the user device.
For instance, when another JAVA application is selected for execution while a startup JAVA application is executed and displayed, the startup JAVA application is then halted and the selected JAVA application is executed.
In other words, the JAVA applications executed in the user device are independent of each other. Therefore, it is difficult to guarantee a continuity between the JAVA applications because information between the independent JAVA applications cannot be shared.
It is an object of the present invention to provide a method for managing JAVA applications wherein an expandability for and a continuity between JAVA applications are provided by changing states of the JAVA applications in execution and sharing information between the JAVA applications.
In order to achieve above-described objects of the present invention, there is provided a method for managing JAVA applications executable in a user device, the method comprising steps of: (a) issuing a request for executing a second JAVA application, the request being issued by a first JAVA application and including a execution type information; (b) changing a state of the first JAVA application according to the execution type information; (c) executing the second JAVA application; and (d) killing the second JAVA application when a request for killing the second JAVA application is issued by the second JAVA application and re-changing the state of the first JAVA application changed in the step (b).
Preferably, the first JAVA application generates the request for executing the second JAVA application based on a user input received through a user interface.
Preferably, the request for executing the second JAVA application further includes a path for obtaining the second JAVA application.
Preferably, the step (c) comprises executing the second JAVA application by obtaining the second JAVA application at a location defined by the path.
Preferably, the execution type information designates one of: a first execution type wherein the first JAVA application is killed when the second JAVA application is executed and the first JAVA application is restarted when the second JAVA application is killed; a second execution type wherein the first JAVA application is paused when the second JAVA application is executed and the first JAVA application is unpaused when the second JAVA application is killed; and a third execution type wherein the first JAVA application is switched to background when the second JAVA application is executed and the first JAVA application is switched to foreground when the second JAVA application is killed.
Preferably, the step (b) comprises: killing the first JAVA application when the execution type information designates the first execution type; pausing the first JAVA application when the execution type information designates the second execution type; and switching the first JAVA application to background when the execution type information designates the third execution type.
Preferably, the step (d) comprises: restarting the first JAVA application when the execution type information designates the first execution type; unpausing the first JAVA application when the execution type information designates the second execution type; and switching the first JAVA application to foreground when the execution type information designates the third execution type.
Preferably, the first JAVA application and the second JAVA application inter-relays a shared information.
Preferably, the first JAVA application and the second JAVA application inter-relays a shared information when the execution type information designates one of the second execution type and the third execution type.
Preferably, each of the first JAVA application and the second JAVA application includes a JAVA application of Xlet format.
There is also provided a method for managing JAVA applications executable in a user device, the method comprising steps of: (a) issuing a request for executing a second JAVA application, the request being issued by a first JAVA application; (b) pausing the first JAVA application; (c) executing the second JAVA application; and (d) killing the second JAVA application when a request for killing the second JAVA application is issued by the second JAVA application and unpausing the first JAVA application paused in the step (b).
Preferably, the first JAVA application generates the request for executing the second JAVA application based on a user input received through a user interface.
Preferably, the request for executing the second JAVA application further includes a path for obtaining the second JAVA application.
Preferably, the step (c) comprises executing the second JAVA application by obtaining the second JAVA application at a location defined by the path.
Preferably, the first JAVA application and the second JAVA application inter-relays a shared information.
Preferably, each of the first JAVA application and the second JAVA application includes a JAVA application of Xlet format.
There is also provided a method for managing JAVA applications executable in a user device, the method comprising steps of: (a) issuing a request for executing a second JAVA application, the request being issued by a first JAVA application; (b) switching the first JAVA application to background; (c) executing the second JAVA application; and (d) killing the second JAVA application when a request for killing the second JAVA application is issued by the second JAVA application and switching the first JAVA application in background to foreground.
Preferably, the first JAVA application generates the request for executing the second JAVA application based on a user input received through a user interface.
Preferably, the request for executing the second JAVA application further includes a path for obtaining the second JAVA application.
Preferably, the step (c) comprises executing the second JAVA application by obtaining the second JAVA application at a location defined by the path.
Preferably, the first JAVA application and the second JAVA application inter-relays a shared information.
Preferably, each of the first JAVA application and the second JAVA application includes a JAVA application of Xlet format.
A method for managing a JAVA application in accordance with the present invention will be described with reference to accompanied drawings.
Referring to
The JAVA application server 100 stores a JAVA application and transmits the JAVA application to the user device 200 when requested by the user device 200.
The user device 200 executes the JAVA application received from the JAVA application server 100 to be provided to a user. The user device 200 may include a digital television, a set-top box, a blu-ray player or a mobile communication terminal.
The JAVA application server 100 and the user device 200 are connected via a communication network such as the Internet and a wireless network.
Hereinafter, an application developer refers to a person who develops the JAVA application which may be executed in the JAVA application server 100 or the user device 200, the user refers to a person who uses the user device 200 and takes advantage of a service provided via the JAVA application developed by the application developer.
The user device 200 comprises a boot program 210, a run-time program 230 and a JAVA application 290.
The boot program 210 is stored within the user device 200 or in a storage medium accessible by the user device 200. The boot program 210 checks a status of the user device 200 and searches and obtains the suitable run-time program 230.
The run-time program 230 provides a run-time environment for the JAVA application 290.
The run-time program 236 includes an X2let API 231, a method invocation API 233, a resource support API 235, an application manager API 237 and a debug support tool 239.
The X2let API 231 developed by the Applicant is implemented by an enhanced Xlet in compliance with JAVA TV standard.
The X2let API 231 supports downloading of the JAVA application 290 from the JAVA application server 100 and execution of the downloaded JAVA application 290.
The method invocation API 233 developed by the Applicant executes a method in the JAVA application server 100 from the user device 200.
The resource support API 235 developed by the Applicant supports a memory-effective caching and a resource downloading. The resource support API 235 may handle resources such as an image, a byte array, a sound and a JAVA class.
The application manager API 237 developed by the Applicant manages a life cycle of the JAVA application 290. The JAVA application 290 may be started, paused, unpaused, switched to background or foreground and killed via the application manager API 237.
The debug support tool 239 237 developed by the Applicant supports debugging.
The JAVA application 290 may be classified into a root JAVA application 293 and a user JAVA application 296.
The root JAVA application 293 is a base application executed in the user device 200. The root JAVA application 293 is required to be executed in the user device 200. The root JAVA application 293 is executed at a startup of the user device 200 and displayed on a screen of the user device 200. The root JAVA application 293 may include a user interface for selecting the user JAVA application 296 to be executed. The user interface may be implemented as a graphical user interface. The user may select the user JAVA application 296 to be executed via the user interface.
The user JAVA application 296 is selected by the user and then executed. The user JAVA application 296 refers to the JAVA application other than the root JAVA application 293.
While the root JAVA application 293 is created by a manufacturer of the user device 200 and distributed with the user device 200, the user JAVA application 296 is created by the application developer and transmitted to the user device 200 through the JAVA application server 100.
The method in accordance with the present invention will be described in detail hereinafter.
Referring to
The request includes an execution type information.
The first JAVA application may be the root JAVA application denoted as reference numeral 293 in
When the root JAVA application issues the request for executing a first child JAVA application, the root JAVA application and first child JAVA application correspond to the first JAVA application and the second JAVA application, respectively.
When first child JAVA application issues the request for executing a second child JAVA application, first child JAVA application and the second child JAVA application correspond to the first JAVA application and the second JAVA application, respectively.
The first JAVA application may include the user interface for receiving a user input.
The user interface may be the graphical user interface for executing the second JAVA application. When the user input is received while executing the first JAVA application, the first JAVA application generates and issues the request for executing the second JAVA application.
The request includes the execution type information which designates an execution type.
The execution type includes one of a first execution type, a second execution type and a third execution type.
In accordance with the first execution type, the first JAVA application is killed when the second JAVA application is executed and the first JAVA application is restarted when the second JAVA application is killed.
In accordance with the second execution type, the first JAVA application is paused when the second JAVA application is executed and the first JAVA application is unpaused when the second JAVA application is killed.
In accordance with the third execution type, the first JAVA application is switched to background when the second JAVA application is executed and the first JAVA application is switched back to foreground when the second JAVA application is killed
In accordance with the present invention, a state of the first JAVA application is determined when the second JAVA application is executed.
When the execution type information does not designate certain the execution types, it may be regarded that the execution type information designates the first execution type.
That is, when the execution type information included in the request that does not designate the certain the execution type is issued, subsequent steps are carried out on an assumption that the execution type is the first execution type.
The request may also include a path for obtaining the second JAVA application.
When the second JAVA application is stored within the user device, the path may represent a location of the second JAVA application in the user device.
When the second JAVA application is stored in the JAVA application server, the path may represent a location of the second JAVA application in the JAVA application server.
The path may have a form of an URL (uniform resource locator).
Thereafter, the state of the first JAVA application is changed according to the execution type information included in the request issued in the step S110 (S130).
Referring to
When the execution type designated in the execution type information is the second execution type, the first JAVA application is paused (S134 and S135).
When the execution type designated in the execution type information is the third execution type, the first JAVA application is switched to background (S137 and S138).
Referring back to
Thereafter, When a request for killing the second JAVA application is issued while the second JAVA application is executed, the second JAVA application is killed and the first JAVA application state of which is changed in the step S130 is re-changed (S170).
Referring to
When the execution type designated in the execution type information is the second execution type, the paused first JAVA application is unpaused (S174 and S175).
When the execution type designated in the execution type information is the third execution type, the first JAVA application in the background is switched back to foreground (S177 and S178).
The first JAVA application and the second JAVA application may relay a shared information to each other, i.e., inter-relay the shared information.
Specifically, if the second JAVA application executed in the step S150 obtains the shared information that is to be shared with the first JAVA application, the second JAVA application may relay the shared information to the first JAVA application in the step S170, and the first JAVA application may use the relayed information.
In one embodiment, when the first JAVA application receives the user input and the received user input includes a certain information which corresponds to the shared information, the first JAVA application transmits the certain information included in the user input to the second JAVA application, and the second JAVA application may use the certain information.
Similarly, when the second JAVA application receives the user input and the received user input includes a certain information which corresponds to the shared information, the second JAVA application transmits the certain information included in the user input to the first JAVA application, and the first JAVA application may use the certain information.
Particularly, the shared information may be inter-relayed when the execution type is the second execution type or the third execution type.
An application manager shown in
Referring to
Here, the root JAVA application and the first child JAVA application correspond to the first JAVA application and the second JAVA application, respectively.
The request for executing the first child JAVA application is denoted as startApp(root, Bound, c1URL) in
startApp(root, Bound, c1URL) represents the request for executing, by the root JAVA application (denoted as “root”), the first child JAVA application located at a path “c1URL” according to the second execution type (denoted as “Bound”).
When the request startApp(root, Bound, c1URL) is received, the application manager pauses the root JAVA application using pauseXlet( ) function.
The application manager also initializes the first child JAVA application using initXlet( ) function, and starts the first child JAVA application using startXlet( ) function.
Thereafter, the first child JAVA application transmits a request for executing the second child JAVA application to the application manager.
Here, the first child JAVA application and the second child JAVA application correspond to the first JAVA application and the second JAVA application, respectively.
The request for executing the second child JAVA application is denoted as startApp(child1, Bound, c2URL) in
startApp(child1, Bound, c2URL) represents the request for executing, by the first child JAVA application (denoted as “child1”), the second child JAVA application located at a path “c2URL” according to the second execution type (denoted as “Bound”).
When the request startApp(child1, Bound, c2URL) is received, the application manager pauses the root JAVA application using pauseXlet( ) function.
The application manager also initializes the second child JAVA application using initXlet( ) function, and starts the second child JAVA application using startXlet( ) function.
When destroyApp(child2) which is a request for killing the second child JAVA application is received from the second child JAVA application, the application manager kills the second child JAVA application using destroyXlet( ) function.
When the second child JAVA application is killed, the application manager unpauses the paused first child JAVA application. In other words, the application manager starts the first child JAVA application using startXlet( ) function.
When destroyApp(child1) which is a request for killing the first child JAVA application is received from the first child JAVA application, the application manager kills the first child JAVA application using destroyXlet( ) function.
When the first child JAVA application is killed, the application manager unpauses the paused root JAVA application. In other words, the application manager starts the root JAVA application using startXlet( ) function.
Referring to
The request for executing the JAVA application “A” is denoted as startApp(root, Standard, aURL) in
startApp(root, Standard, aURL) represents the request for executing, by the root JAVA application (denoted as “root”), the JAVA application “A” located at a path “aURL” according to the first execution type (denoted as “Standard”).
When the request startApp(root, Standard, aURL) is received, the application manager kills the root JAVA application using destroyXlet( ) function.
The application manager also initializes the JAVA application “A” using initXlet( ) function, and starts the JAVA application “A” using startXlet( ) function.
When destroyApp(A) which is a request for killing the JAVA application “A” is received from the JAVA application “A”, the application manager kills the JAVA application “A” using destroyXlet( ) function.
When the JAVA application “A” is killed, the application manager restarts the root JAVA application killed by destroyXlet( ) function. In other words, the application manager starts the root JAVA application using startXlet( ) function.
Thereafter, the root JAVA application transmits a request for executing a JAVA application “B” to the application manager.
The request for executing the JAVA application “B” is denoted as startApp(root, Standard, bURL) in
startApp(root, Standard, bURL) represents the request for executing, by the root JAVA application (denoted as “root”), the JAVA application “B” located at a path “bURL” according to the first execution type (denoted as “Standard”).
When the request startApp(root, Standard, bURL) is received, the application manager kills the root JAVA application using destroyXlet( ) function.
The application manager also initializes the JAVA application “B” using initXlet( ) function, and starts the JAVA application “B” using startXlet( ) function.
When destroyApp(B) which is a request for killing the JAVA application “B” is received from the JAVA application “B”, the application manager kills the JAVA application “B” using destroyXlet( ) function.
When the JAVA application “B” is killed, the application manager restarts the root JAVA application killed by destroyXlet( ) function. In other words, the application manager starts the root JAVA application using startXlet( ) function.
A configuration for changing the state of the JAVA application based on the third execution type is similar to that shown in
When the state of the JAVA application is changed based on the third execution type, background( ) function for switching the JAVA application to the background is used in place of pauseXlet( ) function, and the JAVA application in the background is then switched to foreground.
Referring to
Thereafter, the first JAVA application is paused (S230).
Thereafter, the second JAVA application is obtained and executed in parallel with or after carrying out the step S230 (S250).
When a request for killing the second JAVA application is issued while the second JAVA application is executed, the second JAVA application is killed and the first JAVA application paused in the step S230 is unpaused (S270).
In accordance with the second embodiment, the execution type information is not included in the request for executing the second JAVA application. The second embodiment is identical to the first embodiment except that the execution type information is not included in the request. Therefore, a detailed description is omitted.
Referring to
Thereafter, the first JAVA application is switched to background (S330).
Thereafter, the second JAVA application is obtained and executed in parallel with or after carrying out the step S330 (S350).
When a request for killing the second JAVA application is issued while the second JAVA application is executed, the second JAVA application is killed and the first JAVA application in the background is switched to foreground (S370).
In accordance with the third embodiment, the execution type information is not included in the request for executing the second JAVA application. The third embodiment is identical to the second embodiment except that the first JAVA application is switched to background instead of being paused. Therefore, a detailed description is omitted.
In accordance with the present invention, because the first JAVA application may be associated with the second JAVA application, a use of the JAVA application for the user is facilitated, and the JAVA applications developed by different application developers can be associated with each other in order to improve an expandability. For instance, the application developer may create the first JAVA application in a manner that the first JAVA application includes a path for the second JAVA application in order for the user to take advantage of the second JAVA application.
Particularly, the present invention may be applied to base applications of TV portal services, smart phones and Blu-ray players employing the JAVA application.
Various services may be provided based on the execution type information and the path even when the base application does not include every function.
Moreover, the first JAVA application and the second JAVA application inter-relays the shared information in order to guarantee a continuity therebetween.
While the present invention has been particularly shown and described with reference to the preferred embodiment thereof, it will be understood by those skilled in the art that various changes in form and details may be effected therein without departing from the spirit and scope of the invention as defined by the appended claims.
| 标题 | 发布/更新时间 | 阅读量 |
|---|---|---|
| 再现装置、再现方法 | 2020-05-19 | 95 |
| METHOD FOR THE ATTENUATION OF MULTIPLE REFLECTIONS IN SHALLOW WATER SETTINGS | 2020-05-08 | 628 |
| Image display apparatus and method for providing Xlet thereof | 2020-05-20 | 782 |
| IMAGE FORMING APPARATUS, TERMINAL APPARATUS, INFORMATION PROCESSING METHOD, INFORMATION PROCESSING PROGRAM AND COMPUTER READABLE RECORDING MEDIUM | 2020-05-17 | 210 |
| Method for obtaining context of corresponding Xlet while playing BD-J title | 2020-05-26 | 548 |
| Terminal equipment, information processing method, information processing program, recording medium, and an information processing system | 2020-05-16 | 118 |
| System and method for tuning digital television channels | 2020-05-22 | 282 |
| Image display apparatus | 2020-05-11 | 596 |
| 영상표시장치 및 그의 엑스렛 제공 방법 | 2020-05-16 | 784 |
| 어플리케이션 실행 방법 및 이를 구현하는 셋톱박스 | 2020-05-12 | 496 |
高效检索全球专利专利汇是专利免费检索,专利查询,专利分析-国家发明专利查询检索分析平台，是提供专利分析，专利查询，专利检索等数据服务功能的知识产权数据服务商。
我们的产品包含105个国家的1.26亿组数据，免费查、免费专利分析。
专利汇分析报告产品可以对行业情报数据进行梳理分析，涉及维度包括行业专利基本状况分析、地域分析、技术分析、发明人分析、申请人分析、专利权人分析、失效分析、核心专利分析、法律分析、研发重点分析、企业专利处境分析、技术处境分析、专利寿命分析、企业定位分析、引证分析等超过60个分析角度，系统通过AI智能系统对图表进行解读，只需1分钟，一键生成行业专利分析报告。
