-
Notifications
You must be signed in to change notification settings - Fork 45
Description
This is related to #90 and #104, although it does not strictly solve those exact issues.
I added the following feature: In the main activity, the albums are first categorized as either of
- in progress,
- not started,
- completed,
and then displayed in that order (while keeping the order in each category as before).
I have an ad-hoc solution for this at hacky-albumsort: It simply uses the data from the cursor, calculates the above ordering, and feeds it back to the framework as MatrixCursor
.
While this works (i'm actively using it), it is not quite elegant. In fact, all the computations can be done by the database: for the baby case of a single album (DBAccessUtils::getAlbumTimes
), albumtimes shows how to ask the database directly to sum up the album times.
The general case is implemented in poc-better-albumsort. In order to execute the necessary SELECT
query, i needed to amend the content provider with a new query-only path ALBUM_WITH_TIMES
. I call it proof of concept, because in the present state, it has several deficiencies:
- As i never worked with this content stuff before, i have no clue whether i did this in the best or even a correct way.
It seemed to work in my tests, though. :) - The query code for the new URI completly ignores the
projection
andselection
arguments. - The aggregate column names are hardcoded in the query and should probably be packed into the
AnchorContract
... - The album categorization is forced on the user. There should be an "on/off" preference option for this feature. (The same caveat applies to the hacky solution above.)