It should do, yes - lesson filtering should theoretically use the same filtering logic as the advanced search, which works properly with kana vocab
Sadly it’s somewhat hard to test properly right now with the limited data and only one kana vocab example. I’ll try modifying the subject item in true database to pop it back into the lesson queue when I get time though, don’t see any reason it wouldn’t work.
Plus side, I’ve manually edited API responses enough now to have a fair amount of confidence in the resilience of the new background worker I put in.
Ah, gotcha - yeah, thinking about it I’ve already made far too many changes to what is the current master branch for it to be clean in relation to the upstream, so there’s probably little value. Maybe just a main and feature branches then - sorry, I’m very much showing my lack of git experience here
Links, changelog, instructions for dealing with Play Protect warnings about unknown apps, etc. all added to the original post. I’ll keep this process going forward, so that there’s always one place to look for information ^-^
I feel ya! Getting things back how you like things is already the worst migration feelings, especially if you’ve tweaked things to be super personal. If I could think of a way to get that data out of the old database and get it into the new one, I totally would, but that’s somewhat out of my power, alas
This is incredible!!! Thank you so much for bringing this app back to life, it has become such an integral part of my learning experience and I was really nervous of what was going to happen when the kana update hit. I will keep an eye out for the Play Store version and am even looking forward to migrating my settings over, hahah. Do you have any plans to take donations for your work? Would be happy to support the effort, but not sure if the license allows for it?
I appreciate the thought, but no, really - I can’t take credit for any of the groundwork and it wouldn’t feel right to accept any money from anyone, but thank you
Do you foresee yourself adding any other functionality to the existing feature set, beyond the kana update? One thing I tend to miss from the web client is the more in-depth review forecast:
There’s a nonzero chance something like this existed in FD and I just never found the right toggle, but I always like on the site how I can see how many items will be dropping on such a granular level. Would it be worth filing a ticket about in GitHub?
There’s a good chance I’ll at least give it a go - I’m not a proper developer and this is my first time working with Java properly, so it’ll be a journey, possibly a slow one, but I’ll do my best, hehe
Just downloaded the .apk and installed. Works perfectly fine on my Galaxy S9. Thank you so much for keeping this app alive! Also, I really like the icon
@machinaeZER0 There is a setting under ‘Dashboard settings’ → ‘Show 24h review timeline’. This should display the information you are looking for. There are also a lot of settings for the timeline, including the ability to change the time range (from 12h to 14 days). Although, it is displayed in a graph, rather than a list.
Aha! You know the app better than me, hehe! I only ever used Flaming Durtles for one short period at the start of lockdown when I was using my a Tab S4 (that I only had from work as an ITSec testing device), I’m far more familiar with Tsurukame as an iPhone user, so there’s things I’m learning about the app only through the act of working through the code ^^
Thank you for doing this! I moved to this app on the last big breaking change and really don’t want to lose the undo functionality. I also code for a living so I appreciate you doing this on your off time.
This is entirely your choice. Contrary to what @Kasaicho says, I’m just trying to helpful, not picky.
That said, it is trivially easy to throw away everything on master that you’ve changed. If you’ve created a dev or release branch off of master, with all your changes, then those changes are in your dev or release branch as well and all you need to do is ensure you are on the master branch and run git reset --hard <ejw' last commit hash> and then force push to GitHub. This rewrites history. Usually rewriting pushed history will get you burned alive by anyone else reliant on your repo, so never do it lightly. And I’m not suggesting you do it now. Just letting you know there are options.
This is a really good explanation of what git is and how it does it. Picturing Git: Conceptions and Misconceptions - BiTE Interactive A bit dense, but well worth the read for anyone who wants to go beyond git basics and look under the hood. Clarifies the mental model and makes a whole lot of the rest of git much easier to grok.
I have a fork of com.the_tinkering.wk as well. In my fork, master is clean, tracks EJW’s upstream master, and locally I’ve added your fork as a remote and I merge your changes into a branch other than master. That other branch will always track your release branch. If and when Flaming Durtles truly breaks, I’ll likely use my build from my fork, that’s tracking your release branch.
Again, I’m really pleased you are doing this. Thank you for all the effort.
Flaming Durtles and Smouldering Durtles both are getting sync issues with talking to WK servers. Is this my fault for having 800+ reviews due, or is something else going on?
My test version of Smouldering Durtles, both within the emulators and on my testing tablet (which is an old Tab S4, so by no means performant) don’t experience any issues. Could you talk a bit about what exact issue you’re experiencing?
I’ve currently got 239 lessons and 786 reviews pending (because I’ve been spending my time on this instead, haha, and full pull after a database purge takes about five minutes at most.
No, that topic is talking about the Get All Reviews endpoint, which is when an API call is made simply to /v2/reviews with no other arguments, which tries to pull 1000 review items per page and has been, shut down for that reason.
Smoulding Durtles (and Flaming…) don’t use that endpoint like that.
Just to follow up on this, I’m getting issues when testing currently, but I’m also getting the same issues with Tsurukame, so I don’t believe this is specific to SD/FD, but rather something up with the API right now.
Calls to /v2/subjects aren’t returnign data
This is causing the API data pull to fail at the first subject pull:
To Github please and I’m not sure if your issue there is related to the app itself, or the current API issues shown below. Once the API is behaving again, I’ll take a look
