Radio Button blues

Now we'll clean up the leftovers from this morning's potpourri of items. We didn't do to badly - only two or 3 remain.


2. The verb to go, iku, has two correct pronunciations which both appear in the same list of possible answers much of the time. I will be putting in some code to avoid that.

6. The draft of the app for JLPT 4 needs to be reloaded to the android marketplace, as I'm getting a "app not managed" error when I attempt to install.

7. I also will do some more testing for the crash coming back into QuestionActivity after killing the app.

This change needs to be tested:
9. A lot of the words at some of the levels have multiple meanings in English. To keep the scrolls from getting to wordy, I cut it off at 2, but it seems as if it's cutting off at one. I'll look into that.

Ok, the real programming one is the fix to 行く, いく"iku" i.e. "to go", question. It could be tricky. What the code does is it looks for matching groups of words by suffix.

So, here's the code for the fix. Kind of hacky, but I don't see another easy way around it.

// Don't give two valid choices

if ((question.kanji.equals("行く"))
&& (question.hiragana.equals("いく"))) {
if (fullGuess.equals("ゆく")) {
continue;
}
}

if ((question.kanji.equals("行く"))
&& (question.hiragana.equals("ゆく"))) {
if (fullGuess.equals("いく")) {
continue;
}
}


Ok, let's run it. What number is iku? 34 on the frequency list for level 5.

I just found a bug. I save the mode and exit automatically on the settings activity. But that means if you've changed the other settings, basically start and end quiz number, they don't get saved. There's a reason why save and finish on the mode change. It might be because the save button is already doing all this validation. So, what I might do is create an nested class instead of the current anonymous inner class to save the settings, and call a common save method from the OnClickListener's OnClick method.

Ok, I've created the nested class first. Lets test that.

Ok, seems to work. Now lets refactor the save into a separate method from the onClick.

Wait - that has a view passed to it. What is the view it's passing? Probably the layout...

Ok, SO give this solution:

findViewById(android.R.id.content)

Actually the extracted method doesn't even use view:

public void onClick(View view) {

validateSettings();

}

Let's test that...

Hmm...the licensing service timed out. That's not good.

Ok, it went through this time.

Ok, that worked. Now, let's make that nested class a member, then call the validate method from the radio button methods.

Ah, the problem is that the validate method does a finish if it's valid. So, if the radio button saves the setting, but it's invalid, then what? The user may back out, but is suddenly in a different mode without realizing it. So, I guess I have to have the validate return a flag. Ugh.

The best solution is to incorporate the radio button update routines into the validation routine.

Sugar. I'm almost there, but the change to browse mode requests a confirmation. What if they say no? It should be in the validation part.

Well, then if it's valid, it's got to separate out the update part until the validated completed section.

You know what, this is getting too complicated. I'm backing it out.

I'm just going to save the radio button settings when they press the save button...but what if the user backs out? That yes/no dialog on browse mode is killing me. But it's important

Well, I'll just make it part of the validation routine. Just the warning message.

The basic question is how to I get the yes/no message back from the dialog to the validation routine? Do I set a member variable? Can I set one?

I guess that's the way I have to go. Ok, this is in the validation routine:

if (valid) {
// sets a member variable to indicate user agreement
SettingsActivity.this.confirmBrowse();

if (!SettingsActivity.this.mConfirmedBrowse) {
valid = false;
}
}
}

if (valid) {


// validation successful

// Perform action on clicks
RadioButton rb = (RadioButton) view;

if (rb.getText().equals(
SettingsActivity.this.getString(R.string.srs))) {
SettingsActivity.this.handleSRS();
}

if (rb.getText().equals(
SettingsActivity.this.getString(R.string.browse))) {
SettingsActivity.this.handleBrowse();
}

if (rb.getText().equals(
SettingsActivity.this.getString(R.string.autoplay))) {
SettingsActivity.this.handleAutoplay();
}

// rest of validation and save

Wow. I could've let that one go. Let's test it anyway.

Man - two consecutive timeouts from the license server! That's bad. I haven't seen this before. Maybe reboot the phone...

There we go. I'm sure I'm going to have a lot of issues with that thing.

Sugar. It turns out, there are three radio buttons. The text I'm using assumes it already has the one selected, since the radio listener has it passed it to. Hmmm...probably, what I should do is find each of them, and check which of them is checked. It's getting ugly.

What if I just let it go? It's just a program limitation - a minor inconvenience. Yeah, I'm going to drop this. I might put in a warning later. It still would be ugly code.

I have a good idea. For now, I'll just disable the radio buttons if the numbers get changed. I found some sample code on google:

editText.addTextChangedListener(new TextWatcher() {

public void afterTextChanged (Editable s){
Log.d("seachScreen", "afterTextChanged");
}
public void beforeTextChanged (CharSequence s, int start, int
count, int after){
Log.d("seachScreen", "beforeTextChanged");
}
public void onTextChanged (CharSequence s, int start, int before,
int count) {
Log.d("seachScreen", "onTextChanged");
}


Let's try this:


private TextWatcher textWatcher = new TextWatcher() {

public void onTextChanged(CharSequence s, int start, int before,
int count) {
disableRadioButtons();
}

@Override
public void afterTextChanged(Editable arg0) {
// TODO Auto-generated method stub

}

@Override
public void beforeTextChanged(CharSequence arg0, int arg1, int arg2,
int arg3) {
// TODO Auto-generated method stub

}
};


private void disableRadioButtons() {
this.radioButtonAutoplay.setEnabled(false);
this.radioButtonSrs.setEnabled(false);
this.radioButtonBrowse.setEnabled(false);
}


Ah, good. That at least keeps them from setting the buttons and losing their changes. It would be good if I could somehow gray out the labels? Naw, I've sunk enough time into this.

Ok, let's get back to what we started out with. Testing the something? Oh, yeah, the verb 行く。

And it didn't work!

Well, in the debugger, the text shows up as gargled. Ah, there we go. This time, it offered to save as UTF-8, which is what I was looking for.

Let's try it again.

Ok, now it worked.

Already, how about kill and restart question activity? No problem. Try again in SRS mode. Ok, seems to be ok.

Ok, let's add the draft of the second level to the marketplace.

First, create a copy of one of the other shell projects.

svn export JlptQuiz5Full JlptQuiz2Full

Import to eclipse project - file, import etc.

Refactor / rename the package from com.kanjisoft.jlpt5.full to com.kanjisoft.jlpt2.full

Go into strings.xml and change every 5 to 2 (all 3 entries)...

Export the apk into deploy as unsigned, that's Android tools, export unsigned.

./adbinstall ../JlptQuiz2Full

Ok what's the url of the marketplace? I think I bookmarked it in firefox.

I didn't change the manifest, it thinks I'm updating the old one. That's good - that means updates should be relatively straightforward.

Ok, let's run it.

Ok. That works.

Right now, to my knowledge there are zero bugs. But of course, this will change totally once somebody starts using it. Another problem is it's only been tested on one device - mine, a stock Android Nexus One.

There are tons of enhancements to be made, but this is where I needed to be to put this stuff on the market. So, maybe, finally, can we do that on the next post? I'm keeping my fingers crossed.