El siguiente procedimiento te permite convertir tu app emisora para Android del SDK de Cast v2 al CAF Sender, que se basa en el singleton CastContext.
El SDK de CAF de Cast para remitentes usa CastContext para administrar GoogleApiClient en tu nombre. CastContext administra los ciclos de vida, los errores y las devoluciones de llamada por ti, lo que simplifica en gran medida el desarrollo de una app para Cast.
Introducción
- CAF Sender aún se distribuye como parte de los Servicios de Google Play a través del SDK Manager de Android.
- Se agregaron nuevos paquetes que asumen la responsabilidad de cumplir con la lista de tareas de diseño de Google Cast (
com.google.android.gms.cast.framework.*). - El CAF Sender proporciona widgets que cumplen con los requisitos de la UX de Cast. La versión 2 no proporcionaba ningún componente de IU y requería que implementaras estos widgets.
- Ya no es necesario usar GoogleApiClient para usar la API de Cast.
- Los subtítulos en CAF Sender son similares a los de la versión 2.
Dependencias
V2 y CAF tienen las mismas dependencias en las bibliotecas de compatibilidad y los Servicios de Google Play (9.2.0 o posterior) como se describe en la Guía de funciones de la biblioteca de compatibilidad.
La versión mínima del SDK de Android que admite CAF es la 9 (Gingerbread).
Inicialización
En CAF, se requiere un paso de inicialización explícito para el framework de Cast. Esto implica inicializar el singleton CastContext con un OptionsProvider adecuado para especificar el ID de aplicación de Web Receiver y cualquier otra opción global.
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;
}
}
Declara OptionsProvider dentro de la etiqueta "application" del archivo AndroidManifest.xml de la app:
<application>
...
<meta-data
android:name=
"com.google.android.gms.cast.framework.OPTIONS_PROVIDER_CLASS_NAME"
android:value="com.google.sample.cast.refplayer.CastOptionsProvider" />
</application>
Inicializa CastContext de forma diferida en el método onCreate de cada actividad:
private CastContext mCastContext;
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.video_browser);
setupActionBar();
mCastContext = CastContext.getSharedInstance(this);
}
Estos pasos no eran necesarios en la versión 2.
Detección de dispositivos
En CAF, el framework inicia y detiene automáticamente el proceso de descubrimiento cuando la app pasa a primer plano y a segundo plano, respectivamente. No se deben usar MediaRouteSelector y MediaRouter.Callback.
Botón para transmitir y diálogo de transmisión
Al igual que en la versión 2, estos componentes los proporciona la biblioteca de compatibilidad de MediaRouter.
El botón para transmitir aún se implementa con MediaRouteButton y se puede agregar a tu actividad (con un ActionBar o un Toolbar) como un elemento de menú.
<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"/>
Anula el método onCreateOptionMenu() de cada Activity con CastButtonFactory para conectar MediaRouteButton al framework de 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;
}
Cuando alguien presiona el botón, se muestra automáticamente el diálogo de Cast.
Control de dispositivos
En CAF, el framework controla en gran medida el dispositivo. La aplicación del remitente no necesita controlar (y no debería intentar controlar) la conexión al dispositivo ni el inicio de la aplicación de Web Receiver con GoogleApiClient. La interacción entre el remitente y el receptor web ahora se representa como una "sesión". La clase SessionManager controla el ciclo de vida de la sesión y la inicia y detiene automáticamente en respuesta a los gestos del usuario: una sesión se inicia cuando el usuario selecciona un dispositivo Cast en el diálogo de Cast y finaliza cuando el usuario presiona el botón "Detener la transmisión" en el diálogo de Cast o cuando finaliza la app del remitente. La aplicación del remitente puede recibir notificaciones sobre los eventos del ciclo de vida de la sesión si registra un SessionManagerListener con el SessionManager. Las devoluciones de llamada de SessionManagerListener definen métodos de devolución de llamada para todos los eventos del ciclo de vida de la sesión.
La clase CastSession representa una sesión con un dispositivo de transmisión. La clase tiene métodos para controlar el volumen y los estados de silencio del dispositivo, lo que antes se hacía en la versión 2 con métodos en Cast.CastApi.
En la versión 2, las devoluciones de llamada de Cast.Listener proporcionaban notificaciones de cambios en el estado del dispositivo, incluidos el volumen, el estado de silencio, el estado de espera, etcétera.
En CAF, las notificaciones de cambio de estado de volumen o silencio aún se entregan a través de métodos de devolución de llamada en Cast.Listener. Estos objetos de escucha se registran con CastSession.
Todas las notificaciones restantes del estado del dispositivo se entregan a través de devoluciones de llamada de CastStateListener. Estos objetos de escucha se registran con CastSession. Asegúrate de cancelar el registro de los objetos de escucha cuando los fragmentos, las actividades o las apps asociados pasen a segundo plano.
Lógica de reconexión
Al igual que con la versión 2, CAF intenta restablecer las conexiones de red que se pierden debido a la pérdida temporal de la señal Wi-Fi o a otros errores de red. Ahora se realiza a nivel de la sesión. Una sesión puede entrar en un estado de "suspensión" cuando se pierde la conexión y volverá a un estado de "conexión" cuando se restablezca la conectividad. El framework se encarga de volver a conectarse a la aplicación de Web Receiver y de volver a conectar los canales de Cast como parte de este proceso.
Además, CAF también agrega la reanudación automática de la sesión, que está habilitada de forma predeterminada (y se puede desactivar a través de CastOptions).
Si la aplicación del remitente se envía a segundo plano o se cierra (deslizándola o debido a una falla) mientras hay una sesión de Cast en curso, el framework intentará reanudar esa sesión cuando la aplicación del remitente vuelva a primer plano o se vuelva a iniciar. El SessionManager se encarga de esto automáticamente y emitirá las devoluciones de llamada correspondientes en cualquier instancia de SessionManagerListener registrada.
Registro de canales personalizados
En la versión 2, los canales personalizados (implementados con Cast.MessageReceivedCallback) se registran con Cast.CastApi. En CAF, los canales personalizados se registran con la instancia de CastSession. El registro se puede realizar en el método de devolución de llamada SessionManagerListener.onSessionStarted. En el caso de las apps de medios, ya no es necesario registrar de forma explícita el canal de control de medios a través de Cast.CastApi.setMessageReceivedCallbacks. Consulta la siguiente sección para obtener más detalles.
Control multimedia
La clase RemoteMediaPlayer de la versión 2 está obsoleta y no se debe usar. En CAF, se reemplaza por la nueva clase RemoteMediaClient, que proporciona una funcionalidad equivalente en una API más conveniente. No es necesario inicializar o registrar este objeto de forma explícita. El framework creará una instancia del objeto y registrará el canal de medios subyacente automáticamente en el momento de inicio de la sesión si la aplicación de Web Receiver a la que se conecta admite el espacio de nombres de medios.
Se puede acceder a RemoteMediaClient como el método getRemoteMediaClient del objeto CastSession.
En la versión 2, todas las solicitudes de medios emitidas en RemoteMediaPlayer devolverían un RemoteMediaPlayer.MediaChannelResult a través de una devolución de llamada PendingResult.
En CAF, todas las solicitudes de medios emitidas en RemoteMediaClient devuelven un RemoteMediaClient.MediaChannelResult a través de una devolución de llamada PendingResult que se puede usar para hacer un seguimiento del progreso y el resultado final de la solicitud.
La versión 2 de RemoteMediaPlayer enviaría notificaciones sobre los cambios en el estado del reproductor multimedia en el Web Receiver a través de RemoteMediaPlayer.OnStatusUpdatedListener.
En CAF, RemoteMediaClient proporciona devoluciones de llamada equivalentes a través de su interfaz RemoteMediaClient.Listener. Se puede registrar cualquier cantidad de objetos de escucha con RemoteMediaClient, lo que permite que varios componentes de envío compartan la única instancia de RemoteMediaClient asociada a la sesión.
En la versión 2, la aplicación del remitente tenía que encargarse de mantener la interfaz de usuario sincronizada con el estado del reproductor multimedia en el Web Receiver.
En CAF, la clase UIMediaController asume la mayor parte de esta responsabilidad.
Superposición introductoria
La versión 2 no proporciona una IU de superposición introductoria.
El CAF proporciona una vista personalizada IntroductoryOverlay para destacar el botón para transmitir cuando se muestra por primera vez a los usuarios.
Minicontrolador
En la versión 2, debes implementar un controlador mini desde cero en la app del remitente.
En el CAF, el SDK proporciona una vista personalizada, MiniControllerFragment, que puedes agregar al archivo de diseño de la app de las actividades en las que deseas mostrar el controlador compacto.
Notificaciones y pantalla de bloqueo
En la versión 2, el SDK no proporciona controladores para la notificación y la pantalla de bloqueo. Para ese SDK, debes compilar estas funciones en tu app de envío con las APIs del framework de Android.
En CAF, el SDK proporciona un objeto NotificationsOptions.Builder para ayudarte a compilar controles multimedia para la notificación y la pantalla de bloqueo en la app del remitente. Los controles de la notificación y la pantalla de bloqueo se pueden habilitar con CastOptions cuando se inicializa 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();
}
Control expandido
En la versión 2, debes implementar un controlador expandido desde cero en la app del remitente.
CAF proporciona una clase de ayuda UIMediaController que te facilita la creación de tu propio controlador expandido.
El CAF agrega un widget de controlador expandido prediseñado
ExpandedControllerActivity
que puedes agregar fácilmente a tu app. Ya no necesitas
implementar un controlador expandido personalizado con UIMediaController.
Enfoque de audio
En la versión 2, debes usar MediaSessionCompat para administrar el enfoque de audio.
En CAF, el foco de audio se administra automáticamente.
Registro de depuración
En CAF, no hay opciones de registro.
Apps de ejemplo
Tenemos instructivos de codelab y apps de ejemplo que usan CAF.