MICROSOFT_PRESS_EBOOK_PROGRAMMING_WINDOWS_8_APPS_WITH_HTML_CSS_AND_JAVASCRIPT_PDF

function soundLevelChanged() {
//Catch SoundLevel notifications and determine SoundLevel state.
//If it's muted, we'll pause the player.
var soundLevel = Windows.Media.MediaControl.soundLevel;
//No actions are shown here, but the options are spelled out to show the enumeration
switch (soundLevel) {
case Windows.Media.SoundLevel.muted:
break;
case Windows.Media.SoundLevel.low:
break;
case Windows.Media.SoundLevel.full:
break;
}
}
appMuted();
function appMuted() {
if (audtag) {
if (!audtag.paused) {
audtag.pause();
}
}
}
Technically speaking, a handler for soundlevelchanged is not required here, but the other four are.
Such a minimum implementation is part of the AudioPlayback example with this chapter, where the
code also uses the MediaControl.isPlaying flag to set the play/pause button in the media control UI
(see next section).
A few additional notes about background audio:
• The reason for distinct playpressed, pausepressed, and playpausepressed events is to
support a variety of hardware where some devices have separate play and pause buttons
and others have a single button for both.
• If the audio is paused, a background audio app will be suspended like any other, but if
the user presses a play button, the app will be resumed and audio will then continue
playback.
• The use of background audio is carefully evaluated with apps submitted to the Windows
Store. If you attempt to play an inaudible track as a means to avoid being suspended,
the app will fail Store certification.
• A background audio app should be careful about how it uses the network for streaming
media to support the low power state called connected standby. For details, refer to
Writing a power savvy background media app.
Now let’s see the other important reason why you must implement the media control events: the UI
that Windows displays in response to hardware buttons.
427