• 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)

Related posts

• 6 things we’ve learned from the Android market

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
              foo();
          else
              bar();
          endif
      endif
  endif
  

  Refactoring into something more suitable is usually possible:

  if a && b
      if c
          foo();
      else
          bar();
      endif
  endif
  

• 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++) {
    params.add(stream.parse());
  }
  

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

Related posts

• Don’t look for things. Ask for them!
• Can’t test that Singleton? Try Dependency Injection!

• 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).

Related posts

• How to make money with Android – business models

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:

@Test
public void testCantFixBrokenDownEngine() {
    final Engine engine = EngineFactory.buildBrokenEngine();
    final Car mockCark = Mockito.mock(Car.class);
    Mockito.when(mockCar.getEngine()).thenReturn(engine);
    final ServiceLocator mockServiceLocator = Mockito.mock(ServiceLocator.class);
    Mockito.when(mockServiceLocator.getCar()).thenReturn(car);
    final Mechanic mechanic = new Mechanic(mockServiceLocator);
    mechanic.fixEngine();
    assertFalse(engine.works());
}

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() { /* ... */ }
}

@Test
public void testCantFixBrokenDownEngine() {
  Engine engine = EngineFactory.buildBrokenEngine();
  Mechanic mechanic = new Mechanic(engine);
  mechanic.fixEngine();
  assertFalse(engine.works());
}

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

Related posts

• Can’t test that Singleton? Try Dependency Injection!
• How to write untestable code

public class Client {

    public int process(Params params) {
        final Server server = Server.getInstance();
        final Data data = server.retrieveDate(params);
        // do stuff
    }
}

We don’t want to retrieve an instance of a real server for our little unit-test, so how can we test this method?

It is hard to test code that uses singletons.

We don’t control the creation of the singleton object, as it is performed inside a static method. There is no way to mock the object in order to test the behavior of our method in isolation.

Refactor it to use Dependency Injection.

You can refactor Client to avoid using the singleton pattern. Instead of obtaining the Server instance from the static getInstance() method, allow Client to accept it through its constructor.

public class Client {
    private final Server server;  

    public Client(Server server) {
        this.server = server;
    }  

    public int process(Params params) {
        final Data data = server.retrieveData(params);
        // do stuff
    }
}

Let’s write that test now:

@Test
public void testConnectionUpTime() {
    final Server mockServer = Mockito.mock(Server.class);
    final Params params = // ...
    Mockito.when(mockServer.process(params)).thenReturn(5);
    final Client client = new Client(mockServer);
    assertEquals(5, client.process(params));
}

The code is now both clearer and testable.

The dependency between the client and the server is now explicit: Client client = new Client(server);. There is no way a developer creates a client instance without noticing that a server instance must be configured: it is a parameter in the constructor.

The singleton allowed to create a client instance without configuring the server in advance. The object would be successfully created and the application would execute, until one of the methods runs into a non-configured/non-reachable/null server and fail at runtime :’-(

Related posts

• Don’t look for things. Ask for them!
• How to write untestable code

Random Posts

• How to write untestable code
• Don’t look for things. Ask for them!
• How to make money with Android – business models
• Can’t test that Singleton? Try Dependency Injection!