First, I just want to point that I'm not in any way affiliated with Flurry, and blablahbla.... :
NO I DON'T KNOW THOSE GUYS... I just tried their tool !!
What is Flurry ?
When you launch a new application, it's always great to have some feedbacks on it.
There are many different feedbacks : error reports, user evaluations, user mails, online scores, or... 'some' statistics.
It's useful for two different things :
* for your ego, it's always a good thing to have some feedback that basically says that people are trying your application. It's even better if they say they like it ! Even if you don't have the super-developed ego that most developers have, having this kind of information is good for motivation, and helps you improve your application ! As strange as this point may sound, I think it is really important specially if you are an independant developer, as you will need some motivation !
* It's also crucial if you want to know who your application users are, and how they use it ! It will let you analyse what is good in your application, what are the weaknesses, where to put your efforts in order to satisfy your users...
As I had embedded AdMob ( the now famous ads provider for Android ), I already had some sort of feedback for a while : the number of ads impression for every day. It gives me an indication on how many users are playing my game, and on how this number is evolving.
Flurry ( actually Flurry Analytics ) gives you a lot more statistics on the users and on how they use your application.
How to integrate Flurry ?
The integration of Flurry is really easy.
Create an account on their web site, register your application, add the jar in your application, and copy paste some code on each activity, and voilà ! your first integration is done !!
I also added some special events, in order to know which activity was started, and which game mode was used ( the game has 6 different game modes ).
This is a very good point with this middleware !!
What indications Flurry provides you ?
Flurry provides you informations on :
* users : how many users you have, whether they keep on using your application, how many times did they use it every day, how many sessions you have, how long is a session, and where do they come from.
* Technical : info on which phone was used, which carrier, which firmware, and a simple error reporter is provided ( that does not seem to interfere with mine !! )
* Events : Events are special signals you put in your applications and that are collected by Flurry. You basically do whatever you want with them !
By the way, the information is nicely presented, with some beautiful graphes that make it easy to get the information quickly !
How useful is this information ?
To be honest, I'm kind of fascinated by all this feedback !
All of it is not useful, but it's really interesting to navigate throw this pages and graphes on my game !
In the user pages, you can see the evolution of the way your application is used : if it keeps on increasing.
For instance, I really did see the Chrismas effect : the number of new users has really increased after the 25 !
Welcome to all of those new Android Owners !!
The technical part is also really interesting :
* The firmware versions are divided in about one big third Android 1.5, another third Android 2.0.1, and another little third is Android 1.6...
The rest ( yes, the rest after the 3 thirds... ) is Android 2.0 and Android 2.1. That means that if you want to bypass one of this Android version, you are limiting your audience in large proportions !
* The devices : The droid is the big winner here, with about 1/3 of the devices used. Then the HTC Hero / Eris, the HTC G1/Dream and the MyTouch/Magic...
We can observe that the french version of my game, obviously mainly played in France shows a very different picture :
WordProspector version ( essentially played in the US )
"Chasseur de mots" ( the french version, essentially played in France )
We can see that Samsung - that had shipped the Galaxy a long time ago in France - is much more present, and that Motorola is surprisingly unpresent !
Another funny thing : in the french version there is a ... BlackBerry 8230 : I guess someone played with home-made OS and changed the Phone_Model string !
Last point : the events
The events can clearly be the most important point in Flurry if you use them wisely.
If you want to know something specific on how your users are using your application, Events are for you !
For instance, in my game, I registered which game mode the player were playing.
Personally, I always play the game in Full Game mode, 1 minute, but I discovered that most people played in 'simple mode', for 1 minute.
Conclusion :
Clearly, users want some quick game : both 'simple game' and 'full game' are played.
And the 2 minutes and 3 minutes games are far from being negligeable ( at that point, I was still wondering if I had developed that for more than 3 users :)
Conclusion : was it worth it ?
First, I want to point that, obviously, Flurry your application to open network and localization authorizations. I don't think it is a real issue ( and in my case, I already needed these authorizations for AdMob), but it may be something that you don't want.
If you don't mind opening these authorization, and don't have any other way to get feedbacks, I think Flurry is really a choice to consider.
It's so simple to use and gives you lot of information.
Now I regret that it is not more flexible with the information it gives. I would like to have a way to create my own requests. For instance, I would like to know how the firmwares are distributed on the G1, but you don't have that much freedom ( even if there are a lot of information already available ).
A custom system done by myself would be more flexible. But, let's be honest : I won't invest time enough to have something as elaborate as their tool ! ( not to mention the fact that I don't know how to present the data in such a nice way ).
A blog from an Android developer.
Developing since the start of the platform, and constantly improving my applications, I share my experience developping with Google OS for smartphones.
Thursday, January 21, 2010
Tuesday, January 19, 2010
Friday, January 1, 2010
Android Market : updating an application does not update its place in the 'by date' order anymore ?
Today, I updated my 'Word Prospector' Game, with a small bugfix.
I then took my phone, went to the market to see and test from the market the change.
And ... I couldn't find my game in the top of the list sorted by date !!!
It should have been there, at the first place. But, no, I tried to find it, but couldn't because it was sooo far in this list...
It could be a temporary, local bug, and maybe the old market behavior will come back in the next days / hours ( the famous bug of the 2K10 year ? )?
But I feel like it is a big change in the market policy !
What are the consequences of such a move :
* The "By Date" order in the market gets its real meaning back : you won't always see the same applications in this list. It's quite true that it was strange to see a very old application at the top of this list !
* Constantly improving / debugging your application will have a much lower impact on your visibility on the market. By now, every new version brings some new users. This could be the end of this behavior. Does it means people won't update / improve / debug their applications as much as before ?
* it certainly means it will be better to make a lot of application rather than having an application you constantly improving
* Perhaps it means you should make a 'top quality' appplication from day one, because improving it won't bring you any more users ( but that was already the case because of the ratings : if at start your ratings are low, it is very difficult to change them )
* Will people create a new application when they want to release a new version, or at least when a new feature is integrated in their version ?
Can we consider it is the market getting more mature ?
In my case, I hope that it's just a bug...
What do you think ?
EDIT : It looks like I've been alarmed by a well known ( but that I didn't know ) : an updated application will be at the top of the 'By Date' only if the previous update was more than 'some time' before ("some time" being around one week )
I didn't know that, and didn't observe this behavior before !
Thank to all the people that gave me this info !
I then took my phone, went to the market to see and test from the market the change.
And ... I couldn't find my game in the top of the list sorted by date !!!
It should have been there, at the first place. But, no, I tried to find it, but couldn't because it was sooo far in this list...
It could be a temporary, local bug, and maybe the old market behavior will come back in the next days / hours ( the famous bug of the 2K10 year ? )?
But I feel like it is a big change in the market policy !
What are the consequences of such a move :
* The "By Date" order in the market gets its real meaning back : you won't always see the same applications in this list. It's quite true that it was strange to see a very old application at the top of this list !
* Constantly improving / debugging your application will have a much lower impact on your visibility on the market. By now, every new version brings some new users. This could be the end of this behavior. Does it means people won't update / improve / debug their applications as much as before ?
* it certainly means it will be better to make a lot of application rather than having an application you constantly improving
* Perhaps it means you should make a 'top quality' appplication from day one, because improving it won't bring you any more users ( but that was already the case because of the ratings : if at start your ratings are low, it is very difficult to change them )
* Will people create a new application when they want to release a new version, or at least when a new feature is integrated in their version ?
Can we consider it is the market getting more mature ?
In my case, I hope that it's just a bug...
What do you think ?
EDIT : It looks like I've been alarmed by a well known ( but that I didn't know ) : an updated application will be at the top of the 'By Date' only if the previous update was more than 'some time' before ("some time" being around one week )
I didn't know that, and didn't observe this behavior before !
Thank to all the people that gave me this info !
Thursday, December 10, 2009
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 :
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 :
Cons
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 :
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 :
Monday, December 7, 2009
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 !!
Subscribe to:
Posts (Atom)