WO2006120280A1

WO2006120280A1 - Application desktop management

Info

Publication number: WO2006120280A1
Application number: PCT/FI2005/050146
Authority: WO
Inventors: Gábor PALLER; Roop Kiran Guduri
Original assignee: Nokia Corporation
Priority date: 2005-05-09
Filing date: 2005-05-09
Publication date: 2006-11-16

Abstract

The invention relates to a method for arranging application management in a configuration, wherein a native first application program is executable in a first execution environment for native applications and manageable by a first application manager, and a non-native second application program is executable in a second execution environment for non-native applications and manageable by a second application manager. The configuration is arranged to deliver desktop management information from the first application manager to the second application manager and/or from the second application manager to the first application manager.

Description

APPLICATION DESKTOP MANAGEMENT

FIELD OF THE INVENTION

The present invention relates to arranging application desktop management in electronic devices, and more particularly application desktop man- agement in an electronic device comprising an execution environment for native applications and an execution environment for non-native applications.

BACKGROUND OF THE INVENTION

Java™ is an object-oriented programming language. Java applications have become increasingly popular in various electronic devices. The Java application platform consists of two parts: a programming language, and an execution environment. Java is widely used especially to create downloadable applications. The current version of Java is Java 2, and this is divided into three editions: Java 2 Enterprise Edition (found on high-end business machines), Java 2 Standard Edition (found on desktop computers), and Java 2 Micro Edition or J2ME, which works with smaller handheld devices such as mobile phones and personal digital assistants (PDAs). The J2ME platform is a collection of technologies and specifications designed for small devices. The core of the J2ME platform is formed by two different configurations, Connected Device Configuration (CDC) and Connected Limited Device Configuration (CLDC). A configuration defines central Java technology libraries and virtual machine capabilities. CLDC is targeted at portable devices such as mainstream mobile phones, whereas CDC is targeted at more advanced mobile devices. On top of the configurations are the profiles that define the key functionality and application programming interfaces (APIs) in a specific device cate- gory. The Mobile Information Device Profile (MIDP) is a profile for devices using CLDC. The MIDP allows Java application developers to make use of some features of the device user interface and hardware such as lights, sound, and vibration.

Native applications are applications executed in a native environ- ment, i.e. on top of an operating system using hardware resources of a computing device. Java applications are non-native applications since they are executed in a specific Java virtual machine which is running on top of the native environment. This virtual machine acts as an interpreter translating Java code into native machine instructions. Conventional CLDC Java virtual ma- chines (JVMs) enable only one Java application to be executed at a time. A need exists to be able to run multiple Java applications in a single JVM since multiple JVMs require a large amount of memory. OSGi™ Alliance (http://www.osgi.org) has specified an OSGi service platform allowing parallel execution of multiple Java applications in a single JVM. From the user's point of view, the JVM appears as one of the running processes in the same way as native applications. Some solutions for arranging a Java desktop, i.e. a single user interface to view and manage active Java applications, have been developed. However, existing Java desktops are based on a Java system only and if they were used with a native environment, the Java desktop would be separate from the native desktop providing for instance icons of native applications and a list of active native applications. This means that the user has to select the Java desktop if he or she wishes to launch a specific Java application. The use of two desktops is complicated and it cannot be expected from end users that they care about the differences be- tween a Java and a non-Java application.

BRIEF DESCRIPTION OF THE INVENTION

A method, an electronic device, an application management system, and a computer program product have now been developed, which are characterized by what is stated in the independent claims. Some embodiments of the invention are described in the dependent claims.

According to an aspect of the invention, an electronic device comprising native and non-native application managers is provided with means for delivering desktop management information from a first application manager to a second application manager and/or from the second application manager to the first application manager.

The term "desktop management information" is to be understood broadly to refer to any information related to or caused by a desktop function (for managing information to/from a user interface of the electronic device and/or for arranging management of an application, i.e. a desktop manage- ment action, in the electronic device for instance based on an input from the user interface), such as information related to a view showing icons of applications in the electronic device. It is to be noted that besides referring to some desktop operation related information, the term "desktop management information" may refer to a request or a command to initiate an action related to or caused by desktop management. An application manager is an entity arranged to perform one or more application management related features. The invention makes it possible to arrange desktop management features for both native and non-native applications on the basis of desktop management related information delivered between non-native and native application managers. Interaction between native and non-native execution envi- ronments is facilitated and it becomes possible to provide integrated desktop management facilities. In one embodiment, the electronic device is configured to display information on non-native and native applications in a single view by using desktop management information. Thus, a Java application may be represented in the same way as any other application in the system, for instance by having an icon or a title on the desktop view such that the user may select/launch the application by clicking on the icon. The end user is not required to have any knowledge on the programming code types of the applications he or she is using, i.e. whether an application is written in non-native or in native code.

BRIEF DESCRIPTION OF THE FIGURES

The invention will now be described in greater detail by means of some embodiments and with reference to the attached drawings, in which

Figure 1 is a block diagram illustrating some resources of an electronic device in accordance with an embodiment of the invention, Figure 2 is a flow diagram illustrating a method according to an embodiment of the invention, and

Figure 3 is a signalling diagram illustrating some exemplary embodiments of the invention.

DETAILED DESCRIPTION OF SOME EMBODIMENTS OF THE INVENTION One embodiment of the invention is described in the following in a system comprising a Java application environment; it should, however, be noted that the application of the invention is not limited to such systems. The invention may be applied to any electronic device capable of providing native and non-native execution environments for providing native and non-native applications.

Figure 1 illustrates some resources in an electronic device 100 in accordance with an embodiment of the invention. For instance, the electronic device 100 could be a portable device, such as a mobile communications device, a PDA (Personal Digital Assistant), a laptop computer, or a personal en- tertainment device. Although not shown in Figure 1 , the electronic device 100 further comprises memory, I/O means for data transmission, and a processing unit comprising one or more processors. Hardware specific resources are illustrated by reference 110 in Figure 1. The memory may be used for storing application programs, and the processing unit is coupled to the memory and is used for executing application programs. Computer program code portions executed in the central processing unit can cause the electronic device 100 to implement the inventive means and functions relating to desktop management information and the delivery and usage thereof in the electronic device 100, some embodiments of which to be illustrated below. It is to be noted that one or more entities may be configured to carry out the inventive features, in one embodiment, program code for inventive functions is provided as part of a program code providing an application manager 134 or 144. A computer program can be stored on any storage medium from which it can be loaded into the memory of the electronic device 100 running it. The computer program could also be loaded through a network by using a TCP/IP protocol stack, for instance. If the electronic device 100 is provided with a transceiver for wireless communication, the electronic device 100 may be arranged to download the program code wirelessly via a wireless network. It is also possible to use hardware solutions or a combination of hardware and software solutions to im- plement the inventive means. A chip unit or some other kind of hardware module for controlling the electronic device 100 may, in one embodiment, cause the device to perform the inventive functions. The hardware module comprises connecting means for connecting to the electronic device 100 mechanically and/or functionally. Thus, a hardware module may form part of the device and could be removable. Some examples of such a hardware module include a sub-assembly, a portable data storage medium, an IC card, or an accessory device.

On top of the hardware resources 110, a native operating system (OS) 120 is executed. Native application programs, hereafter referred to as na- tive applications 146, are executable in a native execution environment 140. The native applications 146 are managed by a native application manager 144. A Java execution environment 130 is provided on top of the operating system 120. Java application programs 136 are executed by a Java virtual machine 132. A Java application manager 134 manages these non-native Java application programs 136. An application manager 134, 144 is generally an entity arranged to perform one or more application management related features. These application management features may include all aspects of an application lifecycle: starting, stopping, focus traversal, etc. An application manager 134, 144 may further comprise sub-entities, such as a process manager taking care of the lifecycle of applications and a window manager taking care of application related display features, such as window positions.

The native application manager 144 and the Java application manager 134 are connected by an integration interface 150 by which desktop management information may be delivered between the native application manager 144 and the Java application manager 134. Desktop management information may be any desktop management related information, such as commands, notifications, requests, and/or responses to cause a desktop management action. However, it is to be noted that the interface 150 may be used for delivering also other information than desktop management related information between the application managers 134, 144. A desktop managing functionality is implemented in the native application manager 144 and/or the Java application manager 134.

The electronic device 100 further comprises user interface re- sources 160 arranged to deliver information to the user and to receive user inputs. For instance, the user interface resources 160 may comprise a screen, a keypad, and a means for detecting inputs to these components.

The native application manager 144 or the Java application manager 134 may be configured to function as a desktop manager (not shown in Figure 1 ) communicating with the user interface 160. The desktop manager may be configured to act as a mediator between the native execution environment 140 and the Java execution environment 130 in desktop management related functions and is arranged to receive and submit desktop management information. The desktop manager may be arranged to provide at least one desktop view to be displayed on the screen of the electronic device 100 and to receive desktop specific inputs from the user via the user interface 160. For instance, one desktop view may comprise icons of available applications, both native and non-native 146, 136, and another exemplary desktop view may indicate a list of running applications 136, 146 in the electronic device 100. Figure 2 illustrates basic functions of a desktop manager configured to communicate with an application manager (134 or 144 in another execution environment). In step 200, a need exists to perform a desktop management specific operation which is related to at least one application (136 or 146) in the other execution environment. This need may arise in many circumstances, for instance on the basis of an input from the user. The desktop manager is ar- ranged to specify 202 a request, which may indicate a related application, and pass 204 it via the interface 150 to the other application manager in the other execution environment. Although not shown in Figure 2, the other application manager is arranged to receive the request via the interface 150 and determine one or more required actions on the basis of the request. Such an action could be a command to an application, retrieval of application information on the basis of the request, or storage of information in the request, for instance. The other application manager responds to the request and the desktop manager receives the response in step 206. The desktop manager may further perform 208 a desktop management related action on the basis of the received response. The response may comprise some application information which the desktop manager utilizes in step 208, for instance the desktop manager prepares this information to be displayed on the user interface 160 for the user in a desktop specific view.

It is to be noted that instead of transmitting desktop management re- lated information by a request, the desktop manager may be arranged to transmit a notification or a direct command, for instance, to the other application manager.

Some embodiments relating to the above-illustrated system are illustrated below. It is to be noted that not all features are necessary in a system supporting delivery of desktop management information between application managers (134, 144), and that in different embodiments these features may be combined differently.

First, the embodiment in which the desktop manager is provided by the native application manager 144 is illustrated. The native application man- ager 144 is arranged to communicate at least desktop management related information with the Java application manager 134 via the interface 150. In this embodiment, desktop management information for carrying out at least some of the following functionalities may be delivered via the interface 150 between the native 140 and Java environment 130: - Start and stop Java applications 136. - Provide a unified list for the currently running Java (and non-Java) applications.

- Move Java applications 136 between foreground and background states. - Launch Java applications 136 based on registered MIME types and allow association of MIME types with Java applications 136.

- Allow native applications 146 to reuse Ul parts (views) of Java applications 136 and Java applications 136 to reuse Ul parts of native applications 146. - Allow the native application manager 144 to display icons belonging to Java applications 136 even if the Java applications 136 do not follow the native environment's deployment convention.

Figure 3 illustrates some of these functions in more detail. In the first example, an end user clicks on an icon on the native desktop view, and an in- put is delivered 300 from a user interface (Ul) 160 to a native application manager (NAM) 144 comprising a desktop manager and thus providing the desktop. The desktop manager determines that the selected icon represents a Java application 136, and contacts 301 a Java application manager (JAM) 134 through an interface 150. A JVM 132 is started if it is not already running. A Java application manager 134 then starts 302 the Java application (JA) 136 using a Java application framework and reports 303 a status to the desktop manager in the native application manager 144. Possibly also an output in the desktop view is delivered 304 to the user interface 160. The signalling diagram in steps 300 to 304 is not limited to the above example on activating a Java application, but similar transactions may be utilized for any user input to the desktop area in the Ul affecting an application 136 in the Java execution environment 130. Thus, the user can conveniently also activate a Java application 136 from a single desktop view for native applications 146.

The desktop management information delivered over the interface 150 may thus comprise application identification information. In a further embodiment, the electronic device 100 is configured to display information on native applications 146 and Java application 136 in a single view by using the desktop management information. This embodiment can also be illustrated by steps 300, 301 , 303, and 304 of the first exemplary signalling diagram of Fig- ure 3: One of the Java applications 136 launches another Java application 136. Later an input is received 300 from the Ul 160 for a list of the currently running applications. The desktop manager in the native application manager 144 defines the running native application(s) 146, and also requests 301 information on running applications from the Java application manager 134 over the interface 150. The Java application manager 134 has information on run- ning Java applications 136 and returns 303 the list of running Java applications 136, including also the Java application 136 that was not started by the native application manager 144. The native application manager 144 may then compile a single list indicating both running native and non-native applications which may then be delivered 304 to the Ul to be displayed for the user. By this embodiment, it is possible to indicate all running applications 136, 146 in the device 100 to the user by a single desktop view. Since information on all running Java applications 136 can be obtained from the Java application manager 134, all the running Java applications 136 can be indicated to the user even if multiple Java applications 136 were run in a single JVM. In accordance with the second example of Figure 3, the native application manager 144 may change the foreground/background state of applications 136, 146: The user starts a Java application 136 which comes to the foreground. Later on, a native application 146 is started. The newly activated native application 146 is changed 310 to the foreground and the Java applica- tion 136 is set to the background. In this case, the native application manager 144 will notify 311 the Java application manager 134 that the Java application 136 was or will be set to the background. The Java application manager 134 may move the window of the Java application 136 to the background and may send 312 a notification to the Java application 136 that it is now in the back- ground. Alternatively, it is possible that it is the native application manager 144 that moves the window to the background and only the notification is sent through the Java application manager 134. By this embodiment, it is now possible to bring Java applications 136 to the foreground by the desktop manager. In the third example of Figure 3, the native application manager 144 decides 320 to close one background Java application 136 because of resource shortage, for instance. The desktop manager requests or notifies 321 the Java application manager 134 which closes 322 the Java application 136. If this were the last Java application 136 running, the native application manager 144 may then close the JVM process 132. In the fourth example of Figure 3, a need exists to launch an application by the native application manager 144 on the basis of a MIME type. This MIME type has been registered by a Java application 136 and the MIME type is associated with the Java application 136. The desktop manager in the native application manager 144 finds out 330 that the MIME type is handled by a Java application 136 and invokes 331 the Java application manager. The Java application manager 134 then starts 332 the appropriate Java application 136 (if not already running) and invokes a hook on an appropriate application interface which handles the MIME type.

In a variation of the fourth example, the Java application 136 has registered the MIME type, and the native application 146 notices the new MIME association and modifies its user interface so that the user may know that there is a new application that is able to process that MIME type.

In the fifth example of Figure 3, the Java application 136 offers a useful Ul functionality which other applications may wish to use. For instance, the Java application 136 is able to edit images and produce a certain image format. Other applications (including native 146) would like to reuse this functionality and embed this Ul functionality into their Ul view. An indication of this need 340 is delivered 341 to the native application manager 144. The NAM 144 sends 342 a request or a command to the Java application manager 134. The Java application manager 134 starts 343 the Java application 136, if neo essary, and instructs it to display the requested Ul view. Alternatively, the invoking native application 146 may identify the target Java application 136 and the Ul part or the view that it would like to activate, and may send the invocation directly to the Java application manager 134.

In the sixth example of Figure 3, a native application 146 has 350 an event for a Java application 136. The native application 146 contacts 351 the native application manager 144. As a response to communication 351 , the procedures already illustrated in steps 301 and 303 may be used and a list of active Java applications 136 may be returned to the desktop manager. A complete list of all running applications (native and Java) is returned 352 to the na- tive application 146. The native application 146 checks whether the intended event receiver is running and sends the event if it is.

The mechanism can be extended with automatic routing of the events. An event handler API may find out automatically whether the application is a native or a Java application and may then route the event appropri- ately. This makes it possible that an event sender does not necessarily have to know whether the target of the event is a Java application 136 or a native application 146.

In one further embodiment, not illustrated as such in Figure 3, information on directory structures may be delivered over the interface 150. For instance, a new Java application 136 is installed on the device 100. The Java application directory structure does not have to follow the convention used by the native application manager 144, and the Java application manager 134 may be arranged to maintain a data structure that can be used by the native application manager 144 so that icons and application names can be correctly displayed on the desktop view on the Ul 160.

The above illustrated embodiment enables extensible and integrated interaction between Java programs and native desktop, the system being capable of running multiple Java applications 136 in a single JVM. Extensibility of interaction may be arranged by extensible event sets that Java pro- grams can receive. It is possible to turn application management actions to events.

In an alternative embodiment, the Java application manager 134 provides the desktop manager. The above-illustrated procedures may also be applied to this embodiment; the roles are changed and information related to native applications 146 may be delivered via the interface 150 between the Java application manager 134 now providing the desktop management and the native application manager 144. Thus, the Java application manager 134 may contact the native application manager 144 to control or execute desktop management related actions for the native applications 146. In one example applying this embodiment in which the desktop is provided by a Java application manager 134, the user clicks on an icon on the desktop view and the desktop manager determines that the icon represents a native application 146. The native application manager 144 is contacted and the application 146 is launched. This example is similar to the first example M- lustrated in Figure 3, except that the roles between the Java and native application managers have been swapped. Similar examples can be derived also from other above examples illustrated in Figure 3.

In this embodiment, desktop management information for carrying out at least some of the following functionalities may be delivered via the inter- face 150 between the native (140) and Java environment 130: - Start and stop native applications 146. - Move native applications 146 between foreground and background states.

- Launch native applications 146 based on registered MIME types and allow association of MIME types with native applications 146. - Allow native applications 146 to reuse Ul parts (views) of Java applications 136 and Java applications 136 to reuse Ul parts of native applications 146.

- Allow the Java application manager 134 to display icons belonging to native applications 146 even if the native applications 146 do not follow the native environment's deployment convention.

In one embodiment, the Java application framework 130 is based at least partly on the OSGi specification. However, application of the above illustrated features is not limited to any specific Java implementation; one example of another Java implementationto which the present invention may be applied is a MIDP-based Java implementation enabling execution of multiple M I Diets (MIDP Java applications).

Java applications 136 are deployed on the OSGi framework 130 by the OSGi management agent (134). These applications 136 may be stored in the OSGi framework's 130 implementation-dependent directory structure. The Java application manager 134 may be implemented as an OSGi bundle on top of the OSGi framework. This bundle is always running when the framework (130) is running and it has administrative privileges. The Java application manager 134 discovers the bundles it has to manage by analysing their manifests. The Java application manager 134 does not necessarily manage all OSGi bundles, for instance system background services are out of its scope. The Java application manager may be configured to 134 start the bundles belonging to a Java application 136 on the basis of a request from the native application manager 144, see for instance the embodiments illustrated in Figure 3. The Java application manager 134 knows which bundles to start because it has this information from the management agent. One or more bundles of the application 136 may register a service, which is detected by the Java application manager 134. The Java application manager 134 communicates with the bundles of the application 136 through these services. For instance, the Java application manager 134 can use this service to request processing of a cer- tain MIME type from the application 136 or to present a certain view. In one embodiment, the OSGi management agent 134 maintains a data structure on the basis of which the native application manager 144 (the desktop manager) can display the icons and titles of Java applications 136 indicated in the data structure, even if the framework is not running. The native application manager 144 checks this data structure and displays the icons along with the icons of the native applications 146. In another embodiment, the desktop manager is implemented by an OSGi based Java application manager.

The integration interface 150 between the native application man- ager 144 and the Java application manager 134 is, in one embodiment, implemented by JNI (Java Native Interface) technology. JNI is a native programming interface which is part of the Java SDK. JNI enables Java code to apply code and code libraries written in other languages, such as C and C++, and allows calling Java virtual machine features from native code (by calling JNI functions through an interface pointer). It is to be noted that some parts of the Java application manager 134 may be implemented by non-Java technology. For instance, the deployment component related features may be native. Thus, the JNI is not necessary for each aspect of the interface between the Java application manager 134 and the native application manager 144. In one em- bodiment, the Java execution environment 130 comprises one or more additional, proprietary native integration interface, which may be used instead of JNI.

A JNI based interface between the native application manager 144 and the Java application manager 134 is now illustrated in a situation where a user interacts with the native application manager 144. The interaction between these two application managers 134, 144 may be arranged as follows. A user clicks on an icon representing a Java application 136 running in a Java environment 130. The native desktop realizes that this application 136 needs to be started in the Java environment 130. The Java environment 130 is not running and therefore it is started in its own process. After the Java environment 130 has been started, the native application manager 144 contacts the Java application manager 134. The call from the native application manager 144 is passed on to the Java process by means of an inter-process communication channel (for instance by a Symbian client-server invocation channel). In the Java server, the call is handled by a native code which invokes the JNI interface to forward the call to Java application manager code. The Java applica- tion manager 134 starts the Java application 136 in a new Java application execution context and then returns from the call. The execution returns to the native desktop. If the Java environment 130 is already running, the Java environment 130 is not started and the invocation is passed on to the already run- ning Java process. If the Java environment 130 provides the desktop, the call chain is simpler. In such a case, the Java environment 130 uses JNI to call the native application manager 144 methods to manage the native applications 146.

It should be noted that the embodiments described above could also be applied in any combination thereof. It is apparent to a person skilled in the art that as technology advances, the basic idea of the invention can be implemented in many different ways. The invention and its embodiments are thus not restricted to the examples described above, but may vary within the scope of the claims.

Claims

1. An electronic device, the device comprising memory for storing application programs and a processor coupled to the memory for executing the application programs, wherein a native first application program (146) is execu- table in a first execution environment for native applications and manageable by a first application manager (144), and a non-native second application program (136) is executable in a second execution environment for non-native applications and manageable by a second application manager (134), characterized in that the electronic device comprises means for deliv- ering (204, 206) desktop management information from the first application manager (144) to the second application manager (134) and/or from the second application manager (134) to the first application manager (144).

2. An electronic device according to claim 1, characterized in that the desktop management information comprises application identifica- tion information, and the electronic device is configured to display information on the first and the second application in a single view by using the desktop management information.

3. An electronic device according to claim 2, characterized in that the first or the second application manager is configured to return a list of running applications in response to the received management information.

4. An electronic device according to claim 1, characterized in that the desktop management information comprises an indication of a desired activity, and the first or the second application manager is configured to carry out the activity on the basis of the desktop management information.

5. An electronic device according to claim 4, characterized in that the desktop management information comprises an indication of an application and the indicated activity is a start or stop of an application, and the first or the second application manager is configured to start or stop an application on the basis of the received management information.

6. An electronic device according to claim 4, characterized in that the desktop management information comprises an indication of an application and the indicated activity is a change of state of for an application, and the first or the second application manager is configured to move an application between foreground and background states on the basis of the received management information.

7. An electronic device according to any one of the preceding claims, characterized in that the electronic device comprises a desktop manager configured to originate the desktop management information.

8. An electronic device according to claim 7, characterized in that the desktop manager is implemented in the first application manager, the desktop manager is, on the basis of an input from the first appli- cation program and/or from the user, configured to specify the desktop management information causing one or more actions in the second non -native execution environment, and the second application manager is configured to carry out or initiate the at least one action on the basis of the received desktop management in- formation.

9. An electronic device according to claim 7, characterized in that the desktop manager is implemented in the second application manager, the desktop manager is, on the basis of an input from the second application and/or from the user, configured to specify the desktop management information causing one or more actions in the first native execution environment, and the first application manager is configured to carry out or initiate the at least one action on the basis of the received desktop management informa- tion.

10. An electronic device according to any one of the preceding claims, characterized in that the second application program is a Java™ application program and the second execution environment comprises a Java™ virtual machine.

11. An electronic device according to claim 10, characte r- i z e d in that at least some of the communication between the first application manager and the second application manager is arranged via a JNI (Java Native Interface) based interface.

12. A method for arranging application management in a configura- tion, wherein a native first application program (146) is executable in a first execution environment for native applications and manageable by a first appli- cation manager (144), and a non-native second application program (136) is executable in a second execution environment for non-native applications and manageable by a second application manager (134), characterized by delivering (204, 206) desktop management information from the first application manager (144) to the second application manager (134) as a response to a need to perform a desktop specific operation related to the second execution environment and/or from the second application manager (134) to the first application manager (144) as a response to a need to perform a desktop specific operation related to the first execution environment, and performing (208) the desktop management specific operation relating to the first application program (146) and/or the second application program (136) on the basis of the desktop management information.

13. A method according to claim 12, characterized in that the desktop management information comprises application identification in- formation, and information on the first and the second application is displayed in a single view by using the desktop management information.

14. A method according to claim 12 or 13, characterized in that the desktop management information comprises an indication of a desired activity, and the activity is carried out by the first or the second application manager on the basis of the desktop management information.

15. An application management system comprising a configuration, wherein a native first application program (146) is executable in a first execution environment for native applications and manageable by a first application manager (144), and a non-native second application program (136) is executable in a second execution environment for non-native applications and manageable by a second application manager (134), characterized in that the configuration is arranged to deliver (204, 206) desktop management information from the first application manager (144) to the second application man- ager (134) and/or from the second application manager (134) to the first application manager (144).

16. A computer program product for a data processing device, characterized in that the computer program product comprises a computer program code which, when executed in a processor of the data process- ing device, causes the data processing device to: deliver (204, 206) desktop management information from a first application manager (144) for managing native applications to a second application manager (134) for managing non-native applications and/or from the second application manager (134) to the first application manager (144).

17. A computer program product according to claim 16, characterized in that the computer program product comprises a computer program code for performing (208) a desktop management specific operation relating to a first application program (146) and/or a second application program (136) on the basis of the desktop management information.

18. A computer program product according to claim 16 or 17, characterized in that the desktop management information comprises application identification information, and the execution of the computer program code causes information on the first and the second application to be displayed in a single view by using the desktop management information.

19. A computer program product according to claim 16, 17, or 18, characterized in that the execution of the computer program code causes an indication of a desired activity to be included into the desktop management information and execution of the activity by the first or the second application manager on the basis of the desktop management information.