CatimaLoyalty
Order by most commonly used
Requested through Google Play Beta reviews: https://play.google.com/console/u/0/developers/6021978940953178917/app/4973178217095258613/user-feedback/beta-feedback-details?reviewId=4b8709c3-70cc-43d2-9a63-724e21515058&corpus=BETA_FEEDBACK
"Would it be possible to count the number of uses of a card and offer a sorting option to put the most frequent used cards and top?"
It makes sense to me. However, needs some deciding on how to implement this.
We could keep a counter, which would be the easiest but can maybe be too difficult to move away from most commonly used. Say, you go to a grocery store every day for a year and then stop going, you'd have to use other cards more than 365 times before it shows up above them, which can take a long time.
A workaround for that could be to keep track of every date it is opened, but that could make the system fail for very rarely used cards (like once a month/year) and needs way more complicated logic.
I'm considering this low priority because users can already favourite cards to keep them on top and "recently used" + favourites comes pretty close to this functionality although it's not the exact same.
Thanks for putting this up.
The problem with the "recently used" feature is that it puts cards that have only been used once back at the top. Other cards that users use daily are moved to the bottom. I am happy to help with the implementation if that helps?
Sure! Let's keep it simple and just keep a counter of how often a card is used. If people complain we can always add a "Reset usage statistics" later, but no need for that now (less is more, keeping it simple helps people understand the app better).
Just got an email asking about this again. Sadly the database code has not gotten any cleaner since so I'm still not sure how to cleanly implement this.
I guess one way is to count how often a card is opened and also log the creation date of the card and sort all cards by (open_count / time since creation). Perhaps there are other easy ways, not sure. We should also consider changing the autoincrementing ID to be based on the creation time if safely possible so a future syncing feature would be easier to implement (less conflicts).