Androidsx is now Perops. Visit us at

Androidsx Androidsx | android and wearable developers


Subscribe for market insights and new posts


Admob vs Mobclix: 3rd round [Updated]

August 21, 2010 at 9:15 pm | android, blog, monetizing | 7 comments

Admob vs Mobclix: 3rd round [Updated]

This is the third part of a series of posts, look at the 1st round, 2nd round, and some related problems.

In our previous posts we didn’t cover a critical topic: how to cash out the revenue (ie, money) that you generate.


Every month you get paid the revenue you generated two months before. For instance, on July you get a transfer of the revenue you generated during May. As simple as that.


We started generated revenue on March 2010 and by now, end of August 2010, we have not seen a single dollar[1]. Ouch. That’s not a good business, is it?

This deserves a post on its own: Can’t get our money out of Mobclix.

[1] Update on August 24: We did get paid today.


Admob vs Mobclix: 2nd round

June 9, 2010 at 10:55 pm | android, blog, monetizing | 23 comments


This is the second part of a series of posts, look at the 1st round, 3rd round, and some related problems.

It’s been three months since we migrated to Mobclix from Admob, where we stayed for over two months. So we want to share some data, mainly focused to get our fellow developers starting out in the Android world to better estimate what kind of revenue they can make out of advertising.

We will compare the results for four weeks, aligned by the week day, using the data from February/March for Admob, and April/May for Mobclix.

This is the revenue that we generated per day (*):

And here, the revenue per click, which is our preferred indicator to compare how different ad providers perform:

All this has been generated by three applications, that currently have 100k active users (after over 200k downloads). It is difficult to keep track of how many users we had in each ad provider at every point in time, so comparing absolute numbers, like we did in the first graph, does not yield relevant conclusions.

In an upcoming article, we’ll show values that analyze the long term figures!

(*): We have multiplied all figures by a factor k € [0.2, 5.0], in order not to disclose our real numbers while providing meaningful data. This correction is consistent, i.e. if you have 2x active users, expect a similar price per click but double the revenue per day.


What does it take to develop some android applications, our experience

May 29, 2010 at 12:48 pm | android, blog | 17 comments


The best thing for a newbie Android developer is to start a really simple project, or take a demo project and extend it. But the most important thing is to get the things done, in other words, your main objective should be to finish the idea you have been working on.

We would like to share the time spent in the development of some android applications., in the last months we have had development sprints releasing two games, one app, a chrome extension and some huge improvements in our already released apps. Once you have some experience with Android it is not very difficult to start a project from scratch.

We developed Poke the droid, a simple game similar to Whac-a-mole that test your reaction times. The main motivation was to develop our first game, assuming it will not get the success of other popular games out there. It was developed from scratch in around 2 weeks.

Recently we released Super Stacker, the popular stacker game with some improvements like bonus, levels, etc. We began with Snake demo code as the base so it was not really difficult to be developed (one week), moreover we reused almost all the score system and UI from Poke the droid.

Another simple app we created is Spell Checker, this is a extremely simple application that check your words against Google system. We test the integration in a WebView of a remote web page with the Android system. It was a day of development, thanks to the Javascript library of GoogieSpell.

On the other hand, we have made a huge refactoring in our RSS reader Any RSS reader + widget (1.99 EUR). We have add the feature to open as an application, so you can access your saved feeds from the widget and from the app. It is #11 in the Top Paid of the News and Weather category, this fact has multiplied x2 the number of purchases per day.

Finally, one of us in a boring day developed a simple extension for Chrome called Android Market Link Converter, that converts links like market://search?q=pname:com.androidsx.anyrss into links to the most known Android Market clients (Cyrket, Bubiloop, etc.).

Now, we would like to make use of the Android Cloud to Device Messaging Framework, but at the moment we don’t really have any interesting idea :(

Do you have some fast development experiences? Share with us!


Admob vs Mobclix: 1st round

March 25, 2010 at 1:26 pm | android, blog, monetizing | 39 comments


This is the first part of a series of posts, look at the 2nd round, 3rd round, and some related problems.

We have been using Admob for three of our applications during two months. Our first impression was very positive: we generated way more revenue than what we expected.

The revenue per day was very unstable. In the last weeks, it went sharply down with no apparently reason (almost 30%-40%). We tried hard to understand how the Admob network works internally, with no happy end. We have more users, more impressions, more CTR but much less revenue… (stay tuned for an upcoming post where we share our stats).

After some twitter posts trying to find fellow developers with whom to share experiences, we were contacted by a Mobclix employee suggesting we switched to their mashup of agregated advertisement networks.

So, we tested Mobclix with the smallest app (in active users) with ads that we have, the MLIA widget:

Here it is the comparison between Admob vs Mobclix in MLIA over the same days, it looks really promising!

Admob stats

23-3-20103123 $0.50912.83%$2.93

Moblix stats

23-3-20103,313 $1.53892.69%$5.06

Still, it is very soon to draw firm conclusions. This is the start of a series of post with the comparative.


How to make money with Android – business models

March 5, 2010 at 1:25 pm | android, blog, monetizing | 44 comments


Mark Murphy has been writing really interesting posts in Android guys about the different business models around Android platform. We have chosen the most relevant ones adding some additional information:

  • Build the app and sell it via the Android Market
  • Give a free app, supported by ads (Adsense mobile, Admob, etc.)
  • Give a free app, sell the customizations: plugins, analytics, additional features, account (e.g. RTM, Spotify), etc.
  • Sell development tools: GUI toolkits, portability tool, …
  • Develop custom applications for others (e.g. Droiders)
  • Became a trainer of Android development
  • Specialize in porting iPhone, Windows Mobile, J2ME applications to Android.
  • Promote your ability to port some critical parts of the apps to the Android Native Development Kit (NDK)
  • Became an specialist building cross-platform apps using HTML, Javascript and CSS (e.g. PhoneGap, Titanium, Rhodes)
  • Became an expert to build apps with GPS and backend capabilities of HTML 5.
  • Build an App Generator (e.g. ePUB, RSS, audiobooks) selling this generated apps.
  • Became a specialist building Augmented Reality Layers for Layar or Wikitude

Mark has done an incredible job posting these business models, you can read the different post for more information (Part 1, 2, 3, 4, 5 and 6)


How to write untestable code

January 14, 2010 at 11:08 am | blog, software quality | 2 comments


Say that we write code for a machine that it so powerful that rumors say it could generate a black hole. We need to be serious about security: we cannot let those evil international terrorists find out our black-hole-making secrets and blow half the Milky Way Galaxy.

If they managed to access our source code, they could extend it and adapt it to their cruel use case, which would represent a huge threat for the humankind. In order to reduce risks, we should write code that is difficult to understand, to maintain and of course, to test. Here’s how:

  • Depend on concrete classes – Tie things down to concrete classes – avoid interfaces wherever possible: they let people substitute the concrete classes you’re using for their own classes which would implement the same contract in the interface. By depending on concrete implementation, we make sure that they’ll have a hard time testing whether their evil plans will release enough energy to toast their breakfast bread.
  • Make your own dependencies – Instantiate objects using new in the middle of methods, don’t pass the object in. Anyone that wants to test that code is forced to use that concrete object you new’ed up: they can’t inject a dummy, fake, or other mock in to simplify the behavior or make assertions about what you do to it.
  • Conditional slalom – Feel good when writing lengthy if branches and switch statements. These increase the number of possible execution paths that tests will need to cover when exercising the code under test. The higher the cyclomatic complexity, the harder it is to test and understand! Why use polymorphism instead of conditionals? Don’t make it so easy! Make the branching both deep and wide: if you’re not consistently going at least 5 conditionals deep, the patient terrorists might even find out what the code intends to do under all possible combinations.

    It is also known as the Arrow Antipattern:

    if a
        if b
            if c

    Refactoring into something more suitable is usually possible:

    if a && b
        if c
  • Use global flags – Why call a method explicitly? Set a flag in one part of your code, in order to cause an effect in a totally different part of your application. The testers will go crazy trying to figure out why all of a sudden a conditional that was evaluating true one minute is all of a sudden evaluating to false. Not to mention the mess that using that system becomes: if we manage to keep the wikis safe from their hands, they’ll have a very hard time figuring out what system properties to set in order to get the deadly weapon working.
  • Loop-switch sequence – By means of which a clear set of steps is implemented as a byzantine switch-within-a-loop. Fulfilling our mission to obfuscate the code , is much more difficult to decipher the intent and actual function of the code than the more straightforward refactored solution.

    This is a terrorist-safe code snippet:

    // parse a key, a value, then three parameters
    String key = null;
    String value = null;
    final List params = new LinkedList();
    for (int i = 0; i < 5; i++) {
      switch (i) {
        case 0: key = stream.parse(); break;
        case 1: value = stream.parse(); break;
        default: params.add(stream.parse()); break;

    While this is too easy to understand:

    // parse a key and value
    final String key = stream.parse();
    final String value = stream.parse();
    // parse 3 parameters
    final List params = new LinkedList();
    for (int i = 0; i < 3; i++) {

References: This post on the Google Testing Blog, the Arrow AntiPattern in Cunningham & Cunningham webpage.


6 things we’ve learned from the Android market

December 14, 2009 at 12:08 pm | android, blog | 6 comments


We have three applications on the Android Market, AnyRSS reader widget (0.50 EUR), FML F*ck my life widget (Free) and Daily Stuff widget (Free). It makes for more than 60000 downloads, being F*ck my life the most downloaded application among them. We want to share our experience with the market for the last several months:

  • According to our Flurry stats, the best day to update an application is Friday morning (European afternoon or evening). On other days, such as Wednesday or Thursday, you usually get more downloads. However, other developers don’t usually release new versions in the weekends, so your application stays longer in the top of the Just in section.


  • At the moment, Android users are not accostumed to paying for an application. So, if you want to make money with your application, which strategy should you follow? Free and paid version? Free with ads? Our experience with a paid version is not quite as motivating as we expected (just a few hundreds Euros since September). Free applications with ads have more users but usually less money. The decision depends on many factors, and there’s no magical answer. We’ll probably do an experiment with our paid application, making it free application and adding some AdMob ads (Google Adsense is only available for apps with 100K daily pageviews).
  • It is important to have good ratings during the first days as a new application in te market. Bad comments and ratings in the first days will make it difficult to start growing and get enough relevance to appear on relatively top places in the search results. Make sure your application is pleasant to use from the beginning: focus on reliability and stability rather than on advanced features. You do not want to annoy your first users.
  • Add as many relevant keywords in the description that identify your application as needed: it is too optimistic to expect people to search specifically for your application name.
  • Most of the users don’t care about the impact of a bad rating. If there’s any small problem, they will just throw in a bad rating/comment and uninstall the app. On the other hand, we must take care of the lovely users that suggest new features, report bugs, etc..
  • Be careful with your update frequency: it is annoying for users if you update too frequently. In the Android market, each update goes to the Just in section, which has been really controversial in the Android world. There are many developers that abuse this by making frequent updates to get more downloads. On the other hand, getting visibility on the market through the search or the rankings is not easy, so updating is one of the best ways to gain more downloads: but with real updates, don’t be evil!.

In other posts, we will talk about the limitations of the Android market. If we are to compete with the App Store, the market should be one of the main worries for Android Core Developers and learn from its competitors. Yes, the UI is better and what not, but the visibility, the search and the average money (check this study) that you get with your applications is much lower than in the App Store. With tech companies such as Motorola investing a lot of resources in Android, there will be really powerful market competitors such as SHOP4APPS (seen in El Androide libre, in Spanish).


Don’t look for things. Ask for them!

November 26, 2009 at 12:04 pm | blog, software quality | 5 comments


Before our previous article, our code to model a mechanic used to look like this:

class Mechanic {
    private final Engine engine = ServiceLocator.getCar().getEngine();
    public void fixEngine() { /* ... */ }

Luckily, we applied some dependency injection, resulting in nicer code: testable, and with an explicit dependency on the ServiceLocator:

class Mechanic {
    private final Engine engine;
    public Mechanic(final ServiceLocator serviceLocator) {
        engine = serviceLocator.getCar().getEngine();
    public void fixEngine() { /* ... */ }

However, does our mechanic care about the ServiceLocator at all? Not really, it doesn’t even store a reference to it! The mechanic just wants an engine.

There are some problems with this kind of code:

  • The ServiceLocator probably has references to a lot of other classes in the system. By the transitive property, our Mechanic class is too coupled with the rest of the system: if you want to reuse it in a different project, you’d need to reference not only Mechanic and Engine, but also the ServiceLocator with all its dependencies.
  • The API is not clear. An API client knows that it’d need to provide the ServiceLocator (already an advantage respect to the Singleton-based case). What it doesn’t know is what the mechanic really needs (an engine). This fact is hidden in the source code.
  • The tests contain a lot of setup junk that masks its real purpose. For every test of the mechanic, you’d need to mock the ServiceLocator, and then make sure the appropriate reference can be retrieved from it (the Engine, in this case). When we test the class Garage, that needs a Mechanic, we’ll have to replicate this tedious setup there too.

This is how the test looks like now:

public void testCantFixBrokenDownEngine() {
    final Engine engine = EngineFactory.buildBrokenEngine();
    final Car mockCark = Mockito.mock(Car.class);
    final ServiceLocator mockServiceLocator = Mockito.mock(ServiceLocator.class);
    final Mechanic mechanic = new Mechanic(mockServiceLocator);

Why not just ask for what you need?

class Mechanic {
    private final Engine engine;
    public Mechanic(final Engine engine) {
        this.engine = engine;
    public void fixEngine() { /* ... */ }
public void testCantFixBrokenDownEngine() {
  Engine engine = EngineFactory.buildBrokenEngine();
  Mechanic mechanic = new Mechanic(engine);

Everyone wins:

API writers:

  • Unaffected by ServiceLocator changes
  • In-code documentation is easier to write (what was your comment on the Mechanic‘s constructor for the ServiceLocator)?

Test writers:

  • Tests are easy to read
  • Very little setup code
  • Unaffected by ServiceLocator changes

API users:

  • The API is clear: the mechanic needs an engine

« Older Entries        Newer Entries »


Recent posts: