We recently started getting complaints from users that followed the form:
“I just installed the Android 2.2 update [aka, Froyo] on my phone and Lightning Bug now force closes as soon as it opens!”
First, rest assured we do, in fact, test every release of each of our apps on as many platforms as we reasonably can. Of course, defects will still get by us! In this case a subtle, yet critical, bug did just that. The bug is fixed and patched in our 2.2 release of Lightning Bug. For a little more info (and a little insight into what it’s like developing on Android) keep reading…
When a user reports a force close to us we take it very seriously. The first thing we do is try to recreate the bug with our own phones and emulators. If we can recreate the issue, we smile anxiously to the code kahunas, debug the app, patch the code, and post an update to the Android Market. If we *can’t* reproduce the issue, we give a somewhat different look to the code kahunas, and typically ask the user a long series of questions.
The latter was the case for our Froyo bug. Wow we hate it when this happens! We know there’s an issue, but we have no idea what it is! We started telling users to re-install Lightning Bug, and for the time it seemed that re-install fixed the issue. Of course, this is a work-around, not a “fix” strictly speaking.
For a few days we had affected users re-install Lightning Bug, and hoped reports of this issue would just die out. Then, as fortune had it, we started seeing a crash report in our Market account that seemed to coincide with the reported issue. For those of you that don’t distribute apps on Android, there’s a website publishers log into to publish our apps and that, as of only very recently, started giving us crash reports on our apps.
After looking over the crash report, here’s what we found:
Since version 1.0.8 Lighting Bug has offered an integration feature with the built-in Android alarm clock. But not all Android phones come with the stock Android alarm clock, so this feature is automatically disabled if the built-in alarm can’t be found on the local system. If the Android alarm clock is available and the Lightning bug integration feature is checked by the user, Lightning Bug shows an Alarm icon in it’s main screen whenever a system alarm is active.
This has been all well and good for us so far. However, as of Froyo, the built-in alarm has changed and now has a different internal name than the old built-in alarm.
The result? Well, if you use the built-in alarm clock application you should be happy, the new app is a lot slicker than the old one. But, if you were a Lightning Bug user with Use System Alarm checked before the Froyo update, you got a force close every time Lightning Bug opened!
Why? Once a user checks the Use System Alarm option in Lightning Bug’s clock preferences screen, Lightning Bug just assumes the System Alarm was available. After all, the user couldn’t check the option if a built-in alarm couldn’t be located in the first place. This assumption, clearly, is poor when you consider that the built-in alarm may become unavailable *after* the user has enabled the integration feature!
So in our case, users had checked the Use System Alarm preference before Froyo and everything worked fine. Then they installed the Android update, the old system alarm was replaced with the new system alarm, and Lightning Bug, not knowing better, tried to query the old built-in alarm app for active alarms.
The mistake we made was in not coding Lightning Bug to be smart enough to deal with exactly this situation. Or look at it this way … coding applications, generally, involves making lot’s of assumptions. The consequences of bad coding assumptions are notorious … y2k, code red worm, etc. But the consequences of good coding assumptions should be equally obvious ever time you Google something!
Android puts particular stress on this “art of the assumption” … OS updates are relatively frequent, new devices come out every month, and now Google’s activating something like 200K new Android users daily. This is not a complaint of course, just a comment. While it’s true that, in general, the more complex your software gets the more stress your assumptions will have to weather … Android makes this doubly true, so code with caution!