Make list instructions generic in preparation for the detail list
update.
Detail views need their own instructions datatype, so this is meant to
allow that to be implemented without issue.
Just pre-emptively add support for TXXX variations of the non-standard
vorbis artist fields to the ID3v2 parser.
I'd imagine the naming convention will be similar between them, so why
not.
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.
Like the library package, move out tag information (Date/Album.Type)
into a separate package.
Date never really made sense as base-package information.
When the back button is pressed, clear the current selection before
navigating back.
This is something I was planning to do but then completely forgot about
when implementing multi-select.
Resolves#316.
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.
Fix a crash that would occur when trying to add music dirs without a
file manager to handle it.
Some users apparently disable the built-in file manager under the
assumption that the same intents will work with other file managers.
They do not, and so we need to handle that case and let the user know.
Band-aid a crash that would occur when the library is somehow
unavailable in the detail view. Now, if it's unavailable, the
app simple navigates away.
Not sure how this is happening, but I'd imagine it's some caching
shenanigans I need to fix by using volatile on any shared field.
Decouple DetailSong into two fields for the current song and current
properties.
Combining them was a technical decision that no longer makes sense,
and separating them makes life much easier.
Refactor the internal tag management portion of MetadataExtractor into a
new "Tags" object that can now be re-used in the ReplayGain system.
This also does a minor rework to the ReplayGain object to make it
totally self-sufficient.
Split off parsing-related components from extractor into a new parsing
module.
A lot of these methods are used in non-extractor code, so it makes more
sense for them to not be part of the extractors.
The code that is really extractor-specific can remain within the
extractor files.
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.
Add support for albums to have a range of dates.
Often compilation albums will have Songs released in different months
or years, so it makes some sense to show a date range rather than just
the ealiest date.
The only point at which the earliest date is still shown is in the home
view's popup, as maxiumum dates in a date range are not sorted by, and
so showing it doesn't make sense.
Strengthen Auxio-style UIDs.
These UIDs now leverage SHA-256 hashes with null values now writing
themselves as 0 in order to avoid possible message collissions from
other value arrangements.
Redocument the music module.
Much of it's documentation has drifted from reality as changes were
made, this commit completely redoes the documentation in order to
fix that.
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.
More miscellanious tweaks I can't categorize since I have no time.
It's mostly attempts at improving animation visuals an failing. Really
want to switch to material animations once I can finally get the things
working.
Redefine the meaning of activation across the app to align with the SDK
documentation.
According to the documentation:
- Activation -> A permanent kind of selection initiated by the user.
This means playback states, item selection, etc.
- Selection -> A transient kind of selection that can be added or
removed without user input. This includes things such as playing
indicators.
Redefine usages of selection and activation across the app to align
with this.
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.
