Windows app: the default transport controls of a media element
This topic describes best practices for developing audio-aware applications, including things to consider for designing media elements, using playback manager, and managing call control.
Windows Phone Store apps: There are several media-related certification requirements that you should become familiar with when you develop any media app. For more info, see sections 6.4 and 6.5 of Additional requirements for specific app types for Windows Phone.
Windows app: custom transport controls
- Use a media elements to show video and audio to the user, either full-screen or alongside other visuals. You can show more than one media element on the screen together, and you can programmatically control which is one enabled if you don’t want them to be played back at the same time.
- Place media elements—and their transport controls—in a consistent location to help users interact with them confidently and seamlessly. The media element presents frames of video. By default, transport controls are not displayed, but they can be turned on and off with a simple Boolean property. Transport controls—including a full-screen button—appear when the media element is initially displayed, and when it’s tapped, and then they fade out.
- If you create your own custom transport controls, show them when the media element is initially displayed. They can then fade out to give a clear view of the media, but should return when the user taps the media element. Play/pause should be a toggle button with visuals that indicate the action that happens when tapped. The button should not show the current playing/paused state of the media. Try to use established media playback symbols when showing skip, stop, play, pause, and seek operations in audio and video.
- Design your button-press event handlers to respond with the least amount of delay possible. This will make sure that the user immediately gets verification of their button input. Long delays in response cause the user to press buttons multiple times, resulting in unexpected app behavior.
- Make sure that the media buttons are used in their standard ways so that the user has a familiar experience with the use of the media buttons.
- Don't use track and artist name strings that are longer than 127 characters or an error occurs. If you do not handle this error properly, it could cause the app to stop functioning.
For a tutorial on how to add media buttons and configure them for a Windows Store app, see How to use the system media transport controls.
- Use the msAudioCategory/ MediaElement.AudioCategory assignment only if you need audio to play in the background. Audio playback drains the battery, so unless there is a clear need for background audio (media playback designed for longer term listening, for example) do not declare an audio category. Alternatively, you can use the "Other" category. Otherwise, your application will be muted and then suspended.
- Use low-latency audio only when it is needed for specific applications that require it (including multi-track recorders and low-latency video capture). Low-latency audio is automatically invoked when you select the "Communications" audio category. For any other category, consider leaving low-latency settings at their default (which is OFF). Low-latency buffers use significantly more CPU and battery resources, and are typically reserved for foreground applications on which the user is focused.
If you want to mute the playback of background media, choose ForeGroundOnlyMedia als the msAudioCategory/ MediaElement.AudioCategory for this soundtrack. If you develop a game that plays its own audio soundtrack while the user is playing the game, then the soundtrack will be muted if the user was already playing an audio track in the background when the game started. If you believe that the game's audio soundtrack is essential for the function of the game, you can mute the currently playing background audio. "SoundEffects" that are mixed in with background media will still be heard in either case.
"ForeGroundOnlyMedia" can also be selected for video apps that should stop background media when the video starts, and should not run at all when they are in the background.
For a tutorial on how to categorize an AV stream, and how to use playback manager in a Windows Store app, see How to categorize an AV stream for audio streaming.
The following table presents the practices recommended for managing call control on the default Bluetooth communications device.
- Make call control functionality predictable for communications applications. This ensures that the user has an experience that is familiar and seamless. If your app uses call buttons in an unfamiliar way, make it very obvious to the user.
- Track call tokens carefully. Make sure you end the call correctly for the device, and also end the audio/video stream. Doing this helps you make sure that when the call is completed, you send an "endcall" notification back to the device, with the appropriate call token. That way the user has an indication from the device that the call has ended.
For a tutorial on how to manage Bluetooth calls in a Windows Store app, see How to manage calls on the default Bluetooth communications device.
- For developers
- Bluetooth call control sample
- SystemMediaTransportControls sample
- Configure keys for media sample
- Playback manager sample
- Media for Windows Phone