To refactor or not to refactor...

When I first started Android programming for real earlier this year, I was trying to figure out way to save transitory data plus have data accessible between activities. I extended the ApplicationContext to create a class called "AppState", where I stored all those variables. In order to preserve them when the app was terminated, I would persist the primitive variables in AppState to shared preferences.

This makes things a bit more complicated than they need to be. For primitive variables, I could have just gone straight to the shared preferences without troubling the AppState object. I keep meaning to do this, but something more pressing always seems to arise. Well, with a good 1/2 hour of bug-free testing this morning, that time has come. In addition, I figured out yesterday that by doing things slightly differently, and better, I don't even need four of those variables. Nice.

So, here's the plan. The first thing I'm going to do is comment out the primitives that can be handled directly in SharedPreferences, one or two at a time. I've already set up a SharedPreferencesUtil that gets and stores the data just like regular java bean.

So, without further ado, let's get this long-overdue refactorization underway.

We'll run a quick check first to make sure the project restore discussed in the last post didn't cause any problems.

Ok, seems to be ok. Here we go.

Actually, it will be better to find all the references to them first, and use the new shared pref util to save/access them.

Ok, here's the first one:

int quizStartNum = SharedPreferencesUtil.getQuizStartNum(this);

if (quizStartNum <= 0) {
quizStartNum = 1;
}

SharedPreferencesUtil.setQuizStartNum(this, quizStartNum);

The next:

int quizEndNum = SharedPreferencesUtil.getQuizEndNum(this);

DataBaseHelper dbHelper = DataBaseHelper.createDB(context);

int quizEndNum = SharedPreferencesUtil.getQuizEndNum(this);


if (quizEndNum > dbHelper.getLevelCount(jlptLevel) + 1) {
quizEndNum = dbHelper.getLevelCount(jlptLevel) + 1;
}

Well, this is a fairly extensive change. I'm thinking that as i go forward, I'll utilize the shared settings. But, there are some conveniences to having everything available from the app object. It's just that it's a pretty significant change, and I'm not convinced the gain is worth the effort - and the risk. Going forward, I'll go straight to shared preferences. Or, perhaps better, have app state handle the get and set from shared preferences, in it's getter and setter methods.

Let's have a look at that...

Ok, this looks better. I'm making the appState.quizStartNum private, and adding getter and setters.

Well, it's still going to take a while, although this would be a better approach. I'm just not convinced the time investment is worth the benefit. I'm going to pass this one for now - I think it's the safer, and faster option.