Yet another MVP article — Part 3: Calling APIs using Retrofit

Written by mohsenoid | Published 2016/11/28
Tech Story Tags: android | retrofit2 | dagger-2 | mvp | yetanothermvp

TLDRvia the TL;DR App

Implementing a sample Android Application using MVP, RxJava, Dagger 2, Retrofit2, Test, and all the brand new modern methods and libraries

Previously on this article…

Yet another MVP article — Part 2: How Dagger helps with the project_Implementing a sample Android Application using MVP, RxJava, Dagger 2, Retrofit2, Test, and all the brand new modern…_hackernoon.com

Let’s think that you have studied part1 and part2 which means you know everything about the sample project’s modules and structure and also get more familiar with Dagger usage in wiring up MVP layers.

now let’s continue…

Let’s get into network and API:

Almost all mobile application communicate with their services using the internet. Retrofit is a perfect library contributed by Jake Wharton which can always come handy and help you with developing a network layer for your Android application.

Long story short, in this project Retrofit, uses an interface called MarvelApi which shows the way to API:

Using retrofit is really simple, as you can see there is a RESTful API method located at http://gateway.marvel.com:80/v1/public/characters which needed some parameters to retrieve what you want, which is character data using its name.

A good developer is the one who always read API documents, you can read more about Marvel APIs:

Marvel Developer Portal - Interactive Documentation_The Marvel developer portal gives Marvel fans, partners and other technologists access to an array of powerful APIs…_developer.marvel.com

, and in which MVP layer MarvelApi is located?

All networking and databasing stuff happen inside Model layer.

This layer only works with data and business logic and Presenter knows how to call or how to prepare data for the View layer.

Please stop manipulating data within theModel layer and pass it safe and sound to the Presentation layer, he knows what to do…

and more SOLID principle…

According to “Single responsibility” of SOLID principle “One chef can’t run the whole restaurant”, then Model and Presentation have totally separated tasks to do.

“One chef can’t run the whole restaurant”, — novoda

Can we have a nice log of what we call and what we receive in API response? Why not!

The Retrofit library uses OkHttp library within which is a powerful network library. All magic happens with Interceptors. I will explain one by one and finally show you how to apply them to your OkHttpClient.

By a little configuration you can ask this library to show you a decent log in logcat which always comes handy:

, but don’t forget to disable this logging thing in release version! you can do this by checking BuildConfig.DEBUG variable which generates during application build.

How cache API results caused Database to vanish!!!

First time I do this inside a news reader application, all database record updating and queries almost killed all team members.

Using OkHttp cache feature you can handle header caches and also have an offline file caching which sometimes could be a perfect substitution for Database pain:

There are two cache interceptors in this sample,

  • One cache interceptor changes the header of API response and available caching for 2 minutes (maxAgeMin), which means somehow debouncing user calls from API for 2min.
  • Another one is the offline interceptor, which uses cache directory (which provide using Dagger from app module) to save API responses into files for 7 days (maxStaleDay).

Don’t panic if everything is new, you will learn how to use it after some sample project… ;)

Do you trust network condition after an API call failure? No, then please retry!

Network connections are always lossy or even the service might be down for a few seconds and they may cause trouble for the app, so please try again before informing the user about the situation!

I look for retry policies using RxJava but none of them works with Retrofit, but this interceptor works:

you can customize it if you require more retry times or even more condition to decide to retry or not, but I think it is fine. :)

, and how to attach all interceptors to my OkHttp client?

All interceptors are provided inside ClientModule, which also add them all to OkHttpClient:

Take care of the if(isDebug) statement which comes as the result of BuildConfig.DEBUG variable.

There is also the Network Timeout which tells OkHttp how long wait for the response.

…Where is the Retrofit then!

Okay, all these codings was for the final step… Inside ApiModule we use that OkHttpClient to create the Retrofit instance and use it to create MarvelApi:

You have to provide BaseUrl that usually is the first static part of all your service API URLs, which in this sample is “http://gateway.marvel.com:80/”. (don’t forget the last ‘/’, it is required for the Retrofit library and may cause exception)

API provided in this way would be used by SearchInteractorImpl which communicates with service. Retrofit knows how to response using RxJava and you can easily capture the result parse it using Gson and use it with other RxJava operators (i.e map, flat map, filter, etc.) to manipulate and prepare a response and hand it to View layer to present to the user.

That’s it for now…

Please clone the project repo from GitHub and get more familiar with it because in next part I will explain more about RxJava and RxAndroid and how it helps with spreading response from core to View layer.

I look forward to your comments and helping for more improvements with this article.

Share this article if you think it is useful, and follow me for more articles Mohsen Mirhoseini.

To be continued…

Yet another MVP article — Part 4: RxJava and RxAndroid know how to response_Implementing a sample Android Application using MVP, RxJava, Dagger 2, Retrofit2, Test, and all the brand new modern…_hackernoon.com


Written by mohsenoid | Senior Android Developer
Published by HackerNoon on 2016/11/28