How to improve your application : a crash reporter to improve stability !

What is a crash reporter :
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 :

Introducing the X Phone

Sorry...
Couldn't help...

(note that it is in German, but you don't need to understand what is said to fully appreciate this video )
- thanks Dom for this link !!

Google To Acquire AdMob

It is official : AdMob is now part of Google !

This is kind of funny :
Google is the giant Leader of virtual ads.
But on its own OS, its ads solution is still not ready ( it is still in beta state for the moment, and only avalaible for people with 100 000 pages views / day -sic- )...

So it just bough the current leader on mobiles !

Tutorial : How to customize your toasts !

Toast, despite their strange name that an average french developer like me doesn't understand, are really usefull in Android world ! Specially for developers !

The Standard Toast with butter :
It is obviously a easy and quick way to send text feedback to the user and the developer ( as it is a nice tool to give feedback ).

Toast.makeText(mCurActivity, text, Toast.LENGTH_SHORT).show();

This line has been used such a number of times in my programs, and in many others !


The Toast with orange jam :
But the standard 'look and feel' of your toast does not necessarily fit your application's look. And the default position can be a issue too.
In Word Prospector, I give feedback on whether the word is correct with a toast. But at first this toast was over my game board, preventing the player to click on some letters !

Then enters the toast customisation !!

Here's I changed the position of my toast, in order to have it in the right - bottom corner, and its background, so it's like the others gui element of the page !

To change the toast position, you have to use the setGravity Toast method. You have to provide the gravity of your toast ( this strange Android beast that indicates where your gui element will end up being ), and you can refine this position by some offsets.

To change the style of the toast is also easy :
The default toast is made of a textView.
You can actually access this textView, and change anything you want inside ( in my case, the background image, but you can imagine changing the font, or the text color / size, ... )

Here's my code to change the pos and the background :

protected void ToastMessage( CharSequence text, int ToastPos )
{
Toast toast = Toast.makeText(mCurActivity, text, Toast.LENGTH_SHORT);
View textView = toast.getView();
switch ( ToastPos )
{
case TOAST_LEFT_POS:
toast.setGravity( android.view.Gravity.BOTTOM | android.view.Gravity.LEFT, 00, 0);
break;
case TOAST_CENTER_POS:
toast.setGravity( android.view.Gravity.BOTTOM | android.view.Gravity.CENTER, 00, 0);
break;
case TOAST_RIGHT_POS:
toast.setGravity( android.view.Gravity.BOTTOM | android.view.Gravity.RIGHT, 00, 0);
break;
}
textView.setBackgroundResource( R.drawable.textview);
toast.show();
}

The toast with butter, and orange jam, ... and some chocolate...
Do you want more customisation ?
You can actually change the textView inside the toast by any view you want... Any view.... Including a custom view declared in a Xml file, and that you can inflate inside your toast...
In this case, you can easily add several lines, or images, or whatever you want !

No Toast with orange jam and chicken wings allowed !!
Despite being a really nice to tool to master, the toast is limited in two ways :
* You don't have control on the toast duration. Actually there are only two states LENGTH_LONG and LENGTH_SHORT. Note that I imagine you can force the closure of a toast with the cancel method ( I didn't test it )
* More important : you can't have several toasts at a time ! So if you need to display a new toast and old one is already present, the new one will be queued by the system, and wait for the old one to disappear. At some times, it can be a important limitation, as it means you can't control the feedback your giving will apppear at the correct moment !
You can try to close the first one in order to display the new one ( with the cancel method... Remember ? The one I didn't test ), but in some cases the two toasts should be at different places, and you want the user to see and have time to read both of them !

Tutorial : how to use the LED with Android phone

Some android phones have a nice LED ( but not all of them: I don't think the Galaxy has one ).

This LED can show lots of different colors, and adding this feature in your application is a nice little "plus" !
And it's really easy...


So how to do it ?

You just have to get the notification manager, and use it to send a flash Light notification.
The notification contains the color light, the duration with the LED On, and the duration with the LED off.

Here's the code :

private void RedFlashLight()
{
NotificationManager nm = ( NotificationManager ) getSystemService( NOTIFICATION_SERVICE );
Notification notif = new Notification();
notif.ledARGB = 0xFFff0000;
notif.flags = Notification.FLAG_SHOW_LIGHTS;
notif.ledOnMS = 100;
notif.ledOffMS = 100;
nm.notify(LED_NOTIFICATION_ID, notif);
}

LED_NOTIFICATION_ID is just a value to register this allocation. In my case, it is just 0.
Here, the LED will flash with the color given by the parameter ledARGB, in this case 0xFFff0000 (red ). It will be ON for 100 milliseconds, then OFF for 100 milliseconds, and then loop back ON, etc...

This is nice, but wait... How do I STOP it ?
This code will let the LED flash for ever !

To stop it, we have two solutions :
1) decide to only have the LED flash once, so in this case, you have to add the FLAG_ONLY_ALERT_ONCE flag :
notif.flags = Notification.FLAG_SHOW_LIGHTS | Notification.FLAG_ONLY_ALERT_ONCE;
2) Let the LED flash for as long as you want, then cancel the notification. In my case, I stop it after a certain amount of time by posting a message with a delay.
Here is the full code for this :

private void ClearLED()
{
NotificationManager nm = ( NotificationManager ) getSystemService( NOTIFICATION_SERVICE );
nm.cancel( LED_NOTIFICATION_ID );
}
private Runnable mClearLED_Task = new Runnable()
{
public void run()
{
synchronized( LetterGame.this)
{
ClearLED();
}
}
};

private void RedFlashLight()
{
NotificationManager nm = ( NotificationManager ) getSystemService( NOTIFICATION_SERVICE );
Notification notif = new Notification();
notif.ledARGB = 0xFFff0000;
notif.flags = Notification.FLAG_SHOW_LIGHTS;
notif.ledOnMS = 100;
notif.ledOffMS = 100;
nm.notify(LED_NOTIFICATION_ID, notif);
// Program the end of the light :
mCleanLedHandler.postDelayed(mClearLED_Task, LED_TIME_ON );
}

With mCleanLedHandler being just a handler, and LED_TIME_ON the flash duration.

Some notes :
1) Don't let a handler alive when changing activity ! On the OnPause of your activity, clear the handler :
mCleanLedHandler.removeCallbacks( mClearLED_Task );
2) programming the LED suffers one issue : the emulator does not emulate the LED at all... So you have to use a real device to see what it looks like ( but anyway, you always use real device at some point, don't you ? :) )
3) programming the LED then suffers a Second issue : when the real device is connected to your PC in order for you to develop / test / debug, the device is also charging the battery. And in this case, the LED is orange. Whatever notification you send ! So you have to test without your device plugged !


That's all !
With all that, you can code some nice LED flashes !!!