是否需要使用 Remote Display API 构建的应用程序才能满足重新连接和连续播放的要求?

Posted

技术标签:

【中文标题】是否需要使用 Remote Display API 构建的应用程序才能满足重新连接和连续播放的要求?【英文标题】:Are apps built with the Remote Display API required to fulfill the reconnection and continuous playback requirements? 【发布时间】:2016-10-03 17:51:24 【问题描述】:

根据Google Cast Test Cases的Test Case 1.30

步骤:关闭发送方 WiFi 20 秒

预期结果:

发件人不会崩溃 未填充投射图标 接收器继续不间断播放

步骤:打开WiFi并连接到同一网络

预期结果:

投射重新连接,投射图标已填充

以上内容被列为P0 test case,其中“您的应用程序不能以 P0 错误启动。”但是,使用Remote Display API 的应用程序无法在发送方断开连接时播放媒体,因为内容是通过 WiFi 在本地投射的。此外,我注意到在 android 上,官方 Google Cast 应用的 Cast Screen/Audio 功能不会在 WiFi 断开连接后尝试重新连接。

是否需要使用 Remote Display API 构建的应用才能满足重新连接和连续播放的要求?

【问题讨论】:

【参考方案1】:

据我所知Remote Display API 仅具有保持远程显示会话处于活动状态并在应用程序后台运行后恢复的功能。文档没有提到在 WiFi 断开连接后重新连接。

进一步阅读其他文档,Media Playback Messages 指出:

Google Cast 发送方应用程序通过向接收方应用程序发送 JSON 格式的消息来控制接收方设备上的播放。同样,接收方也以 JSON 格式将消息发送回发送方。这些消息可能是来自发送方的改变播放器状态的命令、对来自接收方的这些命令的响应,或者是描述接收方应用程序媒体的数据结构。

据我了解,您可能需要在播放器状态更改或 WiFi 断开连接后再次启动 creation of connection。

【讨论】:

以上是关于是否需要使用 Remote Display API 构建的应用程序才能满足重新连接和连续播放的要求?的主要内容,如果未能解决你的问题,请参考以下文章

使用来自 API 的 wp_remote_post 请求下载文件

自更新以来,Appengine remote_api_shell 无法使用应用程序默认凭据

docker remote api

docker 开启remote api

『干货​』Go语言使用Docker Remote API ,举个栗子!

visual studio code 配置remote ssh X11Forwarding显示