0

I have built an application that uses Cast Companion Library (CCL) to remotely play video to cast comparable devices. Every thing is working find but I need to be able to change video files and not kill and restart the activity and fragment.

I have implemented my own custom version of the VideoCastControllerActivity that implements the same interface but I am re-using the VideoCastControllerFragment that CCL comes with. One problem is that the VideoCastControllerFragment does not really give specific notice when the end of a video file is reached. It somewhat does by calling closeActivity() from the IVideoCastController interface so I tried to use that event to know when to load the next video file. But loading the next video file by calling 

getCastManager().loadMedia( mSelectedMedia, autoPlay, position );

but doing that results in another call to close activity and a loop until the end of the playlist is reached without playing any video.

Is there another way to go about this without re-writing my own VideoCastControllerFragment?

startoftext
  • 3,846
  • 7
  • 40
  • 49

1 Answers1

1

To answer your first question (or observation), you can listen to various callback events directly in your implementation of VideoCastControllerActivity; you have access to the VideoCastManager so you know when your media status goes to IDLE with the reason FINISHED. Outside of that, you seem to be trying to implement some sort of playlist functionality in your sender while the right place for that is on the receiver (i.e. you need to write a custom receiver); if your playlist knowledge/logic lives on your phone, then the whole thing becomes dependent on your phone so if it goes to sleep, you chromecast doesn't know what to do. In addition, if a second device connects to the same cast device, it cannot correctly reflect the playlist, etc. So a phone device can let user form a playlist and then it has to send the information about that playlist to your custom receiver and your custom receiver should handle playing them in queue and your sender(s) should be able to send custom messages to move to the next/prev, etc and your receiver should do the right thing accordingly. We have a very rudimentary sample on our GitHub repo that shows how you can do video playlist on the receiver.

Ali Naddaf
  • 16,951
  • 2
  • 21
  • 28
  • I think long term it would be nice to do playlist as well as some other features we need receiver side so that there is less dependence on the device that is casting. I am aware of the sleep issues (granted I could solve that with a service to listen for events and handle them). Is it not possible to start playing the next video from the sender? Thanks for your input. – startoftext Jan 26 '15 at 22:20
  • Also would you say that for something that is more complex than just playing a single video should I maybe not use CCL and just use CCL as a reference? Its starting to feel like CCL is great for simple use cases of cast but for more complex use cases it is starting to feel like I am trying to work around it more often than not. – startoftext Jan 26 '15 at 22:58
  • 1
    CCL, as a library, cannot include any API that is not supported by the current SDK on the Android sender or receiver; for example if there is currently no API on the receiver side to handle playlists, it doesn't make sense for CCL to add its own api since there is no standard api on the receiver to handle those api calls and CCL is not going to provide a receiver either. – Ali Naddaf Jan 27 '15 at 00:45
  • So since I have already started using CCL will I be able to keep using CCL with that custom receiver sample you linked to that supports playlist? – startoftext Jan 28 '15 at 18:04