Await execution of custom action

[BeMacized]

As media items do not seem to contain any information about what to play (such as a streaming URL), I am trying to provide the background task with this information using the AudioService.customAction function.
After this, I would like to initiate playing with AudioService.play, roughly as such:

Map<String, String> sources = { 'mediaId': 'exampleUrl' }; 
await AudioService.customAction('addMediaSources', sources);
await AudioService.play();

However, it seems so that sometimes the onPlay callback in the background task is called before the onCustomAction callback completes. Because of this, there is yet no source to play from by the time the onPlay callback is called.
When adding a bit of a delay between the customAction and play calls, everything functions as normal.

It seems that the future returned by customAction can complete before the actual completion of the callback. Is it possible to change this behaviour, or is there maybe some other way I can wait for the custom action to complete before moving on?

[ryanheise]

I notice that you are using the URL as your media ID. If you want to do this, then I would suggest using AudioService.playFromMediaId. That may be a quick solution to what you're trying to do, but...

It seems that you are putting all of your media loading logic on the client side, but is there any reason why you can't move this into the server side?

audio_service uses a client/server architecture by design where the server is intended to be the source of all media items. All clients (including Android Auto) may query the server for available media items. One way to think about it is that your Flutter client shouldn't really do much more than what an Android Auto client does (at least in principle). i.e. The streaming URL isn't supplied by Android Auto, Android Auto merely provides a UI for accessing the list of media items and selecting which one to play, but it is the server side (i.e. your backgroundTask) that provides that list of media items and knows internally what streaming URLs are used to play them. So the server side contains the logic for loading media items. This makes it reusable across different clients such as Android Auto.

I'd be interested to hear more about your use case so that I can see the most appropriate way to fit it into this architecture.

[ryanheise]

Release 0.0.11 now implements AudioService.customAction to await the completion of the action.

[BeMacized]

Awesome, the update seems to work perfectly, thank you!

I have to say that I am not a mobile dev. This is my first time ever dabbling in mobile development so the approach I am taking might make no sense.

My use case for this plugin is trying to replicate behaviour similar to the Spotify app:

Say I open an album view within my app, I first query an external API which responds with a list of songs for that album. Each song includes an audio stream URL.
This returned list of songs is stored inside of a Redux store, which resides in the UI isolate.

To me it seems logical to do this on the UI side as:

1. I can easily do all the error handling here for the HTTP request and inform the user if something goes wrong
2. I can still access my Redux store which helps me keep my state mostly in one place.
3. This action action is only ever taken when the UI isolate is active.

When a user tries to initiate play for one of the album items in the view, I put the entire album in the queue and start playing from the item that the user has tapped.

Right now, I accomplish that as follows:

1. Mapping my album songs to MediaItems
2. Sending the media items to the background isolate via a custom action. (As otherwise queueing is only possible with a single song at a time). A queue index is passed along to indicate where we start from.
3. At this point, I want to initialize play. However, the background isolate does not have an idea yet what audio stream url to play from. Here I have to note that unlike you assumed, I do not send the audio streaming urls as ids for the media items, as the same song can be in the queue multiple times. These are randomly generated ids unique per queue item.
   Because of this, I first send a map that contains mediaId's mapped to stream Urls via another custom action (This is the addMediaSources action I described in the OP, that I wanted to await before initiating play).
4. Now that the background isolate is both aware of my queue and the sources for each queue item, I finally call AudioService.play()

Using the state/queue/current item streams (that were previously callbacks on the connect call), I map the mediaItem's back to my application's song classes, and update the Redux store so all state is synchronized again in one place.

I understand that having the "server" be the source of all media is very useful for playing local files, but I'm afraid doing it that way for my use case would overcomplicate my situation, especially as I cannot share my store between the UI and background isolates, as far as I am aware.

If you have any feedback regarding my approach, I'd love to hear it.

Closing this issue now, as the new implementation works perfectly for my use case. Thanks again for the help!

[ryanheise]

Thank you for describing your use case in detail. I'd probably say to stick with the way you're currently doing it since it works now, while the other approach that I was suggesting actually might not be possible right now since the plugin is still not feature complete.