Abstract: In accordance with one or more aspects, a request to run an application is received. The application has an associated tune manifest that identifies one or more resources that the application may use. The tune manifest is compared to a device resource record, and a check is made, based at least in part on the comparing, whether the one or more resources identified in the tune manifest can be satisfied by the device. If the one or more resources identified in the tune manifest can be satisfied by the device, then the application is run; otherwise, a notification of a conflict between the application and the device is presented. Additionally, when the application exits, a device tune state that identifies a content source to which the device was tuned prior to running the application can be retrieved and the device restored to this device tune state.

Abstract: In accordance with one or more aspects, a request to run an application is received. The application has an associated tune manifest that identifies one or more resources that the application may use. The tune manifest is compared to a device resource record, and a check is made, based at least in part on the comparing, whether the one or more resources identified in the tune manifest can be satisfied by the device. If the one or more resources identified in the tune manifest can be satisfied by the device, then the application is run; otherwise, a notification of a conflict between the application and the device is presented. Additionally, when the application exits, a device tune state that identifies a content source to which the device was tuned prior to running the application can be retrieved and the device restored to this device tune state.

Abstract: In accordance with one or more aspects, a request to run an application is received. The application has an associated tune manifest that identifies one or more resources that the application may use. The tune manifest is compared to a device resource record, and a check is made, based at least in part on the comparing, whether the one or more resources identified in the tune manifest can be satisfied by the device. If the one or more resources identified in the tune manifest can be satisfied by the device, then the application is run; otherwise, a notification of a conflict between the application and the device is presented. Additionally, when the application exits, a device tune state that identifies a content source to which the device was tuned prior to running the application can be retrieved and the device restored to this device tune state.

Abstract: In accordance with one or more aspects, a request to run an application is received. The application has an associated tune manifest that identifies one or more resources that the application may use. The tune manifest is compared to a device resource record, and a check is made, based at least in part on the comparing, whether the one or more resources identified in the tune manifest can be satisfied by the device. If the one or more resources identified in the tune manifest can be satisfied by the device, then the application is run; otherwise, a notification of a conflict between the application and the device is presented. Additionally, when the application exits, a device tune state that identifies a content source to which the device was tuned prior to running the application can be retrieved and the device restored to this device tune state.

Abstract: In accordance with one or more aspects, a request to run an application is received. The application has an associated tune manifest that identifies one or more resources that the application may use. The tune manifest is compared to a device resource record, and a check is made, based at least in part on the comparing, whether the one or more resources identified in the tune manifest can be satisfied by the device. If the one or more resources identified in the tune manifest can be satisfied by the device, then the application is run; otherwise, a notification of a conflict between the application and the device is presented. Additionally, when the application exits, a device tune state that identifies a content source to which the device was tuned prior to running the application can be retrieved and the device restored to this device tune state.

Abstract: In accordance with one or more aspects, a request to run an application is received. The application has an associated tune manifest that identifies one or more resources that the application may use. The tune manifest is compared to a device resource record, and a check is made, based at least in part on the comparing, whether the one or more resources identified in the tune manifest can be satisfied by the device. If the one or more resources identified in the tune manifest can be satisfied by the device, then the application is run; otherwise, a notification of a conflict between the application and the device is presented. Additionally, when the application exits, a device tune state that identifies a content source to which the device was tuned prior to running the application can be retrieved and the device restored to this device tune state.

Abstract: This document describes tools capable of updating data-consuming entities. These tools allow a developer of an application to use data binding to update data-consuming entities without the need to write custom code.

Abstract: In accordance with one or more aspects, a request to run an application is received. The application has an associated tune manifest that identifies one or more resources that the application may use. The tune manifest is compared to a device resource record, and a check is made, based at least in part on the comparing, whether the one or more resources identified in the tune manifest can be satisfied by the device. If the one or more resources identified in the tune manifest can be satisfied by the device, then the application is run; otherwise, a notification of a conflict between the application and the device is presented. Additionally, when the application exits, a device tune state that identifies a content source to which the device was tuned prior to running the application can be retrieved and the device restored to this device tune state.

Abstract: This document describes tools capable of communicating events or event data between application components. These tools allow an application component to communicate an event and event data to another application component even if the two application components are in separate layers or do not exist at the same time.

Abstract: In accordance with one or more aspects, a request to run an application is received. The application has an associated tune manifest that identifies one or more resources that the application may use. The tune manifest is compared to a device resource record, and a check is made, based at least in part on the comparing, whether the one or more resources identified in the tune manifest can be satisfied by the device. If the one or more resources identified in the tune manifest can be satisfied by the device, then the application is run; otherwise, a notification of a conflict between the application and the device is presented. Additionally, when the application exits, a device tune state that identifies a content source to which the device was tuned prior to running the application can be retrieved and the device restored to this device tune state.

Abstract: Asset resolvable bookmarks are described. In embodiments, a bookmark is received at a media content source from a client device. The bookmark corresponds to a media asset and includes an identifier of the media asset. Additional data can be added to the bookmark to generate an asset resolvable bookmark, where the additional data includes at least enough data from which a receiving client device can determine a media content source from which the media asset can be accessed for playback at the receiving client device.

Abstract: In accordance with one or more aspects of the referencing data in triggers from applications, a device can store multiple triggers for media content. For each of these triggers, a check is made as to whether a presentation of media content satisfies a criteria portion of the trigger. When the presentation satisfies the criteria portion, one or more actions in a payload portion of the trigger are performed. Additionally, data in the triggers can be referenced by applications executing on the device. These applications include applications that are launched as part of the one or more actions when the criteria portion of a trigger is satisfied, as well as other applications executing on the device.

Abstract: Controllable device selection based on controller location is described. In embodiments, a companion utility is executed by a portable device to interface the portable device with a selected one of multiple controllable devices via a wireless network. A location of the portable device can be determined based on a positioning unit that is integrated with the portable device. A controllable device can then be selected that is proximate the location of the portable device for input control of the controllable device via the wireless network.

Abstract: Video content in an original markup language is processed and distributed for presentation such that the presentation preserves static and dynamic aspects of the video content in the original markup language. The video content in the original markup language may be processed into a binary format using a client-specific routine that is specific to a predetermined client. The distributed video content may be presented in a way that preserves the static and dynamic aspects of the video content in the original markup language.

Abstract: Editable bookmarks shared via a social network are described. In embodiments, a bookmark is received from a client device at a media content service. The bookmark corresponds to a media asset and includes an identifier of the media asset. Metadata associated with the media asset is added to the bookmark to generate an editable bookmark. A bookmark invitation is also received from the client device, and the bookmark invitation is directed to social network contacts of a user of the client device. The editable bookmark can then be communicated to receiving client devices of the respective social network contacts identified by the bookmark invitation, and a receiving client device can initiate playback of the media asset that corresponds to the editable bookmark. Further, the editable bookmark can be updated when additional data associated with the media asset is received from a social network contact via a respective client device.

Abstract: This document describes tools that enable a computing device to retrieve large data in smaller blocks. The tools also allow the computing device to receive and display data that does not include display formatting information through the use of templates.

Abstract: A rendering engine that supports directional focus navigation, in response to a directional input, shifts the focus to an appropriate focusable element. The rendering engine determines one or more focusable elements that are candidates to receive the focus based on the received directional input and based on the relative display locations of the focusable elements. The rendering engine selects the most appropriate candidate focusable element based on each candidate element's display location in relation to the display location of the element that currently has focus.

Abstract: Channel navigation techniques are described. In one or more implementations, a channel up or channel down command is received during output of content available via a first television channel. Responsive to this, navigation is caused to a second television channel in a list to output content available via the second television channel, the list formed to include channels that have content that is currently available and that is similar to the content that is output via the first television channel.

Abstract: A rendering engine that supports directional focus navigation, in response to a directional input, shifts the focus to an appropriate focusable element. The rendering engine determines one or more focusable elements that are candidates to receive the focus based on the received directional input and based on the relative display locations of the focusable elements. The rendering engine selects the most appropriate candidate focusable element based on each candidate element's display location in relation to the display location of the element that currently has focus.

Abstract: This document describes tools capable of updating media-location data for media-playing entities. These tools allow a developer of an application to use data binding to update media-location data for the media-playing entities without the need to write custom code.