Most Android apps use a networking client to talk to some API. The most popular client is probably Retrofit, a type-safe HTTP client for Android and Java.

If you are familiar with Retrofit and its usage, keep on reading to learn a better way to mock API calls.

In the snippet below, we have defined a Service interface that lists all the endpoints we want to call from API.

It is passed to the Retrofit builder, it generates code for GET, etc. You know the drill.

However, often when working on a project in collaboration with a backend team, you may encounter some difficulties that can affect the further development process.

Some of those problems are API-related issues such as delayed API development, often API changes, or current API inactivity.

At the same time, the ability to check whether your code covers all the possible responses or how your app behaves in case of different response duration can significantly improve the development process.

Retromock adapts a Java interface created by Retrofit using annotations on declared methods to define response mocks.

Setting it up is very simple and can be done in the following steps:

In the following chapters, you’ll find the list of recipes that shows how to solve common problems with Retromock.

Feel free to clone the project and try them out. Make sure that you understand how they work.

Let your API service implement the getUser call. Keep in mind that in the following example there are no mocks yet. Mocks will be defined using annotations, as explained later.

And your data class provided by the getUser call looks like this:

In this case, we use Moshi for serialization. It’s okay to use another serializer to configure Retrofit, because Retromock uses the same serializer as Retrofit under the hood. This means that a fully configured Retrofit instance is required for Retromock to work.

With Retromock, there is an easy way to mock a response using @Mock and @MockResponse annotations. @Mock annotation is used to specify that the method should be mocked. @MockResponse annotation is used to specify parameters for defining a mocked response.

You can find more details in the specification.

Usually, the response is too complicated to fit nicely as an annotation parameter. With Retromock, it is possible to mock responses using JSON files. Here’s how to configure it to read responses from the resources directory.

smith.json

There are two steps to take in order to use this JSON resource file. First, we need to set defaultBodyFactory when initializing Retromock.

Use the following implementation to read JSON files from the resources directory:

Basically, it defines where the JSON resource is located so that Retromock can read it. DefaultBodyFactory needs to be set. By doing that, Retromock will by default read the responses using that class.

In our example, it means the response body will be read from the file in the resource directory, which is called the same as the value of the body parameter of the @MockResponse annotation set.

Next, we need to reference the wanted response from the annotation.

If you want to keep both options – simple responses, and responses from the resource, you can use the parameter bodyFactory from the @MockResponse annotation.

With Retromock, it is also possible to mock response headers. Take a look at the following example.

Response code can be set using the parameter code:

If you set a custom default body factory and do not declare a bodyFactory parameter in @MockResponse annotation, your body factory will be called with the value of body parameter. That also applies if you don’t specifically set a body, like in the example above – in that case, body is empty by default.

If you prefer not to handle the case of empty body, wrap your default body factory into NonEmptyBodyFactory class as follows:

When working with network calls, we should adjust our code to expect possible delays or do something after a specified timeout. With Retromock, we can prepare for both.

To mock an immediate response, initialize Retromock in the following way:

defaultBehaviour(()->0) will initialize behavior that waits 0ms before returning a mocked response.

We can achieve the same thing using MockBehaviour annotation:

Mocking delays can be done by setting durationMillis and durationDeviation parameters.

durationMillis defines a delay value in milliseconds and durationDeviation defines a deviation from that value. Basically, those two parameters define a delay range of durationMillis+-durationDeviation.

Here’s an example:

This would produce a random delay in range [500, 1500>.

Since Retrofit is adjusted to support coroutines for asynchronous calls, similar adjustments are done to Retromock.

So it is possible to write something like this:

Sometimes, two consecutive calls can give two different responses, either with different data or completely different. One such instance is doing a search for some user with different filters.

We can easily mock such behavior simply by defining multiple mock response annotations.

That’s all the set up there is.

The first time when you trigger the getUser call, you’ll get a response defined with smith.json resource. The second time you trigger the getUser call, you’ll get a response defined with doe.json.

Additionally, there is a way to mock an indefinite number of responses in three ways: default, circular, or random. By default, mocked calls will always return the last response, in this case, doe.json.

Let’s use an example with smith.json and doe.json to explain circular and random behavior. Also, we’ll call getUser 5 times to show the result.

@MockCircular

@MockRandom – one possible outcome. As the name says, responses are chosen at random.

Let’s say we use our ”{\”name\”:\”John\”, \”surname\”:\”Smith\”}” as a response body. We also want to mock multiple responses, but with different first and last names. Everything else in possibly a huge response mock should stay the same.

For those cases, we can implement custom BodyFactory.

There are many use cases where you can use Retromock to mock Retrofit calls. With possibilities from mocking simple or complex responses, headers or bodies to delays or multiple responses and more, Retromock provides complete control of the mocked API.

Most used mock recipes are explained in this article, but feel free to check out the specification and the source code for more details.

Do you know why Android developers learn JS? Because they need something to do while waiting for the app to build.

If you are an Android developer, you are most probably familiar with experiencing long build times. Long build times slow down your development process, and nobody likes it.

Especially in situations when you are debugging some nasty bug, you don’t want to wait until your focus on a solution is gone.

A lot of build time is consumed by annotation processor tools of some kind. A big part of that build time consumption is used by dependency injection.

Since Dagger is the most popular dependency injector and is used in most modern projects, it made sense to take a deeper look and see if we can somehow optimize it.

It turned out that making a simple change can significantly improve build time.

To understand why this is an improvement, we need to take a look at the code that is being generated when using @Provides method.

For this purpose, I have created a simple example, HelpersModule which provides StringManager. StringManager is simply a helper object used to provide you strings in presenters or view models without directly exposing Context.

But back to the Dagger, take a look at our HelpersModule.

We have annotated a method that gives us a concrete implementation of a wanted object using @Provides annotation, sounds good right?

Actually, it is a bit more than this. Under the hood, Dagger needs to generate a completely new factory class for this.

Take a look:

If you read this factory class line by line you can figure out more or less what is going on.

In simple words, it is nothing more than a Java representation of what we have taken for granted while writing HelpersModule. The main point is that provides annotation will generate a class.

Let’s try to write this identical thing using @Binds annotation:

If you try to make a build now, you’ll see an expected error:

We forgot to provide Resources object to StringManager. Let’s be naive and create a new @Binds annotated method which will provide resources.

Here’s what happens:

And that is exactly the difference between @Provides and @Binds annotations. @Binds annotation must be assignable to the return type. What does it mean?

In order to enable the injection of some object that needs something itself, like StringManager needed Resources, we need to have all of these atomic objects provided somewhere.

In this example, we needed to provide resources using the @Provides annotated method.

Notice how I had to change our interface into abstract class in order to keep the method that has implementation.

This should be fine now. Let’s make a build:

Ok, that is pretty much straightforward.

We can make the resourcesProvider method static or move it somewhere else. To keep the code clean, we need to separate different semantic entities.

For this purpose, I have used my ApplicationModule which should contain those atomic providers. I have put resourcesProvider there. So this is the final setup:

After we have written this, let’s make a build.

It works!

Now, we want to see generated class:

Correct. It does not exist.

Why?

Because there is no need for it.

In compilation time, Dagger uses @Binds annotated methods to check if it can provide the wanted object and to find appropriate Provider.

Like always, let’s take a look under the hood. So, I have injected StringManager into DashboardViewModel.

Dagger needs a factory for this view model. The generated class looks like this:

As you can see, Provider<StringManager> is all that was needed.

Maybe you think, “Ok, what did we accomplish here?”.

Very soon, this view model will need many other objects. We will still have one generated factory class. Inside that factory, each injected object will have its Provider<T>. And none of the objects annotated with @Binds annotation will need to have their own generated factory class.

In large-scale projects, this makes a difference. Generating files is what really is consuming build time.

If you are still wondering where to find Provider<StringManager> and how it is linked to this factory, let’s take a look at the generated DaggerAppComponent class.

DaggerAppComponent provides the implementation of all components listed in the AppComponent interface. TheDoubleCheck.provider method simply returns a Provider that caches the value from the given delegate provider.

We talked about Dagger module optimization through code examples. I have tested this approach on one of our projects at Infinum.

I made the changes using three rules:

I have also counted generated files for both commit builds, and as expected, for each @Provides -> @Binds conversion there was one generated file less.

One other benefit is that DaggerAppComponent generated less code.

All of this didn’t take more than 10 minutes.

TL;DR
Use @Binds instead of @Provides annotation wherever possible.