Zu Web Receiver migrieren

In dieser Anleitung wird erläutert, wie du eine Cast Receiver v2-App zur neuesten Webversion migrierst. Receiver-App.

Das neue CAF SDK (Cast Application Framework), auch bekannt als Web Receiver v3, ein umfangreiches Upgrade des Receiver v2 SDK. Das Web Receiver SDK bietet eine einfaches, optimiertes SDK für die Entwicklung von Web Receiver-Anwendungen für Medien.

Der Web Receiver bietet eine API, die mit dem neuen CAF-Sender konsistenter ist APIs Es ermöglicht die vollständige Integration eines Players (MPL und Shaka) und Implementierung und Support für gestreamte Medien und Google Assistant Sprachbefehle verwenden. Das CAF SDK bietet außerdem eine Standardbenutzeroberfläche, die sich ganz einfach gestalten lässt. und einen Datenbindungsdienst zur Vereinfachung der UI-Implementierung verwenden.

Warum migrieren?

Bei der Migration einer Receiver v2-Anwendung zu Web Receiver wird viel Code mit dem Player eliminiert werden, sodass Sie sich auf das Schreiben Anwendungsspezifische Geschäftslogik.

CAF bindet MPL- und Shaka-Player nahtlos ein, um ein breiteres Spektrum an Inhaltstypen, einschließlich HTTP Live Streaming (TS und CMAF), MPEG-DASH, Smooth Streaming und Typen, die von der Quelleigenschaft des Mediaelements unterstützt werden (MP3, MP4, Icecast usw.). Eine vollständige Liste finden Sie unter Unterstützte Medien für Google Cast. Derzeit unterstützt CAF keinen vom Nutzer bereitgestellten Player.

Durch die Migration zu CAF wird die Sprachsteuerung mit Google Assistant unterstützt. Jeder neue Google Assistant-Sprachbefehl wird automatisch unterstützt, wenn mit CAF.

Neben der Unterstützung neuer Medienbefehle wie „Titel nach Sprache ändern“ und „Wiedergaberate ändern“. CAF bietet außerdem bessere Wiedergabelisten, besserer Echtzeit-Support.

Was hat sich geändert?

Die Web Receiver API versucht, die Konventionen zu befolgen, CAF-Absender für Android und iOS und unterscheidet sich erheblich von Version 2.

Web Receiver verwendet einen neuen Namespace cast.framework anstelle des Namespace cast.receiver für alle bereitgestellten APIs. Viele von Die von v2 verwendeten Datenobjekte sind in CAF identisch und werden unter die cast.framework.messages Namespace (sie befanden sich hauptsächlich unter cast.receiver.media).

Die folgenden V2-Dienste werden durch entsprechende CAF-Dienste ersetzt:

  • Klasse CastReceiverManager wurde ersetzt durch CastReceiverContext ein Singleton, der die Streamingsitzung, die Absender, die Nachrichten und globale Systemereignisse. Die CastReceiverOptions können verwendet werden, um globale Anwendungsoptionen (z. B. Warteschlange, Empfänger) bereitzustellen. Version, Wiedergabekonfiguration usw.) zum Kontext hinzufügen.
  • Klasse MediaManager wurde ersetzt durch PlayerManager das eine Eigenschaft des CastReceiverContext Singleton und verwaltet Mediensitzungen, Medienanfragen, Assistant-Sprachanfragen (CommandAndControlManager in Version 2), und Medienereignisse auslösen. Konfiguration für die Spieler (cast.player.api.Host in MPL) wird bereitgestellt von PlaybackConfig, die global oder pro Ladeanfrage bereitgestellt werden kann.

Mit der PlayerManager werden auch die neuen untergeordneten Verwaltungskontoklassen angezeigt:

const context = cast.framework.CastReceiverContext.getInstance();
const playerManager = context.getPlayerManager();

// Set global options.
const options = new cast.framework.CastReceiverOptions();
options.versionCode = DEVELOPERS_APP_VERSION;

context.start(options);

Geschäftslogik des Empfängers

Bei Empfänger v2 offengelegte Event-Handler (z. B. CastReceiverManager.onReady oder MediaManager.onLoad), um Geschäftslogik hinzuzufügen. In CAF sind die Event-Handler durch Event-Listener ersetzt (CastReceiverContext.addEventListener) und Nachrichtenabfanger (PlayerManager.setMessageInterceptor) Web Receiver kann mehrere Ereignis-Listener für ein Ereignis haben (der Listener hat keinen Einfluss auf das Ereignis) und ein Abfangende pro Nachricht. Der Interceptor kann die Anfrage aktualisieren oder verarbeiten (eine geänderte Anfrage, eine erfolgreiche Nachricht oder Fehlermeldung) und kann ein asynchroner Handler sein, der ein Promise zurückgibt.

Der Interceptor für Ladeanfragen ist der am häufigsten verwendete Ort, Anwendungsspezifische Logik. Bei Ladeanfragen von einem Absender kann die Content-ID in eine Content-URL konvertiert werden. Der Load-Abfangende ist wird auch für Preload- und Precache-Anfragen aufgerufen, wenn kein expliziter Interceptor für Preload oder Precache bereitgestellt wurde.

playerManager.setMessageInterceptor(
    cast.framework.messages.MessageType.LOAD,
    request => {
      // Resolve entity to content id
      if (request.media.entity && !request.media.contentId) {
        return getMediaByEntity(request.media.entity).then(
            media => {
              request.media.contentId = media.url;
              return request;
            });
      }
      return request;
    });

Der benutzerdefinierte Medienstatus-Handler in Version 2 wurde ebenfalls durch eine Nachricht ersetzt. Abfangfunktion für die Medienstatusnachricht. Web Receiver-Apps, die keine Wenn die Medien-URL im Medienstatus angezeigt wird, kann ein URL-Resolver bereitgestellt werden. (PlayerManager.setMediaUrlResolver), die die Medien-URL für eine Ladeanforderung bereitstellt. Diese URL wird von CAF verwendet intern und wird nicht im Medienstatus aufgeführt.

playerManager.setMessageInterceptor(
    cast.framework.messages.MessageType.MEDIA_STATUS,
    status => {
      // Disable seek.
      status.supportedMediaCommands &=
          ~cast.framework.messages.Command.SEEK
      return status;
    });

Ereignisse

Web Receiver bietet eine große Auswahl an Ereignissen, sowohl von CastReceiverContext und PlayerManager Web Receiver-Apps können für jedes Ereignis mehrere Listener haben und kann auch einen Listener für mehrere Ereignisse bereitstellen. (Siehe cast.framework.events.category für einige Ereignisgruppen.

Die Ereignisse umfassen alle Nutzeranfragen, den Wiedergabefortschritt, die Playerverarbeitung und Low-Level-Mediaelement-Ereignis (CAF zeigt das Medienelement nicht selbst an).

Mit der Web Receiver App können Ereignis-Listener hinzugefügt werden, auf die reagiert werden soll, z. B. Text verfolgt die Definition, wenn der Ladevorgang abgeschlossen ist, oder für Analysen.

// Log all media commands
playerManager.addEventListener(
    cast.framework.events.category.REQUEST,
    event => logEvent(event.type));

Benutzerdefinierter Nachrichtenbus

CAF legt den Nachrichtenbus in der API nicht offen, sondern stellt CastReceiverContext.addCustomMessageListener , um einen Nachrichten-Listener für einen bestimmten Namespace hinzuzufügen (nur einer pro Namespace) und CastReceiverContext.sendCustomMessage zum Senden einer Nachricht in einem Namespace. Alle Namespaces müssen vor dem Starten des Web Receivers (d. h. vor dem Aufruf CastReceiverContext.start) Die Namespaces können folgendermaßen deklariert werden: Nachrichten-Listener hinzufügen oder als Startoption in CastReceiverOptions.customNamespaces

const options = new cast.framework.CastReceiverOptions();
options.customNamespaces = {
    CUSTOM_NS: cast.framework.system.MessageType.JSON
};
context.start(options);

context.sendCustomMessage(CUSTOM_NS, {
  type: 'status'
  message: 'Playing'
});

Standardbenutzeroberfläche

CAF stellt eine standardmäßige Web Receiver-Benutzeroberfläche bereit, auf der eine Fortschrittsanzeige Medienmetadaten nach Bedarf. Die Standardbenutzeroberfläche wird als benutzerdefiniertes Element bereitgestellt. (<cast-media-player>) die mit CSS-ähnlichen Stilen gestaltet werden können.

<style>
   cast-media-player { --splash-image: url("splash.png"); }
</style>
<cast-media-player></cast-media-player>

Für mehr Anpassung kann eine Web Receiver-App eine eigene Benutzeroberfläche implementieren. Die Web Receiver bietet die cast.framework.ui.PlayerDataBinder -Klasse zum Binden eines UI-Objekts an den Wiedergabestatus von Web Receiver.