Vue d’ensemble : lecture audio en arrière-plan (applications Windows Phone Store) (HTML)

[ Cet article est destiné aux développeurs Windows 8.x et Windows Phone 8.x qui créent des applications Windows Runtime. Si vous développez une application pour Windows 10, voir la Documentation ]

Vous pouvez écrire des applications pour Windows Phone 8.1 qui lisent du contenu audio en arrière-plan. Cela signifie que votre application peut continuer à lire du contenu audio même après que l’utilisateur l’a quittée en appuyant sur le bouton Précédent ou Démarrer de son appareil. Cet article présente les composants d’une application de lecture audio en arrière-plan et leurs interactions.

Scénarios de lecture audio en arrière-plan :

• Playslist de longue durée L’utilisateur affiche brièvement une application au premier plan pour sélectionner et lancer une playlist, puis veut que la lecture de la playlist continue en arrière-plan.
• Utilisation du Sélecteur de tâches L’utilisateur affiche brièvement une application au premier plan pour démarrer la lecture d’un contenu audio, puis passe dans une autre application ouverte à l’aide du Sélecteur de tâches. Il veut que la lecture du contenu audio continue en arrière-plan.

Astuce  Vous pouvez télécharger le code de l’exemple de lecture audio en arrière-plan pour Windows Phone 8.1, qui implémente le code dont il est question ici.

Architecture de la lecture audio en arrière-plan

Une application de lecteur de contenu audio en arrière-plan utilise des agents d’arrière-plan. Toutefois, la lecture audio en arrière-plan dans Windows Phone 8.1 est différente de la lecture audio en arrière-plan dans Windows 8. Le modèle est également différent par rapport aux agents audio d’arrière-plan utilisés dans les versions antérieures de Windows Phone.

Important  

Vous pouvez utiliser JavaScript pour écrire des applications de lecture audio en arrière-plan. Toutefois, Windows Phone 8.1 n’autorise pas l’exécution de JavaScript dans un processus en arrière-plan. En d’autres termes, l’application au premier plan et l’interface utilisateur peuvent être écrites en JavaScript, mais votre tâche en arrière-plan doit être écrite en C# ou C++. L’exemple de lecture audio en arrière-plan pour Windows Phone 8.1 fournit un exemple d’application JavaScript qui prend en charge la lecture audio en arrière-plan à l’aide d’un agent d’arrière-plan C#.

L’espace de noms Windows.Media.Playback introduit des API audio génériques et peut être utilisé pour lire de la musique au premier plan même si sa mission première est de lire le contenu audio en arrière-plan. Quand vous utilisez l’une de ces API, il n’y a qu’un seul l’objet MediaPlayer général, par le biais duquel toutes les lectures s’effectuent. Votre application de lecture audio en arrière-plan envoie des commandes au lecteur multimédia pour définir la piste actuelle, démarrer la lecture, mettre en pause, avancer, reculer, etc. Pour cela, vous devez appeler les méthodes de la classe MediaPlayer. L’objet d’instance du lecteur multimédia, accessible via la propriétéBackgroundMediaPlayer.Current, communique avec le lecteur multimédia général pour gérer la lecture du contenu audio.

Vous ne pouvez pas créer de nouvelles instances de la classe MediaPlayer.

Utilisez la classe SystemMediaTransportControls pour déclencher des événements qui sont utilisés par le contrôle de volume universel (UVC). Le contrôle de volume universel est l’interface utilisateur qui s’affiche quand l’utilisateur de l’application appuie sur le contrôle du volume sur son appareil. Vous utilisez la classe SystemMediaTransportControls pour manipuler le lecteur multimédia. En plus de démarrer la lecture audio à partir de votre application, vous pouvez contrôler la lecture audio. Par exemple, utilisez la classe SystemMediaTransportControls pour envoyer des événements à l’interface IBackgroundTask dans votre application ; vous pouvez aussi implémenter la logique de playslist. Nous reviendrons sur l’interface IBackgroundTaskplus loin dans cette rubrique.

Le diagramme suivant est une vue simplifiée de la conception du système. Une application proposant la lecture en arrière-plan comprend deux processus. Le premier processus est l’application principale, qui contient l’interface utilisateur, exécutée au premier plan. Le second processus est la tâche de lecture en arrière-plan, qui contient tous les éléments nécessaires à la lecture audio et, éventuellement, des éléments de logique de l’application. Le processus au premier plan est suspendu ou arrêté par le système d’exploitation en fonction des ressources dont il a besoin. Le processus en arrière-plan continue de s’exécuter.

Alors que la lecture audio s’effectue dans le processus en arrière-plan, le processus au premier plan a accès à toutes les informations via des objets proxy. Le processus au premier plan peut gérer les propriétés de l’instance de la classe MediaPlayer dans le processus en arrière-plan. L’application au premier plan peut recevoir des notifications pour des événements concernant le contenu multimédia, comme MediaOpened, MediaEnded et MediaFailed. Une fois le processus au premier plan terminé ou si l’application est suspendue, la lecture du contenu multimédia continue.

Contrôles de transport de média système

La classe SystemMediaTransportControls est un nouveau jeu d’API introduit dans Windows 8.1. Windows Phone 8.1 implémente aussi cette classe. Toutefois, dans la mesure où Windows Phone ne dispose que d’un contrôle de volume général, un seul processus à la fois peut interagir avec elle. Dans le contexte des API MediaPlayer, il est extrêmement important de définir l’instance et tous les gestionnaires dans le processus en arrière-plan. Cela garantit que la connexion est liée au bon processus en cas d’arrêt de l’application au premier plan.

Envoi de messages entre les tâches

Vous voudrez parfois que les deux processus d’une application de lecture audio en arrière-plan communiquent entre eux. Vous pouvez, par exemple, vouloir que la tâche en arrière-plan informe la tâche au premier plan que la lecture d’une nouvelle piste commence, puis qu’elle envoie le titre de la nouvelle chanson à la tâche de premier plan afin qu’elle l’affiche à l’écran. Un mécanisme de communication simple déclenche des événements à la fois dans le processus au premier plan et dans le processus en arrière-plan. Les méthodes SendMessageToForeground et SendMessageToBackground invoquent chacune des événements dans la tâche correspondante. Des données peuvent être passées sous forme d’argument au gestionnaire d’événements dans la tâche destinataire. Passez des données à l’aide de la nouvelle classe nommée ValueSet. Cette classe est un dictionnaire qui contient une chaîne comme clé et d’autres types de valeur comme valeurs. Vous pouvez passer des types de valeurs simples comme int, string, bool, etc.

Durée de vie d’une tâche en arrière-plan

La durée de vie d’une tâche en arrière-plan est étroitement liée à la capacité de l’application à lire de la musique. Par exemple, lorsqu’un utilisateur met en pause la lecture audio, le système peut terminer ou annuler votre application en fonction des circonstances.

Votre tâche en arrière-plan démarre lorsque votre application accède pour la première fois à BackgroundMediaPlayer.Current dans le code de l’application au premier plan ou lorsque vous enregistrez un gestionnaire pour l’événement MessageReceivedFromBackground, selon la première éventualité. Pour vous assurer que les canaux de communication sont établis lorsque la méthode IBackgroundTask.Run est appelée, vous devez enregistrer l’événement MessageReceivedFromBackground avant d'accéder pour la première fois à la propriété BackgroundMediaPlayer.Current. Votre application doit attendre que votre tâche en arrière-plan s’exécute avant d’essayer de lancer une lecture audio. Vous pourrez ainsi vous abonner à des événements multimédias.

Pour garder active une tâche en arrière-plan, votre application devra obtenir une classe BackgroundTaskDeferral dans la méthode Run et appeler BackgroundTaskDeferral.Complete lorsque l’instance de la tâche reçoit les événements Canceled ou Completed. N’attendez pas dans la méthode Run car cela utilise des ressources et risque de mettre fin à la tâche en arrière-plan de votre application.

Votre tâche en arrière-plan obtient l’événement Completed lorsque la méthode Run est terminée et qu’aucun report n’est demandé. Dans certains cas, lorsque votre application obtient l’événement Canceled, il peut également être suivi de l’événement Completed.

Une tâche en arrière-plan peut être annulée dans les situations suivantes :

• Une nouvelle application proposant des fonctions de lecture audio démarre.
• Une tâche en arrière-plan a été lancée mais aucune musique n’est encore en cours de lecture ; l’application au premier plan est alors suspendue.
• Un moment après le lancement de la tâche en arrière-plan, la lecture est mise en pause et l’application au premier plan est suspendue. La lecture peut être mise en pause par l’utilisateur ou par les interruptions d’autres médias, comme les appels téléphoniques entrants ou les appels VoIP. Si l’appel téléphonique ou l’appel VoIP se termine dans les cinq minutes, votre application reçoit la notification Run avec le bouton SystemMediaTransportControlsButton.Play indiqué dans la classeSystemMediaTransportControlsButtonPressedEventArgs. Dans le cas contraire, l’utilisateur devra commencer la lecture explicitement à l’aide du contrôle de volume universel. L’état du contrôle de volume universel n’est pas perdu. Toutefois, quand l’utilisateur appuie sur le bouton Lecture, la tâche en arrière-plan est relancée. Vous pouvez alors obtenir un appel de méthode Run et une notification SystemMediaTransportControlsButton.Play.

Une tâche en arrière-plan peut être terminée sans avertissement dans les circonstances suivantes :

• Un appel VoIP entre et il n’y a pas assez de mémoire.
• Une stratégie de ressource est enfreinte.
• L’annulation ou la réalisation de la tâche ne s’est pas terminée comme prévu.

Meilleures pratiques en matière de lecture audio en arrière-plan

Le pipeline multimédia est asynchrone par nature, ce qui signifie que le déclenchement d’événements garantit leur occurrence mais pas leur ordre. Par exemple, lorsque votre application récupère un fichier audio à partir d’une source distante, l’application reçoit plusieurs événements de changement d’état, comme Starting, Paused, Closed, etc. Ces gestionnaires ne sont pas nécessairement appelés chaque fois dans le même ordre. Vous ne devez pas trop vous fier aux valeurs CurrentState de votre gestionnaire CurrentStateChanged.

MediaOpened est un événement très important et joue plusieurs rôles. Si vous avez défini AutoPlay sur false et que vous définissez une source pour MediaPlayer, vous continuerez de recevoir l’événement MediaOpened. Cela indique que le pipeline multimédia est lancé et que votre contenu multimédia est prêt à être lu. Lorsque vous définissez une source, la lecture multimédia démarre automatiquement. Vous n’avez pas besoin d’appeler Play après avoir défini la source. Une autre technique très utile consiste à lire explicitement le contenu multimédia dès qu’il est prêt. Cela peut être fait en définissant AutoPlay sur false et en appelant spécifiquement Play dans votre gestionnaire MediaOpened.

Vous pouvez définir la source multimédia sur différents types de contenus en appelant SetUriSource, SetFileSource, SetMediaSourceou SetStreamSource. MediaPlayer peut également lire du contenu protégé. Si vous ne définissez pas une source URI, le système dépend d’objets application ou de code application exécutés en mémoire. De plus, le processus en arrière-plan n’aura pas connaissance de la mémoire de processus dans la tâche au premier plan. Veillez donc à définir la source de tous les objets dans le processus en arrière-plan uniquement. Le système lèvera une exception InvalidCastException si votre application essaie de définir une source autre qu’un URI dans le processus au premier plan.

BackgroundMediaPlayer.Shutdown ferme le pipeline multimédia et libère l’objet MediaPlayer de la mémoire. Si vous essayez d’accéder de nouveau à une référence à BackgroundMediaPlayer.Current après avoir appeléShutdown, vous générerez une erreur. Shutdown permet à une application de nettoyer le pipeline multimédia quand sa tâche est annulée.

Lorsque votre application est suspendue, pensez à vous désabonner des événements MediaPlayer sans quoi vous risquez d’avoir une activité non souhaitée, ce qui peut potentiellement conduire à l’arrêt du processus au premier plan. Cependant, cela ne signifie pas que le processus au premier plan disparaîtra du sélecteur de tâche et l’utilisateur continuera de pouvoir revenir à l’application. Quand votre application reprend, si vous détenez toujours une référence à un MediaPlayer suspendu, une erreur est générée si la tâche audio en arrière-plan a été annulée et que le pipeline multimédia a été fermé.

Rubriques associées

Exemple de lecture audio en arrière-plan pour Windows Phone 8.1

Comment déboguer une tâche en arrière-plan