Application dehydration and rehydration during application-to-application calls

Methods, systems, and computer program products are provided that enable a first application (i.e., a caller application) to call a second application (i.e., a callee application) to perform a function in a manner such that the first application may be dehydrated during the call. Dehydrating includes terminating execution of an instance of the first application, and freeing memory space in a memory of a mobile device that stored the instance of the first application. In such case, the second application may be active while the first application is no longer present in memory. The second application is enabled to respond to the call, causing the first application to be rehydrated. The first application continues execution at a location where the first application was dehydrated, and receives the response to the call.

BACKGROUND

Many types of mobile devices exist, such as smart phones and tablet computers. Such devices are hand-carriable, and therefore provide a great deal of convenience for users. Furthermore, many mobile devices are capable of running numerous programs or applications (e.g., “Apps”) simultaneously to perform a variety of functions. Mobile devices, particularly low end mobile devices, are severely challenged by multi-tasking scenarios, however. This is in part due to the effort to keep the cost associated with mobile devices low in order to be competitive at scale, which leads to the use of low end or low powered parts. Because memory (e.g., random access memory or “RAM”), tends to be expensive, relatively smaller capacity memory devices tend to be used in mobile devices to reduce costs.

In the past where the memory capacity of mobile devices was not as much of a problem, there were situations where a first application A may invoke a second application B to retrieve some data. After the data retrieval operation, both of the applications A and B would be left residing in the memory of the mobile device, even if one or both of them were no longer needed, leading them to continue to consume a portion of the memory resource. This type of cycle would sometimes continue, leading to further numbers of applications unnecessarily remaining in and consuming the memory. Large memory modules and paging together lend themselves to allow for deeply nested scenarios of applications invoking other applications. Something as simple as a third party application that uses Facebook® (operated by Facebook, Inc. of Palo Alto, Calif.) as a picture provider may lead to three applications residing in memory concurrently. This accumulation of applications in memory can create a memory problem for low end devices.

SUMMARY

Methods, systems, and computer program products are provided that enable a first application (i.e., a caller application) to call a second application (i.e., a callee application) to perform a function in a manner such that the first application may be dehydrated during the call. In such case, the second application may be active while the first application is no longer present. The second application is enabled to respond to the call, causing the first application to be rehydrated. The first application continues execution at a program location where the first application was dehydrated, and receives the response to the call.

For instance, in one implementation, a method in a mobile device is provided that includes: receiving a call issued from a first application contained by the mobile device that is directed to a second application, the call including continuation data for the first application and request information; dehydrating the first application; and providing the request information to the second application.

The method may further include: receiving response information from the second application in response to the request information; rehydrating the first application based on the continuation data; and providing the response information to the first application.

In one aspect of the method, the providing of the request information to the second application may include: invoking the second application in the mobile device; and providing the request information to the second application. Furthermore, the receiving of the response information from the second application in response to the request information may lead to the terminating the second application.

In a further aspect of the method, the method may further include: maintaining an application list that includes one or more entries, each entry of the application list indicating an application identifier for a corresponding application and an application instance identifier that identifies a particular instance of the corresponding application; and in response to receiving the call issued from or by the first application, tagging an entry in the application list with the continuation data, the tagged entry corresponding to the instance of the first application that issued the call.

Furthermore, the rehydrating of the first application based on the continuation data may include: identifying the entry in the application list for the instance of the first application in response to receiving the response information; and using the continuation data tagged to the identified entry in the application list to rehydrate the first application.

In an alternative aspect, the method may include receiving an indication that a user interacted with a user interface of the mobile device to attempt to re-launch the first application prior to a response being received from the second application to the provided request information; re-launching the first application at an entry point for the first application that is different than an entry point identified by the continuation data (e.g., a “main” entry point); and discarding the continuation data.

In another implementation, a mobile device is provided. The system includes a broker process configured to execute in a processor circuit of the mobile device. The broker process includes a call broker and a hydration enabler module. The call broker is configured to receive a call issued from an instance of a first application that executes in the mobile device. The call is directed to a second application and includes continuation data for the instance of the first application and request information. The call broker is further configured to provide the request information to the second application without the continuation data. The hydration enabler module is configured to provide a first signal to enable the instance of the first application to be dehydrated. The call broker is further configured to receive response information from the second application in response to the request information. The hydration enable module is configured to cause the instance of the first application to be rehydrated based on the continuation data. The call broker is further configured to provide the response information to the instance of the first application.

In a further aspect, the call broker may be configured to cause the second application to be invoked in the mobile device, and to provide the request information to the invoked second application. Furthermore, the call broker may be configured to cause the second application to be terminated in response to receipt of the response information from the second application.

Memory space of a primary memory that was allocated to the instance of the first application is freed when the instance of the first application is dehydrated. Furthermore, memory space in the primary memory is reallocated to the instance of the first application and the first application is re-launched at an entry point identified by the continuation data when the instance of the first application is rehydrated based on the continuation data.

In a further aspect, the system may also include a foreground manager. The foreground manager is configured to maintain an application list that includes one or more entries. Each entry of the application list indicates an application identifier for a corresponding application and an application instance identifier that identifies a particular instance of the corresponding application. The call broker may be configured to tag an entry in the application list with the continuation data in response to receiving the call issued by the first application. The tagged entry corresponds to the instance of the first application that issued the call.

Furthermore, in response to receiving response information regarding the call from the second application, the call broker may be configured to identify the entry in the application list for the instance of the first application, and to use the continuation data tagged to the identified entry in the application list to rehydrate the first application.

A computer readable storage medium is also disclosed herein having computer program instructions stored therein that enable a caller application to be dehydrated while a call issued by the caller application to a callee application is processed, and to rehydrate the caller application when the call is complete, as well as enabling further embodiments described herein.

DETAILED DESCRIPTION

The present specification and accompanying drawings disclose one or more embodiments that incorporate the features of the present invention. The scope of the present invention is not limited to the disclosed embodiments. The disclosed embodiments merely exemplify the present invention, and modified versions of the disclosed embodiments are also encompassed by the present invention. Embodiments of the present invention are defined by the claims appended hereto.

Embodiments described herein enable a first application (i.e., a caller application) to call a second application (i.e., a callee application) to perform a function in a manner such that the first application may be dehydrated during the call. In such case, the second application may be active while the first application is no longer present. The second application is enabled to respond to the call, causing the first application to be rehydrated. The first application is re-invoked and continues execution at a location where the first application was dehydrated, and receives the response to the call. Mechanisms are disclosed to pass simple state information for the first application through communications such as URI (uniform resource indicators), and to pass more complex state through service entities across these boundaries. These techniques may be implemented in association with public contracts that participating entities may opt into and make sure their applications are configured to participate with.

For instance,FIG. 1shows a block diagram of a mobile device100, according to an example embodiment. As shown inFIG. 1, mobile device100includes a caller application102and a callee application104residing in a primary memory110of mobile device100. For ease of illustration, many more features that may be included in mobile device100are not shown inFIG. 1, and at least some of such features may be described elsewhere herein. Mobile device100is described as follows.

Mobile device100may be any type of mobile computing device, including a mobile computer or mobile computing device (e.g., a Microsoft® Surface® device, a personal digital assistant (PDA), a laptop computer, a notebook computer, a tablet computer such as an Apple® iPad™, a netbook, etc.), a mobile phone (e.g., a cell phone, a smart phone such as a Microsoft® Windows® phone, an Apple® iPhone®, a phone implementing the Google® Android™ operating system, a Palm® device, a Blackberry® device, etc.), a wearable computing device (e.g., a smart watch, a head-mounted device including smart glasses such as Google® Glass™ etc.), a digital camera, or other type of mobile device.

Mobile device100may include a network interface that enables mobile device100to communicate over one or more networks. Example networks include a local area network (LAN), a wide area network (WAN), a personal area network (PAN), and/or a combination of communication networks, such as the Internet. One or more of any type of network interface may be present, wired or wireless, including a network interface card (NIC), an Institute of Electrical and Electronics Engineers (IEEE) 802.11 wireless LAN (WLAN) wireless interface, a Worldwide Interoperability for Microwave Access (Wi-MAX) interface, an Ethernet interface, a Universal Serial Bus (USB) interface, a cellular network interface, a Bluetooth™ interface, a near field communication (NFC) interface, etc.

Primary memory110(or “main memory” etc.) of mobile device100includes one or more physical hardware memory devices accessible by one or more processors of mobile device100. Such memory devices may be integrated in or separate from the processor(s). Primary memory110typically is used to store, among other things, applications of mobile device100that are open and executing. Such applications may typically be stored in secondary storage of mobile device100when not open and executing. Secondary storage is considered long term, persistent storage of mobile device100. Applications stored in secondary storage may be copied from secondary storage to primary memory110when invoked for execution. A copy of an application that has been copied into primary memory110may be considered an “instance” of the applications. A single application stored in secondary memory may have one or more instances of the application that are copied into primary memory110and executing in mobile device100at any one time. When an instance of an application is closed, so that the application instance no longer to be executed, the memory space used by the application instance in primary memory110may be freed up to be used by other applications and/or other resources.

Caller application102and callee application104may each be any type of application capable of running on a mobile device, including at least some desktop applications as well as mobile applications that may be referred to as “Mobile Apps” or just “Apps.” Examples of such mobile applications include email applications, calendar applications, word processing applications, database management applications, contacts management applications, stock market applications, news applications, weather applications, games, factory automation applications, mapping and location-based services applications, banking applications, order-tracking applications, ticket purchasing applications, mobile medical applications, social networking applications, photo management applications, music management applications, video management applications, etc. Such applications may be configured to communicate with network-based or “cloud”-based services (e.g., at servers) for file access, file storage, information access, etc., to assist with performance of application functions.

According to embodiments, caller application102and callee application104may communicate to handle a call issued by caller application102in a manner such that caller application102does not need to reside in primary memory110during the entire time the call is processed. Such embodiments may be performed in various ways. For instance,FIG. 2shows a flowchart200providing a process for enabling an application to be dehydrated upon issuing an application-to-application call, and to be rehydrated when the call is completed, according to an example embodiment. Flowchart200is described as follows with respect to mobile device100ofFIG. 1. Further structural and operational embodiments will be apparent to persons skilled in the relevant art(s) based on the following description.

Flowchart200begins with step202. In step202, a call is issued from a first application to a second application to request information. For example, as shown inFIG. 1, caller application102may issue a call106to callee application104. Call106is an application-to-application call that requests information. For instance, call106may include a request for a file (e.g., a document, an image, or other object) from callee application104and/or a request for callee application104to perform a function and provide return data and/or an acknowledgment that the function was performed. Call106may be issued in any suitable form, including in serialized or non-serialized form.

In one embodiment, call106may be provided from caller application102to callee application104directly. In another embodiment, call106may be provided from caller application102to callee application104through an intermediate entity in mobile device100. For example,FIG. 3shows a block diagram of a mobile device300in which caller application102issues a call to callee application104via an intermediate entity302, according to an example embodiment. Mobile device300is an example of mobile device100ofFIG. 1. As shown inFIG. 3, caller application102issues call106. In the example ofFIG. 3, call106is received by intermediate entity302. Intermediate entity302may be any suitable intermediary entity for calls that operates in mobile device300, including an operating system entity such as a broker or other entity. Intermediate entity302may extract request information from call106to be used by callee application104to service call106, and may forward that extracted request information to callee application104in forwarded call information304.

As such, callee application104either receives call106(FIG. 1) directly from caller application102, or receives forwarded call information304from intermediate entity302(FIG. 3). In either case, callee application104processes the call based on the received call information.

Referring back toFIG. 2, in step204, the first application is dehydrated during processing of the call by the second application. In an embodiment, caller application102may be dehydrated during the processing of call106. Dehydration of caller application102entails shutting down execution of the instance of caller application102that issued call106, and freeing up the memory space of primary memory110that stored that instance of caller application102. In this manner, memory space in primary memory110is conserved. In one embodiment, the executing instance of caller application102may be dehydrated, and callee application104may subsequently be invoked to service call106, such that the instance of caller application102and the invoked instance of callee application104do not reside in primary memory110at the same time, conserving memory space of primary memory110even further.

In step206, the first application is rehydrated. In an embodiment, caller application102may be rehydrated after call106is processed by callee application104. Rehydration of caller application102entails invoking an instance of caller application102, such that the invoked instance of caller application102resides in memory space of primary memory110. In this manner, memory space in primary memory110was conserved during at least a portion of the time that callee application104processed call106. In one embodiment, callee application104may be terminated, such that execution of the responding instance of callee application104is shutdown, and the memory space of primary memory110of that instance of callee application104is freed, and caller application102may subsequently be rehydrated. In this manner, the invoked instance of caller application102and the terminated instance of callee application104do not necessarily reside in primary memory110at the same time, conserving memory space of primary memory110even further.

In step208, a response to the call is received at the first application. As shown inFIG. 1, callee application104generates and provides call response108in response to call106. For instance, call response108may include a requested file, requested information, return data, etc., provided in response to call106. Call response108may be received by caller application102directly from callee application104. Alternatively, such as according to the embodiment ofFIG. 3, call response108may be provided from callee application104through an intermediate entity in mobile device100. For example,FIG. 3shows callee application104having generated response information306. Response information306may include the requested file, requested information, return data, etc. Response information306is received from callee application104by intermediate entity302. Intermediate entity302may identify caller application102as the intended recipient of response information306, and may forward response information306to caller application102in call response108.

In an embodiment, intermediate entity302may generate call response108to include state information provided by caller application102in call106. The state information may indicate a state of operation of caller application102when call106was issued, and thus, when received by caller application102in call response108, may enable caller application102to continue operating from the point when call106was issued. For instance, an instance of caller application102may be rehydrated, and may use the state information to continue operation at an entry point of caller application102indicated in the state information. The state information that enables caller application102to continue operating at a particular entry point may be referred to as “continuation data.” Caller application102may have any number of entry points that are predefined, and operation may be continued (e.g., from rehydration) at any of them based on the appropriate continuation data.

Note that in some embodiments, after rehydration of caller application102, continuation data may be applied with global state information (that is maintained elsewhere by an operating system of mobile device102) to caller application102to enable caller application102to continue operating at the entry point indicated by the continuation data.

Mobile devices may be configured in various ways to enable dehydration and rehydration of caller applications according to embodiments. For instance,FIG. 4shows a block diagram of a mobile device400issuing an application-to-application call that is handled by an intermediate entity, according to an example embodiment. Mobile device400is an example of mobile device300ofFIG. 3. As shown inFIG. 4, mobile device400includes a primary memory406. Primary memory406is an example of primary memory110(FIG. 3). Furthermore, primary memory406stores caller application102, an operating system404that includes a broker process402, and suspension logic426. Although suspension logic426is shown as being independent of operating system404inFIG. 4, in an embodiment, suspension logic426may be included in operating system404. Still further, caller application102includes a call handler408and a continuation data generator410, and broker process402includes a call broker412, a hydration enabler module414, and a foreground manager416. In embodiments, foreground manager416may be included in broker process402as shown inFIG. 4, or may be external to broker process402. Furthermore, in an embodiment, suspension logic426may be included in foreground manager416.

Mobile device400is described as follows with respect toFIGS. 5-14.FIGS. 6 and 11show mobile device400during subsequent processing of the call shown issued inFIG. 4, according to example embodiments.FIGS. 5, 7-10, and 12-14show example flowcharts providing processes related to the processing of an application-to application call, according to embodiments.

FIG. 4is described with respect toFIG. 5as follows.FIG. 5shows a flowchart500providing a process in a broker process for processing a call received from a first application that is directed to a second application, according to an example embodiment. For example, in an embodiment, flowchart500may performed by broker process402shown inFIG. 4. Further structural and operational embodiments will be apparent to persons skilled in the relevant art(s) based on the following description of flowchart500.

Flowchart500begins with step502. In step502, a call issued from a first application contained by a mobile device is received that is directed to a second application. For example, as shown inFIG. 4, call handler408of caller application102may issue a call420. Call420is an example of call106ofFIG. 1. Call handler408is configured to manage the issuing of calls, and the receiving of call responses, for caller application102. Call handler408may issue calls in various ways, including ways known to persons skilled in the relevant art(s). For example, call handler408may generate call420in the form of a uniform resource indicator (URI), a system call, and/or another form.

Furthermore, call handler408may generate call420to include request information. The request information defines the purpose of call420by indicating what information and/or response is desired from the callee application. For instance, the request information may define one or more requested files or other objects from the callee application, a function to be performed by the callee application (e.g., open a file picker interface so that the user can select a file), data desired from the called application, etc.

Still further, as shown inFIG. 4, continuation data generator410may generate continuation data418that is received by call handler408, and included by call handler408in call420. Continuation data generator410is configured to generate continuation data418to include data that defines a current state of caller application102. Continuation data418may include data in any suitable form, including a key-value structure, etc. Continuation data418may be received by caller application102, and used by caller application102to continue operation at a point where call420is issued from caller application102. For instance, continuation data418may be provided to an instance of caller application102that is rehydrated after call420is processed by the callee application. This enables the rehydrated instance of caller application102to continue operating at the entry point at which caller application102operated when call420was issued.

For instance, in one illustrative example, caller application102may be a social networking application (e.g., Facebook® operated by Facebook, Inc. of Palo Alto, Calif., Google+™ operated by Google, Inc. of Mountain View, Calif., etc.) that has multiple points where a photo may be requested from a photo manager application. In turn, the photo manager application may invoke a storage application that actually stores at least some photos (e.g., Dropbox™ operated by Dropbox, Inc. of San Francisco, Calif., etc.). Accordingly, when a user interacts with the social network application, two or even three applications may be involved (e.g., social networking application, photo manager application, and storage application).

The social networking application may have multiple entry points in its program code. For example, at a first point in the social networking application, a user may be enabled to interact with the social network application to select a photo (also referred to as an “image”) from a photo manager application to include in their profile (a profile photo update point). At a second point, the user may be enabled to interact with the social network application to select a photo to include in their personal timeline (a timeline update point). At further points, the user may be enabled to select photos for other purposes. As such, the social networking application may have multiple points where a call may be issued to a photo manager application to request an image. Each of these points may be considered “entry points” at which the social network application may enter back into operation upon completion of the call that requests the image from the photo manager application, particularly if the social network application is dehydrated upon issuance of the call, and is rehydrated upon completion of the call. The social networking application may be rehydrated and continued at a first entry point, where a profile image was selected, at a second entry point, where a timeline image was selected, or at another entry point, depending on where the image was requested. Continuation data418enables the continuation of operation to occur at the particular entry point by recording the entry point for this subsequent use.

Continuation data418may include various information to enable operation continuation for caller application102, including an identification of the entry point of caller application102at which call420is issued, a contract identifier of a contract between participating entities, an identification of the requested file or other object, an identification of the callee application to which call420is being issued, requested information, return data, etc., an identifier for caller application102(e.g., an “application identifier”) that may be a numerical, alphanumerical, or other form of identifier, an instance identifier for the instance of caller application102that is executing and issued call420(an “application instance identifier”) that may be a numerical, alphanumerical, or other form of identifier, further state information that identifies a state of caller application102when call420is issued, and/or further information.

As shown inFIG. 4, call broker412of broker process402receives call420. Call420, including continuation data418, may be provided in a serialized or non-serialized form by call handler408. Serialization (converting data to a serialized form) refers to translating the data to a form that can be stored and/or transmitted, and that can be subsequently reconstructed. Broker process402may be one or more processes of operating system404. Operating system404is an operating system of mobile device400, and may be resident in primary memory406of mobile device400during operation of mobile device400. Call broker412of broker process402is configured to broker calls issued between applications of mobile device400, including being capable of receiving calls from caller applications, and forwarding information of the received calls to the corresponding callee applications, as well as being capable of receiving call response information from callee applications, and forwarding the response information to the corresponding caller applications. For instance, in an embodiment, call broker412may be implemented as an application programming interface (API) (e.g., expressed as a set of classes with an associated set of class methods), or in another form, to define how caller and callee application can interact with broker process402to send and receive call-related information. In other embodiments, call broker412may be implemented in other ways.

In an embodiment, foreground manager416may be present to track continuation data418received in call420. For instance, broker process412may receive call420, and extract and provide continuation data418to foreground manager416to store in an application list422. Application list422is a data structure (e.g., a table, a database, an array, etc.) that stores a list of applications that may be executing in mobile device400. For instance, the list may include a plurality of entries, with each entry corresponding to a particular instance of an application, whether the instance is actually executing or has been dehydrated (so may not be currently running, but may be rehydrated in the future to be running). In an embodiment, foreground manager416may store in or otherwise associate continuation data418in application list422with the instance of caller application102that issued call420. In this manner, continuation data418may subsequently be used to continue caller application102after call420is processed.

For instance, in an embodiment, foreground manager416may operate according toFIG. 7.FIG. 7shows a flowchart700providing a process for tracking a call for a first application using an application list, according to an example embodiment. Further structural and operational embodiments will be apparent to persons skilled in the relevant art(s) based on the following description of flowchart700.

Flowchart700begins with step702. In step702, an application list is maintained that includes one or more entries, each entry of the application list indicating an application identifier for a corresponding application and an application instance identifier that identifies a particular instance of the corresponding application. For instance, as described above, foreground manager416may maintain application list422, which contains one or more entries that each correspond to an executing application instance.

In one embodiment, each entry of application list422may indicate an application identifier for a corresponding application and an application instance identifier that identifies a particular instance of the corresponding application. For instance, application list422may include a plurality of entries that are each similar to the following example entry:

where

[ApplicationIdentifier]=an application identifier for an application, and

[ApplicationInstanceIdentifier]=an identifier of an executing instance of the application identified by [ApplicationIdentifier].

In one embodiment, [ApplicationIdentifier] may be identified as an “AUMID” (Application User Model ID) as utilized in the Microsoft® Windows® Store. In such an example, [ApplicationIdentifier] may be composed of a package family name portion, followed by an exclamation point, followed by an application ID. For instance, an example AUMID is illustrated below:

where

SampleApplicationPackageName=the package family name portion, and

In other embodiments, application list422may identify application instances in other manners.

Referring back toFIG. 7, in step702, an entry in the application list is tagged with the continuation data in response to receiving the call issued by the first application. In an embodiment, when foreground manager416receives continuation data418from a received call420, foreground manager416is configured to associate the received continuation data418with an entry in application list422for the instance of caller application102having issued call420. In one embodiment, call420may identify the instance of caller application102. Alternatively, call420may not identify the instance of caller application102. In such a situation, call broker412may be configured to determine the instance of caller application102that issued call420, and may provide the application instance identifier for the identified instance to foreground manager416.

Call broker412may identify the instance of caller application102in any manner. For instance, in one example provided for illustrative purposes, call broker412may identify a UI (user interface) thread, also known as an ASTA (Application Single-Threaded Apartment), in which a UI for caller application102runs. When call420is received from caller application102, call broker412may identify the ASTA associated with caller application102. A one-to-one correspondence between the ASTA associated with caller application102is stored in operating system402. Accordingly, call broker412may determine the application instance identifier for caller application102from the ASTA determined from call420.

Once the application instance identifier for caller application102is identified, foreground manager416may tag (e.g., associate) the entry in application list422containing the identified application instance identifier with continuation data418. Foreground manager416may store the continuation data418in application list422in association with the determined entry, or may tag the entry with the continuation data418in any other manner.

Referring back to flowchart500inFIG. 5, in step504, the first application is dehydrated. In an embodiment, after receiving call420, broker process402may cause caller application102to be dehydrated. For instance, this may be performed to save device resources (e.g., reduce memory consumption) while call420is being processed. In such an embodiment, call broker412may notify hydration enabler module414that call420has been received. In response, hydration enabler module414may cause caller application102to be dehydrated. For example, in an embodiment, hydration enabler module414may issue a dehydration request424(seeFIG. 4), which is configured to cause caller application102to be dehydrated.

In one embodiment, dehydration request424may be directed to and received directly by caller application102. In response, caller application102may be configured to enact a shutdown process. In another embodiment, dehydration request424may be directed to suspension logic426. Suspension logic426may be configured to handle the dehydration of applications, including caller application102. For instance, as shown inFIG. 4, suspension logic426may generate a shutdown instruction428that is received by caller application102. In response, caller application102may be configured to enact a shutdown process.

In an embodiment, step504ofFIG. 5may include the process shown inFIG. 8.FIG. 8shows a flowchart800providing a process for dehydrating a caller application, according to an example embodiment. Further structural and operational embodiments will be apparent to persons skilled in the relevant art(s) based on the following description of flowchart800.

Flowchart800begins with step802. In step802, the first application is shut down. For example, as described above, hydration enabler module414may issue a dehydration request424, which is configured to cause caller application102to be dehydrated. Caller application102may receive dehydration request424or shut down instruction428(from suspension logic426), and may accordingly perform a shutdown process where caller application102terminates execution.

In step804, memory space of a primary memory that was allocated to the first application is freed. In an embodiment, memory space of primary memory406that was allocated to caller application102may be freed now that caller application102has terminated execution. In embodiments, hydration enabler module414or suspension logic426may notify a memory manager (not shown inFIG. 4) of mobile device400that manages memory space in primary memory406. As a result, the memory manager may open up or free the memory space that was allocated to caller application102in primary memory406to be used by other applications and/or resources.

As a result of dehydration, caller application102no longer resides in primary memory406. For instance,FIG. 6shows a block diagram of mobile device400in which caller application102has been dehydrated and therefore is not shown in primary memory406, according to an example embodiment.

Note that in an embodiment, such dehydrating of caller application102may be performed selectively. For instance, in some cases, caller application102may be dehydrated, and in other cases, caller application102may be allowed to remain in primary memory406in some situations. For example, if mobile device400has a sufficiently large amount of memory (e.g., mobile device400is a “high end” device), caller application102may be allowed to remain in primary memory406during processing of call420. Broker process402may be configured to selectively dehydrate caller application102in various circumstances, such as when primary memory406is filled to a predetermined threshold amount (and some freeing up of primary memory406is desirable), when a predetermined number of applications are running in mobile device400(e.g., above a threshold number of applications), and/or based on another trigger.

Referring back to flowchart500inFIG. 5, in step506, the request information is provided to the second application. For example, with continued reference toFIG. 6, call broker412provides request information602to callee application104. Request information602includes request information that was received from caller application102in call420. In an embodiment, however, request information602does not include continuation data418(FIG. 4). This is because callee application104is not concerned with the state of caller application102(e.g., whether caller application102is dehydrated or hydrated), and thus does not need any state information of caller application102, including continuation data418. Accordingly, callee application104processes request information602to fulfill the request, such as retrieving one or more requested files or objects, retrieving and/or determining requested information or return data, etc.

Note that in one embodiment, callee application104may already be executing and present in primary memory406when call420is issued by caller application102. In another embodiment, callee application104may not be executing or be present in primary memory406when call420is issued by caller application102. In such a case, callee application104needs to be invoked in order to receive and respond to request information602.

Accordingly,FIG. 9shows a flowchart900providing a process for invoking a callee application to process a call, according to an example embodiment. Further structural and operational embodiments will be apparent to persons skilled in the relevant art(s) based on the following description of flowchart900.

Flowchart900begins with step902. In step902, the second application is invoked in the mobile device. In an embodiment, call broker402receives call420, and determines that call420is directed to callee application104. In response, broker process402may determine that callee application104is not executing and may invoke callee application104, and/or may issue a request to a resource of operating system404to determine whether callee application104is executing and to request that callee application104be invoked. According to one of these techniques, or in any other suitable manner, callee application104may be invoked. As shown inFIG. 6, callee application104has been invoked and is residing in primary memory406. In the embodiments ofFIGS. 4 and 6, caller application102and callee application104do not reside in primary memory406simultaneously.

In step904, the request information is provided to the second application. As shown inFIG. 6, call broker412provides request information602to callee application104. For example, call broker412may provide request information602in the form of a uniform resource indicator (URI), a system call, and/or another form.

In an embodiment, flowchart500ofFIG. 5may continue as shown inFIG. 10to finish processing of the call.FIG. 10shows a flowchart1000providing a process for rehydrating a caller application to complete a call, according to an example embodiment. Further structural and operational embodiments will be apparent to persons skilled in the relevant art(s) based on the following description of flowchart1000.

Flowchart1000begins with step1002. In step1002, response information is received from the second application in response to the request information. For example, as shown inFIG. 6, callee application104generates response information604. Response information604is received by call broker412. As described above, response information, e.g., response information306ofFIG. 3, may include the requested file, requested information, return data, a completion acknowledgment, etc.

Accordingly, in an embodiment, callee application104may no longer need to be executing and taking up space in primary memory406. Accordingly, step1002inFIG. 10may be performed as show inFIG. 12.FIG. 12shows a flowchart1200providing a process for terminating a callee application after responding to a call, according to an example embodiment. Further structural and operational embodiments will be apparent to persons skilled in the relevant art(s) based on the following description of flowchart1200.

Flowchart1200begins with step1202. In step1202, the response information is received from the second application. For instance, as described above, callee application104generates response information604, which is received by call broker412.

In step1204, the second application is terminated. In an embodiment, after receiving response information604, broker process402may determine that callee application104is no longer needed with respect to the received call. As such, broker process402may generate a shutdown signal (not shown inFIG. 6) that is received by callee application104directly, or that is received by another device resource that manages device resources, such as a memory manager, suspension logic426(FIG. 4), or other resource, and which in turn provides a shutdown instruction directly to callee application104. Accordingly, callee application104may be caused to invoke a shutdown process by the shutdown signal received from broker process402or other resource. The shutdown process results in caller application102terminating execution. Furthermore, a memory manager may open up or free the memory space that was allocated to callee application104in primary memory406to be used by other applications and/or resources. Alternatively, if callee application104is determined to be in use by the user and/or other applications, callee application104may not be shutdown.

In step1004of flowchart1000inFIG. 10, the first application is rehydrated based on the continuation data. In an embodiment, upon receiving response information604, hydration enabler module414may be configured to rehydrate caller application102so that caller application102can be provided with the response. Continuation data418previously received from caller application102in call420may be used by hydration enabler module414to rehydrate continuation application102at a particular entry point. Continuation data418may be located and retrieved in any manner.

For example, in an embodiment, the process shown inFIG. 13may be performed.FIG. 13shows a flowchart1300providing a process for locating continuation data for a first application using an application list, according to an example embodiment. Further structural and operational embodiments will be apparent to persons skilled in the relevant art(s) based on the following description of flowchart1300.

Flowchart1300begins with step1302. In step1302, the entry is identified in the application list for the instance of the first application in response to receiving the response information. For instance, in an embodiment, response information604received from caller application102may be correlated with call420and/or request information602to identify the instance of caller application102that issued call420. In this manner, the entry in application list422for the identified instance of caller application102may be accessed to retrieve the associated continuation data418.

In step1304, the continuation data tagged to the identified entry in the application list is used to rehydrate the first application. In an embodiment, hydration enabler module414may use the retrieved continuation data418to rehydrate caller application102. For instance,FIG. 11shows the block diagram of mobile device400ofFIG. 4, with caller application102having been rehydrated, according to an example embodiment. In an embodiment, and as shown inFIG. 11, hydration enabler module414may issue a rehydration request1104, which is configured to cause caller application102to be rehydrated.

In one embodiment, rehydration request1104may be configured to directly cause caller application102to be invoked. In another embodiment, rehydration request1104may be directed to suspension logic426. Suspension logic426may be configured to handle the rehydration of applications, such as caller application102. For instance, as shown inFIG. 11, suspension logic426may generate a rehydration instruction1106that causes caller application102to be invoked. In either case, continuation data418is provided to caller application102to cause caller application102to continue operation at the entry point at which call420was issued.

For example, referring back to the social networking application example, continuation data418may identify a profile photo update entry point, a timeline update entry point, or other entry point for the social networking application. Accordingly, continuation data418may cause the social networking application to continue at the indicated entry point.

Accordingly, step1004inFIG. 10of rehydrating the first application may include the process shown inFIG. 14.FIG. 14shows a flowchart1400providing a process for rehydrating a caller application, according to an example embodiment. Further structural and operational embodiments will be apparent to persons skilled in the relevant art(s) based on the following description of flowchart1400.

Flowchart1400begins with step1402. In step1402, memory space is reallocated in the primary memory to the first application. In an embodiment, hydration enabler module414or suspension logic426may notify a memory manager (not shown inFIG. 11) of mobile device400to allocate memory space in primary memory406to the instance of caller application102to be invoked.

In step1404, the first application is re-launched at an entry point identified by the continuation data. As described above, hydration enabler module414and/or suspension logic426may cause caller application102to be invoked.

Referring back toFIG. 10, in step1006, the response information is provided to the first application. For example, as shown inFIG. 11, call broker412provides response information1102to call handler408of caller application102. In response information1102, call broker412forwards the response information included in response information604(FIG. 6) to caller application102. In this manner, caller application102has access to the response information such as a file (e.g., a photo, a video, an audio file, etc.) or other object, generated information or return data, etc., which may be displayed or otherwise used by caller application102. Furthermore, the response information is provided at the entry point of caller application102indicated by continuation data418(e.g., an updated profile photo, a new timeline photo, etc.).

It is noted that the description provided with respect toFIGS. 4-14is provided with respect to first and second applications. With regard to the above described social networking application example, where a user attempts to select a photo to insert in their social networking profile or timeline, the first and second applications may be the social networking application (caller) and photo manager application (callee), where the social networking application calls for a photo from the photo manager application. Alternatively or additionally, the first and second applications may be the photo manager application (caller) and storage application (callee), where the photo manager application calls for a photo from the storage application. As such, embodiments are applicable to nested or chained scenarios, where a first application issues a call to a second application, which leads to the second application issuing a call to a third application, which leads to the third application potentially issuing a call to a fourth application, etc. Such nesting can include any number of nested caller-callee pairs.

Furthermore, note thatFIGS. 4-14are described in the context of a broker that acts as an intermediary between a caller application and a callee application. In other embodiments, another resource of a mobile device may operate as an intermediary between a caller application and a callee application in a similar manner as described according toFIGS. 4-14.

In the embodiments described above with respect to flowchart1000ofFIG. 10, the caller application is dehydrated, response information is received from the callee application, and the caller application is rehydrated and provided with the response information. It is noted that in some cases, during processing of the call, a user may re-launch the dehydrated caller application before the response information is received. In such case, the call operation may be effectively canceled, and any response information may be discarded and/or ignored. Accordingly, the user may be enabled to proceed with interacting with the caller application without the call being completed.

For example, in an embodiment, an indication is received that a user interacted with a user interface of the mobile device to attempt to re-launch the first application. For instance, the user may have selected the application for execution, may have selected a “back” button, or may otherwise have re-launched the first application. The indication may be received prior to a response being received from the second application to the provided request information. As such, the first application may be re-launched at a main entry point (or the last entry point) for the first application rather than the entry point identified by the continuation data. The first application may be brought forward as the foreground application on the mobile device. Furthermore, the continuation data may be discarded.

Furthermore, in some other cases, the callee application may fail to respond to the call from the caller application. For instance, with respect toFIG. 6and flowchart1000ofFIG. 10, callee application104may not provide response information604to be received in step1002. Many possible reasons exist for the callee application not responding, including the callee application crashing, the user “light dismissing” the second application using a back button, etc. In such a situation, the caller application may be rehydrated (step1004of flowchart1000), the continuation data may be provided to the caller application, and broker process402may indicate to the caller application that the call was canceled (rather than performing step1006of flowchart1000). For instance, in the example of the call being a request for one or more files from the callee application (a “file pick” operation), no files would be returned to the caller application.

III. Example Mobile and Stationary Device Embodiments

For instance, in an embodiment, one or more, in any combination, of caller application102, callee application104, intermediate entity302, broker process402, operating system404, call handler408, continuation data generator410, call broker412, hydration enabler module414, foreground manager416, suspension logic426, flowchart200, flowchart500, flowchart700, flowchart800, flowchart900, flowchart1000, flowchart1200, flowchart1300, and/or flowchart1400may be implemented together in a system on a chip (SoC). The SoC may include an integrated circuit chip that includes one or more of a processor (e.g., a central processing unit (CPU), microcontroller, microprocessor, digital signal processor (DSP), etc.), memory, one or more communication interfaces, and/or further circuits, and may optionally execute received program code and/or include embedded firmware to perform functions.

FIG. 15shows a block diagram of an exemplary mobile device1500including a variety of optional hardware and software components, shown generally as components1502. For instance, components1502of mobile device1500are examples of components that may be included in mobile device100, mobile device300, and/or mobile device400, in mobile device embodiments. Any number and combination of the features/elements of components1502may be included in a mobile device embodiment, as well as additional and/or alternative features/elements, as would be known to persons skilled in the relevant art(s). Such features/elements may also be included in stationary device embodiments. It is noted that any of components1502can communicate with any other of components1502, although not all connections are shown, for ease of illustration. Mobile device1500can be any of a variety of mobile devices described or mentioned elsewhere herein or otherwise known (e.g., cell phone, smartphone, handheld computer, Personal Digital Assistant (PDA), etc.) and can allow wireless two-way communications with one or more mobile devices over one or more communications networks1504, such as a cellular or satellite network, or with a local area or wide area network.

The illustrated mobile device1500can include a controller or processor referred to as processor circuit1510for performing such tasks as signal coding, image processing, data processing, input/output processing, power control, and/or other functions. Processor circuit1510is an electrical and/or optical circuit implemented in one or more physical hardware electrical circuit device elements and/or integrated circuit devices (semiconductor material chips or dies) as a central processing unit (CPU), a microcontroller, a microprocessor, and/or other physical hardware processor circuit. Processor circuit1510may execute program code stored in a computer readable medium, such as program code of one or more applications1514, operating system1512, any program code stored in memory1520, etc. Operating system1512can control the allocation and usage of the components1502and support for one or more application programs1514(a.k.a. applications, “apps”, etc.). Application programs1514can include common mobile computing applications (e.g., email applications, calendars, contact managers, web browsers, messaging applications) and any other computing applications (e.g., word processing applications, mapping applications, media player applications).

As illustrated, mobile device1500can include memory1520. Memory1520can include non-removable memory1522and/or removable memory1524. The non-removable memory1522can include RAM, read only memory (ROM), flash memory, a hard disk, or other well-known memory storage technologies. The removable memory1524can include flash memory or a Subscriber Identity Module (SIM) card, which is well known in Global System for Mobile (GSM) communication systems, or other well-known memory storage technologies, such as “smart cards.” The memory1520can be used for storing data and/or code for running the operating system1512and the applications1514. Example data can include web pages, text, images, sound files, video data, or other data sets to be sent to and/or received from one or more network servers or other devices via one or more wired or wireless networks. Memory1520can be used to store a subscriber identifier, such as an International Mobile Subscriber Identity (IMSI), and an equipment identifier, such as an International Mobile Equipment Identifier (IMEI). Such identifiers can be transmitted to a network server to identify users and equipment.

A number of programs may be stored in memory1520. These programs include operating system1512, one or more application programs1514, and other program modules and program data. Examples of such application programs or program modules may include, for example, computer program logic (e.g., computer program code or instructions) for implementing caller application102, callee application104, intermediate entity302, broker process402, operating system404, call handler408, continuation data generator410, call broker412, hydration enabler module414, foreground manager416, suspension logic426, flowchart200, flowchart500, flowchart700, flowchart800, flowchart900, flowchart1000, flowchart1200, flowchart1300, and/or flowchart1400(including any suitable step of flowcharts200,500,700,900,1000,1200,1300, and1400), and/or further embodiments described herein.

Mobile device1500can support one or more input devices1530, such as a touch screen1532, microphone1534, camera1536, physical keyboard1538and/or trackball1540and one or more output devices1550, such as a speaker1552and a display1554. Touch screens, such as touch screen1532, can detect input in different ways. For example, capacitive touch screens detect touch input when an object (e.g., a fingertip) distorts or interrupts an electrical current running across the surface. As another example, touch screens can use optical sensors to detect touch input when beams from the optical sensors are interrupted. Physical contact with the surface of the screen is not necessary for input to be detected by some touch screens. For example, the touch screen1532may be configured to support finger hover detection using capacitive sensing, as is well understood in the art. Other detection techniques can be used, as already described above, including camera-based detection and ultrasonic-based detection. To implement a finger hover, a user's finger is typically within a predetermined spaced distance above the touch screen, such as between 0.1 to 0.25 inches, or between 0.25 inches and 0.5 inches, or between 0.5 inches and 0.75 inches or between 0.75 inches and 1 inch, or between 1 inch and 1.5 inches, etc.

The touch screen1532is shown to include a control interface1592for illustrative purposes. The control interface1592is configured to control content associated with a virtual element that is displayed on the touch screen1532. In an example embodiment, the control interface1592is configured to control content that is provided by one or more of applications1514. For instance, when a user of the mobile device1500utilizes an application, the control interface1592may be presented to the user on touch screen1532to enable the user to access controls that control such content. Presentation of the control interface1592may be based on (e.g., triggered by) detection of a motion within a designated distance from the touch screen1532or absence of such motion. Example embodiments for causing a control interface (e.g., control interface1592) to be presented on a touch screen (e.g., touch screen1532) based on a motion or absence thereof are described in greater detail below.

Other possible output devices (not shown) can include piezoelectric or other haptic output devices. Some devices can serve more than one input/output function. For example, touch screen1532and display1554can be combined in a single input/output device. The input devices1530can include a Natural User Interface (NUI). An NUI is any interface technology that enables a user to interact with a device in a “natural” manner, free from artificial constraints imposed by input devices such as mice, keyboards, remote controls, and the like. Examples of NUI methods include those relying on speech recognition, touch and stylus recognition, gesture recognition both on screen and adjacent to the screen, air gestures, head and eye tracking, voice and speech, vision, touch, gestures, and machine intelligence. Other examples of a NUI include motion gesture detection using accelerometers/gyroscopes, facial recognition, three dimensional (3D) displays, head, eye, and gaze tracking, immersive augmented reality and virtual reality systems, all of which provide a more natural interface, as well as technologies for sensing brain activity using electric field sensing electrodes (electroencephalogram (EEG) and related methods). Thus, in one specific example, the operating system1512or applications1514can comprise speech-recognition software as part of a voice control interface that allows a user to operate the device1500via voice commands. Further, device1500can comprise input devices and software that allows for user interaction via a user's spatial gestures, such as detecting and interpreting gestures to provide input to a gaming application.

Wireless modem(s)1560can be coupled to antenna(s) (not shown) and can support two-way communications between processor circuit1510and external devices, as is well understood in the art. The modem(s)1560are shown generically and can include a cellular modem1566for communicating with the mobile communication network1504and/or other radio-based modems (e.g., Bluetooth® 1564 and/or Wi-Fi® 1562). Cellular modem1566may be configured to enable phone calls (and optionally transmit data) according to any suitable communication standard or technology, such as GSM®, 3G, 4G, 5G, etc. At least one of the wireless modem(s)1560is typically configured for communication with one or more cellular networks, such as a GSM® network for data and voice communications within a single cellular network, between cellular networks, or between the mobile device and a public switched telephone network (PSTN).

Mobile device1500can further include at least one input/output port1580, a power supply1582, a satellite navigation system receiver1584, such as a Global Positioning System (GPS) receiver, an accelerometer1586, and/or a physical connector1590, which can be a USB port, IEEE 1394 (FireWire®) port, and/or RS-232 port. The illustrated components1502are not required or all-inclusive, as any components may be not present and other components may be additionally present as would be recognized by one skilled in the art.

As used herein, the terms “computer program medium,” “computer-readable medium,” and “computer-readable storage medium” are used to generally refer to physical hardware media such as the hard disk associated with a hard disk drive, removable magnetic disk, removable optical disk, other physical hardware media such as RAMs, ROMs, flash memory cards, digital video disks, zip disks, microelectromechanical systems (MEMO, nanotechnology-based storage devices, and further types of physical/tangible hardware storage media (including memory1520ofFIG. 15). Such computer-readable storage media are distinguished from and non-overlapping with communication media (do not include communication media). Communication media typically embodies computer-readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave. The term “modulated data signal” means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wireless media such as acoustic, radio frequency (RF), infrared and other wireless media, as well as wired media. Embodiments are also directed to such communication media.

As noted above, computer programs and modules (including applications1514ofFIG. 15) may be stored on a hard disk, magnetic disk, optical disk, ROM, RAM, or other hardware storage medium. Such computer programs may also be received via the network interface(s) of wireless modem1560, physical connector1590, or any other interface type. Such computer programs, when executed or loaded by an application, enable mobile device1502to implement features of embodiments discussed herein. Accordingly, such computer programs represent controllers of mobile device1502.