U.S. patent application number 13/164497 was filed with the patent office on 2012-08-16 for dormant background applications on mobile devices.
This patent application is currently assigned to MICROSOFT CORPORATION. Invention is credited to Paul D. Barnett, Shawn P. Burke, Istvan Cseri, Abolade Gbadegesin, Srivatsan Kidambi, Timothy Michael Kurtzman, Randal J. Ramig, Bruno C. Silva, Peter John Torr, Adina Magdalena Trufinescu, Ion Vasilian.
Application Number | 20120210321 13/164497 |
Document ID | / |
Family ID | 46637513 |
Filed Date | 2012-08-16 |
United States Patent
Application |
20120210321 |
Kind Code |
A1 |
Silva; Bruno C. ; et
al. |
August 16, 2012 |
Dormant Background Applications on Mobile Devices
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.
Inventors: |
Silva; Bruno C.; (Clyde
Hill, WA) ; Gbadegesin; Abolade; (Seattle, WA)
; Vasilian; Ion; (Seattle, WA) ; Burke; Shawn
P.; (Kirkland, WA) ; Kurtzman; Timothy Michael;
(Redmond, WA) ; Cseri; Istvan; (Seattle, WA)
; Ramig; Randal J.; (Seattle, WA) ; Trufinescu;
Adina Magdalena; (Redmond, WA) ; Torr; Peter
John; (Bellevue, WA) ; Barnett; Paul D.;
(Renton, WA) ; Kidambi; Srivatsan; (Hyderabad,
IN) |
Assignee: |
MICROSOFT CORPORATION
Redmond
WA
|
Family ID: |
46637513 |
Appl. No.: |
13/164497 |
Filed: |
June 20, 2011 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
61442735 |
Feb 14, 2011 |
|
|
|
61442701 |
Feb 14, 2011 |
|
|
|
61442713 |
Feb 14, 2011 |
|
|
|
61442740 |
Feb 14, 2011 |
|
|
|
61442753 |
Feb 14, 2011 |
|
|
|
Current U.S.
Class: |
718/100 |
Current CPC
Class: |
Y02D 70/144 20180101;
H04W 4/50 20180201; G06F 9/546 20130101; H04L 41/0893 20130101;
H04N 21/6175 20130101; Y02D 70/12 20180101; Y02D 70/124 20180101;
H04W 4/60 20180201; H04W 52/0264 20130101; Y02D 70/23 20180101;
Y02D 70/26 20180101; H04N 21/4126 20130101; Y02D 30/70 20200801;
H04N 21/439 20130101; H04N 21/233 20130101; G06F 9/5011 20130101;
Y02D 70/142 20180101; Y02D 70/146 20180101; Y02D 70/164
20180101 |
Class at
Publication: |
718/100 |
International
Class: |
G06F 9/46 20060101
G06F009/46 |
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.
Description
CROSS-REFERENCE TO RELATED APPLICATION
[0001] 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
[0002] 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.
[0003] 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
[0004] 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.
[0005] 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.
[0006] 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).
[0007] 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.
[0008] 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.
[0009] Other advantages may become apparent from the following
detailed description when taken in conjunction with the
drawings.
BRIEF DESCRIPTION OF THE DRAWINGS
[0010] 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:
[0011] FIG. 1 is a block diagram representing example applications
in different states hosted by an operating system shell, including
applications in a dormant state.
[0012] FIG. 2 is state diagram showing example states for
applications, including a dormant state, and transitions between
the states.
[0013] FIG. 3A is a sequence/control diagram representing an
example flow of events/control among components when launching an
application.
[0014] FIG. 3B is a sequence/control diagram representing an
example flow of events/control among components when deactivating
an application.
[0015] 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.
[0016] FIG. 4B is a sequence/control diagram representing an
example flow of events/control among components when closing an
application.
[0017] 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
[0018] 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.RTM. 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.
[0019] 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.
[0020] 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.RTM. 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.
[0021] 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.
[0022] As exemplified in FIG. 1, one or more applications are
tombstoned applications 110.sub.1-110.sub.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.
[0023] The technology described herein is directed towards
maintaining one or more applications as dormant applications
114.sub.1-114.sub.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.
[0024] 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.
[0025] 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.
[0026] 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.
[0027] 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.
[0028] 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.
[0029] 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.
[0030] 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.
[0031] 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.
[0032] 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.
[0033] 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.
[0034] 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.
[0035] FIGS. 3A-4B are sequence diagrams directed towards a
Windows.RTM. 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).
[0036] 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.RTM.-based and common language runtimes,
respectively, used in this example environment. The application
code is represented via the app component 342.
Exemplary Operating Environment
[0037] 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.
[0038] 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.
[0039] 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.
[0040] 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.
[0041] 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.RTM., 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.
[0042] 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.
[0043] 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.
[0044] 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.
[0045] 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.
[0046] 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.
[0047] 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.
[0048] 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.
[0049] 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.RTM.
messages. Yet another antenna (or a shared antenna) may transmit
and receive network messages via a wireless Ethernet network
standard.
[0050] 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.
[0051] 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.
[0052] 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.
[0053] 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.
[0054] 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.
[0055] 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
[0056] 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.
* * * * *