Clean your API calls!

T.Surkis
AndroidPub
Published in
3 min readSep 16, 2017

--

You need to add a new API call. Because the server error and API error handling code is usually similar to all the API calls, you just copy paste another call and change its parsing code. We have all done it at one point or another in our Android career.
We have all been bothered by the long never ending list of similarly looking API calls

If you’re looking for a faster to write, cleaner and less bug prone code — tag along.

I will be using Retrofit 2.0. Even if you are not familiar with Retrofit or don’t want to be, I recommend reading on as this article is more of a blueprint.

I will be referring in this article to the asynchronous way to do an API call using Retrofit, but the logic can be applied to a synchronous call as well.

I will also use generics so if you are not familiar or feeling rusty regarding the subject you can check out an article I wrote regarding that subject:

Typical Call

Each asynchronous Retrofit call expects a Callback<T> object. The T represents the object that is supposed to be received from the API call.

As seen in the code, the class Callback<T> is an interface that is expected to be passed in for each API call.

Generalizing the failure response

In Object Oriented Programming, if class A inherits or implements from class B it can be treated as B. Therefore, if we create a class implementing the Callback<T> interface we can pass it instead.

The class is deliberately abstract to allow us to implement any method. The method that we will override will be the server error method.

Server errors generally have the same handling across all the API calls of the app. If a particular case of processing is needed, the method can be easily overridden.

Generalizing the parsing process

The Retrofit response object holds the parsed data in the variable body that is retrieved through the body() method. Therefore, we can retrieve the object for any API call from the body() method.

Our API call has gotten a hell lot shorter. However, something is missing. How do we notify the listener of the response?

Delivering the response

Since our class handles all the responses from Retrofit, the only way to provide the response to the listener is by passing it to the constructor and save it as a member class.

The listener is saved as a WeakReference<T> to allow it to be cleaned by the garbage collector if necessary. For more information about different reference types I suggest reading: https://medium.com/google-developer-experts/finally-understanding-how-references-work-in-android-and-java-26a0d9c92f83

The final result is a just a single line:

Each new API call would only require us to create a new POJO class to hold the parsed data and a single line to retrieve the result to the listener.
How great is that? ;)

Summary

This article is more of a blueprint than a single way to handle API calls. I hope I have inspired some of you to create a cleaner and more maintainable approach to API calls.

The code example of this article can be found in:

👏 to let me know if you enjoyed the article and follow me on Medium and Twitter ;)

--

--

T.Surkis
AndroidPub

A Flutter developer by day, a technology enthusiast by night.