Question

I’ve got an android app that pulls a random 20 questions (rows) as a cursor from a SQLite DB and loops through all the questions to ask the user all 20 questions.

Is there some way to save the cursor’s state/location when the activity is paused or stopped so that when the activity resumes the cursor is restored and in the same position as it was when the activity was paused/stopped?

If you need me to post my code just ask.

Thanks for your time!

Answer 1

Getting it to save the position it was at is very easy, just put some code in the onPause method like so:

protected void onPause(){
 position = yourCursor.getPosition();
 super.onPause();
}

where position is a class field (i.e. declared outside of any method, usually at the top). Then in onResume you can just move your cursor back to that position. If you aren’t familiar with onPause()/onResume(), read up on the activity lifecycle. However, I suspect you want to save which questions were randomly selected as well. I don’t think your cursor would persist across the onPause/onResume since they’re generally closed in onPause to avoid memory issues. The only thing I can think of, but I’m no expert, is that you’d have to save the rowIDs of the questions and then requery the database to get those rows. How clumsy that solution is depends on how you query for the random questions in the first place. If you already generate 20 random numbers and then feed that into your query, then you can just reuse the same method but with the 20 saved rows instead.

---

This was too long to fit as a comment:

@Ryan: Indeed, saving the position without the cursor state is pretty useless if you can’t recreate an identical cursor – that’s what I was saying in the second half of my reply. I assume that your RANDOM() is a standard SQL function? (What’s the syntax for that in Android by the way? I couldn’t get my database to accept it.) If so, then you might have to do the brute force method to recreate your cursor. By that I mean requery the database with a “rowId = ? OR rowId = ? OR rowId = ? OR….” with the selection args being the rowIds you retrieved from your original cursor. It’s not pretty and there’s probably a better way to do it, but that will work. Building the SELECT String would be easy with a loop like so:

String selectQuery = "";
String[] selectArgs = new String[savedRows.length];
for (int i = 0; i < savedRows.length; i++){
    selectQuery = selectQuery.concat("rowID = ? OR ");
    selectArgs[i] = Long.toString(savedRows[i]);
}

//Remove the last " OR " you'd have in the string
int index = selectQuery.lastIndexOf(" OR ");
selectQuery = selectQuery.substring(0, index);

This is assuming that you save your rowIds from the original cursor into a long[] savedRows in the onPause method. You can then pass those into a new database query.

---

Again, too long for comments:

@Ryan: Good point, they might not get pulled back in the same order. You could experiment to see, but it’d be hard to tell whether it was fluke or by design that it was always returned in the same order. Ok, idea number 3 then is creating an intermediate table which is filled with the 20 random questions. This table would have a column for its row number (giving you the order of the questions) and then a foreign key column with the rowId of the question in the questions table. Retrieving your questions in the same order from this table would be easy, and you could drop the table once the user finishes all the questions. Or, you could even keep the table so that the user can see how well they did on past question sets – but that’s a whole different feature.

Note: I should have mentioned onSaveInstanceState as well in my first post. onPause is a good place to make quick saves before changing activities, but simply saving the position into an int isn’t foolproof. Obviously it resets when the user starts a new quiz (as it should), but it also resets if while the user was looking at another activity, the OS had to kill your process for memory. In that case, when the user returns to the activity it has to restart from onCreate, and thus it loses variable data. This is intended to work with the onSaveInstanceState() method, which supplies you with a Bundle into which you can save your data. This same Bundle is then supplied in onCreate, allowing you to reload whatever is necessary and make it look like the app was never killed.