Rework Sort again into a new class that leverages a better Mode design
and static comparator instances.
This somewhat improves efficiency, but is also far easier to work with
and has far less footguns with adding new sorts.
Add new shortcut utilities for collecting StateFlows in a safe manner.
The priamry addition here is collectImmediately. collectImmediately
just calls block with the existing value initially, which helps remove
a good amount of bugs regarding state initialization. Sure, it is a bit
inefficient given that it will also initialize on startup, but this is
okay.
The other utilities are the same, but simply remove the launch
boilerplate.
Add a new "Detail playback mode" option that allows one to configure
what selecting a song will do in an album/artist/genre.
This is mostly a clone of the prior setting, just in a new context.
Resolves#164.
Add a utility to easily work with lifecycle-dependent fragment objects.
This reduces the code duplication required to maintain objects that
would leak after the destruction of a fragment. We normally would not
do this as a delegate, as that usually entails some lifecycle wizardry
that can easily break and crash the app in esoteric situations.
However, this this just extends the normal lifecycle without watching
any state, it seems to be pretty safe to use.
Rework the preference classes to reduce the horrible bloat of the
recursivelyHandlePreference function.
This was mostly implementing new methods into IntListPreference and
adding a new preference to represent the weird, "generic" dialogs that
are used at points. While some preferences still need to be tweaked in
recursivelyHandlePreference, it is nowhere near as bad as it was prior.
Revamp the shared object SettingsManager into a standalone utility
called Settings.
This makes many things easier in Auxio. It completely unifies the key
format that we use (Android Strings instead of Java consts), eliminates
the pretty dumb initialization method that we use, and eliminates the
dubiousness of holding a Context-related utility in a global field.
The only cost was having to migrate even more ViewModels to Android
ViewModels. Whatever.
Add synchronized calls to all mutations in PlaybackStateManager.
I mean, it is global mutable state modified on several threads. This is
the safest option to remove a bunch of horrible bugs.
Add a controller role to PlaybackStateManager.
The controller manages the internal player, and acts as an intermediary
between other internal objects that want to modify the player, but
don't actually have access to it.
This makes a bunch of future changes far easier.
Add a shortcut to shuffle all songs.
This is likely the only static shortcut Auxio will have. Top tracks
and recently added are completely useless for me, so I will never
add them. I may add more dynamic shortcuts for recently played items,
however.
Note that we use a basic black shuffle icon here. I will not add icon
customization to these shortcuts.
Fix a visual issue with the queue animation where the playback view
will still slightly show.
This was caused by the lack of a background in the queue fragment UI.
Use ServiceCompat.stopForeground instead of stopForeground.
This is preliminary preparation for Android 13. I can only change SDK
versions however when the Android Gradle Plugin makes a new release
though.
Only show codecs in the "format" field, if we are able to extract them.
This is primarily for consistency, as there is no way for us to
determine the container format outside of an extension (which could not
be sane).
Completely rework the excluded directory system into a new
"Music Folders" system.
This is implemented alongside a new "Include" mode. This mode
allows the user to restrict music indexing to a parsicular folder.
I've been reluctant to add this feature, as having two separate
options seemed bad. This resolves it by effectively packing whether
to include/exclude directories into a single option.
Resolves#154.
Add a non-queue version of the song menu to the playback panel.
While the original UI flow of clicking on each TextView to navigate
to a particular item is still present, this simply makes the action
more clear to a first-time user.
Remove scientific notation from the auxio icon, allowing me to
reintroduce it to the notification icon.
API 21 does not support scientific notation in vector drawables, so we
need to remove them from the icon for it to not crash the system ui.
When ReplayGain is not needed, use ByteBuffer.put in favor of a for
loop when doing a simple copy.
ByteBuffer.put is highly optimized and far more efficient than a for
loop.
Add a new view called ImageGroup that will handle all advanced image
hacks from now on.
This includes the indicator (which is now animated), any selection
indicators, and the weirdness of the album song image. All of that
is now handled by ImageGroup. This is the culmination of probably
a day and a half of wrangling with android insanity and having to
remove a lot of what I liked about the indicator in order to make
this work on a basic level.
The only major bug I am currently aware of with this is that the
indicator is bugged out on Lollipop devices due to bad vectors.
Again.
I never want to do this again. I cannot believe that adding a basic
indicator took this long and required so much stupid hacks and
inefficient code. And then google wonders why android apps are so
visually unappealing and janky and laggy. Hm. Must be that devs aren't
using the brand new FooBarBlasterFlow library!
Add a playing indicator to cover art.
This is simply to improve the general aestethics of this view. Of
course, the current way I implement this is incredibly stupid and I
plan to replace it.
Completely rework the way Auxio handles icons.
This is mostly two changes:
1. Removing ImageButton/StyledImageButton for MaterialButton. This is
done by abusing MaterialButton's theming options to make it only show
an icon.
2. Standardizing icon sizes into small, medium, and large categories.
Small is the default, Medium and Large are for edge-cases like the
playback icons which look horrible at 24dp.
3. Abusing the Toolbar to make it follow Material 3 guidelines. This
mostly involved removing the strange icon sizing and correctly padding
the view.
4. Reworking the playback bar to use more, smaller icons, making it
more like a Toolbar in the process (which I like).
Supply a view to WindowInsetsCompat.toWindowInsetsCompat through all
calls in the app.
This does nothing, but it would resolve future bugs if I were to use
the most exotic window inset types.
On the playback par, pick the larger inset out of the system bar
insets or system gesture insets.
This is to fix an issue where android just does not provide correct
gesture insets on Android 12L, and [maybe???] fix what is going on
in #149.
Rework PrimitiveBackingData into SyncBackingData.
Google says that you should not use DiffUtil on the main thread, as it
is far too slow. In practice, the time it takes to diff is negligable,
even more so when costly diffs are filled in with a replace call
instead. Not only that, but switching to a synced list differ fixees
the horrible nightmare that is the queue adapter. Generally a win-win
for most use-cases in Auxio.
Improve Indexer's state management by splitting up the current loading
state and the last response.
This is intended to resolve a bug where if the UI task and
IndexerService are both killed, the Indexer state would become
indeterminate and the library would not show. Resolve this by keeping
track of whatever the last completed state was and falling back to it
whenever the loading process is canceled.
Add a dedicated service towards the loading of the music library.
This new service was created for two reasons:
1. Music loading is slow and resource-intensive, so putting it on the
ViewModel layer just didn't seem right and made it vulnerable to the
OS simply stopping the loading process.
2. For automatic rescanning [#72], there must be something watching
the music library and waiting for a change in the background. This
would require a service as that is probably the least insane way to
do that kind of background work.
I have no garuntees how viable the service might be. If anything, it
might be halted by some insane android restriction or issue that
makes it more or less impossible to use for most apps, and I will have
to largely drop truly automatic rescanning.
Rework loading management into a new object, Indexer, which should act
as the base for all future loading changes.
Indexer tries to solve a two issues with music loading:
1. The issue of what occurs when tasks must be restarted or cancelled,
which is common with music loading.
2. Trying to find a good strategy to mediate between service and
ViewModel components in a sensible manner.
Indexer also rolls in a lot of the universal music loading code
alongside this, as much of MusicStore's loading state went unused
by app components and only raised technical challenges when reworking
it.
Fix two major highlighting bugs based around the janky and stupid way
I would handle highlighting previously.
Previously, I would index the views of a RecyclerView in order to
highlight viewholders. In retrospect this was a pretty bad idea,
as viewholders could be in a weird limbo state where they are bound,
but not accessible. I mean, it's in the name. It's a Recycling View.
Fortunately, google actually knew what they were doing and provided
a way to mutate viewholders at runtime using notifyItemChanged.
And the API actually makes sense! Wow! Migrate all detail adapters
to a system that uses notifyItemChanged instead of the terrible
pre-existing system.
Fix a state restore issue that would cause the parent to restore
incorrectly.
At some point, I accidentally used the index for the PlaybackMode field
when restoring the playbackState. This resulted in the playback mode
effectively reverting to ALL_SONGS and causing a number of subtle
issues.
Fix a regression where media button controls would no longer work
with GadgetBridge.
In 4a79de4, I assumed that my code was redundant, as there should be
some kind of reciever handling media button events already. I was
completely wrong. Re-add the reciever code (with extra checks) to
make controls work again.
Switch from LiveData to StateFlow.
While LiveData is a pretty good data storage/observer mechanism, it has
a few flaws:
- Values are always nullable in LiveData, even if you make them
non-null.
- LiveData can only be mutated on Dispatchers.Main, which frustrates
possible additions like a more fine-grained music status system.
- LiveData's perks are exclusive to ViewModels, which made coupling
with shared objects somewhat cumbersome.
StateFlow solves all of these by being a native coroutine solution with
proper android bindings. Use it instead.
Move the loading screen into the home view.
Previously, we would use a Snackbar to track the music loading state.
This ended up being a pretty stupid and buggy idea, and would get even
worse with the new music loader changes. Instead, we re-implement the
loading screen into the home view to generally be more sane and
extendable compared to previously.
Make addCallback calls (or similar) initalize the caller by calling the
specific callback methods.
This is primarily intended as a fix to an issue where the music library
would actually reload during a warm start. This is extremely bad, but I
hope it doesn't make the app too unusable until the next version.
Move out the MediaStoreCompat interface into a full interface called
Backend.
In preparation for direct metadata parsing, it would be useful to
create some kind of object system to properly handle the capabilities
of each metadata indexing mode. Backend fulfills that by allowing
each object to implement their own query and then loading routine.
This system is designed somewhat strangely. This is firstly because
the ExoPlayer metadata backend will have to plug in to the original
MediaStore backend, so making methods more granular allows the
ExoPlayer backend to avoid some of the stupid inefficiencies from
the actual MediaStore backend, such as the genre loading process.
We also want to separate the steps of loading music in order to
more adequately show the current loading process to the user in
a future change.
Implement a safe slider wrapper that does not crash with invalid values
as often.
Slider is a terrible component that is not designed with Auxio's
use-case in the slightest. Instead of gracefully degrading with invalid
values, it just crashes the entire app, which is horrible for UX.
Since SeekBar is a useless buggy version-specific sh******ed mess too,
we have no choice but to wrap Slider in a safe view layout that
hopefully hacks with the input enough to not crash the app when doing
simple seeking actions.
I hate android so much.
Resolves#140.
Create separate routines to parse disc and track numbers in the most
optimal manner.
On API 30 (Android R) and above, ensure that we are using the superior
CD_TRACK_NUMBER and DISC_NUMBER database fields, while below API 30,
stick with the normal TRACK field.
Revert the introduction of the thin/tiny widgets, but keep the new
cover layout I created while working on them.
There is simply no way I can cram controls and metadata within the
size bucket that the thin widget occupies. I have decided to give up
and revert the widget to it's old form.
I understand why the thin widget is not appealing. However, the sizing
at which a widget can properly accomodate a taller widget is just too
precise and not really large enough to justify it's existance.
Also use the gesture insets on playback panel.
Turns out when the panel uses normal insets, the playback panel is
extremely close to the system bars. Fix this by using the bigger
gesture insets.
Resolves#137.
Hack around more insane lollipop bugs, such as:
- The angular auxio icon crashing the system UI
- Optimized icons being corrupted
- Setting image alpha not working properly
I really wish I could drop support for this horrible version, but I
either have to wait for a major library to drop support or for the
usage numbers to reach 1%.
