I’d likely use it if there is an undo answer function (I use it for dealing with typos an synonyms). The offline feature would be great as I spend some of my commute time underground where data connections fail.
I’m currently using WK for Wanikani to study on the commute but my train has a lot of tunnels so the offline support would mean the world to me (and probably to my husband, who knows he is only allowed to talk to me on the train when I don’t have signal ).
So yeah, basically as soon as this is good to go I will be downloading it.
Hey there, you had replied to my post where I was try to figure out how to use the API.
I’m working on my iPhone app, its going alright so far, haven’t really implemented much of the functionality yet, but I got all the reviews/lessons downloaded to the app and now I just have to work on presenting them and actually being able to answer them. Then I’ll worry about figuring out how to post it back to WaniKani.
My question for you is in regards to the offline functionality. I’ve seen WaniKani apps that boast offline functionality. It seems to be important or necessary for some people. How exactly does that work? Is it downloading reviews while internet is available, and then when reviews are completed it just saves it and uploads when a connection is available? Or is it more complicated than that?
That’s is, more or less. In a little more detail:
- Know which reviews are coming up during the offline period, and when. (Use the summary endpoint, or keep a record of the user’s assignments.)
- Know all the relevant details about the subjects being reviewed.
- When a review is available according to step 1, let the user do the review.
- Store the result of the review locally.
- When the device comes online again, create the review records using the API.
- Hope and pray that the user hasn’t done the same reviews from another device in the mean time.
If you’re not supporting offline mode, you don’t need to collect so much information ahead of time, and you don’t need to store the review result locally before posting it to the WK API.
By the way, if you’re developing on iOS, have a look at the thead for AlliCrab ([iOS] Mobile AlliCrab for WaniKani ). Recent rules for the iOS app store make it rather hard to get any iOS app for WK approved these days.
Been using Flutter lately, and it seems to hit the sweet spot of being cross platform but native at the same time. It’s really great, has many advantages over react native (and I wouldn’t even compare it with PhoneGap or the like because those are pure web tech, they never work well on mobile).
This looks very interesting! Offline support would be so nice!
Here are some examples of userscripts with features that would be much appreciated in an app:
I think I’m dating myself slightly by talking about PhoneGap. Do people even still use that?
I too try to use the OLD OLD (not even on Google Play anymore, I keep copying the SDK file over to new phones) “WaniKani Mobile” app that hasn’t been supported since before I used it on the first phone (2 phones ago, 5-6 years ago when I first joined WK!).
Honestly, the only things I’m looking for in an app are the ability to do a batch (or a few batches) of reviews online, have the app save the state (results) of what I’d done (right/wrong, etc - supposed to go from Guru to Master) and then send it up to WK when I DO have connectivity - even if it means the next set are pushed back an hour or so (better than waiting 8-11 hours when I get home from work). (I too attempt Subway review sessions, and since I’m with the carrier with signals in the stations, sometimes I can get about half a short session in, but I might have to redo 1/3 or half of my inputs at the next connection point). Notifications of when reviews are available (the old app has a threshold - so I only get a notification for 5+ reviews). And finally, because it’s on mobile, the IGNORE script being a feature, for when I inevitably type too fast and こんにちは turns to きんにちは.
That’s it. Anything else is BONUS. Doesn’t even have to “look pretty” - in fact, a simple sleek design (like what you already seem to have going from those gifs) is nice and functional enough for me.
I hope not
Let’s see, I feel like elaborating here since I’ve had my share of troubles. And especially because I’m an architect by title, so I like to be thorough in understanding the different solutions for a certain problem.
I’ve pretty much slid through all of the different stacks of mobile. Cordova (and by extension, phonegap/ionic/…) were the worst. I’m not blaming them, they did the best they could in a web environment on mobile. As much as I like going native, native ios and -especially- android platforms are a pain to work with, even without considering the impact of having 2 completely separate codebases (support libs and UI in general are just… not modern). React Native is a big step up, with a reactive UI and familiar syntax, but still suffers a bit under the hood as it still needs a JS VM working on translating between levels. (And I personally hate the idea of having “React” in the name tbh)
Right now, Flutter combines the best of all worlds, and I really mean all, and it’s a long time overdue for the mobile stack.
Kotlin do or die.
It seems like there are a lot of developers lurking in the forums.
In terms of multiplatform, I evaluated Flutter briefly before I found that it only supported raw SQLite and did not have support for recurring subsriptions through the iOS/Google mobile billing SDK’s. I am a Google Boy myself and I wish it well, but pass. As @ejplugge noted, we’re building a complex application and that may come with difficult tradeoffs in a multiplatform codebase. It’s the flexibility (one codebase) vs complexity (custom solutions required) question. The less we have to rely on javaBoi69’s GitHub package for some wrapped feature in Dart, the better.
I’m sure that WK evaluated this too, but it’s unlikely they are going to share their entire business-technical strategy or internal debates here. Rather than a technical reason, React Native is likely a popular choice because they do not have to retrain or hire x-number of new developers and can simply plug into their small (but excellent) JS web team. If only companies revolved around the best tech stacks rather than cost; but alas, that it not the case. I’m sure all of you have a story that goes along with this.
There are a lot of interesting posts on Medium on this topic:
- Who will steal Android from Google?
- Susetting React Native - Airbnb
- The (not so) hidden cost of sharing code between iOS and Android - DropBox
At my current job, we recently found ourself in the same situation as DropBox. We decided to abandon a shared low-level C++ library in favor of using the iOS and Android SDK’s. If I were starting a business, I would be worried about what would happen when Mark Zuckerburg decides to stop supporting React Native after Airbnb left, and we’ve already built an app and invested $250k into the product, and Android R in October 2020 uses a revolutionary new navigation paradigm that only uses SOLI pinch and eye gestures; then javaBoi69 takes over the community-led React Native solution. Some middle manager at Facebook could destroy your life.
Thanks, this is really helpful. And thanks for the information about the App Store. I usually use the Tsurukame app, and he actually just posted yesterday saying he just sent an update to the App Store, and should be available in a few days after Apple approval. Well, I’m thinking chances are he will run into the same issues as the Allicrab dev mentioned. I looked at that thread for just a minute, and he mentions that they complain about WaniKani subscription not being in app (because Apple just HAS to take a cut of your profits), which is kinda bullshit because its a third party app. App devs have no control over this.
Anyways, at the very least, creating this would be good experience, and I would definitely use it for myself. And thanks for the info about offline reviews. Funny that you mentioned #6, cause I was wondering about that!
Hey everyone, happy belated new year!
First congratulations to @ejplugge for beating me to release with their Flaming Durtles app. I think the positive feedback they received shows the number of passionate users, language enthusiasts, and talented people right here in the forums. It’s a cool place to be. I also like the idea that somewhere in Europe I have a doppelganger with the exact same routine, hobbies, and projects. Haha.
I’ve decided to make this an open source project with a copyleft license and to narrow the scope of a v1.0 release which is available today in an open public beta:
I took a look at implementing a bottom nav, learned items, lessons, and had a data flow working; which you saw in the first post. While the path to full-feature port of the website to an app was within sight, it is outside of the scope of a v1 release and probably outside the scope of an unfunded community-only project in general.
Tofugu-WaniKani Community Open Source Partnership Proposal
The best case scenario for this project is that it is forked by Tofugu to become the official WaniKani Android app and is co-developed by a Tofugu-WaniKani Community partnership. It could be overseen by a full-time engineer at WK with financial reinvestment into the community through something like GitHub Sponsors.
This has potential to be a win-win model in that the app is distributed and maintained by Tofugu, but kept open source so that we all have a stake in it and can contribute to its success. Specifically, individual developers here could pool our efforts with WaniKani to create the “real” app - instead of one offs that always die - while also getting paid for our efforts on a feature-by-feature or maintainer basis. The heavy features and business-tech costs associated with an independent project would be housed under Tofugu who already have a solution. Tofugu could also quickly move ahead with their own team and contractors if they decided to do so. Users would benefit by being able to see exactly how their data is used with a direct link to the bug, feature, and testing process if they’re feeling tech savvy. Tofugu would benefit by getting apps into the store, being an official maintainer, and being able to tap into a handful of mobile specialists in the community as needed.
There are some successful projects with small teams out there that follow a similar model to a varying degree and almost all big name apps out there use open source components developed like this. And in fact, there is already a subculture of community-driven web extensions in place that might guide us in the right direction. (Of course an official app would be excellent too, but alas it is 2020 and I paid for a lifetime subscription and it’s still not here.) The template is here if Tofugu wants to takeover. To be clear-- my goal is not for the community to pick up the task of making the mobile apps for free, but to explore a platform for partnership. While WaniKani is doing good for the language learning world with a great mission, they are still a private company and we should keep that in mind.
The WK team did a great job developing and documenting their API. It is one of the best I’ve used, and it’s clear a lot of thought and effort went into it. On this topic, great job team.
Leap For WaniKani Open Source and Copyleft License
My main focus was a scalable architecture with the latest Android tools that could be made into a full-feature app by a team. Before continuing, I’d be interested to hear from the WaniKani team on the official plans.
Other developers can fork the project as as long as they also release open source back into the commons under the same copyleft license. This guarantees the community always has a stake in whatever comes out of this project even if it just might be an experimental way for you (an individual developer) to learn the WaniKani API on Android or to develop a parallel architecture on iOS.
For technical questions and discussion, it would be great to keep it under the GitHub Issues so that this thread is friendlier for everyone from this point forward. The repository and a technical walkthrough can be found here: https://github.com/vrickey123/LeapForWaniKani
For now, we’ll be focusing on bug fixes until our future goals are clarified.
For v1.0 we have:
- A Dashboard that syncs your current WaniKani lessons and reviews status to your device
- Push notifications that alert you if you have pending lessons or reviews in your queue
- An in-app browser that takes you directly to your lessons or reviews then back to the app’s Dashboard
You might be saying, “isn’t this just a dashboard with push notifications that links you out to the website? Why don’t they get a real app developer!?” Well, yes it is and I’m also hoping for a full app as I described above. The hardest part of efficiently downloading, saving, and displaying WaniKani data is finished for the most part, which means we can now think about making different screens for the app.
Before I release a full rollout to the public, I’d be grateful for a high-level user (someone level 15+) just to test our initial download of a large number of assignment records. No data from the app is sent up to WaniKani, so it cannot corrupt your current state. The expected result is that your Android dashboard reflects your web dashboard.
The public release is available on Google Play:
And the open source project is available on GitHub:
Happy studying and coding
You are a man among men.
I rolled out a minor update includes bug fixes for notifications and Notification Preferences accessible from the Nav Drawer. This lets you set your notification frequency for lessons and reviews to once every 1-24 hours.
Available Lessons and Reviews Notification
- Takes you to the Dashboard
Available Reviews Notification
- Takes you directly to Reviews
Available Lessons Notification
- Takes you directly to Lessons
Hopefully this helps some of you dial into your study schedule. Enjoy
Never heard of this before, is this in competition with flaming durtles?
I installed this app to have a look at how it’s going. But I noticed a problem with notifications. After installing, I got a notification, dismissed it, and then disabled notifications in the app’s settings. But now I keep getting notifications every 15 minutes, despite having disabled them. I’m using Android 10.
Not wanting to jump the gun on vrickey, but no, this app and Flaming Durtles are not competitors in any real way. They’re just two apps that coexist in one ecosystem. They are developed along completely different paths in terms of design, feature set and future plans, and we both do our own thing.
Because I take a pretty fast and loose approach to design and code quality, FD has had a ton of bugs and ugliness, but it’s also been able to grow fast in feature set. But choice is good, so I genuinely hope this app and mine can be strong and useful apps on their own and that everybody picks whichever they prefer.
Whoops! Thanks for pointing that out. I will roll out a quick patch for that. The technical reason why is because the Android tool I’m using for the notification mechanism has a default refresh of 15 minutes instead of off. All the other refresh schedules from 1-24 hours will work accordingly. In the meantime, anyone can disable notifications in the app’s Android system settings as in the past. Hmm, a 15-minute schedule: a feature or a bug?