A rather annoying “feature” of Android is the fact that screen rotation causes recreating the current activity from scratch. While this is quite reasonable, it has an undesired side effect: most data are lost. (What is left is the state of widgets having an id.) In Logeox, this is not what I would like to have: if I rotate my phone (and that might happen by accident!), all my drawings are erased.
The problem is: what do I do with it? Quite surprisingly, the solution seems far from obvious. After about an hour of reading and experiments, here’s what I learned and did.
There are a few options to make data persist after recreating the activity. You can pass them around in a Bundle, you can make your data Parcelable, you can use Serializable or JSON, or you can use an (a bit dirty) hack with retaining them in a dummy Fragment. (Of course, there are also more heavy-weight solutions like keeping them in an SQL database, or even a file in internal storage.) I decided that keeping them in a file or database was not what I wanted – after all, it’s just a question of saving a few kilobytes while the app is running. OTOH, since I’d like to explore the possibilities of actually saving some drawings to disk, I keep those approaches in mind.
I started with trying to make a TurtleCommand a Parcelable. After some time spent coding, I have to admit it didn’t work. I couldn’t even make it compile, and I’m not really sure what was the reason. (One of the problems was that I didn’t want to repeat nearly identical code in all TurtleCommand’s descendants.) In Parcelable, the approach is to break up your object into simpler types and “write” them to the “parcel” consecutively. In my use case, however, one of the important characteristics of the command is the actual type. I tried to use Java’s reflection mechanisms to convert it to a string (not optimal, but I wanted to get anything to work first) – which was easy enough – but I failed to recreate the object from my “parcel”.
After this failed experiment, I was torn between Serializable (which seems to be generally hated on the Interwebs) and JSON (which would be a no-brainer had I coded in JavaScript, but I’m a bit afraid of juggling with converting types into strings and back again). After some thinking, I decided to go with the Fragment way. It seems vary hackish, but hey, this is what Google engineers do, it must be wise!
Surprisingly, it worked. Well, almost: the starting position was somehow getting messed up. It turned out that the timing problem I wrote about some time ago hit me again, and after using a Runnable everything went smoothly.
I have to say that I’m really tempted to throw all this away and do it again in JavaScript. I’m pretty sure it could be coded in half the time I made this half-baked Java/Android experiment. Of course, I’m going to resist the temptation, though now that the contest is close to finish (and I’ve started working on other things, some quite time-consuming), I certainly won’t be able to spend a lot of time on Logeox. I think the time has (almost) come for some kind of summary of all my Android-related effort – expect such post this week. Spoiler: I’m really glad that ten weeks, coding less than half an hour a day on average, was enough to have something that my daughter (sort of) likes – and is (sort of) usable, even though I didn’t manage to put any programming-related stuff in. (I’m probably going to release an APK file soon anyway – I’ll have to do a few finishing touches, like adding an “About” screen or changing the icon from the default etc. In the current state of affairs, though, putting it in the Google Play Store wouldn’t make much sense, though.)