Abstract:
The subject disclosure is directed towards a task switching technology on a computing device such as a Smartphone. An application is comprised of one or more tasks. When a user requests that another task be executed, information about the previously executing task (e.g., including a screenshot) is preserved to a stack. If the user invokes a task switcher program, the user is presented with a view of the stack, e.g., containing the screenshots (and representative text) of the tasks that previously executed. The user may navigate among those presented task representations to arbitrarily select any one, with the selected task resumed upon selection.

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, 332320.02, 332339.02 and 332340.02, assigned to the assignee of the present invention, hereby incorporated by reference. 
     
    
     BACKGROUND 
       [0002]    Users of mobile devices switch applications into the foreground. Some mobiles devices offer an interface to switch between recently used applications. For example, the user can use a “Back” button to navigate through the user&#39;s applications. This technique is inefficient, because not only does the user need to remember which applications were recently used so as to know whether the “Back” button will get to the desired application, the technique does not provide a quick way for the user to resume an application that is more than a couple of back button presses away. 
         [0003]    Moreover, there is no clear distinction between resuming an application and launching an application in a fresh state. The user is not offered a choice. 
       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 a task switcher provides a straightforward mechanism for a user to view and navigate among previous tasks of applications and arbitrarily switch to any selected task. In general, an application (or other program such as an operating system component) may be comprised of one or more tasks, such as an email application having a mail task, a calendar task, and a contacts task, or a browser program having a task for each tabbed page. 
         [0006]    In one aspect, a task switcher (e.g., program) may be invoked by user action, e.g., in response to a user request, and obtains information from a data structure (e.g., a stack). The data structure contains the information (state data) associated with each task of a set of tasks that previously executed on the computing device. The task switcher uses the information to output a representation (e.g., a screenshot with accompanying text) of each task to a user interface of the task switcher. Via the user interface, the user may navigate among the task representations and/or arbitrarily select any task of the set for resuming that task. For example, the application may be re-launched, with state information saved in the stack or elsewhere used to resume the task within its corresponding application. 
         [0007]    In one aspect, information associated with a plurality of tasks is maintained, with each task corresponding to an application program that previously executed as a foreground application. A task switcher uses the maintained information for outputting a representation of each task to an interactive user interface. The task switcher detects user interaction (e.g., user navigation and selection) corresponding to user-selection of one of the task representations as a selected task, and takes action to switch to the selected task by resuming the application in a state corresponding to the selected task. 
         [0008]    In one aspect, the stack is updated to save information regarding an executing task before replacing the executing task with a task of another application. Maintaining the stack may include releasing data of another task from the stack to provide memory space to save the information regarding the executing task, and/or filtering out data of a duplicate task. 
         [0009]    In one aspect, there is described a technology for presenting a view of a stack of task data corresponding to previously executing tasks of applications, in which the view includes visible representations of tasks having task data in the stack. Upon detecting interaction with the view to navigate to a particular task representation, and detecting interaction to select a selected task, execution of the selected task may be resumed. 
         [0010]    Other advantages may become apparent from the following detailed description when taken in conjunction with the drawings. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0011]    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: 
           [0012]      FIG. 1  is a block diagram representing example components used in performing task switching among tasks. 
           [0013]      FIG. 2  is an example representation of tasks among which a user may navigate and select for resuming on the device. 
           [0014]      FIG. 3  is a block diagram representing example components used in one implementation of a task switching system. 
           [0015]      FIG. 4  is an example timing sequence/dataflow diagram showing operations related to how information including a captured screen image is obtained and maintained in a task switching system. 
           [0016]      FIG. 5  is an example timing sequence/dataflow diagram showing operations related to invoking a task switcher. 
           [0017]      FIG. 6  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 reliable and easy technique to resume a previous task that a user was performing on a mobile device, such as a task on a mobile phone. As will be understood, switching “tasks” is more flexible and powerful than switching applications; examples of tasks include a contact card, an email draft, a calendar appointment (e.g., within the same email application), a browser webpage tab, and so forth. Notwithstanding, an application may comprise a single task. 
         [0019]    To this end, there is provided a task switcher on a device that provides users with the ability to reliably and to quickly resume or finish a task that was previously started. The task switcher, which in one implementation comprises a program with an accompanying user interface (UI), shows a user the state in which the user&#39;s tasks were left, so that the user can easily identify a desired task to resume. Also exemplified herein is one example visual design for showing the last state of a task, accompanied by its name, which provides benefits and advantages relative to an application icon, for example. 
         [0020]    It should be understood that any of the examples herein are non-limiting. 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 for switching among tasks, including a task switcher  102 , where an application has one or more tasks specified for it as defined by the application developer. For example, an application such as a calculator may only have one task, whereas an application such as Microsoft® Outlook may have a mail task, a calendar task, a contacts task, and so on. 
         [0022]    In general, a plurality of application tasks  104   1 - 104   n  may be run in the foreground of the device at different times. Each time a new instance of an application task is run, referred to as a session, the operating system  106  saves information regarding the previous task to a backstack  108 . Filtering may be performed, e.g., to avoid adding duplicate tasks to the backstack  108 , such as by only allowing one instance of a task/session to be added. 
         [0023]    The backstack  108  comprises a data structure (e.g., in memory) that maintains information regarding the saved tasks, as well as information needed to restore a task. For example, the backstack  108  may comprise a list of objects, with each object containing data (and/or a reference to the data) regarding a saved task, such as to provide a screenshot of the task captured when saved, the name of the application, task state data, and so forth. The number of objects may be limited (e.g., by default or user configuration) so as to keep the number of maintained tasks practical for the user, as well as to control memory usage; thus, adding a new task to the backstack removes the oldest task. As described herein, the backstack may be used to maintain (or reference pointers to) screenshots and/or other metadata related to a set of a maintained task or tasks. With the task switcher, users may navigate to any session (and in no specified order) in the backstack. This does not break the navigation within sessions. Note that the backstack maintains the tasks in time order, however a user may navigate to any task, and thus make that task the newest task with the others keeping the same order behind that newest task. 
         [0024]    In general, a task switcher activation mechanism  110  comprising a button or the like is detected by a suitable part of the operating system  106 , which invokes the task switcher  102 . The task switcher  102  may be launched in any suitable way, such as in one implementation in which the task switcher  102  may be launched via a long press on a hardware back button. When invoked, the task switcher (e.g., along with the operating system  106 ) captures the last state of a task before the user leaves the task, e.g., by adding that task&#39;s data to the backstack  108 . Note however that data regarding the task switcher  102  need not be added to the backstack  108  when leaving the task switcher  102 . 
         [0025]    The task switcher  102  displays each of the captured task states in some suitable way as a view  112 , such as ordered from left to right as generally represented in  FIG. 2 , e.g., with the left task being the oldest task and the right task being the newest one. In one view, only one task is shown at a time, as represented by the dashed “view” box  212 , and users can pan horizontally (as represented by the arrows) to find a previous or later task via an interaction/selection mechanism  114  ( FIG. 1 ), with selection able to be made on the currently shown task. In another view, users can see multiple tasks at the same time, and pick one via the interaction/selection mechanism  114 , such as by tapping on the task&#39;s screen capture image. Thus, the user may make an arbitrary selection of any task to resume via its displayed representation, rather than having to resume in sequential order. The user can also cancel without making any selection, whereby the task that was running when the user invoked the task switcher is resumed. 
         [0026]    As can be readily appreciated, virtually any view with an appropriate selection mechanism is feasible, subject to practical screen size limitations. Moreover, instead of or in addition to a screen capture, some other representation of the task may be provided, along with possibly additional text (e.g., timestamp), graphics, animation, video and so forth. 
         [0027]    Note that multi-tasking allows applications to continue to work even when they are not in the foreground, including via a task model that allows users to navigate in the forward direction and allow back navigations one page at a time. To quickly resume previously used applications to the foreground, the task switcher allows a user to quickly view and navigate among application tasks (e.g., user interfaces) maintained in the backstack. 
         [0028]    Turning to additional details of one example implementation, a long press on the back hardware button beyond a threshold time (e.g., the duration of the press-and-hold button press is on the order of 800 ms) launches the task switcher UI, comprising the sessions in the backstack, each represented by a screen capture of the session&#39;s last page as generally represented in  FIG. 2 . In this implementation, the screen captures are ordered from left to right, with the most recent being in the most right. The UI pans horizontally. Tapping on a screen capture resumes the corresponding session at that page, that is, each screen capture in  FIG. 2  represents a task which the user may resume by tapping on its screen capture. Transition animations may be used for any screen image change, and the background may use the current accent theme color. 
         [0029]    Sessions are added in order, e.g., whereby the most recent session is the rightmost screen capture. The task switcher launches with the right most screenshot in view. In one implementation, the task switcher does not remember its scrolled state so as to consistently provide a predictable default view. 
         [0030]    When a session is resumed from the task switcher, it is moved from its current position to the rightmost position, as the most recent session. A short press on back navigates within the current session. The behavior of the backstack does not change. The start screen does not show in the task switcher, and the only way to get to Start is via the Start hardware button in one implementation. 
         [0031]    The task switcher uses screen captures for the user to identify a task that he or she wants to resume. A screen capture of the last page of a session is used to represent the session. The screen capture may include transient UI like reminders, alarms and message boxes. In order to help users better identify a task, one implementation may display the corresponding application name beneath the screen capture. 
         [0032]    The task switcher may be dismissed when the phone locks (either manually by the user or automatically after a timeout). It does not work above the lock screen. When the task switcher is in the foreground and the incoming call UI appears, the task switcher stays behind the call UI so that the user can continue a task after dealing with the incoming call. The behavior of the incoming call UI does not change. 
         [0000]    
       
         
               
             
               
               
               
             
           
               
                   
               
               
                 Example Hardware Buttons with respect to Task Switcher 
               
             
          
           
               
                   
                 Button 
                 Behavior 
               
               
                   
                   
               
               
                   
                 Start 
                 Dismisses the task switcher and launches Start 
               
               
                   
                 Back 
                 Dismisses the task switcher 
               
               
                   
                 Search 
                 Dismisses the task switcher and launches Search 
               
               
                   
                 Volume 
                 Works over task switcher 
               
               
                   
                 Power 
                 Dismisses task switcher and locks the phone 
               
               
                   
                 Camera 
                 Dismisses the task switcher and launches Camera 
               
               
                   
                   
               
             
          
         
       
     
         [0033]    When there are no sessions in the task switcher, one implementation may show a screen capture of Start. When tapped on, Start is brought to the foreground. This way, the user is never “dead-ended” in the task switcher. 
         [0034]    Because one goal is to present a literal backstack, each tab in the browser may show as an individual session in the task switcher. 
         [0035]      FIG. 3  shows additional details of an example architecture version, (with labels 3xx instead of 1xx for like or similar components) in which the task switcher  302  may be a part of the shell chrome and thus may reside in the shell frame  330  (e.g., ShellFrame.dll). Note that if a task switcher is instead a separate application, bringing it up as a conventional application may force another application off of the backstack  108  (corresponding to the PageStack  308  in  FIG. 3 ), which is generally not desirable. Thus, the task switcher  302  may be kept in the shell frame  330  to avoid having an application removed from the backstack/PageStack  308  when the task switcher  302  gets launched. Additionally, it may be easier to handle z-ordering of the task switcher UI relative to other chrome components, e.g. Lock screen, ARDs (because the shell frame  330  handles top level z-order policy). The task switcher may be part of the system chrome, and sits relatively low in the z-order, whereby the previous foreground application receives an obscured message when the task switcher is launched above it. Also being inside the shell frame  330  may facilitate custom transitions between the task switcher and the applications. 
         [0036]    In one implementation generally represented in  FIG. 3 , the screenshot of the application&#39;s page is captured each time the user or the like navigates forward to a new session or a new child task; (note that any part of the screen image not part of the application (e.g., a pop-up “toast” message may be not included in the capture). More particularly, in one implementation, a call may be made from within frame_server&#39;s Page::SendOnHideRequest( )API. This API is executed by the application that is being navigated to but within telshell&#39;s process space (e.g., a PSL call from application into frame_server). 
         [0037]    As represented in the timing/sequence diagram of  FIG. 4 , the screen capture (BITMAP) may be obtained by calling a CaptureScreen API exposed by a compositor  334  (e.g., compositor.exe via coredll). Once obtained, the handle to the HBITMAP may be written into a message queue. A background thread (e.g., of the task switcher) running in telshell may consume this HBITMAP, StretchBlt it to an appropriate size (e.g., 259*439) and then convert it into an IUIXImage. 
         [0038]    The background thread may maintain a list of up to n (e.g. five) such IUIXImages and their corresponding Sessionlds. When a request comes in for an n+1 (e.g., sixth) image, the thread may query into Frame_Server  336  to obtain the list of active sessions and overwrite (release and reallocate) the image corresponding to the session that has fallen off the backstack/pagestack  308 . Note that in one implementation, because the allocations are greater than 16K, these may be virtual allocations whereby memory fragmentation is not an issue. 
         [0039]    Note that one implementation may show one page associated with a session. As a result, if the user navigates to a child task then one implementation may overwrite the screenshot of the parent task with the screenshot of the child task. 
         [0040]    Returning to  FIGS. 1 and 2 , the task switcher  102  may show the (localized) title of the application just below each screenshot ( FIG. 2 ). An API or the like may be provided for the task switcher  102  to resume the application&#39;s session (once the user has selected the UI), regardless of the activation policy of the application. The task switcher user interface shows a screenshot of the topmost page of each session that is on the backstack  108 . In order to know which sessions are currently on the backstack, the frame_server  336  ( FIG. 3 ) may be queried, e.g., via an API. 
         [0041]    In order to obtain the localized title of the application, one implementation may pass in a ProductId to a package manager, in which the ProductId may be obtained using the Friendly Name (or TaskURI if Friendly Name does not exist) associated with the task in a list obtained from DumpTasks. Note that while the DumpTasks gives the Sessionlds, one implementation may need to rely on the PAGESTACKCONTAINERDESC information obtained from the TestHook_GetPageStackContainerList API because there is a need to be able to distinguish the sessions that are on the backstack  108  and those which are not on the backstack  108  but have not yet been destructed. 
         [0042]    In memory size of the images, one implementation may capture (after resizing) 454 KB (439*259*4) of image data. One implementation may have n such images loaded at a given time (e.g., n may be five thereby consuming approximately 2.2 MB), however other implementations may have different numbers of n images depending on image size and available memory. Also note that the dimensions are subject to change, e.g., depending on whether or not UI artifacts for borders and lines result due to the resizing. 
         [0043]    One implementation refreshes the images while task switcher is active. This may be achieved by passing in raw bits (i.e. IUIXImage) to a splash (internal implementation) application  340 . This causes the splash application to allocate two buffers for the image, one comprising the original buffer and the second comprising a DX texture used by the renderer. 
         [0044]    As described above and represented in the timing sequence diagram of  FIG. 5 , to invoke the task switcher  102  the user may press and hold the back button. This may be detected by the key handler thread which lives in telshell. The key handler thread may then make a deferred invoke call into ShellFrame, i.e. pass off execution to ShellFrame&#39;s UI thread, which may initiate the task switcher&#39;s invocation process. The invocation process may include taking a screenshot of the currently visible application UI and bringing up the task switcher UI. In one implementation the CaptureScreen API exposed by the Compositor sometimes takes a little over 100 ms. Because the UI thread cannot be blocked for longer than 100 ms, the UI thread may not process the HBITMAP obtained, but instead may put this into the message queue for the background thread to process. The UI thread may show some kind of a temporary “loading” screen in the task switcher UI. When the background thread gets notified that the UI is coming up (e.g., through a named event or the message inserted into the queue by the UI thread being marked as “Alert”), it may query into frame_server to get a list of currently active sessions and populate the UI with the appropriate IUIXImages. Once the user selects which session UI he or she wants to navigate to (e.g., by clicking the appropriate screenshot), the task switcher may call into the frame_server  336  asking it to reactivate the task selected by the user. In one implementation, the API that may be used is PageManager::ReActivateSession( ) Because the frame_server  336  is queried when there are more than n images and also when the task switcher UI is coming up, one implementation may not need to explicitly be notified when the tasks/sessions are going away. 
         [0045]    In this manner, there is provided a simple navigation model for users and developers. In general, launching an application from Start takes the user to the application&#39;s default experience, while launching an application from the task switcher  102  (e.g., via the back hardware button) resumes the application to the state in which the user left it. 
         [0046]    With respect to multi-tasking, the model creates a number of background services that can perform tasks on an application&#39;s behalf. These services effectively enable applications to continue to work even when they are not in the foreground. Furthermore, a previously used application may be reasonably quickly to the foreground. Multi-tasking combined with fast-application-resume improves the user&#39;s ability to switch between multiple applications in order to complete a task. 
         [0047]    Although the back button provides convenient access to the last used application, it is not an efficient method to jump to a previous application that is farther than one back press away. Thus, the task switcher provides a more efficient way to help users resume and finish a previous task. 
         [0048]    There is thus provided easy and reliable access to the task switcher from anywhere. The task switcher shows previously opened tasks, and allows users to launch a previous task. Launching a task moves its session to the top of the backstack. 
         [0049]    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. 
       Exemplary Operating Environment 
       [0050]      FIG. 6  illustrates an example of a suitable mobile device  600  on which aspects of the subject matter described herein may be implemented. The mobile device  600  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  600  be interpreted as having any dependency or requirement relating to any one or combination of components illustrated in the exemplary mobile device  600 . 
         [0051]    With reference to  FIG. 6 , an exemplary device for implementing aspects of the subject matter described herein includes a mobile device  600 . In some embodiments, the mobile device  600  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  600  may be equipped with a camera for taking pictures, although this may not be required in other embodiments. In other embodiments, the mobile device  600  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  600  may comprise devices that are generally considered non-mobile such as personal computers, servers, or the like. 
         [0052]    Components of the mobile device  600  may include, but are not limited to, a processing unit  605 , system memory  610 , and a bus  615  that couples various system components including the system memory  610  to the processing unit  605 . The bus  615  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  615  allows data to be transmitted between various components of the mobile device  600 . 
         [0053]    The mobile device  600  may include a variety of computer-readable media. Computer-readable media can be any available media that can be accessed by the mobile device  600  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  600 . 
         [0054]    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. 
         [0055]    The system memory  610  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  620  is sometimes included in ROM although, in other embodiments, this is not required. Similarly, application programs  625  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  630  provides memory for state associated with the operating system  620  and the application programs  625 . For example, the operating system  620  and application programs  625  may store variables and data structures in the heap  630  during their operations. 
         [0056]    The mobile device  600  may also include other removable/non-removable, volatile/nonvolatile memory. By way of example,  FIG. 6  illustrates a flash card  635 , a hard disk drive  636 , and a memory stick  637 . The hard disk drive  636  may be miniaturized to fit in a memory slot, for example. The mobile device  600  may interface with these types of non-volatile removable memory via a removable memory interface  631 , or may be connected via a universal serial bus (USB), IEEE 6394, one or more of the wired port(s)  640 , or antenna(s)  665 . In these embodiments, the removable memory devices  635 - 637  may interface with the mobile device via the communications module(s)  632 . 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. 
         [0057]    In some embodiments, the hard disk drive  636  may be connected in such a way as to be more permanently attached to the mobile device  600 . For example, the hard disk drive  636  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  615 . In such embodiments, removing the hard drive may involve removing a cover of the mobile device  600  and removing screws or other fasteners that connect the hard drive  636  to support structures within the mobile device  600 . 
         [0058]    The removable memory devices  635 - 637  and their associated computer storage media, discussed above and illustrated in  FIG. 6 , provide storage of computer-readable instructions, program modules, data structures, and other data for the mobile device  600 . For example, the removable memory device or devices  635 - 637  may store images taken by the mobile device  600 , voice recordings, contact information, programs, data for the programs and so forth. 
         [0059]    A user may enter commands and information into the mobile device  600  through input devices such as a key pad  641  and the microphone  642 . In some embodiments, the display  643  may be touch-sensitive screen and may allow a user to enter commands and information thereon. The key pad  641  and display  643  may be connected to the processing unit  605  through a user input interface  650  that is coupled to the bus  615 , but may also be connected by other interface and bus structures, such as the communications module(s)  632  and wired port(s)  640 . Motion detection  652  can be used to determine gestures made with the device  600 . 
         [0060]    A user may communicate with other users via speaking into the microphone  642  and via text messages that are entered on the key pad  641  or a touch sensitive display  643 , for example. The audio unit  655  may provide electrical signals to drive the speaker  644  as well as receive and digitize audio signals received from the microphone  642 . 
         [0061]    The mobile device  600  may include a video unit  660  that provides signals to drive a camera  661 . The video unit  660  may also receive images obtained by the camera  661  and provide these images to the processing unit  605  and/or memory included on the mobile device  600 . The images obtained by the camera  661  may comprise video, one or more images that do not form a video, or some combination thereof. 
         [0062]    The communication module(s)  632  may provide signals to and receive signals from one or more antenna(s)  665 . One of the antenna(s)  665  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. 
         [0063]    Still further, an antenna provides location-based information, e.g., GPS signals to a GPS interface and mechanism  672 . In turn, the GPS mechanism  672  makes available the corresponding GPS data (e.g., time and coordinates) for processing. 
         [0064]    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. 
         [0065]    When operated in a networked environment, the mobile device  600  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  600 . 
         [0066]    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. 
         [0067]    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. 
         [0068]    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 
       [0069]    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.