Generating a random, matching answer

Ok, well I've been slacking off on the blogging lately. Sometimes it's just quicker to go ahead and code, you know?

But, I'm back because I'm trying to figure out what to tackle next. I've put some new capabilities into the app based on recent feedback, including:

1) If it's kana only, then instead of giving an answer in multiple choice that's only identical to the question, I've swapped off to English. It works really well, and seems natural, so I'm very pleased with it.

2) I've added functionality which allows English to Japanese

3) I've added Japanese to English (before it was Japanese kanji to Japanese hiragana only).

4) I've added setting to support the above functionality.

Ah, I just remembered, I need to change the settings display to hide the "multipleChoiceInEnglish" if "English to Japanese" is selected.

Ok, that was easy - just connect a method to the switch and code it like this:


-(IBAction)switchEnglishToJapanese:(id)sender {

if(englishToJapanese.on){

self.multipleChoiceInEnglishLabel.hidden = YES;
self.multipleChoiceInEnglish.hidden = YES;

}
else{

self.multipleChoiceInEnglishLabel.hidden = NO;
self.multipleChoiceInEnglish.hidden = NO;

}
}


Ok, so, I have a couple of options for this program. My daughter actually had the idea of truncating the hirgana suffixes/prefixes of the question, then having the multiple choice be kana, but with the kanji root separated from the hiragana suffix by parens or better yet a dash or a dot.

If it's a compound kanji, then just choose compound kanji for the possible answers.

The first thing I'll need to do is loop through the word, identifying if it has a hiragana prefix or suffix. If so, extract the root, and display that.

Then, when searching for answers, look for *any* words that have a suffix or prefix. The suffixes no long have to match.

Then just display the kana with an intervening dot or whatever.

If there is no suffix, then look for words that *don't* have a suffix. And just display the whole suffix.

Don't bother doing that for anything where the vocabulary is only kana.

This is great. It will be much cleaner code, and also a better test.

Ok, this is interesting. Here's how you loop through a string:

NSMutableArray *characters = [[NSMutableArray alloc]
initWithCapacity:[myString length]];
for (int i=0; i < [myString length]; i++)
{
NSString *ichar = [NSString stringWithFormat:@"%c", [myString characterAtIndex:i ]];

[characters addObject:ichar];
}

Now, what this algorithm need to do is, when it's getting potential answers, it has to keep looping until it finds one. This won't be difficult, because most words will fit the solution. But, I'll probably call this as a method which has the infinite loop internal to itself, and just returns the word when it finds one. And I'll call it four times.

The method will just loop, and check to make sure that

1. It's not kana only
2. It's not katakana
2. If the question has trailing hiragana, it has trailing hiragana and
3. If the question doesn't have trailing hiragana, it doesn't have trailing hiragana

The check for trailing hiragana can be a utils method. It will ignore the first character, and then check if the any of the subsequent characters are < ”あ" and greater than　"ん". If so they aren't in the hiragana range.

Also, to check for katakana, do the same thing for the corresponding katakana values.

For safekeeping, this is the hiragana range in Unicode:

Hiragana. Range: 3040–309F.

Unicode range · U+30A0–U+30FF

-- to be continued ---