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 and selection 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.)
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
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
SELECTquery, i needed to amend the content provider with a new query-only pathALBUM_WITH_TIMES. I call it proof of concept, because in the present state, it has several deficiencies:projectionandselectionarguments.AnchorContract...