Advanced networking: when Retrofit is not enough

Almost every Android application uses remote services nowadays. I wouldn’t be surprised even if some small, homebrew TODO-list app will synchronize your data with backend server.

I also remember the times when you had to manually crank up your HttpUrlConnection or HttpsUrlConnection, wrap it up by some NetworkManager class and access it in your AsyncTask. Those were dark times, no doubt.

At the time OkHttp, Retrofit and Volley hit the Android dev community it was like a breath of a fresh air. Especially Retrofit. Sure, it had it’s problems, especially when Android couldn’t perform well with reflection, but these days are long gone and Retrofit is an industry standard de-facto. Just write an interface, wrap it up in annotations, setup your Retrofit instance and spawn any API interface implementations you have.

But the time goes on, as well as requirements from businesses. And even though Retrofit is great library and I love it, it has a very serious limitation when you need to do something out-of-box: everything in Retrofit is final. Here’s an example based on our use-case: you need to track the amount of retries of every unique call and put this information as a header. How would you solve that with Retrofit? The only thing I could come up with is to fork a RxJavaCallAdapter extension library and modify it:

So, even for that simple use-case on the surface, I had to not only fork an extension library, but also use additional reflection inside! And that’s only one example. In case you want to intercept something, the only option you will have is to provide Interceptor to the OkHttpClient. And even there you’re pretty much limited to options: all fields are final and basically you’re forced to manually recreate your Call instance if you want to modify anything. Or use reflection.

After a several such use-cases it was obvious: Retrofit is not enough at Agoda. We want our app to be much more flexible and adaptive, but the limitations implied by the library forces us to use a lot of hacks and a lot of reflection, which is not a good practice in any way.

Is there any good alternatives to Retrofit out there in the wild? Not so much. At least with the same level of easy-to-use. So we decided to build something in-house. And we did. Our main requirements for the networking library were:

• The same base capabilities as Retrofit
• Interceptors at two levels: requests and responses
• Ability to extend and modify any property of requests and responses through the flow
• Straightforward retry and fallback policies

Even though the final product met all of the requirements above, we missed the most important part: easy-to-use principle. Library required to write a lot of boilerplate code, which sometimes was hard to follow.

So, while migrating our current networking implementation to this library, we started to think on the next iteration. The goal was simple: keep all new functionality, but make it as easy to use as Retrofit. So, here you go: Ninjato.

Ninjato is a flexible and type-safe inline HTTP client written in Kotlin with DSL for configuration of calls and uses as low reflection as possible. To do a simple call, all you have to write are there lines:

Or even less, if you’re fan of default implementations of interfaces in Kotlin:

Most of the features are implemented with the help of Kotlin’s inlining and reified generic types. The only place where reflection is used is Type acquiring for the serialization/deserialization purposes. So most of the code is inlined during compilation time.

But that’s just base functionality. What we’re really interested is possibility to affect the flow of request — response as we want. And this solution has a lot of tools to do that. First, interceptors:

Request and Response factories (to add new properties and/or behavior to these entities):

And on top of all that, retry and fallback policies:

These are not all of the library’s features, but the most important to us. If you want to take a full look at the capabilities, syntax and documentation, you can find it at GitHub.

But just introducing new library is not enough. Especially when you are developing a solution that is targeting to replace existing one. In our case, it would be simple, yet will take a lot of effort since we have a lot of networking in out product. But every migration should have a strict guideline, and we want to follow this approach:

1. If the API interface class is written in Kotlin, provide Ninjato implementation as default to this interface.
2. If the API interface class is written in Java, provide implementation class and resolve through DI.

With this approach it is very easy to do A/B testing to verify that behavior is not affected by the changes and is consistent approach to introducing any type of replacing libraries in your projects.

As a summary, I want everyone to realize that Retrofit is great solution and if your needs are fully satisfied with it, there is no need to jump off to any new fancy solution. Every tool is suited for a specific task. But if you feel that Retrofit is not enough, I would be more than glad if you check out Ninjato. It is open-source (as all of other cool Agoda’s libraries) and ready to use. Have fun!