[Android] Smouldering Durtles (v1.1.1) - native app with offline lessons and reviews, plus themes and script-like features!

[Joeni]

This is a third-party script/app and is not created by the WaniKani team. By using this, you understand that it can stop working at any time or be discontinued indefinitely.

The Story

When Tofugu added kana-only vocabulary to WaniKani, lots of users were justifiably concerned that this change would cause issues with their favourite app, Flaming Durtles.

The original application had been unspported for a while, and though I’m not an Android developer, or even an Android user, I know how many members of the community love all that the app offered and so wanted to do what I could to try and keep it functional.

Why Smouldering Durtles?

The original developer of Flaming Durtles released it open source, but stipulated that nobody reuse the name. I fully respected that, but wanted to keep things as close as possible; so I chose Smouldering Durtles to highlight that the fire hasn’t burnt out.

What’s The Difference?

• Fully baked-in support for the most recent changes to WaniKani
• Updated to support the newest versions of Android
• Regular new feature updates and improvements
• Otherwise? Nothing, it’s the same app you know and love!

What Are The Features?

• Feature rich dashboard with a 24hr timline for forecasting
• User-script style features like reordering, and back-to-back modes
• Typo-protection support for undoing or skipping items
• Granular filtering and a range of advanced options
• Fully customisable UI colours and a range of themes
• Lots more, like anki mode, pitch info, and self-study quizing!

How Do I Install it?

Current Play Store Version: v1.1.1
Current GitHub Version: v1.1.1
^{(See changelog below for previous versions)}

Get a Play Protect or Unknown Source warning?

The release is self-signed, so it hasn’t been through Google’s app verification process and may therefore cause a warning from Play Protect. You should be able to click ‘Install Anyway’ if you’re on a newer version of Android, but if not, you can follow these steps to allow it to install:

1. Navigate to Setting > Security
2. Check the option “Unknown sources“
3. Tap OK on the prompt message
4. Select “Trust“

Easy as that, you can now you can try again to install it.

Extensive theming support and custom colours

Simple and advanced search modes

Tons of userscript inspired features

Changelog

^{Check the release page on GitHub via the link for full details}

\textcolor{ProcessBlue}{\small{\textsf{v1.1.1 }}} - Fixes to swiping behaviours in lessons, placement of SRS indicator, and button texts

\textcolor{ProcessBlue}{\small{\textsf{v1.1.0 }}} - Rolled back swiping changes to restore timeline function and incorporated theme switching fix

\textcolor{ProcessBlue}{\small{\textsf{v1.0.9 }}} - New automatic day/night theme switching, swipe gestures, blurred translations, and numerous other tweaks.

\textcolor{ProcessBlue}{\small{\textsf{v1.0.8 }}} - New previous level bar limiter, haptic feedback, and monochrome icon option.

\textcolor{ProcessBlue}{\small{\textsf{v1.0.7 }}} - Resolved a number of style related issues and moved the alternative meaning toast.

Older Versions

v1.0.6 - Resolved notification issues and added play button to kana-only vocab - also added new back/restore options.

v1.0.5 - Resolved bugs with the wrap-up page, notification icons, and level up target indicator. Added a new Nord theme.

v1.0.4 - Resolved remaining bugs with dialog overlays, colour picker order, and database removal spelling.

v1.0.3 - Resolved issue with widgets not updating and, hopefully, fixed notification updating issues.

v1.0.2 - Resolved issue with the lesson/review number preference dialog, but there’s an outstanding issue with the semi-transparent overlay remaining briefly after dismissal.

v1.0.1 - Resolved reported issues with the vocal totals on the dashboard and fixed issue with custom search engine preferences where the dialogs weren’t showing due to a fragment issue.

v1.0.0 Final changes to kana formatting complete and fixes made to the progress bars, etc. that were causing duplicate vocabulary bars to be formed. Now feature complete and ready for submission to Play Store once this is possible.

Pre-Launch Versions

v0.9.2 - Custom colour picker fixed, upgraded API handling and resolved some kana formatting issues, upgraded a number of depreciated modules.

v0.9.1 - Refactored project to support Android 13/API 33 and therefore make it suitable for submission to Play Store once this is possible.

v0.9.0 - Kana lesson support introduced, but app still only supporting API 29. Custom colour selection broken and kana formatting inconsistent across app.

Issues / Suggestions / Feature Requests

Drop me a comment here by all means, but if there’s a specific feature request or issue you want me to look at, I’d encourage you to open an issue on the GitHub repo as this will allow me to keep track more reliably

Issues · jerryhcooke/smouldering_durtles

[marciska]

Awesome work, you rock!
I don’t have an Android, and I’m mostly using Tsurukame on iOS, but just wanted to come here to honor your work

[Joeni]

I appreciate that! Thank you! ^-^

As an aside, I’m an iOS user myself and rely on Tsurukame, so I hope that it’ll be updated soon, hehe. Though by all accounts it appears it should just gracefully discard the kana if not updated, rather than cause any issues (fingers crossed) - the developer appears to still be active with it, so hopefully I’ll not need to look at that one too - I’m not sure I have the time or energy to learn Swift alongside Java

[marciska]

Same. I glanced over the code to evaluate the effort I would have for it to fix it but… ダメだ！I’d definitely need to learn Swift before that. But may also be a good reason to start learning it.

[polv]

Not verified by Play Protect (i.e. not yet approved by Google). I can install it anyway, but the button is as hidden as Windows.

Normally, the builds would be put inside Assets, like this one.

@Joeni

As an aside, I’m an iOS user myself

Not sure if you can emulate Android apps on iOS?

[Joeni]

@polv

Not verified by Play Protect (i.e. not yet approved by Google). I can install it anyway, but the button is as hidden as Windows.

Currently pending verification of my developer account before I can get any bundles verified (as far as I can tell) - I’ve no prior experience with the process, though I’m got all the prelim listing steps done already,

@polv

Normally, the builds would be put inside Assets, like this one.

Noted, will make the releases more compliant in naming and releasing terms. I don’t typically use GitHub for anything but private repos, so I’m not used to actually posting releases

@polv

Not sure if you can emulate Android apps on iOS?

I don’t suspect so, it’s not a massive issue in the short term though.

[skatefriday]

I was going to open an issue on your repository, but apparently that’s turned off on your fork.

 *     Just pick a new name that does not include my name or trademark anywhere
 *     in it. It's fine to acknowledge in documentation that the app derives from
 *     my work, and/or to reference my app. But DO NOT actually use my name or trademark
 *     for any part of your app.

For this, might I suggest a branch that tracks master, that you release out of that contains two changes the original author wants to protect his trademark?

Also, you typically don’t necessarily want your master branch to be ahead of the repository you forked from. Although in this case that might be acceptable if Flaming Durtles is completely abandoned. But I’d use a dev branch for all the changes that the new kana vocabulary feature requires, including the requested changes to trademark related files. Merge that into the release branch only for cutting releases you are going to build for the Google Play store.

Then the instructions for building the app are simply, “Checkout the release branch and build within Android Studio, if you want to live on the bleeding edge, checkout dev and build.”

And you can add a caveat to the README that deploying to Google Play is not permitted directly from your release branch. I mean the existing approach doesn’t prevent a malicious actor from attempting to reuse the Flaming Durtles name. Could a non-malicious actor upload an APK using the Smouldering Durtles name semi-accidentally? Maybe?

Oh, and thanks for all this. You Rock!

[scallensc]

Just checked out 0.92 beta, thanks for your work continuing this app!
One question - is it possible to add the functionality from the “extra study” section that WK has? - eg:

• Recent Lessons
• Recent Mistakes
• x of x Burned Items

I can see how some of these might be covered in the self study quiz section in the app, but I can’t get it to show me recent mistakes no matter what combination of parameters I try.

It’s about the only part I need included in order to divorce myself from having to use the website at all.

Thanks!

[Joeni]

@skatefriday

I was going to open an issue on your repository, but apparently that’s turned off on your fork.

Oops, didn’t realise those aren’t turned on by default - have turned them on now ^-^

My field of computing is primarily engineering and security focussed and this is my first time dealing with a codebase that somebody other than me or a couple of other people might use, so I appreciate the feedback.

My intention was to get the kana supporting version stable and Play Store releasable on the master branch and then create a dev branch to work on any additional change. You might have to ELI5 it for me, but is your suggestion that:

master = the original Flaming Durtles code, unmodified except for the name changes
release = the currently stable build
dev = the current feature-adding / working-on build prior to stability

I’m not sure I’m understanding the logic here, given the original repo is abandoned, unless your point is maintaining an unmodified codebase for reference? Again, sorry to ask you to explain, but the most I’ve used GitHub in the past is for managing puppet builds at work and keeping my Obsidian vault synced, hehe.

@scallensc

One question - is it possible to add the functionality from the “extra study” section that WK has?

It’s definitely something I can look at, once I’ve gotten things final. I’m happy to look at things people wanted updated or added to the original app, but I’ll caveat that it might be to slow learning progress as I become accustomed to Java - my only coding experience is in Python (and a bit of Pascal back in the day, hehe).

Now that I’ve turned Issues on, could I ask that you pop your request in there? I’ve got ADHD and so things tend to fall out of my brain if I don’t have somewhere central to organise them and I don’t trust myself to reliably keep track otherwise ^^

Issues · jerryhcooke/smouldering_durtles

[Aislin]

I’m immensely thankful to you for picking up the maintenance of this app

[Joeni]

@Aislin

I’m immensely thankful to you for picking up the maintenance of this app

The moment I looked at the code and could kind of see what needed to be done, I couldn’t stop myself from doing it, if you know what I mean? It’s always like that with me and projects

[Fryie]

I respect you a lot for picking this up even though you were completely unfamiliar with Java and Android.

[Joeni]

Thank you ^^

When you get down to it, code is code, and in the age of GPT4 so long as you know how an IDE works, how to deal with errors and dependencies in general, etc. it’s a lot easier to code with an unfamiliar language than it used to be.

Even if GPT4 is only right about 70% of the time, at least it points you in the right dirrection.

[skatefriday]

@Joeni

My intention was to get the kana supporting version stable and Play Store releasable on the master branch and then create a dev branch to work on any additional change. You might have to ELI5 it for me, but is your suggestion that:

master = the original Flaming Durtles code, unmodified except for the name changes
release = the currently stable build
dev = the current feature-adding / working-on build prior to stability

Yes.

However, I noticed you changed the base path of the package names, which is why you have changes to over 500 files. Most of the diff between your master and the upstream is copyright and package path changes. I don’t think that was absolutely necessary and would make any merges from upstream master should EJW ever reappear more difficult than they have to be.

But more importantly, should EJW ever reappear and say, “Oh hey, this is awesome, let’s merge your stuff into Flaming Durtles!” that’s now nigh impossible cause he’s never to going to able to merge a pull request with all those package name changes.

I’m not sure I’m understanding the logic here, given the original repo is abandoned, unless your point is maintaining an unmodified codebase for reference? Again, sorry to ask you to explain, but the most I’ve used GitHub in the past is for managing puppet builds at work and keeping my Obsidian vault synced, hehe.

Yes. Typical best practice with forks on GitHub is to keep the main, or master, branch clean with respect to the upstream repository. This makes fetch/merge cycles much, much easier and cleaner. If the intent is to hard fork and never talk to upstream again, then what you are doing here is fine, but branches in git are so cheap and easy, that it’s almost no work to adopt the other branch strategy.

Orthogonal to the branch strategy discussion did you make changes to strings.xml? Your repo doesn’t currently build with missing resources.

[milopiccolo]

Thanks for your hard work on this so far!!

I believe you should preserve the original author’s copyright notices - I opened a GitHub issue to keep this thread from branching out in too many directions!

[Joeni]

@skatefriday

I don’t think that was absolutely necessary and would make any merges from upstream master should EJW ever reappear more difficult than they have to be.

I’m really just feeling in the dark, honestly - I didn’t really consider that all the file changes would mean it would be hard for anyone to see where the real changes were, so sorry about that - very much my naivety. Likewise regarding merging back, I honestly didn’t really consider that as something likely to happy, so I didn’t really give it might thought.

I’d suggest at this point that I’ve refactored and upgraded enough packages, changed API calls, etc. that it would be difficult to have smoothly merged it back regardless, we’re working on a different gradle version and a number of dependancies have been completely changed, as well as now and targeting different API versions.

@skatefriday

Orthogonal to the branch strategy discussion did you make changes to strings.xml? Your repo doesn’t currently build with missing resources.

Again, my naivety here - not being used to how Java handles string replacement, I didn’t realise they then lived in strings.xml. Given how the build instructions work, that’s not sensible, so I’ve retuned them to static strings.

@milopiccolo

I believe you should preserve the original author’s copyright notices

You’re entirely right, I didn’t realise that was a requirement of the Apache licence, so I’ve returned them all to how they were and simply placed new copyright statements on the new class files I’ve authored

[Kasaicho]

I don’t use any third party apps but I deeply respect this kind of thing. taking action to make the world better. especially when its slightly out of your comfort zone with publishing and copyright notices and master/fork revision numbers that people get picky about. seems like you did a great job.

[AllieKatte]

Just wondering, since the filtering feature is somewhat hidden behind the advanced settings, but will this new version of *durtles support lesson filtering the kana vocab?

[scallensc]

I’ve popped this into the issues section on the repo as per your request. Thanks!

[polv]

@skatefriday

However, I noticed you changed the base path of the package names, which is why you have changes to over 500 files. Most of the diff between your master and the upstream is copyright and package path changes. I don’t think that was absolutely necessary and would make any merges from upstream master should EJW ever reappear more difficult than they have to be.

Perhaps commit rewrites (like with git-filter-repo), then force push. Well, if Joeni want to keep connected with the upstream.

@Joeni

My intention was to get the kana supporting version stable and Play Store releasable on the master branch and then create a dev branch to work on any additional change. You might have to ELI5 it for me, but is your suggestion that:

master = the original Flaming Durtles code, unmodified except for the name changes
release = the currently stable build
dev = the current feature-adding / working-on build prior to stability

A usual flow is, a new dev branch for every new feature, then merge into master when you are ready.

Not sure about keeping a release branch separate. That can be managed by Git tags, or releases.

But then, for a forked repo, keeping master unchanged and clean, would help with fetching and diffing with the upstream’s master. Not sure if it applies to an abandoned repo.