Cast example

[Marekkon5]

Hello, some time ago I created issue #211 asking for cast support, and I made a proof-of-concept that barely works. This PR isn't meant to be merged, it's just to show a working example.

What this example does:

Added 2 new functions (getAvailableCastDevices, connectCast) that allow listing available cast devices, and connecting to them.
When connected a hardcoded example song is being played, it is because the CastPlayer uses different queueing / MediaSources than the default ExoPlayer.
Play, pause, seeking, updating position affect the cast player when connected.

How to:

Just run the example app, and you can press the cast button. I personally do not own any cast devices, so I used AirScreen app on another device to emulate one.
Note 1: You might need to connect twice to start playback because it sometimes throws unknown error.
Note 2: You need to press the play/pause button when cast started to update the UI to control the remote playback.

I know that this example is really barebones, barely working, but let me know if you find it useful or gonna work on this feature. Thank you for the amazing library!

[ryanheise]

Thanks for this example! It's a feature I'd definitely like to see and this is certainly a useful first step.

I haven't fully looked into the API documentation yet, so my only exposure is through reading your code. I know even less about AirPlay, so that will be the next thing for me to understand before figuring out how to unify the two APIs and create a Dart API.

[keaganhilliard]

Just wanted to point out that Cast is supported on iOS as well, but it would likely be a larger lift than using the exoplayer castplayer implementation. Not sure how that would factor into the airplay and cast architecture. There is interesting crossover with audio_service as well. You are technically supposed to create a notification showing that something is casting and there's a CastSession as well which kind of aligns to MediaSession and you also need to pass metadata over to the Cast device. All of this is handled audio_service which kind of blurs the lines between these two packages. Almost like the functionality would have to be implemented in both places, but that would also likely involve using the SDK directly rather than using exoplayer's stuff on the audio_service end of things. I could be overcomplicating it 🤷

[ryanheise]

That's interesting to think about. What are the requirements for an app? When switching from the regular player to the cast player, it needs to:

• stop the media session
• start the cast session

Does it need to co-opt audio_service's media notification, or is it OK to shut it down and start a new notification?

[keaganhilliard]

As far as I can tell it's fine to kill the notification and create a new one. I've seen other apps do that.

https://developers.google.com/cast/docs/design_checklist/sender#sender-control-notification

They have a lot of opinions about how you handle the cast stuff in your app as well haha

[ryanheise]

OK, that technically means no changes need to be made to audio_service, however I'd rather think through the alternative solutions thoroughly first before deciding anything.

If we reuse audio_service's notification, we can leverage its callback and isolate management, but then we also need to solve the problem of sharing the cast session between audio_service and just_audio which implies extracting parts of this out into a 3rd plugin.

[markst]

@Marekkon5 have you followed any of the discussion in #211?

[Marekkon5]

@markst Thank you for the reminder, however I am no longer working on any Flutter project related to this, so I've abandoned it. Sorry for ignorance.