Break up the monster AuxioService into sub-classes, keeping just the
major lifecycle and music stuff in AuxioService for now (which will
likely be split out itself eventually)
Apparently:
1. Some OEMs don't actually autocrop to rounded corners
2. I was not correctly using the right corner radius attributes in the
first place, making it inconsistent.
Let's fix that.
Closes#730
Playback and indexing now occur in the same service through a new
bridge called AuxioService.
AuxioService contains the existing service instances as Fragment
implementations, and then forwards typical service events to them
(albeit this will drift more and more as I continue to deal with
lifecycle issues).
This should be the first step in enabling true service independence,
as it means that the service will now immediately initialize and load
music as soon as possible.
Add a 1x3/1x4 widget that displays the cover and controls
Also requires another widget type that just displays controls to
accomodate landscape devices.
Resolves#420.
Mirror the last playback state of the holder inside
PlaybackStateManager.
This is generally more efficient and will enable better handling of
when state holders attach and detach.
Add an option to restore the old 1:1 crop behavior to the app.
Some people think this looks better, some people like to have youtube
thumbnails in their APICs. Can't really be opinionated here.
Make the app UI properly handle album covers that are not 1:1, instead
of just cropping them.
This required switching to Coil's rounded corners transformation
outright so that the non-1:1 image can sit inside the CoverView in a
way that actually looks good
I'm pretty confident this will work, but there might be some edge cases
since coil's transformation is really finicky.
Resolves#355.
Refactor the music name implementation to do the following:
1. Unify normal and sort names under a single datatype
2. Handle arbitrary-length digit strings
3. Ignore puncutation regardless of the intelligent sort
configuration, as it is trivially localizable.
Resolves#423.
Co-authored by: ChatGPT-3.5
Refactor the weird picker god module into specific sub-impls in
playback and a new navigation package.
I cannot keep this unified. The needs are too different among each
picker. Better to keep it separate, especially in preparation for
the playlist dialogs.
Re-add the fine-grained updates that were removed prior due to state
concerns.
This time they should be safe enough to use, as the differ has been
fully vendored. The change is not complete enough however, as the queue
view has not been properly ported to use these updates just yet.
Use dependency injection with Coil.
This allows me to use the coil-base artifact which should remove a bit
of superfluous dexcode, assuming dagger uses less. It probably doesn't.
Fully use DI in the playback module.
Previously use was split among different components that could leverage
injection, and components that could not. This fully unifies them.
Use @Binds more heavily with dependency injection, whee currently
reasonable.
Reduces the amount of boilerplate "fun from" functions that need to be
used.
Finally give up and use Room to persist the playback state.
This should make dependency injection much easier, and the
implementation isn't exactly the *worst*, as I was already using
"raw" data structures for the old queue database.
Switch back to using settings-specific listeners rather than the
SharedPreference listener.
Again, this is due to the need to decouple android code from settings.
It also allows us to fully obscure the details of what settings we are
actually working with.
Decouple the settings god object into feature-specific settings.
This should make testing settings-dependent code much easier, as it no
longer requires a context.
Allow past and currently playing queue items to be edited, instead of
just future queue items.
This was a somewhat requested feature that was impossible with the
prior queue system. With some fixes, the new queue system can now be
used to do this.
This even works with edge cases like removing the currently playing
song. Albeit, it's likely that more bug fixes and testing will be
needed.
Resolves#223.
Implement a new heap-based queue system into the app.
Unlike the prior queue, this one no longer keeps one canonical queue
and then simply swaps between shuffled and ordered queues by
re-grabbing the song list currently being played. Instead, the same
"heap" of songs is used throughout, with only the way they are
interpreted changing.
This enables a bunch of near functionality that would not be possible
with the prior queue system, but is also really unstable and needs a
lot more testing.
Currently this commit disables state saving at the moment. It will be
re-enabled when the new queue can be reliably restored.
Rework some of the taped together ways context-dependent objects were
replied on in-app, such as removing redundant constructs and extremely
hacky lifecycle mechanisms.
