Download at in Objective-C

Making ECC200 in Objective-C Download at

expensive buffers. However, if you call deallocate() on each when it goes away, the overhead for the 11 nonplaying channels will be minimal.

As it runs, the Player will deliver information about its current status to all registered PlayerListener objects. You will almost always want to register at least one PlayerListener with each Player. At an absolute minimum, this will provide you with useful debugging information about what is happening. In most cases, you will want to take some action based on certain important events. For example, you may show a Loading screen when a stream is buffering, or exit the current screen once a song finishes playing. Figure 3-3 shows the potential sequence of one media play execution.

Many events are defined as part of the MMAPI spec, and RIM can send custom events, as well. Whenever your PlayerListener is called, it will be passed a String with the event name, and an Object containing more information about the event. The most common events are shown in Table 3-1.

Player enters buffering mode. Player exits buffering mode. Player closed; end of events. An exclusive device is now available to this Player in the REALIZED state.

deviceUnavailable DEVICE_ This Player has lost access UNAVAILABLE to an exclusive device and placed back in the REALIZED state. The next event must be DEVICE_AVAILABLE or ERROR. durationUpdated DURATION_ UPDATED

The duration for this Player Long has changed. This generally occurs when the duration cannot be known at start but becomes available later. The Player has reached the Long end of the media. The Player encountered an String error. A playing video s size has changed; for example, the screen may have changed orientation. Player has begun to play.

Media time for the end of media. Detailed error message (see below).

Table 3-1. PlayerListener Events (continued)

Player has reached the time Long specified by a previous call to StopTimeControl.setStopTi me and returned to the PREFETCHED state.

Volume has changed; for VolumeCon- Object with new example, user has pressed a trol volume level volume key. Media has advanced. Called Long about once per second. Current media time in microseconds. N/A

Note: The MMAPI does not specify what units media time correspond to. On BlackBerry devices, each unit of media time is one microsecond. Multiply by 1,000 to convert to milliseconds (useful when comparing to system time), and by 1,000,000 to convert to seconds (useful when showing elapsed play time). No app will need to respond to all the above events, but every app will likely care about at least a few of them. You should just look for the ones you care about and ignore the rest. Be aware that certain media operations might generate a slew of events for example, you might receive a "com.rim.timeUpdate" every second while a stream is playing. Because of this, you may want to avoid actions like logging every event that is passed, because doing so would slow down the operation of your app. Pay particular attention to errors. There is a fundamental difference between transient errors and permanent errors. If media will not play because of a network hiccup or temporary loss of the output device, you may want to retry the operation to save your user the hassle. On the other hand, if the media itself is corrupt or incompatible, you cannot do anything about it. To facilitate more deterministic handling of errors, RIM has decided to use integer values as the ERROR extended message. Table 3-2 shows the currently defined codes and their meaning.

Table 3-2. RIM Media Error Codes (continued)

3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22