I interviewed Jason Hudgins about our new bug checker feature in ShopSavvy:

Q: How does the application know it crashed?
A: I wrote a custom exception handler to replace the DefaultExceptionHandler, the default one normally just shows the user a dialogue box that informs them that the app crashed).  Our custom handler still shows this same message, but in the background it collects some data and attempts to send it back to our server.  It’s completely transparent to the user.

Q: What data is sent back when the application crashes?
A: The phones unique id, a timestamp, the app version number, and a stack dump that can usually tell us exactly where a fault in the application occured.

Q: How many crashes did we see in our most recent release (Mothra)?
A: 151 – it’s mainly 2 or 3 minor bugs that are re-occuring, i’ve got some fixes ready to go.. the majority of our users aren’t likely experiencing any problems.

Q: Is this feature unique to ShopSavvy?
A: TuneWiki is the only other app that I know that does this.. Zach Hobbs was telling me about catching lots of obscure bugs in TuneWiki with it, and I thought it would be a good idea to do the same thing for our app.

Q: Should all mobile applications have this feature?
A: Probably…

Q: How much overhead does it add to the application?
A: Not much, I’d say it’s about 150 lines of code or less, our entire app is over 20k lines of code. It doesn’t log *everything*, for example the force close bug we had with 3.1.0 didn’t use the defaultexceptionhandler, so it doesn’t show up in our logs