La procédure suivante vous permet de convertir votre application d'émetteur Android du SDK Cast v2 vers l'émetteur CAF, qui est basé sur l'objet singleton CastContext.
Le SDK Cast CAF Sender utilise CastContext pour gérer GoogleAPIClient en votre nom. CastContext gère les cycles de vie, les erreurs et les rappels pour vous, ce qui simplifie grandement le développement d'une application Cast.
Introduction
- L'expéditeur CAF est toujours distribué dans les services Google Play à l'aide du gestionnaire de SDK Android.
- De nouveaux packages ont été ajoutés pour assurer le respect de la checklist de conception Google Cast (
com.google.android.gms.cast.framework.*
). - L'expéditeur CAF fournit des widgets conformes aux exigences d'expérience utilisateur Cast. La version 2 ne fournissait aucun composant d'interface utilisateur et vous obligeait à implémenter ces widgets.
- L'utilisation de GoogleApiClient n'est plus nécessaire pour utiliser l'API Cast.
- Les sous-titres dans CAF Sender sont semblables à la version 2.
Dépendances
La version 2 et la CAF ont les mêmes dépendances sur les bibliothèques de compatibilité et les services Google Play (9.2.0 ou version ultérieure), comme décrit dans le Guide des fonctionnalités de la bibliothèque de compatibilité.
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
à l'aide d'un OptionsProvider
approprié pour spécifier l'ID d'application du récepteur Web et toute autre option globale.
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 l'OptionsProvider
dans le tag "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>
Lancez en douceur l'initialisation de 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 version 2.
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 au premier plan et en arrière-plan, respectivement. MediaRouteSelector
et MediaRouter.Callback
ne doivent pas être utilisés.
Bouton Cast et boîte de dialogue Cast
Comme dans la version 2, ces composants sont fournis par la bibliothèque d'assistance MediaRouter.
Le bouton Cast est toujours implémenté par MediaRouteButton
et peut être ajouté à 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é à l'aide de CastButtonFactory
pour connecter 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 de l'appareil est largement géré par le framework. L'application d'envoi 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 Web Receiver à l'aide de GoogleApiClient
. L'interaction entre l'expéditeur et le récepteur Web est désormais représentée par une "session". La classe SessionManager
gère le cycle de vie des sessions et démarre et arrête automatiquement les sessions en réponse aux gestes de l'utilisateur: une session est lancée 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 la diffusion" dans la boîte de dialogue Cast ou lorsque l'application d'envoi se termine. L'application d'envoi peut être avertie des événements de cycle de vie de la session en enregistrant un SessionManagerListener
avec le 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 dispose de méthodes permettant de contrôler le volume et les états de mise en sourdine de l'appareil, ce qui était auparavant effectué dans la version 2 à l'aide de méthodes sur Cast.CastApi
.
Dans la version 2, les rappels Cast.Listener
fournissaient des notifications sur les modifications de l'état de l'appareil, y compris le volume, l'état de mise en sourdine, l'état de veille, etc.
Dans CAF, les notifications de changement d'état du volume/de la mise en sourdine sont toujours envoyées via des méthodes de rappel dans Cast.Listener
. Ces écouteurs sont enregistrés avec CastSession
.
Toutes les autres notifications d'état de l'appareil sont envoyées via des rappels CastStateListener
. Ces écouteurs sont enregistrés auprès de CastSession
. Veillez à toujours désenregistrer les écouteurs lorsque les fragments, activités ou applications associés passent en arrière-plan.
Logique de reconnexion
Comme avec la version 2, la 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, et revenir à l'état "connecté" lorsque la connectivité est rétablie. Le framework se charge de se reconnecter à l'application Web Receiver et de reconnecter tous les canaux Cast dans le cadre de ce processus.
De plus, CAF ajoute également la reprise automatique des sessions, qui est activée par défaut (et peut être désactivée via CastOptions
).
Si l'application d'envoi est envoyée en arrière-plan ou arrêtée (en balayant l'écran ou en raison d'un plantage) alors qu'une session Cast est en cours, le framework tentera de reprendre cette session lorsque l'application d'envoi reviendra au premier plan ou sera 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 de critères personnalisés
Dans la version 2, 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 auprès de 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 contrôle 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 ni d'enregistrer explicitement cet objet. Le framework initialisera automatiquement l'objet et enregistrera 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 le RemoteMediaPlayer
renvoyaient un RemoteMediaPlayer.MediaChannelResult
via un rappel PendingResult
.
Dans CAF, toutes les requêtes multimédias émises sur le 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 RemoteMediaPlayer
v2 envoyait des notifications sur les modifications de l'état du lecteur multimédia sur le récepteur Web via la RemoteMediaPlayer.OnStatusUpdatedListener
.
Dans CAF, RemoteMediaClient
fournit des rappels équivalents via son interface RemoteMediaClient.Listener
. Un nombre illimité d'écouteurs peut être enregistré 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 d'envoi devait s'assurer que l'interface utilisateur était synchronisée avec l'état du lecteur multimédia sur le récepteur Web.
Dans CAF, la classe UIMediaController
assume la majeure partie de cette responsabilité.
Message d'annonce en superposition
La version 2 ne fournit pas d'interface utilisateur de superposition d'annonce.
Le CAF fournit une vue personnalisée IntroductoryOverlay
pour mettre en surbrillance le bouton Cast lorsqu'il est présenté aux utilisateurs pour la première fois.
Mini-télécommande
Dans la version 2, vous devez implémenter une mini-télécommande à partir de zéro dans l'application de l'émetteur.
Dans CAF, le SDK fournit une vue personnalisée, MiniControllerFragment
, que vous pouvez ajouter au fichier de mise en page de l'application des activités pour lesquelles vous souhaitez afficher la mini-télécommande.
Notifications et écran de verrouillage
Dans la version 2, le SDK ne fournit pas de contrôleurs pour les notifications et l'écran de verrouillage. Pour ce SDK, vous devez intégrer ces fonctionnalités à votre application d'envoi à 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 de l'émetteur. 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 version 2, vous devez implémenter une télécommande agrandie à partir de zéro dans l'application émettrice.
CAF fournit une classe d'assistance UIMediaController
qui vous permet de créer facilement votre propre contrôleur développé.
CAF ajoute un widget de contrôleur développé 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 version 2, vous devez utiliser MediaSessionCompat
pour gérer la sélection audio.
Dans CAF, la priorité audio est gérée automatiquement.
Consignation des données de débogage
Dans CAF, il n'existe aucune option de journalisation.
Applications exemples
Nous proposons des tutoriels d'atelier de programmation et des exemples d'applications qui utilisent CAF.