One condition for success, when shipping an application is that it should be as stable as possible !
And to achieve this, you have to test as deeply as possible your application. But :
1) If you are alone, it is a time consuming task,
2) It's still easy to miss some bugs, some special cases.
On the other hand, if you have a lot of users, the application will be launched a lot of times, a lot of special cases will be experimented by users, so they will suffer from unexpected crashes.
So we have to collect informations on the crashes that occurs on the end user device !
This is what a crash reporter is doing : whenever your application crash (and don't be over confident, it WILL happen ), it sends you informations on the conditions of the crash...
Don't get me wrong : the end users should not be your testers. If your application is full of bugs, they won't use it anymore, and you're just loosing your time ! But if you estimate your application is safe enough, and that you can't find any more bugs, publish your application with a crash reporter : you'll see all the 'other' bugs. The ones that result from situation you didn't imagine, and that really happen on your customer mobiles !
So what is in the crash reporter :
A crash is made of two different parts : the first one that collects information, and the second one that sends this information to you.
Note that there are already some packaged solutions for this, like this one :
http://code.google.com/p/android-remote-stacktrace/
But I preferred to create my own one (is it a good solution ? )
What to report ?
For each report, I chose to report as much information as possible. That includes :
- The callstack
- The information about the system that android provides me ( like the device type, the OS version, the application version, ...)
- The avalaible memory ( memory is one of the most common issue in small mobile world ).
How to report ?
Most of the crash reporters I saw or heard about are using a Http connection silently opended to send the information to a Php wbe server that will store the issues in a database.
But I prefered to simply use mail :
Pro :
- Simple to implement,
- No server side code to make / test / debug,
- gmail will automatic dealed with cases where there is no internet connection,
- Let the customer know that his problem is taken care of,
- Let the customer know exactly what informations he sends you,
- Involve the customer in the quality of your program ( if he didn't send a report, he can hardly complain the application is still bugged, so he 'should' be more tolerant).
Cons
- All customer won't send the report !
- Some customer could fake it ? That would be strange, but we definitively live in a strange world... So better be prepared to it !!
- If you have a lot of bugs / a lot of customers, you can finally have a lot of mail to treat !
- A Web/database solution is way easier to use for creating analysing tools ( like counting the occurences of each bugs, linking it to a version, etc ... )
So as you can see, each solution has some advantages. I would say if your application is big, go for a web/database solution.
In my case, I knew ( actually I hoped ) I hadn't a lot of bugs, so I chose the mail solution BECAUSE IT IS WAY SIMPLER TO DO !!
So here is the code :
