Split mutations method out of TrackSelection
`TrackSelection` had mutation methods which were to be called only internally by ExoPlayer components but were exposed in the public `Player` interface. The mutation methods have been moved out of `TrackSelection` to a new class `ExoTrackSelection`. Current track related read-only method have also been moved out, because they are actually something quite unclear. Even for a single item playlist, it's the track being buffered rather than the track being played, which is unclear. But when you have a playlist it starts to get really confusing, because if the next item is being buffered, then it's actually the last track to be buffered in the currently playing item. As a final aside, the implementations don't do proper thread synchronization to ensure visibility of updated state by the calling thread. Exposing those mutable methods in the public `Player` interface was problematic because they leaking internal concepts of `ExoPlayer`. This is also required to minimize the `Player` interface for long term stability. `ExoTrackSelection` is a subclass of `TrackSelection`. This is not ideal as an `TrackSelection` implementation could break the current immutability. This was done in order for this refactor to be simpler. A future patch will fully split the two classes. All `MediaPeriod` and `Sources` had to be updated to use the new `TrackSelection` dynamic aspect class name. An alternative would have been to break ExoPlayer's public API, keeping `TrackSelection` as the dynamic aspect name, and calling the public static aspect class `TrackSelectionState` or similar. Nevertheless, while it would have impacted less files, it would have many more small apps and casual users of ExoPlayer. #player-to-common PiperOrigin-RevId: 353637924
Showing
with
632 additions
and
633 deletions
Please
register
or
sign in
to comment