La procédure suivante vous permet de convertir votre application émettrice Android du SDK Cast v2 vers l'émetteur CAF, qui est basé sur le singleton CastContext.
Le SDK de l'expéditeur Cast CAF utilise CastContext pour gérer GoogleAPIClient en votre nom. CastContext gère les cycles de vie, les erreurs et les rappels à votre place, ce qui simplifie considérablement le développement d'une application Cast.
Introduction
- L'expéditeur CAF est toujours distribué dans le cadre des services Google Play à l'aide du gestionnaire du SDK Android.
- De nouveaux packages ont été ajoutés pour assurer la conformité avec la checklist de conception Google Cast (
com.google.android.gms.cast.framework.*). - L'expéditeur CAF fournit des widgets conformes aux exigences de l'expérience utilisateur Cast. La v2 ne fournissait aucun composant d'interface utilisateur et vous obligeait à implémenter ces widgets.
- L'utilisation de GoogleApiClient n'est plus requise pour utiliser l'API Cast.
- Les sous-titres dans l'émetteur CAF sont semblables à ceux de la v2.
Dépendances
La V2 et le CAF ont les mêmes dépendances vis-à-vis des bibliothèques d'assistance et des services Google Play (9.2.0 ou version ultérieure), comme décrit dans le guide des fonctionnalités de la bibliothèque d'assistance.
La version minimale du SDK Android compatible avec CAF est la version 9 (Gingerbread).
Initialisation
Dans CAF, une étape d'initialisation explicite est requise pour le framework Cast. Pour ce faire, vous devez initialiser le singleton CastContext, en utilisant un OptionsProvider approprié pour spécifier l'ID d'application Web Receiver et toutes les autres options globales.
public class CastOptionsProvider implements OptionsProvider {
@Override
public CastOptions getCastOptions(Context context) {
return new CastOptions.Builder()
.setReceiverApplicationId(context.getString(R.string.app_id))
.build();
}
@Override
public List<SessionProvider> getAdditionalSessionProviders(Context context) {
return null;
}
}
Déclarez OptionsProvider dans la balise "application" du fichier AndroidManifest.xml de l'application :
<application>
...
<meta-data
android:name=
"com.google.android.gms.cast.framework.OPTIONS_PROVIDER_CLASS_NAME"
android:value="com.google.sample.cast.refplayer.CastOptionsProvider" />
</application>
Initialisez de manière différée CastContext dans la méthode onCreate de chaque activité :
private CastContext mCastContext;
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.video_browser);
setupActionBar();
mCastContext = CastContext.getSharedInstance(this);
}
Ces étapes n'étaient pas nécessaires dans la v2.
Détection d'appareils
Dans CAF, le processus de découverte est démarré et arrêté automatiquement par le framework lorsque l'application passe respectivement au premier plan et en arrière-plan. MediaRouteSelector et MediaRouter.Callback ne doivent pas être utilisés.
Icône Cast et boîte de dialogue Cast
Comme dans la v2, ces composants sont fournis par la bibliothèque Support MediaRouter.
L'icône Cast est toujours implémentée par MediaRouteButton et peut être ajoutée à votre activité (à l'aide d'un ActionBar ou d'un Toolbar) en tant qu'élément de menu.
<item
android:id="@+id/media_route_menu_item"
android:title="@string/media_route_menu_title"
app:actionProviderClass="android.support.v7.app.MediaRouteActionProvider"
app:showAsAction="always"/>
Remplacez la méthode onCreateOptionMenu() de chaque activité en utilisant CastButtonFactory pour associer MediaRouteButton au framework Cast :
private MenuItem mediaRouteMenuItem;
public boolean onCreateOptionsMenu(Menu menu) {
super.onCreateOptionsMenu(menu);
getMenuInflater().inflate(R.menu.browse, menu);
mediaRouteMenuItem =
CastButtonFactory.setUpMediaRouteButton(getApplicationContext(),
menu,
R.id.media_route_menu_item);
return true;
}
Lorsqu'un utilisateur appuie sur le bouton, la boîte de dialogue Cast s'affiche automatiquement.
Contrôle des appareils
Dans CAF, le contrôle des appareils est en grande partie géré par le framework. L'application émettrice n'a pas besoin de gérer (et ne doit pas essayer de gérer) la connexion à l'appareil et le lancement de l'application réceptrice Web à l'aide de GoogleApiClient. L'interaction entre l'expéditeur et le récepteur Web est désormais représentée sous la forme d'une "session". La classe SessionManager gère le cycle de vie de la session, et démarre et arrête automatiquement les sessions en réponse aux gestes de l'utilisateur : une session démarre lorsque l'utilisateur sélectionne un appareil Cast dans la boîte de dialogue Cast et se termine lorsque l'utilisateur appuie sur le bouton "Arrêter de caster" dans la boîte de dialogue Cast ou lorsque l'application émettrice elle-même s'arrête. L'application émettrice peut être informée des événements de cycle de vie de la session en enregistrant un SessionManagerListener auprès de SessionManager. Les rappels SessionManagerListener définissent des méthodes de rappel pour tous les événements de cycle de vie de la session.
La classe CastSession représente une session avec un appareil Cast. La classe comporte des méthodes permettant de contrôler le volume et l'état de coupure du son de l'appareil, ce qui était auparavant effectué dans la version 2 à l'aide de méthodes sur Cast.CastApi.
Dans la v2, les rappels Cast.Listener fournissaient des notifications de modification de l'état de l'appareil, y compris le volume, l'état de coupure du son, l'état de veille, etc.
Dans CAF, les notifications de changement d'état du volume/du son sont toujours envoyées via des méthodes de rappel dans Cast.Listener. Ces écouteurs sont enregistrés avec CastSession.
Toutes les notifications d'état de l'appareil restantes sont envoyées via des rappels CastStateListener. Ces écouteurs sont enregistrés auprès de CastSession. Veillez à toujours annuler l'enregistrement des écouteurs lorsque les fragments, activités ou applications associés passent en arrière-plan.
Logique de reconnexion
Comme avec la v2, le CAF tente de rétablir les connexions réseau perdues en raison d'une perte temporaire du signal Wi-Fi ou d'autres erreurs réseau. Cette opération est désormais effectuée au niveau de la session. Une session peut passer à l'état "suspendu" lorsque la connexion est perdue, puis revenir à l'état "connecté" lorsque la connectivité est rétablie. Le framework se charge de se reconnecter à l'application Web Receiver et de reconnecter les canaux Cast dans le cadre de ce processus.
De plus, le CAF ajoute également la reprise automatique de session, qui est activée par défaut (et peut être désactivée via CastOptions).
Si l'application émettrice est envoyée en arrière-plan ou arrêtée (par balayage ou en raison d'un plantage) alors qu'une session Cast est en cours, le framework tente de reprendre cette session lorsque l'application émettrice revient au premier plan ou est relancée. Cette opération est gérée automatiquement par SessionManager, qui émet les rappels appropriés sur toutes les instances SessionManagerListener enregistrées.
Enregistrement d'un canal personnalisé
Dans la v2, les canaux personnalisés (implémentés à l'aide de Cast.MessageReceivedCallback) sont enregistrés auprès de Cast.CastApi. Dans CAF, les canaux personnalisés sont enregistrés avec l'instance CastSession. L'enregistrement peut être effectué dans la méthode de rappel SessionManagerListener.onSessionStarted. Pour les applications multimédias, il n'est plus nécessaire d'enregistrer explicitement le canal de commande multimédia via Cast.CastApi.setMessageReceivedCallbacks. Pour en savoir plus, consultez la section suivante.
Commande multimédia
La classe v2 RemoteMediaPlayer est obsolète et ne doit pas être utilisée. Dans CAF, elle est remplacée par la nouvelle classe RemoteMediaClient, qui fournit des fonctionnalités équivalentes dans une API plus pratique. Il n'est pas nécessaire d'initialiser ou d'enregistrer explicitement cet objet. Le framework instancie automatiquement l'objet et enregistre le canal multimédia sous-jacent au début de la session si l'application Web Receiver à laquelle il est connecté est compatible avec l'espace de noms multimédia.
RemoteMediaClient est accessible en tant que méthode getRemoteMediaClient de l'objet CastSession.
Dans la version 2, toutes les requêtes multimédias émises sur RemoteMediaPlayer renvoyaient un RemoteMediaPlayer.MediaChannelResult via un rappel PendingResult.
Dans CAF, toutes les requêtes multimédias émises sur RemoteMediaClient renvoient un RemoteMediaClient.MediaChannelResult via un rappel PendingResult qui peut être utilisé pour suivre la progression et le résultat final de la requête.
La version 2 de RemoteMediaPlayer envoie des notifications sur les changements d'état du lecteur multimédia sur le récepteur Web via RemoteMediaPlayer.OnStatusUpdatedListener.
Dans CAF, RemoteMediaClient fournit des rappels équivalents via son interface RemoteMediaClient.Listener. Vous pouvez enregistrer autant d'écouteurs que vous le souhaitez avec RemoteMediaClient, ce qui permet à plusieurs composants d'expéditeur de partager l'instance unique de RemoteMediaClient associée à la session.
Dans la version 2, l'application émettrice devait se charger de synchroniser l'interface utilisateur avec l'état du lecteur multimédia sur le récepteur Web.
Dans le CAF, la classe UIMediaController assume la majeure partie de cette responsabilité.
Message d'annonce en superposition
La V2 ne fournit pas d'interface utilisateur de superposition d'introduction.
CAF fournit une vue personnalisée IntroductoryOverlay pour mettre en évidence l'icône Cast lorsqu'elle est présentée aux utilisateurs pour la première fois.
Mini-télécommande
Dans la v2, vous devez implémenter un mini-contrôleur de zéro dans l'application émettrice.
Dans CAF, le SDK fournit une vue personnalisée, MiniControllerFragment, que vous pouvez ajouter au fichier de mise en page de l'application pour les activités dans lesquelles vous souhaitez afficher le mini-contrôleur.
Notifications et écran de verrouillage
Dans la version 2, les contrôleurs de notification et d'écran de verrouillage ne sont pas fournis par le SDK. Pour ce SDK, vous devez intégrer ces fonctionnalités à votre application émettrice à l'aide des API du framework Android.
Dans CAF, le SDK fournit un NotificationsOptions.Builder pour vous aider à créer des commandes multimédias pour la notification et l'écran de verrouillage dans l'application émettrice. Les commandes de notification et de l'écran de verrouillage peuvent être activées avec CastOptions lors de l'initialisation de CastContext.
public CastOptions getCastOptions(Context context) {
NotificationOptions notificationOptions = new NotificationOptions.Builder()
.setTargetActivityClassName(VideoBrowserActivity.class.getName())
.build();
CastMediaOptions mediaOptions = new CastMediaOptions.Builder()
.setNotificationOptions(notificationOptions)
.build();
return new CastOptions.Builder()
.setReceiverApplicationId(context.getString(R.string.app_id))
.setCastMediaOptions(mediaOptions)
.build();
}
Télécommande agrandie
Dans la v2, vous devez implémenter un contrôleur développé à partir de zéro dans l'application émettrice.
CAF fournit une classe d'assistance UIMediaController qui vous permet de créer facilement votre propre télécommande développée.
Le CAF ajoute un widget de contrôleur développé prédéfini ExpandedControllerActivity que vous pouvez simplement ajouter à votre application. Vous n'avez plus besoin d'implémenter un contrôleur développé personnalisé à l'aide de UIMediaController.
Priorité audio
Dans la v2, vous devez utiliser MediaSessionCompat pour gérer la priorité audio.
Dans CAF, la priorité audio est gérée automatiquement.
Journal de débogage
CAF ne propose pas d'options de journalisation.
Applications exemples
Nous proposons des tutoriels d'ateliers de programmation et des exemples d'applications qui utilisent le CAF.