-
-
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
Way to discern between user killing task and requesting stop #344
Comments
I stand corrected - the stop callback is called when the task is killed. |
That isn't enough for my use case, because by convention if the user clicks a stop button, user expects position to be reset to start, but if user swipes away task, the expectation is that the current position will be saved. Updated initial comment and issue title |
Hi @yringler I'm not sure if this is possible on iOS but on Android it could support it. I think the way to go is to replace the current For iOS, you will still need to still use your current approach unfortunately. |
Actually, the closest backward compatible default would be an empty implementation. Then, instead of void onTaskRemoved() {
onStop();
} The void onTaskRemoved() {
if (!AudioServiceBackground.state.playing) {
onStop();
}
} I'm not sure what would happen if the |
Sorry, what I was talking about above was handling swiping away the task in the task manager rather than swiping away the notification. Still, it may be useful to have callbacks for both of these. Again, I'm not sure exactly how this would work on the iOS side... |
I've just implemented the above in git master, and also added another callback: void onClose() {
onStop();
} This will be called when the user swipes away the notification (on Android). Unfortunately this is a breaking change, and you must update your manifest file to point to a different broadcast receiver: <receiver android:name="com.ryanheise.audioservice.MediaButtonReceiver" >
<intent-filter>
<action android:name="android.intent.action.MEDIA_BUTTON" />
</intent-filter>
</receiver> Let me know if it works for you, or if you uncover any bugs. |
@ryanheise, it seems that play/pause buttons on android in notification drop down aren't working anymore? |
Did you update your manifest? |
You are fast! Yes, I had realized after I posted that that I had forgotten that. Updated, just finished testing, works great! |
Thank you! |
Glad to hear! I've recently been rewriting the README. It might be good to wait a couple of weeks as I'm still restructuring things, but hopefully I can make it simpler, briefer and easier to skim through for people who want to get going quickly. |
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. |
Is your feature request related to a problem? Please describe.
I want to keep track of where a user is holding in an audio class. I can save the current location when user pauses, skips, changes to another class.
But if user kills the background service, for example by swiping away the notification if it's paused, I can't differentiate between whether the user clicked a stop button, which would mean resetting the position, or the notification was swiped away.
Describe the solution you'd like
A way to know when the audio service will be killed, not due to user clicking a stop button.
This could be another callback on
BackgroundAudioTask
or a static stream or future in AudioServiceBackground. There are probably other ways.Describe alternatives you've considered
I considered updating the position every 5 seconds, so I'll never be that far off. But ti's not a clean solution, besides for not being accurate.
The text was updated successfully, but these errors were encountered: