本指南說明如何將 Cast Receiver v2 應用程式遷移至最新版本 接收器應用程式。
全新的 Cast 應用程式架構 (CAF) SDK,也稱為 Web 接收器 v3 接收器 v2 SDK 的重大升級。Web Receiver SDK 提供 簡單易用的簡化版 SDK,適合開發媒體 Web Receiver 應用程式。
Web Receiver 提供的 API 與新的 CAF 傳送者更加一致 相互整合能完全整合播放器 (MPL 和 Shaka) 及 針對投放媒體和 Google 助理的實作與支援 語音指令。CAF SDK 也提供可輕鬆設定樣式的預設 UI 以及運用資料繫結服務,可簡化使用者介面的實作程序。
為何要遷移?
將 Receiver v2 應用程式遷移至 Web Receiver,其中有許多程式碼 就可以消除遊戲過程,專心寫作 應用程式專屬的商業邏輯
CAF 完美整合 MPL 和 Shaka 播放器,以支援 內容類型,包括 HTTP 即時串流 (TS 和 CMAF)、MPEG-DASH、流暢度 媒體元素來源資源 (MP3、MP4、 Icecast 等...)。如需完整清單,請參閱 Google Cast 支援的媒體。 目前 CAF 不支援使用者提供的播放器。
遷移至 CAF 後,系統將開始支援 Google 助理的語音控制功能。 系統將自動支援所有新的 Google 助理語音指令, 使用 CAF
除了支援新的媒體指令 (例如「依語言變更音軌」) 之外, 以及「變更播放率」—CAF 也改善了內建廣告佇列功能 支援服務和更良好的即時支援。
有何不同之處呢?
Web Receiver API 會嘗試遵循 CAF 寄件者: Android 和 iOS、 也與第 2 版有很大的差異
Web Receiver 正在使用新的命名空間
cast.framework
敬上
而非所有已公開 API 的 cast.receiver
命名空間許多
因為第 2 版所使用的資料物件在 CAF 中相同
這個
cast.framework.messages
敬上
命名空間 (這些字元大多低於 cast.receiver.media
)。
下列 v2 服務會由對應的 CAF 服務取代:
CastReceiverManager
類別已由CastReceiverContext
這是一種單例模式,可管理投放工作階段、傳送者 訊息和全域系統事件CastReceiverOptions
敬上 可用於提供全域應用程式選項 (例如佇列、接收器) 版本、播放設定等等)。MediaManager
類別已由PlayerManager
這是CastReceiverContext
單例模式,負責管理媒體工作階段、媒體要求 Google 助理語音要求 (v2 中的CommandAndControlManager
)、 並觸發媒體事件玩家設定 (MPL 中的cast.player.api.Host
) 由以下實體提供:PlaybackConfig
, 這組 ID 可在全域或根據載入要求提供
PlayerManager
也會提供新的副管理員類別:
TextTracksManager
- 管理媒體文字軌。AudioTracksManager
:管理音軌。QueueManager
:管理佇列。BreakManager
- 管理廣告。
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);
接收端商業邏輯
接收者 v2 公開的事件處理常式 (例如 CastReceiverManager.onReady
或
MediaManager.onLoad
) 新增商業邏輯。在 CAF 中,事件處理常式
已由事件監聽器取代
(CastReceiverContext.addEventListener
)。
以及訊息攔截器
(PlayerManager.setMessageInterceptor
)。
網路接收端可以為事件 (事件監聽器) 有多個事件監聽器
不會影響事件),且每封郵件有一個攔截器。攔截器
可以更新或處理要求 (傳回修改的要求,
訊息或錯誤訊息),而且可以是傳回承諾結果的非同步處理常式。
載入要求攔截器是最常見的 特定應用程式的邏輯對於來自傳送方的載入要求, 攔截器可以將 Content ID 轉換為內容網址。載入攔截器是 如果沒有明確的攔截器,則 也會呼叫用於預先載入和預載要求 提供的預載資源或友善快取。
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;
});
第 2 版自訂媒體狀態處理常式也會替換為訊息
媒體狀態訊息攔截器。不想要的網路接收端應用程式
在媒體狀態中顯示媒體網址可以提供網址解析器
(PlayerManager.setMediaUrlResolver
),
會提供載入要求的媒體網址。CAF 正在使用該網址
而非媒體狀態。
playerManager.setMessageInterceptor(
cast.framework.messages.MessageType.MEDIA_STATUS,
status => {
// Disable seek.
status.supportedMediaCommands &=
~cast.framework.messages.Command.SEEK
return status;
});
活動
Web Receiver 提供各式各樣的事件
CastReceiverContext
敬上
和
PlayerManager
。
網路接收端應用程式可以在任何事件上擁有多個事件監聽器。
也可以為多個事件提供一個事件監聽器。(詳情請參閱
cast.framework.events.category
敬上
)
這些事件涵蓋任何使用者要求、播放進度、播放器處理程序,以及 低階媒體元素事件 (CAF 不會公開媒體元素本身),
Web Receiver 應用程式可新增事件監聽器,以便採取行動 (例如加入文字) 追蹤定義。
// Log all media commands
playerManager.addEventListener(
cast.framework.events.category.REQUEST,
event => logEvent(event.type));
自訂訊息匯流排
CAF 不會在 API 中顯示訊息匯流排,而是提供
CastReceiverContext.addCustomMessageListener
敬上
為特定命名空間 (每個命名空間只能新增一個) 的訊息事件監聽器,
CastReceiverContext.sendCustomMessage
。
在命名空間中傳送訊息所有命名空間都必須宣告
啟動 Web Receiver (也就是在呼叫
CastReceiverContext.start
)。
命名空間可宣告
新增訊息接聽器至用戶端,或也可以做為起始選項,使用
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'
});
預設 UI
CAF 提供預設的網路接收器 UI,顯示播放進度列,
視需要使用媒體中繼資料提供預設 UI 做為自訂元素
(<cast-media-player>
)。
我們再以類似 CSS 樣式的樣式設定樣式
<style>
cast-media-player { --splash-image: url("splash.png"); }
</style>
<cast-media-player></cast-media-player>
如要進一步自訂, Web Receiver 應用程式可實作專屬的使用者介面。
Web Receiver 提供
cast.framework.ui.PlayerDataBinder
敬上
類別,協助將 UI 物件繫結至網路接收器播放狀態。