[UserScript] WaniKani Notify

WaniKani API And Third-Party Apps
1

Little popup when reviews are ready.  Shows on top of everything on your computer.

971×331 57.5 KB

11/04/17: Long time no update. Been playing around with Pushover on my OpenHab setup and thought ‘Hey, why not add Pushover to my WaniKani Notifier?’ So, I did. You’ll have to supply your own API Key and User Token. (In the settings. Dashboard page, top right, where your avatar is)
Also, since this is a userscript, your computer will have to be on, and WaniKani open. But hey, not everything is perfect.

https://greasyfork.org/en/scripts/23453-wanikani-notify

2

But will it do your reviews for you…? Please…??

1 Like
3

Thanks for making this! It’s exactly the sort of thing I’m looking for, since I can forget to check to make sure I do things on time.

EDIT: By the way, is a 15 minute interval ok? Since that’s the shortest interval at which wk reviews can be spaced. That makes 4 api calls an hour.

4
aniustaluwis said...By the way, is a 15 minute interval ok? Since that's the shortest interval at which wk reviews can be spaced. That makes 4 api calls an hour.
15 minutes is more than okay. Most apps make very few API calls as they just aren't needed. So you could easily up that number with absolutely no issue. You could safely go every minute if that's what you need. I use a rainmeter skin that allows me to see this type of information on the desktop of my second monitor, I messed up initially and set that to check every 50 seconds instead of 5 minutes. Even that caused no issue.
5

.

6

So far the app is working great! But it seems to only run on the dashboard page, so that I only get notifications when the dashboard page specifically is open.

7
aniustaluwis said... So far the app is working great! But it seems to only run on the dashboard page, so that I only get notifications when the dashboard page specifically is open.
 This is true.  To keep from constantly making API calls every time you go to a different page, I kept it just dashboard.  Say you were reviewing a bunch of stuff and/or had multi WK tabs open at the same time, API calls could add up.  Perhaps an additional setting is in order...
8
DaisukeJigen said...
aniustaluwis said... So far the app is working great! But it seems to only run on the dashboard page, so that I only get notifications when the dashboard page specifically is open.
 This is true.  To keep from constantly making API calls every time you go to a different page, I kept it just dashboard.  Say you were reviewing a bunch of stuff and/or had multi WK tabs open at the same time, API calls could add up.  Perhaps an additional setting is in order...
 oh i see that makes sense! I wonder how you could make it run on any page without it multiplying api calls by number of pages you have open?
9

Downloaded. Thanks a lot.

But isn’t there a way to avoid multiple API calls? (Not a rhetorical question.)
I’m only an amateur, and I’m really not savvy with everything browser-related, but… If you could create a cookie - this would be the weakest point in my argument, I believe - all you’d really need to know is when the next review is scheduled for (and the number of items to be reviewed but that doesn’t matter here).
- Have the cookie store the time of next review as nextCall (if nextCall - current time > 4 hours then nextCall = current time + 4 hours) and remain valid until current time = nextCall.
- Then have the script make an API call only if/as soon as there is no valid cookie (and replace the cookie).

The only situation where new review sessions are going to appear in the schedule after a call is if you do lessons, and this is covered by the maximum interval being set to four hours.

Then again, if you can’t create cookies (or use any other way to store values) that… doesn’t work.





10

Re: what @Brook said, once you know the next review time, you won’t need to check again unless the user did lessons.  You can set a ‘need_to_refresh’ flag if the user visits the lesson page.  But that doesn’t account for if a user does lessons on a different device.  In the timeline script, I accounted for that by assuming the user would always start up on the dashboard, where I check the ‘recent unlocks’ to see if lessons have been done since last update.  (Plus timeline is only on the dashboard anyway)

Or, you could just check the recent-unlocks api request no more that once every 15 minutes, since reviews only pop up on the quarter- or half-hour.

11
rfindley said... But that doesn't account for if a user does lessons on a different device.
I agreed at first, but if I'm not mistaken, that's covered by the four-hour limit. If you make a call from your PC and then do some lessons on your phone, no new reviews will be scheluded at a time anterior to that at which the PC will check again.
But to be totally honest, I considered the multi-device support for about two seconds before throwing it in the "asking too much" box.

EDIT:
This is also asking too much, but it's a little bit more useful/fun than multi-device support, in my humble opinion, and I'm not asking anything, only suggesting features I thought would be cool to have (nothing vital, nothing revolutionary).

[] Notify me only of current level reviews
[] Notify me X minutes before review
[] Show number of items in the next Y minutes // {e.g. 32 reviews available (25 more in the next 120 minutes)} for those who don't like surprises
[] Don't notify me until the review count is more than Z // should include later reviews if previous box is checked
[] 42+ // for those who do like surprises

12
Brook said...
rfindley said...But that doesn't account for if a user does lessons on a different device.
I agreed at first, but if I'm not mistaken, that's covered by the four-hour limit. If you make a call from your PC and then do some lessons on your phone, no new reviews will be scheluded at a time anterior to that at which the PC will check again.
But to be totally honest, I considered the multi-device support for about two seconds before throwing it in the "asking too much" box.
Yeah, you're correct.
Sorry, I didn't express clearly...  I was thinking about the fact that (if I understand your proposal correctly) you'd basically be doing a check once every 4hrs at least.  And that really is a nice simple way to reduce server load.

I was adding an additional point to what you said, and unfortunately didn't include much of the detail to make that clear (... posting while sleepy ;^_^ ).

Since the script does a full load of the user's items, even once every 4hrs is a big load on the servers if the script becomes popular.  As a low- to mid-level user, @DaisukeJigen will see reasonably fast response times to his own API queries.  For higher-level users, one massive request for all vocab often fails because the API request times out before all the data can be fetched.  For that reason, the Timeline script breaks it up into smaller requests of 5 levels per query... though 10 or 15 may be better if it's going to request every 4hrs.

To minimize server load, the Timeline script relies on the recent_unlocks request -- which is a very fast and light request -- to determine only the minimum number of item levels that need to be queried.  Basically, just query the levels that have had unlocks, or which had reviews go by.

Timeline caches all the items, so it knows which levels have had reviews go by, and therefore which levels need to be re-queried.  Since DaisukeJigen isn't storing the items, he could instead sort all the items by level, and find the 'next-review' per level.  That way, as a review time goes by, you know which levels need to be re-queried.  (hard to explain... I hope that was clear).

But, that's a fair amount of extra work, sooo...  ^_^
13

Didn’t think about request timeouts being possible for higher level users.  Breaking requests into groups isn’t hard, but does raise the number of APi calls being made.  Already have to make three separate calls for radical, kanji, and vocab.
But the next-review per level idea has me thinking.  If you’re a high level, chances are you’ve burned everything in low levels.  So maybe keep track of levels I won’t need to query at all?
Or even when you only have a few left in a level, I may not need to query it again for a few months.  Although testing a ‘ignore this for 4 months function’ can be tricky to test.  Have to fake it a bit, which isn’t always perfect.  I’ll play around and see what I can come up with when I get some time.

14
rfindley said.Sorry, I didn't express clearly...
Nah, I see what you meant, now. If anything, I'm the one who should apologize for misunderstanding. Sometimes I just don't english much well. My bad.

I thought about checking the recently unlocked items to detect lessons, but the four-hour limit thing made it appear useless to me - little did I know. As the requests are done every fifteen minutes, I assumed the reply consisted in a minimal object with a [boolean, integer] couple of values and concluded that such a small request every four hours was hard to beat.
Considering the available queries, it's hard to come up with a better method than yours, but that's still a lot of useless data to load for DaisukeJigen's script.


DaisukeJigen said... I'll play around and see what I can come up with when I get some time.
 Have fun.
15

Rolled back to earlier versions as I broke it.

16

Alright, lets try this again.  New coding to only query levels that we need to.  Script will keep a record of next available review per level per category, and then not query for those areas until that time has passed.

17

Long time no update. Been playing around with Pushover on my OpenHab setup and thought ‘Hey, why not add Pushover to my WaniKani Notifier?’ So, I did. You’ll have to supply your own API Key and User Token. (In the settings. Dashboard page, top right, where your avatar is)
Also, since this is a userscript, your computer will have to be on, and WaniKani open. But hey, not everything is perfect.

18

Hey, just poped by to say I got a little bug when I turned the vacation mode on.
The script would notify me in a loop.
Don’t know if it’s of any help…
Thanks for the script by the way.

19

Never took vacation mode into consideration. My fault there. Can definitely see that causing issues, now.
I’ll have to look into how to handle that scenario. Not sure if API tells me vacation status or not… Something to look into when I get a chance. Sorry for the infinite loop.

20

Don’t worry mate, I just toggled the script off so it doesn’t bother me at
all.
Thanks again for the script !