Way to discern between user killing task and requesting stop

[yringler]

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.

[yringler]

I stand corrected - the stop callback is called when the task is killed.

[yringler]

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

[ryanheise]

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 androidStopOnRemoveTask option with an onTaskRemoved callback that you override in the background audio task, which you can implement to do what you like. I could perhaps have the default implementation just call onStop. Would this work for you?

For iOS, you will still need to still use your current approach unfortunately.

[ryanheise]

Actually, the closest backward compatible default would be an empty implementation.

Then, instead of androidStopOnRemoveTask you could override as follows:

  void onTaskRemoved() {
    onStop();
  }

The androidStopForegroundOnPause isn't going away, but it would no longer influence the onTaskRemoved behaviour, so you'd need to override it as follows to emulate the old behaviour:

  void onTaskRemoved() {
    if (!AudioServiceBackground.state.playing) {
      onStop();
    }
  }

I'm not sure what would happen if the androidStopForegroundOnPause were on but the app didn't override this method accordingly. I guess after 10 minutes out of the foreground state, the OS may decide to destroy the service without any callbacks being called to gracefully clean up.

[ryanheise]

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...

[ryanheise]

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.

[yringler]

@ryanheise, it seems that play/pause buttons on android in notification drop down aren't working anymore?
-Possibly this is my bug - I'm looking into it now.-Yep, called it - I had forgotten to update AndroidManifest.xml.

[ryanheise]

Did you update your manifest?

[yringler]

You are fast! Yes, I had realized after I posted that that I had forgotten that. Updated, just finished testing, works great!

[yringler]

Thank you!
This is the last thing I wanted to add to my audio task with just_audio plugin. After I use it in production for a couple weeks, maybe later this month, I'll open a PR to include it in the README or something

[ryanheise]

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.

[github-actions]

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.