ankidroid / Anki-Android

AnkiDroid: Anki flashcards on Android. Your secret trick to achieve superhuman information retention.
GNU General Public License v3.0
8.67k stars 2.24k forks source link

Add anki stats provider (API) #9088

Closed moonlight83340 closed 3 years ago

moonlight83340 commented 3 years ago

Feature Description Is-it possible to add an anki stats provider ? It would be great to be able to access to the anki stats (anki streaks (days learned))

Describe the solution you'd like An access to the anki stats from the API.

Additional context Someone try to begin something like that once : https://github.com/ankidroid/Anki-Android/pull/5057 Example of stats : image

welcome[bot] commented 3 years ago

Hello! 👋 Thanks for logging this issue. Please remember we are all volunteers here, so some patience may be required before we can get to the issue. Also remember that the fastest way to get resolution on an issue is to propose a change directly, https://github.com/ankidroid/Anki-Android/wiki/Contributing

mikehardy commented 3 years ago

Hi there! This can be added, but someone will need to pick up #5057 which I started, and finish it. It's not a priority for me at the moment, sorry.

github-actions[bot] commented 3 years ago

Hello 👋, this issue has been opened for more than 2 months with no activity on it. If the issue is still here, please keep in mind that we need community support and help to fix it! Just comment something like still searching for solutions and if you found one, please open a pull request! You have 7 days until this gets closed automatically

bqv commented 5 months ago

Any chance of reprioritizing this?

david-allison commented 5 months ago

@bqv Are you interested in sumbitting a PR?

bqv commented 5 months ago

I'm interested in addon development - something to gamify AnkiDroid. I don't think I'm alone, so I hoped there might be some motivation on the team, but I don't know the codebase enough to weigh in on code

david-allison commented 5 months ago

I don't feel we have capacity currently. Unlikely within the next few years, but I don't oppose it on principle.

I suspect we'd expose the revlog data, rather than a specific "streak" metric

david-allison commented 5 months ago

Probably best to add a thread in: https://forums.ankiweb.net/c/ankidroid/suggestions/23

We've moved suggestions off GitHub recently

iamllama commented 2 weeks ago

Was about to make an issue on this 😅 A lot of addons work off of revlog data and having it available would allow them to be ported over

Not committing to anything just yet (because kotlin really isn't my strong suit), but would I be right in assuming that a good first step would be to have a StatsProvider (or RevlogProvider?) override query to take a direct SQL query via a URI (.../revlogs) and return a Cursor just like how CardContentProvider currently handles NOTES_V2? Following the work in #5057, insert, update and delete would be no-ops.

Would it also be ok to co-opt the existing FlashCardsContract or would there need to be an additional StatsContract to hold the constants (URIs and revlog columns for projection)?

david-allison commented 2 weeks ago

It would be worth discussing (architecturally) whether we want CardContentProvider to be the singular accessor to the API, or whether we would want a secondary content provider.

I haven't thought through this thoroughly, but I'd support aliasing CardContentProvider to Anki[Droid]ContentProvider, given that the API surface now covers significantly more than just cards.

In this case, the data would remain in FlashCardsContract

Just exposing query() seems sensible

The content provider should be an abstraction over the SQL, rather than directly accepting a SQL query: https://developer.android.com/guide/topics/providers/content-provider-basics#Query

@mikehardy pinging due to work on the following, which instead adds a second provider

iamllama commented 2 weeks ago

Another point I'd like to bring up for discussion is the issue of parallel builds (A, B, etc.) sharing the same FlashCardsContract.AUTHORITY as set in https://github.com/ankidroid/Anki-Android/blob/17748efe929a60ac4b1308b9a27358ae20f8a6e6/api/build.gradle.kts#L32

Right now, AnkiDroid proper seems to take precedence over AnkiDroid.A (unless there are factors i'm missing).

Doesn't seem that big an issue, but it could help ease development

EDIT: This seems to be already accounted for in the manifest, but not in the provider's uri matcher yet 🤔 https://github.com/ankidroid/Anki-Android/blob/17748efe929a60ac4b1308b9a27358ae20f8a6e6/AnkiDroid/src/main/AndroidManifest.xml#L659-L666

EDIT2: Opened a seperate issue for the provider uri under #17309

mikehardy commented 2 weeks ago

1- fixing the provider uri matcher to handle the .A .B (or -debug installs?) seems like it would be very useful 2- I'm okay with everything David said - it all seems sensible to me. My work on the stats provider was really just wearing my "Community PR sheepherding Hat" and trying to get something that looked useful merged, I hadn't thought deeply about it