They released an alpha version a few years back and it went very poorly. They ran into some issues (I don’t know what) that were so bad they just dropped the project entirely.
Also, I’d argue that they could avoid this by making the need for apps go away. The mobile experience for WaniKani is fine overall, so the main reason to use a mobile app is to get the features that people often want but have to rely on scripts to get on desktop. If they had a native undo and reorder feature on the website, 90% of the need for a native app would go away.
You’re welcome, I just don’t want people to be stranded without an app that they’re used to using. It might be a terrible idea and it might not work, but I think it should
I think that’s what I need, but I’m not really sure, haha. I believe I can set up a dummy REST server for Gradle to use given enough effort, but it’s not something I’ve tried before. Testing API interactions is something I assume @Kumirei has some experience with.
I’m guessing most developers work with throw away accounts and just use real data, so a dummy API (slash test account) that already had some lessons and reviews in the new format would be lovely, but I very much understand if that’s not something you’ve got access to yet
It is not just 60, it is 60 FOR NOW. What if they eventually add 5000 vocab and you already knew 4000 of them? Vocabulary for kana only words is huge and they will either make insignificat amount of them, thus wasting dev time and confusing the people with what is even purpose of WK and if they should be learning kana only elsewhere or not, or they will double the amount of vocab items, making this a viable option only for newcomming users that havent learned anything yet (for which this might actually be a nice change, not gonna argue), people knowing at least a little bit will be offput by the number of items they know already without any option to skip/suspend it.
I would also be curious what kind of vocab is common enough to be justified for adding in the first batch of 60, but also rare enough to be fitted in level 48, by which people hopefully have at least N4 level of understanding from other sources.
Kana only vocab just doesnt make sense outside of either opt out or it being some separate path.
Unfortunately the offline support of flaming durtles is too big to overlook, i do have plenty mobile data, but even ive used it when traveling to country where i cant use them or when i was somewhere with not an ideal reception. Especially if you consider that those situations without internet are the best downtime oppourtinities to learn.
But other than that yea, having native undo and reorder would help a lot. That would in general help with backlash of new updates as they could never break and losing some lesser scripts for a few days wouldnt be as big of an deal as it is with undo and reoder currently.
All the code for the has been in place for quite sometime as I previously mentioned. We have just held back the publishing of the content (which is also ready to go). To support your request I would need to create a custom build for you to test against and this isn’t something we normally do. Usually if there is something significant we put it on preview.wanikani.com, but preview uses the same data as production, and we cant publish the new items yet.
However let me speak to the rest of the team about the custom build, and if it doesn’t take me away from the other things I am working on for too long, I may be able to help out a bit more. In the meantime, lets take this conversation into the support channel, If you could send an email to hello@wanikani.com and mention this post, then customer support will forward it on to me. I don’t want to send any private urls etc in the forum if this is something we can do. (* it is also a public holiday for some of the team on Monday, so I may not respond until Tuesday after I have had a chance to talk with the team).
Ideally the app would have automated tests where you can mock out API responses with the values provided in the API, but I also understand you are just picking up a hobby project from someone else (it is called com.the_tinkering.wk after all) and it is not everyones cup of tea to write tests when we are just tinkering (which I also understand).
It would be good if you could get approval or become the maintainer of the original app, as I think another app in the play store will only add to more user confusion. Do you know if anyone has tried to get in contact with the orginal developer?
In theory progressive web apps support offline functionality, so maybe it’s possible to still do that without a native app. I’ve never made one before though, so I can’t say for sure. Either way it’s a good point.
You could use something like https://www.mocks-server.org/ - I don’t think it has a Gradle integration but at least for manual testing, it would be easy enough to start it manually via Node or docker. But it would still take effort to set up everything (and you would have to change the API url in the app of course, or make it configurable). If you want to make it less manual work, you could think about making it an almost transparent proxy for the real API, and just modify certain responses (e.g. by adding mocks for the new kana-only vocab).
The only reason I installed the app was that I need to be able to do reviews off-line when I don’t have access to the Internet. All the great extra features of Flaming Durtles (essentially building in many of the most popular features of userscripts) were just the icing on the cake.
I can certainly manage without native undo and reorder, but a program that requires daily reviews but is only usable online would be a problem for me.
Edit: Sorry, I posted my reply before noticing that @Nirgan had already made the same point:
That’s good to know, thanks - already have the account now, so will probably publish it on there regardless, but…
Have already done this, in fact, just pushed the 2nd beta version having got it finally compliant with API 33 (Android 13) and building properly. I’m an Apple user, but the emulated Pixel 3 on Android 13 appears to be running it just fine. I have got an Android tablet I use for IT Security testing stuff at work, so will check it on there, but I don’t anticipate any issues.
As it stands, it appears to work as expected with the current API, with the only thing currently broken the aforementioned custom colour picker - the themes all work though, it’s just my not being used to the layout design stuff. Will hopefully resolve it before it needs to go on the app store.
I would appreciate that, thank you, and I realise this isn’t a common occurrence, so thank you for taking the time to support this. I realise that supporting third party applications isn’t the responsibility of Tofugu, but as a non-Android user who just wants to see the members of the community who are reliant on Flaming Durtles continue to have access to a working app, I speak for them when I say that the support is very welcome.
Quite so, I’d love to be able to code that in, but it’s out of my limited Python and Javascript knowledge range to do that kind of thing in Java within the JDK. If I continue to maintain this, I’ll certainly look at building that functionality in or setting up an easier way to test dummy inputs - I’m familiar enough with BurpSuite and other ITSec testing to know how to spoof requests with browsers, but not so much with apps.
That would be the ideal and I’d just merge my changes into primary branch if they were engaging, but while the app on the play store was updated a year ago, the github hasn’t been touched in three years now - hence having to spend a fair bit of time. There have been no responses to any PRs in the last three years either and the user hasn’t been seen on the forums in the last year.
As per their Apache licence, they don’t allow releasing the code under the same name, hence repackaging it. I’ll make every effort to signpost - logically anyone with an issue will probably come to the thread on the forum, I’d hope.
I have used Charles proxy in the past to test third party APIs when I have done iOS and android development. You can proxy your requests through Charles (or similar) and intercept the server response and manipulate it before sending it on. I would use it to spike out an idea before investing too much time. It is worth looking into if you haven’t already.
Just tried it out and all seems to be working! (Android 13 mobile) Thanks for your work on this, it’s greatly appreciated!
If you get a chance at some point, I have a small formatting request for the app - on the dashboard the SRS counters are on two lines (apprentice + guru + master, and enlightened + burned). It would be great if the two on the second line were 1.5 times the width of the ones on the first line so as to fill the same width, rather than leaving an awkward gap there. Not very urgent or important but would be nice
It’ll be a learn as I go experience with all this, I’ve got some coding experience, but no app experience, hehe. I won’t make anymore changes until I’ve confirmed that the kana support works, at which point I’ll be confident enough to create a thread for it and let all the Flaming Durtle users know there’s something to migrate to ^^
At THAT point, I’ll start taking some feedback for stuff people have been wanting fixed, but it might be a slow process as I get accustomed, haha
And this is where things get complicated, hehe - it’s very hard to account for different screens. I don’t know enough about android layout design to know if it’s possible to have it dynamically adjust based on screen width, but it’s something I’d look at, should it be possible. Again, on the basis of when I’m able to, hehe
I have quite a bit of Android development experience, but very little experience with respect to getting something hosted on Google Play. The one time I went through the process I told myself to avoid it again at all costs. DM me if you have any questions about software or build issues. I have a vested interest in seeing Flaming Durtles continue to burn.
