Redocument the detail, home, image, and list modules.
Much of this project's documentation has drifted from actual
functionality, and newer code is pretty sparely documented.
This commit seeks to rectify that by redocumenting every source
file in this project.
Remove childish wording/diatribes from the codebase that were added
when I was younger.
I'm an adult now. I have to make this repository at least somewhat
professional.
Rework the music picker system to be a reactive, viewmodel-based system
instead of a janky UI system.
This should make it much easier to maintain and extend in the future.
Merge DisplayMode and PlaybackMode into a new class called MusicMode.
Both of these datatypes represented similar things, and thus it's much
easier to make them the same datatype. Moreover, it makes the
forthcoming addition of the music selector much easier if the same
datatype was tied to the representation of music.
This commit also moves around things around the project to be slightly
more coherent.
Completely rework the ID system to pave the way to MusicBrainz ID
support and greatly increase ID integrity in general.
This changeset removes the old ID field, an emulation of a polynomial
hash that was used in all items, and replaces it with a new type called
UID that is specific to Music. Other types just use plain equals now,
and most instances of "id" to check for equality in the app have either
been inlined into an equals override or removed outright.
The new UID format is as follows:
datatype/format:uuid
Datatype is a tag that is just the lowercase tag name. For example,
"song". Format is the program that created the UID. auxio will be an
md5 hash, and musicbrainz will the a musicbrainz ID extracted from a
file. UUID is the uuid itself.
This is much more reliable and extendable than the old ID format. This
will also be the last time I break compat with old ID formats. From now
on, a legacy UID field will not be included to enable backwards compat,
when the time comes for a breaking change.
Auxio tried to leverage built-in android string attributes for Ok and
Cancel while still completing them for other translations that were not
supported by the OS.
Turns out this was a terrible idea when I switched to Weblate, which
has no knowledge of this trick and could lead to a misleading
translation value. Remove it.
Resolves#215.
Leverage min heights for the playback layouts instead of the land
modifier.
This prevents an issue where some split-screen displays won't use the
correct "compact" layout.
Add a split playback UI in landscape mode.
Apparently the mere act of doing this also fixes the infurating
window inset issue I previously did either. Odd.
Use MaterialFadeThrough in the search transition and a Z-axis
transition in the detail views.
This is more semantically correct than the previous transitions.
Remove useless id fields from Headers, replacing them with vlaues
related to their string resource.
String resources and disc numbers are more or less garunteed to be
unique in Auxio's context.
Fix more bottom sheet issues regarding the queue sheet.
Guess I brought it upon myself for nesting bottom sheets like this in a
way that I doubt the behavior expects.
Fix an issue on some devices where bottom sheet transitions would not
initialize correctly.
Turns out I can't try to do transitions using the callback and simply
initalizing them on startup. Apparently on some devices,
CoordinatorLayout will simply not lay out until some arbitrary point
past onResume. This breaks our transitions.
Fix it by using a pre-draw listener instead. I cannot believe I have to
do this.
Re-implement the queue, now leveraging a bottom sheet too.
This makes the queue much easier to open, and actually plays along with
the new transition system. I really hope this doesn't have a stupid
gotcha that ruins the UX. Please. Please. Please.
Use BottomSheetBehavior with the playback sheet.
This is the result of two weeks of painful hacking to get a working
implementation that did not immediately have a brain aneursym. It
also requires me to still vendor BottomSheetBehavior for the time
being. However, this greatly reduces technical issues on my end and
allows the addition of new playback UI concepts, while still
retaining the UI fluidity of prior.
Temporarily remove queue navigation, as it can no longer really fit
with the new transitions.
This will eventually be replaced with a queue bottom sheet, implying
that I can abuse one into working.
Fix several issues with the bottom sheet implementation, mostly
relating to what occurs when the bar is hidden.
Previously, if the bar was hidden and then re-shown, it would not be
visible, and you could override a hidden event with another tap. These
are now both resolved by removing a stray visibility assignment and
replacing the old drag checks with a new isDraggable attribute.
In the future, I hope to abuse BottomSheetBehavior into not being a
pile of garbage and replace this system once and for all.
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.
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 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.
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.
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.
Rework the tiny widget to cram even more information into it.
The tiny widget is nominally meant for edge cases like exceptionally
small screens or landscape mode, but apparently it's triggered on some
devices in normal use because of platform fragmentation and OEM insanity.
Update the tiny widget layout with some new buttons in order to make it
more usable in mnormal use. This is still nowehre near ideal. For
example, when triggering the layout on my device, it ends up squishing
the buttons. But it should probably work better outside of those edge
cases.
