There is no documentation for wasUser and no documentation for when a track naturally ends

[SaadArdati]

For every wasUser parameter for the soundPlayer events, wasUser always always returns false.
It's unclear what it does. I tried triggering the events both from in the app and from the shade UI.

There's also no documentation for when a player naturally ends. Like a bolean for onStopped() that dictates if the player was stopped because the track ended or because something else stopped it. Or perhaps add a "complete" enum to the DispositionState enum class. "Stop" is too general and limits things like auto playing

[bsutton]

The wasUser flag is meant to indicate that a user caused the stop to occur.
If wasUser is false then the system naturally ended.

There is a bug in ShadePlayer that isn't setting wasUser

What if we changed the wasUser bool to an enum:

Completed - the audio completed to its end
User - the user stopped playback
Error - an error occurred causing playback to stop
System - ? if you call release the audio will be stopped. I guess this could be considered an 'App' stop. I cant' currently find any paths in the code that could result in the 'system' causing audio to stop (as apposed to the system pause/resume). So maybe we can ignore this one.
App - ? do we need this. If the api SoundPlayer.stop is called by the 'app' rather than as a user action. This is possible useful as it allows the app internally to differentiate when the callback occurs.

This enum could then also be reflected in the DispositionState as you suggested.

Thoughts?

[SaadArdati]

imo an event is more suited, like onComplete that only triggers when the track ends naturally. You gotta rename wasUser to something more descriptive though, like "isCompleted" or something. The Boolean doesn't really make any sense in events like onStart, onResume, onPause because you said it's when the system stops, but those events are not for stopping

[bsutton]

There are separate events for onPause, onResume etc. wasUser on the onStop was intended to differentiate between the playback ending naturally vs the user stopping the playback through something like clicking a 'stop' button in the ui. Part of the reason for combining the idea of onStop/onComplete into a single event was so the user only has to deal with a single event to do resource cleanup.

…

On Sun, 16 Aug 2020 at 16:29, SwissCheese ***@***.***> wrote: imo an event is more suited, like onComplete that only triggers when the track ends naturally. You gotta rename wasUser to something more descriptive though, like "isCompleted" or something. The Boolean doesn't really make any sense in events like onStart, onResume, onPause because you said it's when the system stops, but those events are not for stopping — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#28 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAG32OHPA5DWOBU6DXLADBDSA54GBANCNFSM4P6WS2CQ> .

[SaadArdati]

Imo that causes behavior that prevents granularity.
What are the separate events? I was under the assumption that calling any player function would cause it's respective event to fire, and under the assumption that the shade UI calls the same events for the same functions.
So player.pause() and clicking the pause button in the shade player would both trigger onPause event. Is this not how it works? I didn't see any other events.

[bsutton]

No the events are the same no matter whether you use the shade or not. I don't understand the source of your question as it doesn't seem to lead in from my prior statements.

…

On Sun, 16 Aug 2020, 6:54 pm SwissCheese, ***@***.***> wrote: Imo that causes behavior that prevents granularity. What are the separate events? I was under the assumption that calling any player function would cause it's respective event to fire, and under the assumption that the shade UI calls the same events for the same functions. So player.pause() and clicking the pause button in the shade player would both trigger onPause event. Is this not how it works? I didn't see any other events. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#28 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAG32OH33JRFGAQO3DQCYBDSA6NEHANCNFSM4P6WS2CQ> .