Cleaning out the closet

There is another bug I need to fix up. This one has to do with the settings when the app is newly installed. What I want to do is make sure that it default to the correct start and anding numbers on a clean install. So, what I'm going to do is clear the settings from the code. How do you do that?

How about creating a method in Utils:

public static void clearPreferences(Context context){

SharedPreferences sharedPreferences = PreferenceManager
.getDefaultSharedPreferences(context);

SharedPreferences.Editor prefEditor = sharedPreferences.edit();

prefEditor.clear();
prefEditor.commit();

}


Ok, delete the app from the device using adb shell:
$ adb shell

$su
# cd sdcard/data
# ls
com.innovativelanguage.wordpowerlite.jp
com.keramidas.TitaniumBackup
# rm ./.com.myapp.jlpt/jlpt.db
#

Clearing out the db isn't completely necessary, but srs mode uses it to access questions.

Ok, let's add the code to clear the preferences using the previous method:


InitUtils.clearPreferences(appState);


The appState object extends the application, so it's a bit redundant to access it twice, but

Ok, let's run it...

Cool. Actually, it's 1 to 10, but that's what I wanted.

Ok, I'm going to freeze the level now, as I'm selling level separately.


mLevel.setEnabled(false);

And uncomment the code to move the starting cursor back to the quiz start num:


quizStartNum.setFocusable(true);
quizStartNum.requestFocus();
quizStartNum.setSelectAllOnFocus(true);

And run it...

Ok, it's working great. Now let's try running exercisor monkey...


adb shell monkey -p com.jlptquiz.app -v 5000

Hmm...it only lasted 1500 events. What's the problem:

D/QuestionActivity( 4861): >>>>>>>>>> childCount: 4
D/PlaySoundUtil( 4861): playSound
D/PlaySoundUtil( 4861): playSoundFile start
D/UpdateSRSUtil( 4861): ========================== SRS ===========================
D/UpdateSRSUtil( 4861): Secs Remaining: 0
I/StagefrightPlayer( 68): setDataSource('/mnt/sdcard/data/com.myapp.quiz/audio_files/4_546.mp3')
D/PlaySoundUtil( 4861): playSoundFile end
D/PlaySoundUtil( 4861): playSound end
W/AudioFlinger( 68): write blocked for 159 msecs, 17 delayed writes, thread 0xea00
D/dalvikvm( 454): GC_EXPLICIT freed 39K, 49% free 2779K/5379K, external 1625K/2137K, paused 80ms
D/UpdateSRSUtil( 4861): Update execution time was 0 ms.
D/UpdateSRSUtil( 4861): Insert execution time was 2876 ms.
D/UpdateSRSUtil( 4861): Method execution time was 2883 ms.
E/MP3Extractor( 68): Unable to resync. Signalling end of stream.
D/dalvikvm( 2204): GC_EXPLICIT freed 125K, 49% free 2829K/5447K, external 1625K/2137K, paused 65ms
D/AudioHardwareQSD( 68): AudioHardware pcm playback is going to standby.
D/dalvikvm( 478): GC_EXPLICIT freed 51K, 49% free 2743K/5379K, external 1625K/2137K, paused 56ms

Unable to resync from mp3 extractor? Hmmm. What's the monkey output?

:Sending Pointer ACTION_DOWN x=126.0 y=474.0
:Sending Pointer ACTION_UP x=126.0 y=474.0
// NOT RESPONDING: com.jlptquiz.app (pid 4861)
ANR in com.jlptquiz.app (com.jlptquiz.app/.QuestionActivity)

Load: 3.15 / 2.31 / 2.27
CPU usage from 8790ms to 3689ms ago:
36% 4861/com.jlptquiz.app: 35% user + 1.3% kernel / faults: 2471 minor
24% 101/system_server: 16% user + 7.4% kernel / faults: 859 minor
21% 57/mmcqd: 0% user + 21% kernel
5.6% 4912/com.android.commands.monkey: 5% user + 0.5% kernel / faults: 124 minor
3.3% 172/com.google.android.inputmethod.latin: 2.1% user + 1.1% kernel / faults: 13 minor
1.3% 73/akmd: 0% user + 1.3% kernel
0% 68/mediaserver: 0% user + 0% kernel / faults: 51 minor 31 major
0.7% 157/com.android.systemui: 0.7% user + 0% kernel / faults: 13 minor
0.7% 4920/com.google.android.music: 0.5% user + 0.1% kernel / faults: 69 minor
0.3% 217/com.google.process.gapps: 0.3% user + 0% kernel
0.1% 2204/android.process.media: 0% user + 0% kernel / faults: 18 minor
0% 47/file-storage: 0% user + 0% kernel
0.1% 74/adbd: 0% user + 0.1% kernel
0% 197/com.android.launcher: 0% user + 0% kernel / faults: 5 minor
0.1% 2880/com.android.browser: 0% user + 0.1% kernel / faults: 1

I think this might have to do with the fact that, since I added the SRS mode, it takes longer to bring up the questions, since they are accessed in order of schedule date, over a srs joined view. A couple of options here are to get rid of the view and incorporate the schedule data directly into question. Another would be to put the access of the data into a thread using AsyncTask, but I'm not sure I want to let the user do anything until the data returns.

Well, one way to test it is to disable srs mode. Hmmm...well, let's just first run it again. Well, it made it through 5000 events this time. Let's make it 10000.

Cool, that finished with no problem. Let's up the ante to 50000.

Well, how do you like that? It made it through. Usually it crashes on an ANR or zero children on the list, which I refuse to fix because there's no chance (I think) the user will go so fast that the list doesn't have time to populate. Ok. Let's ramp it up to 100k.

And it made it! I don't know why all of a sudden it's just getting done. But, it's starting to get to the point where I'm thinking, just ship it, baby, just ship it.

Well, that's wrap for now. Hopefully, I'll be dealing with how to release issues in upcoming posts.