-
-
Notifications
You must be signed in to change notification settings - Fork 481
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support bi-directional custom actions #181
Comments
Any Updates on this? |
This is definitely high on my priority list. I plan to take a crack at it on the weekend. There have always been workarounds using Dart's standard APIs to send arbitrary messages between isolates using send/receive ports (you may find mentions of the approach in past issues). |
Hi everyone, Is it possible to support partially bi-directional actions first (by changing the |
Hi @lkho You can't send futures through a method channel. I am wondering what API would be most appropriate for this. Currently all communication from the background task to the UI is via streams, so my current thinking is to make a custom event stream. By the way, I have added an FAQ entry in the wiki for how to use the standard isolate APIs to send messages if you need something immediately. |
I mean by changing this line to return the result (and if the result is a audio_service/lib/audio_service.dart Lines 852 to 853 in 19712fa
i.e. return task.onCustomAction(
then we can call Similarly for all other audio_service/lib/audio_service.dart Line 762 in 19712fa
I know this is not a perfect bi-directional communication, but at least the background task can passively react to some action and return some info. |
I see, that could be useful as well. Maybe would integrate both ideas into the API going forward. |
Update! I've just implemented bi-directional custom actions on git master. (I haven't yet implemented @lkho 's good suggestion, but that can be considered eventually too.) Probably a better way to describe this is that "actions" are the messages you send to the background audio task, and "events" are what you listen to coming back, so this feature is really "custom events". To send a custom event from the background to the UI, call: AudioServiceBackground.setCustomEvent(whatever); And in the UI, listen to the P.S. Apologies for the huge wait. I know what it's like to wait a long time for an issue to be addressed, and I originally hoped to not let that sort of thing happen on this project, but hopefully the FAQ on |
Cool! This for me personally removes some boilerplate code to start up the audio service and play a playlist/station. Hopefully it's similar for everyone else that does those kinds of things. |
I've now also implemented @lkho 's suggestion. I have tested this on Android, but not yet on iOS. |
Thanks very much! :) |
I've finished testing this on iOS (seems to work as intended), and it is now released in 0.8.0. |
in I want to know that is it possible to make a method in because currently we only can send one type of ``` |
If you want the reversed direction, you can use |
I know that . |
@mohammadne Do you mean you prefer actions rather than events? If so, I'm not sure why since class MyEvent {
String name;
dynamic args;
} And send instances of this as your custom events. And since you can invent your own class, you could even add fields that are more specific to your app, and you could even create subclasses for different types of event, etc. |
Hi @ryanheise I mean that we have a similar approach in both directions. |
There are really two issues here. I meant that But the other issue is that in one direction we use "actions" and in the reverse direction we use "events". That is intentional because when the UI communicates with the background task, it does so synchronously. That is, it says "DO THIS NOW!". E.g. |
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs, or use StackOverflow if you need help with audio_service. |
Note to self: Implement bi-directional custom actions. This essentially means adding a mechanism to send arbitrary messages from the background task to the UI.
The text was updated successfully, but these errors were encountered: