Sorting by "Date Added": descending order?

[ChristianGruen]

I have a style with a single "Read & Unread" group and a single "Date Added" sort key. Grouping works fine, as well as sorting dates in ascending order. However, switching to descending order still sorts everything in ascending order.

[tfonteyn]

I don't know if it's applicable, but have a look at the 2nd issue here.

Date groups have a specific "feature"

[ChristianGruen]

I tend to believe it's not (I may be wrong): I am grouping by the Read/Unread state and I am sorting by date.

[tfonteyn]

just tried it, and it works fine for me.

-set style to the default "read/unread"

• edit style (so it gets cloned) with new name
• remove author,series so the single group "Read/unread" is used
• in the sorting field, set the default title to unsorted and set "date added" to "Descending"
• in fields displayed on book level, switch on "date added"
• back to the list, and all was correct.

Can you check these steps? Otherwise do a backup, extract the "preferences" and "styles" and upload (dont need the rest)

[ChristianGruen]

Perfect: Creating a new clone did resolve the issue! I will delete the old styles.

And I like the new menu item that allows me to directly edit the style.

[ChristianGruen]

…and I learned that sorting seems to work only if the value is actually selected to be displayed, as you indicated with step 4:

in fields displayed on book level, switch on "date added"

This may be surprising (particularly in the Grid View, where the value is not visible), but I guess there are good reasons? And it's no problem once you know it.

[tfonteyn]

Perfect: Creating a new clone did resolve the issue!

I think we covered this before, see the docs. Styles are cloned, they are not hierarchical. So if after you cloned a style, you modify the default, that style will not receive the updated config. Some day I might make them hierarchical, but then I will need to dump the whole "androix.preference" framework (you can guess... another component which google has abandoned).

guess there are good reasons

fairly simple, although maybe not well documented: any field used in sorting has to be "present". In theory this can be automated internally, but that means adding a 3rd field state "hidden", "used but hidden", "visible". There comes a point of too much overkill for too few benefits...

[ChristianGruen]

I think we covered this before, see the docs. Styles are cloned, they are not hierarchical. So if after you cloned a style, you modify the default, that style will not receive the updated config.

Yeah, I was aware of that (I had done my changes in the clone, not the default). I think the problem was (…I have already deleted my old styles to verify it) that the field to be sorted was not selected to be displayed in the List View. I somehow assumed that sorting and rendering are separated from each other. No need to invest time in this; it works just fine now.

[tfonteyn]

added to docs