-
-
Notifications
You must be signed in to change notification settings - Fork 627
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
Confusing AudioPlayerState vs AudioPlaybackState #2
Comments
I appreciate the suggestion. I had the same naming challenge with audio_service, actually. In the native Android APIs, they call the data structure "PlaybackState" and the enum "State" which shows that I am not alone in this struggle. I definitely want to keep the word 'state" since it is so prevalent in existing media APIs, and the enum itself should definitely be called state because it is a state machine with state transitions. Basically it's a FSA. The word "status" is not suggestive of it being an FSA. However, I'm open to changing the name of the struct. I think probably a good suffix could be "event" since events are triggered in response to certain things happening and they typically encapsulate multiple pieces of data. So we could have PlaybackState for the enum and PlaybackEvent for the struct. Would that work for you? |
Yes. Good points, good idea. |
I've just renamed |
Published. |
Awesome! I just updated to 0.0.6, it makes a big difference. Thank you. |
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 just_audio. |
Developer ergonomics
As I was switching to use this library, I found myself losing track of
PlayerState
(i.eplayerState
,playerStateStream
) andPlaybackState
(i.eplaybackStateStream
). I couldn't remember which was the enum and which was the class, and had to keep on checking.I suggest that the core issue is that state is a generic word (as in the phrase, "maintaining app state"), and differentiating is relying on the words "player" and "playback", both of which aren't so strongly associated with the data their representing.
I suggest that the API and docs be updated to use "Status" for the enum, and "Details" for the object.
My reasoning:
That would give us, perhaps
playerDetailsStream
,playbackStatus
,playbackStatusStream
, etc.Further, I suggest that the split between "player" and "playback" is additionall information which has to be interpreted by the developer, while not adding that much additional clarity. Perhaps the "prefix" should be a standard "audio", giving
audioDetailsStream
,audioStatus
,audioStatusStream
, and classAudioDetails
and enumAudioStatus
.This is my personal opinion, and this is more of a discussion issue (at this point at least).
If you agree, this is something I could try my hands at making a PR for, although it may be a few days until I can get around to it.
The text was updated successfully, but these errors were encountered: