US20120210321A1

US20120210321A1 - Dormant Background Applications on Mobile Devices

Info

Publication number: US20120210321A1
Application number: US13/164,497
Authority: US
Inventors: Bruno C. Silva; Abolade Gbadegesin; Ion Vasilian; Shawn P. Burke; Timothy Michael Kurtzman; Istvan Cseri; Randal J. Ramig; Adina Magdalena Trufinescu; Peter John Torr; Paul D. Barnett; Srivatsan Kidambi
Original assignee: Microsoft Corp
Current assignee: Microsoft Technology Licensing LLC
Priority date: 2011-02-14
Filing date: 2011-06-20
Publication date: 2012-08-16
Also published as: WO2012112405A3; US11006369B2; US20120209946A1; US20180352516A1; US20180139700A9; EP2676206A2; CN102685729B; CN102685729A; EP2676206A4; US10542496B2; US9060196B2; US20120210326A1; WO2012112405A2; US20200154360A1; CN102779070A; CN102866913A; US10009850B2; WO2012112404A3; WO2012112404A2; US20170238259A1

Abstract

The subject disclosure is directed towards a technology in which a mobile device maintains an application in a dormant state in which the application's process is not terminated and remains in memory, but the application cannot execute code. Further, state and execution context are maintained for the application, allowing the application to be quickly and efficiently resumed into the running state. To prevent the application from executing code while dormant, thread activity is suspended, requests canceled, completed or paused, resources detached, and so forth. Resource usage may be monitored for dormant applications, to remove a misbehaving dormant application process from memory if improperly using resources.

Description

CROSS-REFERENCE TO RELATED APPLICATION

The present application claims priority to U.S. provisional patent applications Ser. Nos. 61/442,701, 61/442,713, 61/442,735, 61/442,740 and 61/442,753, each filed Feb. 14, 2011 and hereby incorporated by reference. The present application is related to U.S. patent applications attorney docket nos. 332296.02, 332297.02, 332339.02 and 332340.02, assigned to the assignee of the present invention, and hereby incorporated by reference.

BACKGROUND

On a contemporary mobile device, if an application is running and is subsequently replaced in the foreground by another application or experience, the first application is deactivated and the application's process is terminated by the operating system. An application may be deactivated if the user presses the Start button or if the device timeout causes the lock screen to be engaged, for example.
In one system, the user may return to the application to continue an application task/experience from where the user left it. However, when returning to an application that was terminated by the operating system, the user needs to wait for the device application framework to initialize, and for the application itself to load saved state and to resume the previous experience. Resuming in this way can seem relatively slow and thus provide a somewhat undesirable user experience.

SUMMARY

This Summary is provided to introduce a selection of representative concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used in any way that would limit the scope of the claimed subject matter.
Briefly, various aspects of the subject matter described herein are directed towards a technology by which an application is moved from a running (e.g., foreground) state into a dormant state in which the application process is retained in memory. Further, state data and execution context information are maintained in association with the application, which allows the application to be activated to the running state, e.g., in a rapid, efficient manner. In one aspect, moving the application from the running state into the dormant state includes pausing for a time duration to allow the application to prepare for the dormant state, e.g., persist data from memory, close any open files, and so forth.
In one aspect, moving the foreground application from a running state into the dormant state includes detaching at least one resource from the application, pausing at least one update notification provided by a resource to the application, canceling at least one cancellable request, pausing at least one non-cancellable request, stopping at least one thread, and/or freeing at least one application resource (e.g., memory allocated to the application).
To activate the application back from the dormant state to a foreground application in the running state, the state data and the execution context information is accessed, and at least one resource is attached to the application. Also described is resuming at least one update notification provided by a resource to the application, running a failure path for at least one cancellable request, resuming at least one non-cancellable request, firing at least one notification, recreating an resuming at least one thread, and/or recreating at least one application resource.
In one aspect, a resource monitor is configured to evaluate whether the application, when in the dormant state, is using at least one resource (e.g., CPU) beyond an allowed threshold. If so, the shell is configured to move the application from the dormant state into another state in which the process of the application is not retained in memory.
Other advantages may become apparent from the following detailed description when taken in conjunction with the drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention is illustrated by way of example and not limited in the accompanying figures in which like reference numerals indicate similar elements and in which:

FIG. 1 is a block diagram representing example applications in different states hosted by an operating system shell, including applications in a dormant state.

FIG. 2 is state diagram showing example states for applications, including a dormant state, and transitions between the states.

FIG. 3A is a sequence/control diagram representing an example flow of events/control among components when launching an application.

FIG. 3B is a sequence/control diagram representing an example flow of events/control among components when deactivating an application.

FIG. 4A is a sequence/control diagram representing an example flow of events/control among components when resuming a deactivated application from a dormant state.

FIG. 4B is a sequence/control diagram representing an example flow of events/control among components when closing an application.

FIG. 5 is a block diagram representing an exemplary non-limiting computing system or operating environment, e.g., in the example of a mobile phone device, in which one or more aspects of various embodiments described herein can be implemented.

DETAILED DESCRIPTION

Various aspects of the technology described herein are generally directed towards a technology in which a mobile device or the like maintains an application in a dormant state, generally corresponding to an application that cannot execute any code when in the background. To this end, the shell component/framework that comprises the (e.g., Windows® phone) application platform retains the application process in memory, and maintains state and execution context for the application, but does not allow the process to run. For example, the shell may suspend thread activity within background applications. The dormant background application regains the ability to execute code when the user brings the application to foreground.
In one implementation, the operating system does not terminate the application's process when deactivating an application. Instead, applications may go in the background and remain resident in memory. This eliminates the need to reinitialize the application and reload state, which implicitly means faster application resume time.
It should be understood that any of the examples herein are non-limiting. For one, example implementations and dormant applications are described in the context of a Windows® mobile device operating environment, however this is only for purposes of explanation, and other operating environments may benefit from the concept of a dormant application state as described herein. As such, the present invention is not limited to any particular embodiments, aspects, concepts, structures, functionalities or examples described herein. Rather, any of the embodiments, aspects, concepts, structures, functionalities or examples described herein are non-limiting, and the present invention may be used various ways that provide benefits and advantages in computing and application/task switching in general.
FIG. 1 is a generalized block diagram showing various example components in a mobile device environment. A plurality of applications are controlled by a shell 102 (application framework), which provides access to device resources, including exclusive resources 104 (e.g., the display) that only one application, usually only the foreground application 106, typically can access, and shared resources 108 (e.g., memory, networking and so forth) that the foreground application 106 and other applications may use.
As exemplified in FIG. 1, one or more applications are tombstoned applications 110 ₁-110 _m. More particularly, in conventional mobile devices, applications are terminated shortly after they are no longer the foreground application. In previous devices, the application remained terminated (e.g., block 112) and had to be fully re-launched as a new instance. In some more contemporary mobile devices, if the UX (user experience, including user interface components) provides mechanisms for the user to navigate back to application instances, each application instead may be tombstoned in contrast to terminated, meaning that the application is given a chance to save state, after which the process is torn down and a marker of its prior existence is kept on an application stack.
The technology described herein is directed towards maintaining one or more applications as dormant applications 114 ₁-114 _n, in which a dormant application (e.g., its process) is retained as resident in memory, in conjunction with maintaining the application's associated state and execution context. This allows a dormant application to be more rapidly activated (relative to tombstoned applications) to the foreground running state.
FIG. 2 is a state diagram showing example states of an application once the user launches the application (block 222) and the application enters the running state 224. In this example, the application remains in the running state 224 until the user takes a user interaction, navigation-related action, namely a backward navigation action (block 226, e.g., back past the application in the stack, or a close the application action), which in response closes the application, or a forward navigation action (block 228), such as pressing the Start button, which deactivates the application.
When deactivated, the shell/framework notifies the application and pauses for a duration (e.g., for up to ten seconds) to give the application time to prepare for becoming a dormant application. For example, the application is given time to persist memory, close any open files, and so forth.
Pausing is represented in FIG. 2 by the pausing state 230, which when pausing completes (block 234) enters the dormant state 236. In the event the user returns to the application (activated, block 240) before the full pause time is reached, the application returns to the running state 224.
The shell 102 detects when an application is deactivated, and moves it into the dormant state 236. When detected, the shell 102 performs certain operations to ensure that the dormant application is not able to interfere with the new foreground application. For example, the shell 102 cancels any cancellable requests, may block API utilization, releases exclusive hardware resources attached to the deactivated application, and suspends threads created by the application or on behalf of the application. The shell suspends the application's thread activity and prevents the background application from consuming CPU cycles. By doing so, dormant background applications act as if the process was terminated by the operating system and do not continue using the device's battery or slow down the device foreground activity.
Note that for performance/perceived performance, some of these operations may be in parallel with preparing the new foreground application. For example, the shell may give the new application the display resource during the pause time so that the user does not have to wait the full ten seconds to perceive the change to the new foreground application. The foreground application may not be given the camera resource right away, e.g., in case the user inadvertently pressed the Start button, for example, and wants to return to the application that was running.
The shell detaches resources from deactivated applications. Examples of such resources include the vibration controller, sound and media player, photo/video camera, location services, sensors, networking and so forth. By doing so, in the dormant state 236, dormant background applications act as if the process was terminated by the operating system and does not continue using device resources or prevent the application in the foreground from using these resources.
The shell may release memory resources from dormant background applications to minimize the memory footprint in the operating system. The smaller the application memory footprint, the greater the number of dormant background applications that are able to reside in memory, and thus be quickly resumed.
The shell 102, e.g., via a resource monitor component 120 (FIG. 1, incorporated therein or coupled thereto) also may monitor usage of at least one resource (e.g., CPU usage) by the dormant application. More particularly, a general goal is that a dormant application performs no significant activity, including that no code runs; however some code (e.g., first party native applications) may continue to run code. Thus, after the ten second duration to allow preparation for becoming dormant, the shell may enforce resource non-usage. To this end, periodically (e.g., every five minutes) or according to some other event, each dormant application's CPU usage is checked. If still dormant and there is some CPU usage, (e.g., CPU usage>0 or some other allowed threshold), the dormant application is moved to the tombstoned state 238 (FIG. 2). This may checked regardless of other state (e.g., not just when the device/phone is idle). Further, a progressive tightening policy may be used, e.g., the threshold may be non-zero and decrease over time.
If necessary, such as when the operating system reaches out-of-memory conditions, the shell may terminate the processes of dormant background applications, e.g., by tombstoning or fully terminating by not maintaining state/a marker. This frees up memory resources (and any other shared resources) for the application in the foreground.
To summarize, when paused, the system shell operates to detach exclusive use resources from underneath the application, and detach shared use resources from underneath the application. The shell pauses update notifications provided by a resource to the application. For cancellable requests that are pending, the shell cancels them; any non-cancellable requests are paused or given a completion notification. In process (in-proc) native threads created on behalf of the application are stopped, and if possible, any out of process (out-of-proc) native threads created on behalf of the application are stopped. Any application resources that can be easily and quickly recreated are freed.
Turning to activating/resuming the application from the dormant state, upon application activation, the framework resumes the application threads and runs the normal failure paths for cancelled requests, and attaches resources on behalf of the application. More particularly, when resuming, the system shell operates to reattach exclusive use resources and restore their state. If possible, shared use resources are reattached and their state restored. Update notifications provided by a resource to the application are resumed. For cancellable requests that were cancelled, the normal failure path in the application is run. Any non-cancellable requests are resumed, and any pending completion notifications are fired. The shell recreates/resumes any in-proc native threads created on behalf of the application, and any out-of-proc native threads created on behalf of the application as needed. Freed resources are also recreated as needed.
FIGS. 3A-4B are sequence diagrams directed towards a Windows® mobile device environment, generally showing how events trigger various components to participate in deactivating an application to the dormant state, and activating an application from the dormant state. FIG. 3A illustrates example combined control flows for a forward navigation scenario where an application is launching while an application (previously in the foreground) is deactivated (FIG. 3B). FIGS. 4A and 4B are sequence diagrams illustrating example combined control flows for resuming an activated application (FIG. 4A), and closing an application (FIG. 4B).
In FIGS. 3A-4B, the shell 102 comprises a server that hosts one or more client processes, e.g., the taskhost.exe 330 for each application. To start a launched task (FIG. 3A), a shell execution manager 331 communicates with a client execution manager 332, which in turn signals a task host component 334. In FIGS. 3A-4D, the task host component 334 communicates with a frame component 336 that handle pages exposed by application navigation, e.g., puts previous pages on a stack for navigation, manages buffers (including using an internal splash application to allocate image buffers) and so forth. As the user interacts via pages, the frame component generates events. The SLM/XNA and CLR components 338 and 340 refer to Silverlight®-based and common language runtimes, respectively, used in this example environment. The application code is represented via the app component 342.

Exemplary Operating Environment

FIG. 5 illustrates an example of a suitable mobile device 500 on which aspects of the subject matter described herein may be implemented. The mobile device 500 is only one example of a device and is not intended to suggest any limitation as to the scope of use or functionality of aspects of the subject matter described herein. Neither should the mobile device 500 be interpreted as having any dependency or requirement relating to any one or combination of components illustrated in the exemplary mobile device 500.
With reference to FIG. 5, an exemplary device for implementing aspects of the subject matter described herein includes a mobile device 500. In some embodiments, the mobile device 500 comprises a cell phone, a handheld device that allows voice communications with others, some other voice communications device, or the like. In these embodiments, the mobile device 500 may be equipped with a camera for taking pictures, although this may not be required in other embodiments. In other embodiments, the mobile device 500 may comprise a personal digital assistant (PDA), hand-held gaming device, notebook computer, printer, appliance including a set-top, media center, or other appliance, other mobile devices, or the like. In yet other embodiments, the mobile device 500 may comprise devices that are generally considered non-mobile such as personal computers, servers, or the like.
Components of the mobile device 500 may include, but are not limited to, a processing unit 505, system memory 510, and a bus 515 that couples various system components including the system memory 510 to the processing unit 505. The bus 515 may include any of several types of bus structures including a memory bus, memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures, and the like. The bus 515 allows data to be transmitted between various components of the mobile device 500.
The mobile device 500 may include a variety of computer-readable media. Computer-readable media can be any available media that can be accessed by the mobile device 500 and includes both volatile and nonvolatile media, and removable and non-removable media. By way of example, and not limitation, computer-readable media may comprise computer storage media and communication media. Computer storage media includes volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer-readable instructions, data structures, program modules, or other data. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by the mobile device 500.
Communication media typically embodies computer-readable instructions, data structures, program modules, or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media. 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 wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, Bluetooth®, Wireless USB, infrared, WiFi, WiMAX, and other wireless media. Combinations of any of the above should also be included within the scope of computer-readable media.
The system memory 510 includes computer storage media in the form of volatile and/or nonvolatile memory and may include read only memory (ROM) and random access memory (RAM). On a mobile device such as a cell phone, operating system code 520 is sometimes included in ROM although, in other embodiments, this is not required. Similarly, application programs 525 are often placed in RAM although again, in other embodiments, application programs may be placed in ROM or in other computer-readable memory. The heap 530 provides memory for state associated with the operating system 520 and the application programs 525. For example, the operating system 520 and application programs 525 may store variables and data structures in the heap 530 during their operations.
The mobile device 500 may also include other removable/non-removable, volatile/nonvolatile memory. By way of example, FIG. 5 illustrates a flash card 535, a hard disk drive 536, and a memory stick 537. The hard disk drive 536 may be miniaturized to fit in a memory slot, for example. The mobile device 500 may interface with these types of non-volatile removable memory via a removable memory interface 531, or may be connected via a universal serial bus (USB), IEEE 5394, one or more of the wired port(s) 540, or antenna(s) 565. In these embodiments, the removable memory devices 535-537 may interface with the mobile device via the communications module(s) 532. In some embodiments, not all of these types of memory may be included on a single mobile device. In other embodiments, one or more of these and other types of removable memory may be included on a single mobile device.
In some embodiments, the hard disk drive 536 may be connected in such a way as to be more permanently attached to the mobile device 500. For example, the hard disk drive 536 may be connected to an interface such as parallel advanced technology attachment (PATA), serial advanced technology attachment (SATA) or otherwise, which may be connected to the bus 515. In such embodiments, removing the hard drive may involve removing a cover of the mobile device 500 and removing screws or other fasteners that connect the hard drive 536 to support structures within the mobile device 500.
The removable memory devices 535-537 and their associated computer storage media, discussed above and illustrated in FIG. 5, provide storage of computer-readable instructions, program modules, data structures, and other data for the mobile device 500. For example, the removable memory device or devices 535-537 may store images taken by the mobile device 500, voice recordings, contact information, programs, data for the programs and so forth.
A user may enter commands and information into the mobile device 500 through input devices such as a key pad 541 and the microphone 542. In some embodiments, the display 543 may be touch-sensitive screen and may allow a user to enter commands and information thereon. The key pad 541 and display 543 may be connected to the processing unit 505 through a user input interface 550 that is coupled to the bus 515, but may also be connected by other interface and bus structures, such as the communications module(s) 532 and wired port(s) 540. Motion detection 552 can be used to determine gestures made with the device 500.
A user may communicate with other users via speaking into the microphone 542 and via text messages that are entered on the key pad 541 or a touch sensitive display 543, for example. The audio unit 555 may provide electrical signals to drive the speaker 544 as well as receive and digitize audio signals received from the microphone 542.
The mobile device 500 may include a video unit 560 that provides signals to drive a camera 561. The video unit 560 may also receive images obtained by the camera 561 and provide these images to the processing unit 505 and/or memory included on the mobile device 500. The images obtained by the camera 561 may comprise video, one or more images that do not form a video, or some combination thereof.
The communication module(s) 532 may provide signals to and receive signals from one or more antenna(s) 565. One of the antenna(s) 565 may transmit and receive messages for a cell phone network. Another antenna may transmit and receive Bluetooth® messages. Yet another antenna (or a shared antenna) may transmit and receive network messages via a wireless Ethernet network standard.
Still further, an antenna provides location-based information, e.g., GPS signals to a GPS interface and mechanism 572. In turn, the GPS mechanism 572 makes available the corresponding GPS data (e.g., time and coordinates) for processing.
In some embodiments, a single antenna may be used to transmit and/or receive messages for more than one type of network. For example, a single antenna may transmit and receive voice and packet messages.
When operated in a networked environment, the mobile device 500 may connect to one or more remote devices. The remote devices may include a personal computer, a server, a router, a network PC, a cell phone, a media playback device, a peer device or other common network node, and typically includes many or all of the elements described above relative to the mobile device 500.
Aspects of the subject matter described herein are operational with numerous other general purpose or special purpose computing system environments or configurations. Examples of well known computing systems, environments, and/or configurations that may be suitable for use with aspects of the subject matter described herein include, but are not limited to, personal computers, server computers, hand-held or laptop devices, multiprocessor systems, microcontroller-based systems, set top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, distributed computing environments that include any of the above systems or devices, and the like.
Aspects of the subject matter described herein may be described in the general context of computer-executable instructions, such as program modules, being executed by a mobile device. Generally, program modules include routines, programs, objects, components, data structures, and so forth, which perform particular tasks or implement particular abstract data types. Aspects of the subject matter described herein may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.
Furthermore, although the term server may be used herein, it will be recognized that this term may also encompass a client, a set of one or more processes distributed on one or more computers, one or more stand-alone storage devices, a set of one or more other devices, a combination of one or more of the above, and the like.

Conclusion

While the invention is susceptible to various modifications and alternative constructions, certain illustrated embodiments thereof are shown in the drawings and have been described above in detail. It should be understood, however, that there is no intention to limit the invention to the specific forms disclosed, but on the contrary, the intention is to cover all modifications, alternative constructions, and equivalents falling within the spirit and scope of the invention.

Claims

1. In a computing environment, a method performed at least in part on at least one processor, comprising, moving an application from a running state into a dormant state, including retaining an application process in memory, and maintaining state data and execution context information in association with the application that allows the application to be activated to the running state.

2. The method of claim 1 wherein moving the application from the running state into the dormant state includes pausing for a time duration to allow the application to prepare for the dormant state.

3. The method of claim 1 wherein moving the application from the running state into the dormant state occurs in response to detecting user interaction corresponding to forward navigation.

4. The method of claim 1 further comprising, activating the application from the dormant state into a running state, wherein moving the application from the dormant state into the running state occurs in response to detecting user interaction corresponding to backward navigation.

5. The method of claim 1 wherein moving the application from the running state into the dormant state includes suspending at least one thread created by the application or on behalf of the application, or both.

6. The method of claim 1 wherein moving the application from the running state into the dormant state includes canceling at least one cancellable request.

7. The method of claim 1 wherein moving the application from the running state into the dormant state includes blocking utilization of APIs by the application.

8. The method of claim 1 wherein moving the application from the running state into the dormant state includes releasing at least one resource attached to the application.

9. The method of claim 1 wherein the application is dormant on a mobile computing device, and further comprising, determining that the device needs more available memory, terminating the application process, including moving the application from the dormant state into a terminated state, and reclaiming at least some of the memory that was used for retaining the application process.

10. The method of claim 1 further comprising, monitoring resource usage of the dormant application, and if the resource usage exceeds a threshold, moving the application from the dormant state into a tombstoned state.

11. The method of claim 1 further comprising, activating the application from the dormant state into a running state, including accessing the state data and the execution context information.

12. The method of claim 11 wherein moving the application from the running state into the dormant state includes suspending at least one thread created by the application or on behalf of the application, or both, and wherein activating the application from the dormant state into the running state comprises resuming at least one suspended thread created by the application or on behalf of the application, or both.

13. The method of claim 11 wherein maintaining the application in the dormant state further comprises canceling at least one cancellable request, and wherein activating the application further comprises, running a failure path for at least one cancelled request.

14. The method of claim 11 wherein maintaining the application in the dormant state further comprises blocking utilization of APIs, and wherein activating the application further comprises allowing utilization of APIs.

15. The method of claim 11 wherein maintaining the application in the dormant state further comprises, releasing at least one resource associated with the application, and wherein activating the application further comprises attaching at least one resource to the application.

16. In a computing environment, a system comprising, a shell component configured to transition applications between states, including from a running state into a dormant state in which a process of the application is retained in memory, and a resource monitor component coupled to the shell component, the resource monitor component configured to evaluate whether the application when in the dormant state is using at least one resource beyond an allowed threshold, and if so, the shell component configured to move the application from the dormant state into a state in which the process of the application is not retained in memory.

17. The system of claim 16 wherein when moving the application into the dormant state, the shell component is further configured to detach at least one resource from the application, pause at least one update notification provided by a resource to the application, cancel at least one cancellable request, pause or complete or both at least one non-cancellable request, stop at least one thread, or free at least one application resource, or any combination thereof.

18. The system of claim 16 wherein the shell component is further configured to activate the application from the dormant state to a running state, including by attaching at least one resource to the application, resuming at least one update notification provided by a resource to the application, running a failure path for at least one cancellable request, resuming at least one non-cancellable request, firing at least one notification, recreating an resuming at least one thread, or recreating at least one application resource, or any combination thereof.

19. One or more computer-readable media having computer-executable instructions, which when executed perform steps, comprising,

moving a foreground application from a running state into a dormant state, including pausing for a time to allow the application to prepare for the dormant state, detaching at least one resource from the application, blocking API utilization, pausing at least one update notification provided by a resource to the application, canceling at least one cancellable request, pausing at least one non-cancellable request, stopping at least one thread, or freeing at least one application resource, or any combination thereof; and

moving the application from the dormant state to a foreground application in the running state, including by attaching at least one resource to the application, resuming at least one update notification provided by a resource to the application, allowing API utilization, running a failure path for at least one cancellable request, resuming at least one non-cancellable request, firing at least one notification, recreating an resuming at least one thread, or recreating at least one application resource, or any combination thereof

20. The one or more computer-readable media of claim 19 having further computer-executable instructions comprising, detecting navigation commands, and moving the foreground application from the running state into the dormant state based upon at least one navigation command, and moving the application from the dormant state into the running state based upon at least one other navigation command.