Lots of cruft has built up with my dimensions, partially collapse them
into a more consistent set of re-usable dimens (within reason) and try
to delegate to MDC as much as possible.
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)
Vendor BottomSheetDialog(Fragment) with the inset fix that prior used
reflection.
Apparently said reflection breaks down and crashes the release build
somehow. So now I just have to hastily patch BackportBottomSheetBehavior
and vendor another 1000 lines of MDC code.
Really considering making a PHP sadness-like blog solely for android
at this point.
Don't disable bottom sheet inset calculations and use the expanded
state hack to mitigate for the peek height calculation, instead,
just clobber the window inset routine to fix the peek height while
not applying the padding. The expanded hack still remains, but is
now relegated to the cases where the 16:9 keyline breaks down.
Make sure that we don't drop selections or playlist edits when we
navigate to dialogs, this time achieved through a more general
navigation listener implementation than prior.
Fix an issue where the options in MenuDialog could not full scroll for
an unknown reason.
Derived from some absurd issue where BottomSheetBehavior dislikes
ConstraintLayout's spacing and decides to improperly allocate enough
space for the RecyclerView to scroll.
Add a dialog that shows menu information as a bottom sheet instead of as
a PopupMenu.
This did not take as much finessing of BottomSheetBehavior as the main
playback UI framework did, just some style redefinitions.
Move the music editing state to the toolbar.
This should be signifigantly clearer than prior, at the cost of it's
"universality" implying that renaming should be available when it
actually won't be.
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.
If the user clicks on the playback bar in any context, including the
queue view, open the playback panel.
This adds another means to closing the queue that does not involve
swiping.
Resolves#402.
FINALLY update to MDC 1.7.0. After over half a year.
I have been continually blocked by doing this due to this absurd ripple
bug that was so continually frustrating. Today, I finally figred out
how to hack a fix in by using R E F L E C T I O N and manually
disabling the bugged code path since google apparently can't be bothered
to fix it.
Now, you might wonder why I didn't update to 1.8.0. That is because
there is ANOTHER RIPPLE BUG. THIS TIME WITH THE TAB LAYOUT. AND ONLY IF
IT'S IN A COLLAPSING TOOLBAR LAYOUT. Can't wait to finally use the new
1.8.0 features in December!
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.
Use @Binds more heavily with dependency injection, whee currently
reasonable.
Reduces the amount of boilerplate "fun from" functions that need to be
used.
Parallelize music loading.
- Queries over Media DB and Cache are ran parallel
- MediaStoreExtractor can now continue extracting songs independent
of MetadataExtractor's task pool capacity
- Library and Cache are saved in parallel
Resolves#343.
This should result in some pretty signifigant performance gains
due to the operations now being ran in parallel instead of
sequentially.
Switch to item decorations to manage header dividers.
This is much more reliable than encoding it in-data. Only cost comes in
that it forces me to backport yet another component since I still can't
update MDC after over half a year.
Make all adapters relying on diffing unified into a DiffAdapter
superclass that can then accurately respond to the new
UpdateInstructions data.
UpdateInstructions is still not fully used everywhere, but will be
soon.
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.
Make all list listeners operate on generic values.
Wanted to do this for awhile, but couldn't figure out how to get the
listener to work with sub-typed listeners until I learned what the in
keyword actually does. This removes a ton of type-checking boilerplate
that it's not even funny.
