Portable media playback device including user interface event passthrough to non-media-playback processing

This application is a continuation of and claims priority under 35 U.S.C. §120 to U.S. patent application Ser. No. 11/530,773 filed Sep. 11, 2006 and is hereby incorporated by reference.

Portable electronic devices for media playback are becoming ever more popular. For example, a very popular portable media player is the line of iPod® media players from Apple Inc. of Cupertino, Calif. In addition to media playback, the iPod® media players also provide non-media-playback capabilities, including game playing capabilities.

The inventors have realized that it is desirable to create an integrated media playback and non-media-playback experience.

Methods of operating a portable electronics device can include integrated operation of media playback processing and non-media-playback processing (such as, for example, game processing). The method can include receiving an event corresponding to operation of a user interface item by a user of the portable electronics device. The received event can be provided to the non-media-playback processing. The non-media-playback processing can determine whether to cause an action corresponding to the provided received event with respect to the non-media-playback processing.

For an event determined by the non-media-playback processing to not cause an action corresponding to the provided received event with respect to the non-media-playback processing, the provided received event can be provided to the media playback processing. Typically, the operating performed by the media playback processing based on the event can be the processing that would otherwise be performed by the media playback processing if the non-media-playback processing was not even occurring.

FIG. 1 is an architecture diagram broadly illustrating an example of processing to handle UI events to a portable electronics device such that the UI events may be operated upon by media playback processing and non-media-playback processing, as appropriate.

FIG. 2 is a flowchart illustrating processing within a non-media-playback (e.g., game) application, and

FIG. 3 is a flowchart illustrating processing of a media player application.

Methods are described to handle UI events to a portable electronics device such that the UI events may be operated upon by media playback processing and non-media-playback processing, as appropriate. The media playback processing and the non-media-playback processing may occur, at least when considered at a macroscopic level, in parallel. For example, the media playback processing may include playback of songs, such as is a commonly-known function of an iPod® media player. In general, the media playback nominally occurs in a predictive manner and, while user interaction may affect the media playback audio (e.g., by a user activating a “fast forward” or other user interface item), the media playback nominally occurs in a predictive manner.

In one example, an event corresponding to operation of a user interface item by a user of the portable electronics device is received. The received event is provided to the non-media-playback processing. The non-media-playback processing includes processing to determine whether to cause an action corresponding to the provided received event, with respect to the non-media-playback processing. For an event determined by the non-media-playback processing to not cause an action corresponding to the received event with respect to the non-media-playback processing, the received event is provided to the media playback processing.

A game application is an example of non-media-playback processing. That is, the game application substantially operates responsive to game-playing actions of a user of the portable media player. In this respect, the game video is not nominally generated in a predictive manner, as is the case with media playback processing.

FIG. 1 is an architecture diagram broadly illustrating an example of this processing. As shown in FIG. 1 , a user interface event 110 is received by the media player application 102 executing on a portable media player device. For example, the user interface event 110 is a result of a user interacting with a user interface (for example, a physical or virtual knob, switch etc.) of the portable media player. At step 106 of processing with the media player application 102 , the media player application 102 passes through the UI event 110 to the non-media-playback application 104 (in this example, a game playing application).

At step 112 , within the game playing application 104 , the game playing application 104 determines whether it is configured to act on the UI event 110 that was passed to the game playing application 104 through the media player application 102 . If the determination at step 112 is yes, then the UI event is acted upon at step 114 , within the game playing application 104 .

Otherwise, at step 116 within the game playing application 104 , the UI event is passed back to the media player application 102 . Then, at step 108 within the media player application 102 , the UI event is acted upon by the media player application.

FIGS. 2 and 3 illustrate a particular implementation of the UI event processing, wherein an input queue and an output queue are employed for handling the UI events. FIG. 2 illustrates processing within the non-media-playback (e.g., game) application. At step 202 , a UI event is read from an input queue. At step 204 , the game application determines if it is configured to act on the UI event. If yes, the game application acts on the UI event at step 206 . If no, the game application operates to write the UI event to an output queue.

Meanwhile, the media player application ( FIG. 3 ) operates on a frame-by-frame basis. Within one frame of processing, step 302 (and, in some instances, discussed below), step 304 and step 306 are performed. At step 302 , it is determined if there is a UI event in the output queue. (Remember, a UI event ends up in the output queue as a result of step 208 of the game application processing, where the game application is not configured to act on the UI event.) If, at step 302 , there is not a UI event in the output queue, then processing returns to step 302 , for a subsequent frame.

Otherwise, if at step 302 there is a UI event in the output queue, then an operation is performed, at step 304 , corresponding to the UI event. At step 306 , the just-processed UI event is removed from the output queue.

As an example, the UI event may correspond to the “next button up.” For example, if a game or other non-media-playback processing is not configured to handle this event, then the media playback processing will perform a “standard” next command. This may include traversing to the next chapter, if playing a chaptered track such as a podcast or audiobook, or playing the next playable track in the “now playing” list. In other words, the typically, the operating performed by the media playback processing based on the event is the processing that would otherwise be performed by the media playback processing if the non-media-playback processing was not even occurring.

Thus, the non-media-playback processing can determine which events to handle, and other events can be passed back to the playback processing.

The following applications are incorporated herein by reference in their entirety: U.S. patent application Ser. No. 11/530,807, filed Sep. 11, 2006, entitled “TECHNIQUES FOR INTERACTIVE INPUT TO PORTABLE ELECTRONIC DEVICES,”; and U.S. patent application Ser. No. 11/530,846, filed Sep. 11, 2006, entitled “ALLOWING MEDIA AND GAMING ENVIRONMENTS TO EFFECTIVELY INTERACT AND/OR AFFECT EACH OTHER,”.