WO2009156964A1

WO2009156964A1 - Launching an application

Info

Publication number: WO2009156964A1
Application number: PCT/IB2009/052751
Authority: WO
Inventors: Lovell Thomas
Original assignee: Nokia Corporation
Priority date: 2008-06-25
Filing date: 2009-06-25
Publication date: 2009-12-30

Abstract

A computing device comprising a first processor for launching applications and having at least one application stored thereon. The application has at least one associated first operation which is first processor intensive, and at least one associated operation which is not first processor intensive. The device is arranged to execute both said operations such that a part of one operation occurs at the same time as a part of the other operation.

Description

LAUNCHING AN APPLICATION

TECHNICAL FIELD

Examples of this invention relate to an apparatus and a method for the loading of applications.

BACKGROUND TO THE INVENTION

Although the processing speed and storage requirements of computing devices are continually improving, software is also becoming more and more complex. This can result in software applications appearing to be slow. This can be particularly true when applications are first started. The initialisation of the application can result in a perceptible delay, which may be particularly noticeable to the user as she is awaiting the functionality provided by the application.

SUMMARY OF THE INVENTION

According to an example of the invention there is provided an apparatus comprising: at least one processor; and at least one memory including computer program code; the at least one memory and the computer program code configured to, with the at least one processor, cause the apparatus at least to perform: executing a first operation and a second operation such that at least a part of the first operation occurs at the same time as at least a part of the second operation, wherein: the first operation relates to launching an application on the apparatus; and the second operation relates to establishing a communications channel for utilisation by the application.

According to a further example, the invention provides a method comprising: executing a first operation and a second operation such that at least a part of the first operation occurs at the same time as at least a part of the second operation, wherein: the first operation relates to launching an application on the apparatus; and the second operation relates to establishing a communications channel for utilisation by the application.

According to yet a further example, the invention provides a registry for use in an apparatus having a processor for launching applications, the registry being adapted to list, for at least one application, at least one associated first operation which is relatively processor intensive and at least one associated second operation which is not processor intensive.

Further examples of the invention may provide a computer program, a suite of computer programs, a computer readable storage medium, or any combination of software and hardware suitable for carrying out the inventive features of the invention.

The processor may comprise but is not limited to (1 ) one or more microprocessors, (2) one or more processor(s) with accompanying digital signal processor(s), (3) one or more processor(s) without accompanying digital signal processor(s), (3) one or more special-purpose computer chips, (4) one or more field-programmable gate arrays (FPGAS), (5) one or more controllers, (6) one or more application-specific integrated circuits (ASICS), (7) one or more combination of hardware/firmware, or (7) one or more computer(s). The memory may include one or more memories (e.g., ROM, RAM, etc.) which have been programmed in such a way as to carry out the inventive function.

BREIF DESCRIPTION OF THE DRAWINGS

Embodiments of the invention will now be described in detail, by way of example, with reference to the accompanying drawings in which:

Figure 1 shows an example mobile device in accordance with an embodiment of the invention;

Figure 2 is a schematic diagram of some components of the example mobile device shown in Figure 1 ; Figure 3 is a representation of some applications and other files stored on the example mobile device shown in Figure 1 ;

Figure 4 is a flow chart showing a method of operation of the mobile device shown in connection with Figure 1 in accordance with an example embodiment;

Figure 5 is a flow chart showing a further method of operation of the mobile device shown in connection with Figure 1 in accordance with another example; and

Figure 6 is a flow chart showing a further method of operation of the mobile device shown in connection with Figure 1 in accordance with a further example.

DESCRIPTION OF EXAMPLE EMBODIMENTS When an apparatus is initialising an application, hardware related operations specific to the application can sometimes cause a delay. For example, communications related applications can be dependent on the establishment of a communications channel, which can take a relatively long time to perform.

Some common use cases of a mobile phone involve opening an application, and then accessing some remote entity or entities. For example:

Web browser. Can involve accessing a cellular network or Wifi network Bluetooth® application. Involves searching for nearby Bluetooth® devices to connect to. - Wifi configuration application. Involves searching for nearby Wifi access points to connect to.

A mobile device 101 , which is arranged to operate in accordance with a first example embodiment of the present invention, is shown in Figure 1. The mobile device 101 comprises an outer casing 102, which includes a speaker 103 and a microphone 104. The mobile device 101 also includes a keypad 105 and a display 106. The keypad 105 enables a user to enter information into the mobile device 101 and instruct the mobile device to perform the various functions which it provides. For example, a user may enter a telephone number, or select another mobile device from a list stored on the mobile device 101 , as well as perform functions such as initiating a telephone call.

Figure 2 is a schematic diagram showing some components of the example mobile device 101. The device includes a system bus 107 to which the components are connected and which allows the components to communicate with each other. Here, the components are shown to communicate via a single system bus 107. However, in practice the mobile device may include several buses to connect the various components. In Figure 2 the components of the mobile device 101 include an application processor 108, a baseband processor 109, memory 1 10, a speaker controller 11 1 , a microphone controller 1 12, a display controller 1 13, a keyboard controller 1 14, a baseband radio 1 15 and a storage device controller 1 16. The application processor 108 of this example is for running an operating system (OS) and user applications. The baseband processor 109 is for controlling a telephony stack. The baseband radio 1 15 is also connected to an antenna 1 17. The example mobile device 101 is arranged to communicate, via WCDMA radio 1 15, with a base station of a WCDMA mobile phone network (not shown). The storage device controller 1 16 is connected to a storage device 1 18 which may be an internal hard drive or a removable storage device such as a flash memory card. The mobile device 101 of this example also includes a Bluetooth® radio 119 which is connected to an antenna 120. The mobile device 101 also includes an WiFi® radio 121 which is connected to an antenna 122.

In this example embodiment the mobile device 101 enables a framework in which each application on a mobile phone can optionally have a "pre-loader" plugin associated with it (e.g. by some unique identifier related to the application's executable). These plugins are loaded and owned by the application-launching functionality at device start-up. When an application is to be launched in accordance with this embodiment (e.g. from an application menu), the corresponding plugin is called first, and only when this plugin signals back to the application menu that the specified actions have been successfully completed, is the application actually loaded and instantiated. In an alternative example embodiment, the plugin is called at the same time as the application. Of course if a plugin does not exist for a given application, the application may be loaded normally.

These plugins can be sufficiently small so as to involve minimal overhead in loading or executing their functionality. To avoid the need for plugins to specify too much functionality (e.g. in order to decide what action to take before returning control to the application menu), an ini file (which acts as a registry) is provided in the example embodiment, which the application itself is responsible for changing when the application was last open. Suppliers of after-market third-party applications may then be able to supply a plugin as well, so embodiments of this invention are not limited to applications in a phone's default firmware.

Figure 3 is a representation of certain executables stored in memory on the example mobile computing device 101. The executables include a browser executable 130, a Bluetooth® executable 131 and a WiFi® executable 132. In this example the browser executable 130 represents a web browser application which allows a user to view Internet and Intranet based HTTP pages. The browser establishes a network connection using the phone's communications hardware. The Bluetooth® executable 131 represents a Bluetooth® setup application. The Bluetooth® setup application enables a user to switch Bluetooth on and off, control device visibility, set a device name, search for nearby devices, connect to specific devices etc. The WiFi® executable 132 in this example represents a WiFi® configuration application. The application allows a user to setup WiFi® networks, control security, make specific connections etc.

Each executable in this example has an associated preloader plugin; i.e. there is a browser preloader plugin 133, a Bluetooth® preloader plugin 134 and a WiFi® preloader plugin 135. Each preloader plugin is configured to carry out certain actions prior to the loading of the respective executable, as will be described in more detail below. In addition, each executable/preloader plugin pair in this example includes a corresponding ini file. In particular, the device includes a browser ini 136, a Bluetooth® ini 137 and a WiFi® ini 138. The ini files are text based information stores which the applications or preloader plugins can refer to prior to loading. Some of their potential uses will be described below in example embodiments. When an executable is installed, a menu icon representing the executable may be created. This menu icon can act as a short-cut to the executable. In the example embodiment, a menu icon is created at install time, and the menu icon is a short cut to the preloader plugin. The preloader plugin can then launch an appropriate application, either immediately, or following certain actions, as will be described below. The mobile device of this embodiment includes a browser icon 139, a Bluetooth® icon 140, and a WiFi® icon 141.

The operation of the browser will be described below in an example with reference to Figure 4. Although this example relates to a browser, it is to be understood that other example embodiments of the invention can be applied to any other application which uses a communications connection.

When starting a browser application, the user may want to make use of a data connection. In this example, a user selects the browser icon 139 (block 201 ). This launches the browser preloader plugin 133 (block 202). The browser preloader plugin 133 starts an outgoing network connection (which could, for example, be cellular or WiFi®, depending on what the phone supports, or what the user has selected as a default connection type). Some devices can support "bearer selection", and different bearers can be tried in turn, for example in order of user preference or according to a default order. Embodiments of the invention could be useful in the context of bearer selection, as checking for nearby WiFi® access points can be quite time consuming, so could be effective if done in parallel with loading a browser.

Creating a network connection has two stages in this example: (1 ) retrieve configuration information from a local settings database, and (2) activate the connection "externally". It is during phase (2) that the browser executable 130 loading will take place in this example, as the application processor is idle. In the example, once the browser preloader plugin 133 has been launched at block 202, the preloader plugin retrieves configuration information from the local settings database (block 203). The preloader plugin 133 detects when phase (1 ) has completed (this may be determined by virtue of progress updates provided by the OS) (block 204), and at that point, signals back to the application loader to proceed with loading the browser executable 130 (block 205). Furthermore the preloader plugin 133 instructs the device to activate an external connection (block 206).

Thus in this example, while the device is establishing an external connection, the browser executable 130 is loading. This means that, by the time the browser executable 130 has finished loading (block 207), the device should have established a data connection (block 208). This could mean that a user can start browsing the Internet quicker than in a prior art device. In a prior art device, once the browser has loaded, the user may then have to wait for a network connection to be established. Example of this problem may be particularly noticeable in mobile devices, since they may not be permanently connected to the Internet, and a connection may need to be established before browsing can begin.

Although the Browser preloader plugin 133 of the example creates a connection when launched, the Browser executable 130 will also attempt to create a connection when it has finished loading. However, as a suitable connection is already open, the connection attempt by the executable 130 will complete instantly as the connection has previously been established. In this example, the preloader plugin 133 holds the handle on this connection open for 20 seconds, after which it will close it, in the knowledge that the browser 130 now has a handle of its own to keep the connection alive. It will be appreciated that the 20 second time window mentioned above is given only as an example; other times may be appropriate dependent on many factors, including connection type, hardware platform, application start-up time etc.

In an optional extension of this example embodiment, the Browser executable 130 is able to provide user-related information (e.g. details of the user's home page) to the preloader plugin 133. As such, the next time the browser application is opened, the preloader plugin 133 triggers an "HTTP Get" call on the user's home page if a network connection is already active. The data would then be cached (assuming that caching is supported), and so the relevant information would be returned far quicker in this optional extension. In an alternative embodiment, the preloader plugin 133 acts as a cache for the home page, providing the relevant information directly to the Browser executable 130. This could be significantly faster than awaiting the establishment of the connection. The browser ini 136 may store this information.

With some Bluetooth® configuration applications, the user may be able to switch Bluetooth® connectivity on and off, control visibility, set a device name, search for nearby devices (e.g. to pair a new device), and connect to specific devices.

In the example embodiment, the Bluetooth® preloader plugin 134 is arranged to initiate a device search, such that when the Bluetooth® executable 131 is fully loaded, and the user goes to select "Add new device", or equivalent, the search has already begun and a list of devices is readily available. (Some OSs can provide for some sort of caching of recently discovered devices, which could be utilised here, such that no changes may be needed to the way the Bluetooth® executable performs its device search).

As noted above, the device in the example includes a Bluetooth® ini 137. The Bluetooth® ini 137 keeps a live record of the status of Bluetooth®, e.g. it keeps a record of whether or not Bluetooth® is turned on or off. The Bluetooth® executable, which controls Bluetooth®, updates Bluetooth® ini 137 with this information in the example embodiment. The preloader plugin 134 reads this information from the Bluetooth® ini 137 when it is launched. When Bluetooth® is switched off, the preloader plugin does not initiate a search for devices. When Bluetooth® is switched on, the preloader plugin does initiate a search for devices.

Furthermore, the Bluetooth® ini 137 in the example also keeps a live record of whether a physical Bluetooth® link already exists. The Bluetooth® preloader plugin 134 can be arranged not to perform an automatic search if any Bluetooth® physical links already exist. This can help to avoid impairing the existing connection (for example a device scan while streaming audio can cause dropouts, so if a rescan is going to occur, it may be preferable that the user has explicitly activated the scan). In addition, if a device is already connected, it may be less likely that the user will wish to find a new device, and more likely that the user will wish to disconnect or monitor the existing connection. Initially, a user selects the Bluetooth® icon 140 (block 301 of the example embodiment). This launches the Bluetooth® preloader plugin 134 (block 302). The Bluetooth® preloader plugin 134 then reads the Bluetooth® ini 137 (block 303). The preloader plugin initially determines whether or not Bluetooth® is switched on (block 304). Simultaneously, the preloader plugin 134 launches the Bluetooth® executable (block 305). If Bluetooth® is switched on, the Bluetooth® preloader plugin 134 checks the ini 137 to determine whether or not a connection is already active (block 306). If a connection is already active, the preloader plugin 134 does not conduct a search and the preloader terminates (block 307). If a connection is not active, the preloader plugin 134 commences a device search (block 308). While the device search is being conducted, little or no application processor time is being used in this example. During this time, the Bluetooth® executable 131 is simultaneously launching. If it is determined that Bluetooth® is not switched on at block 304, the preloader plugin 134 is terminated, and no search is conducted (block 309).

Once the Bluetooth® executable has launched (block 310), the results of searching should be available in this example (block 311 ), assuming Bluetooth® was on and no active connections were present. If Bluetooth® was not on, the user can switch it on and search in the usual manner.

The WiFi® executable 132 of this example allows the user to search for WiFi® access points (either to associate with, or to connect to), and configure the security settings for the access points as well as specify other configuration related aspects. The WiFi® preloader plugin 135 is arranged to initiate a device scan at the same time as the loading of the WiFi® executable 132. The results of the scan should be available in this example when the executable 132 has loaded. As with Bluetooth®, searching for nearby devices may be a most common usage of this type of application.

In the example embodiment, the WiFi® preloader plugin 135 is arranged to initiate a device search, such that when the WiFi® executable 132 is fully loaded, and the user wishes to connect to a new access point, the search has already begun (or has completed) and a list of devices is available. As noted above, the example device includes a WiFi® ini 138. The WiFi® ini 138 keeps a live record of the status of the WiFi® radio, e.g. whether WiFi® is turned on or off. The WiFi® executable 132, which controls WiFi®, updates WiFi® ini 138 with this information. The preloader plugin 135 reads this information from the WiFi® ini 138 when it is launched. When WiFi® is switched off, the preloader plugin 135 does not initiate a search for devices. When WiFi® is switched on, the preloader plugin does initiate a search for devices.

Initially, a user selects the WiFi® icon 12 (block 401 of this example). This launches the WiFi® preloader plugin 135 (block 402). The WiFi® preloader plugin 135 then reads the WiFi® ini 138 (block 403). The preloader plugin 135 initially determines whether or not WiFi® is switched on (block 404). Simultaneously, the preloader plugin 135 launches the WiFi® executable (block 405). If WiFi® is switched on, the preloader plugin 135 commences a device search (block 406). While the device search is being conducted, little or no application processor time is being used in this example. During this time, the WiFi® executable 132 is simultaneously launching. If it is determined that WiFi® is not switched on at block 404, the preloader plugin 135 is terminated, and no search is conducted (407).

Once the WiFi® executable has launched in this example (block 408), the results of searching should be available (block 409), assuming WiFi® was on. If WiFi® was not on, the user can switch it on and search in the usual manner.

The example caching mechanism mentioned above can be used so that existing exectuables may need no modification to work with the above embodiments.

According to a further example embodiment, certain applications (such as an email application) may have an account which is configured to use a certain connection (such as a specified WiFi® connection). This information can be written into the corresponding preloader plugin's ini file, so that whenever this application is started, the corresponding connection can be started.

The use of ini files as described in the example embodiments can allow applications to adapt their behaviour by predicting what the user may want to do next time they start the application. This can be done without the preloader plugin needing to be overly complex by making use of ini files.

It is to be appreciated that embodiments of the invention can also be applicable to location based services. A position acquisition request may be triggered before a corresponding application starts loading.

In the Browser example above the preloader plugin 133 may monitor connection progress notifications, so that it knows when the CPU becomes idle. An example approach to this could be to monitor CPU activity of a null thread.

In an alternative embodiment, the mobile device does not include individual plugins relating to each application. Instead, the device includes a preloader framework. When an application is installed in this embodiment, it is registered with the framework. The framework includes a registry of applications which can include details of actions which must be carried out while an application is launching. So, for example, a browser application could register the fact that a network connection should be opened while the browser is launching. Other than the fact that the framework of this example embodiment implements a central registry based system, the preloader framework can implement the same application specific routines detailed in relation to the previous embodiments.

A technical effect of at least some of the above described embodiments is that the time between the user initiating an application and the application providing functionality to the user can be reduced.

Establishing a connection to remote devices may take time, but may not consume significant application processor power. During an asynchronous connection phase, little or no application processor time may be used. Loading and instantiating an application can also take time, and this may consume significant application processor resources. In some prior arrangements, an application is loaded/instantiated and then an external connection created, which can take a long time for the user. Examples of the present invention are based on the realisation that application processor intensive operations can be completed at the same time as operations which are not application processor intensive.

Various modifications, including additions and deletions, will be apparent to the skilled person to provide further embodiments, any and all of which are intended to fall within the appended claims. It will be understood that any combinations of the features and examples of the described embodiments of the invention may be made within the scope of the invention.

Claims

1. An apparatus comprising: at least one processor; and at least one memory including computer program code; the at least one memory and the computer program code configured to, with the at least one processor, cause the apparatus at least to perform: executing a first operation and a second operation such that at least a part of the first operation occurs at the same time as at least a part of the second operation, wherein: the first operation relates to launching an application on the apparatus; and the second operation relates to establishing a communications channel for utilisation by the application.

2. Apparatus according to claim 1 wherein the first operation is processor intensive relative to the second operation.

3. Apparatus according to claim 1 or claim 2 wherein the second operation involves at least one of: initiating a search for available communications channels, and setting up a communications channel.

4. Apparatus according to any preceding claim, wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the apparatus at least to begin execution of the first and second operations substantially simultaneously.

5. Apparatus according to any of claims 1 to 3, wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the apparatus at least to begin execution of the second operation before beginning execution of the first operation.

6. Apparatus according to any preceding claim, wherein executing a first operation and a second operation is performed in response to a command to launch the application.

7. Apparatus according to any preceding claim, wherein the application is associated with a third operation which is also relatively processor intensive, and the at least one memory and the computer program code are configured to, with the at least one processor, cause the apparatus at least to complete the third operation before executing the first and second operations.

8. Apparatus according to claim 7, wherein the third operation is the retrieval of communication channel configuration information.

9. Apparatus according to any preceding claim, further having a plugin stored thereon, associated with the application, wherein the plugin is arranged to initiate the operations.

10. Apparatus according to claim 19, wherein the second operation is performed by the plugin .

1 1. Apparatus according to any preceding claim, wherein the second operation which involves setting up a WiFi connection or a Bluetooth® connection.

12. A method comprising: executing a first operation and a second operation such that at least a part of the first operation occurs at the same time as at least a part of the second operation, wherein: the first operation relates to launching an application on the apparatus; and the second operation relates to establishing a communications channel for utilisation by the application.

13. A registry for use in an apparatus having a processor for launching applications, the registry being adapted to list, for at least one application, at least one associated first operation which is relatively processor intensive and at least one associated second operation which is not processor intensive.

14. A computer program or suite of computer programs arranged such that when executed by apparatus they cause the apparatus to operate in accordance with the method of any of claim 12.

15. A computer readable medium storing the computer program, or at least one of the suites of computer programs, according to claim 14.

16. An operating system for causing apparatus to operate in accordance with a method as claimed in claim 12.

17. Apparatus substantially as described hereinbefore and as shown in Figures 1 to 6.