Quote:
Originally Posted by kaufman
That sounds very nteresting, but the first thing I would ask for is actually an auto mark when I looked at the details and sort them by date marked and clear all marks. 
It's actually also a very big job that does a ton more than my original idea. Which isn't bad, but if my original idea is interesting at all, I may have come up with a simpler way to implement it.
[SNIP]
I would prefer this within cc, because my next step after looking at the list is to look at details again,not to open the book. |
So, order is as important as existence, which means that a boolean mark won't cut it. If marks are ordered, then why does one need Clear All? Simply to clean up?
I understand the suggestion as being "capture the last N books that had their details opened, including their order". Capturing book details visits is easier using the same technique as capturing opening the book, but unfortunately the rest of it is hard. Database access is built deep into book list/grid display. There is currently no way to display a list of books, sorted or otherwise, without getting that information from the database. Of course that could be changed, but doing so would be quite risky (a parallel mechanism) and a lot of work.
It would be easy to show the info in a widget, but it wouldn't be easy to have a tap on the widget open book details. And in any event that would be weird.
Assuming that the info is stored in the DB, then the existing mechanisms could be used. A book is considered "marked" if it has a non-null marked date, making that into a group similar to "Read". The list could be sorted by that date by adding a "Date marked" to the sorting drawer. Checking the box in book details would store the date, not the boolean. And this still leaves us with the "request to sync" problem.
Another approach similar to your first request would be to store the date book details was opened in the db, then add a sort that does the obvious thing. The sort could be named "Date accessed (CC)" or some such. This avoids check boxes and grouping, at the cost of a significant restriction in usefulness. It also probably avoids the requests to sync the info. And it is not hard to build.
I will keep thinking about this. I would want some evidence that the function would be useful to more than a handful of people.