I have looked over the chromecast examples on git and have looked over the older, v7 mediarouter examples that included the "play or enqueue" behavior. Its not clear from the chromecast interfaces, how one layers the older helper type behavior from 'RemotePlaybackClient' and its 'play or enqueue' on to the chromecast samples that follow the "Typical sender application Flow" mentioned here.
--Observed in chromecast samples onPlay event--
Looks as if each button event for "Play" in the sender app will preempt any current video occupying a session.. The current video is interrupted and the new video buffers and plays.
-- What i want --
The older behavior from the RemotePlaybackClient where a 'play' event in the chromecast sender app communicates a 'playORenqueue' message/instruction to the receiver app. Any currently playing video is NOT affected in any way by the 'add to queue' instruction implemented by the receiver.
My question - how to implement 'play-OR-enqueue()' where the instruction from the sender app is like an async request for the receiver app to issue a "play" or an "enqueue" depending on the current player session-state (isPlaying or not). Is there sample code around for something like this?
--EDIT-- It looks doable as indicated in following details but there is one thing i don't understand regarding the older 'RemotePlaybackClient' vs. the newer 'RemoteMediaPlayer' ....
What happened to the 'enqueue' method? If i want to enqueue does that mean using MediaRouter and not 'chromecast?'
It looks like the following will need to happen:
Chromecast sender and Chromecast receiver
sender formats message for the Next item to play
sender sends message
receiver unpacks message and interprets as "queue up another media URI" if player is busy
receiver gets the session & the player ( a RemoteMediaPlayer i guess )
receiver calls "enqueue()" or equivalent on the player
sample message:
{
"action":"launch", *** need "play or enqueue" ***
"activityType":"video_playback",
"activityId":"jsurtrdlc0hj",
"initParams": {
"videoUrl":"your_video",
"currentTime":0,
"duration":0,
"paused":false,
"muted":false,
"volume":0.5,
"mediaUrl":"your_video"
},
"senderId":"z1c1xp7jh26o",
"receiverId":"local:1",
"disconnectPolicy":"continue"
}
The right place for holding the queue is not on the sender but either on the receiver or in the cloud, depending on whether you need a persistence or not. In addition, holding that queue on the receiver or in the cloud allows multiple people to contribute to the queue. If you need to preserve the "playlist" (i.e. the queue) between application restarts, then you need to think of cloud as the main holder since there is no persistent storage available on the chromecast for individual applications.
It seems you are on the right track; you need to use custom namespace and a custom receiver to accomplish what you want; you basically "add" items to your queue (, say queue is held on the receiver) and receiver, when one media finishes, grabs the next from the queue. By the way, in your sample message, you have a videoUrl and a mediaUrl, I am not sure what the difference is.
In a more advanced implementation, any sender should be able to "query" the receiver to get the queue, and senders could potentially delete items from the queue or rearrange them, etc.