Nerd For Tech

NFT is an Educational Media House. Our mission is to bring the invaluable knowledge and experiences…

Follow publication

Safe Retrofit calls extension with kotlin Coroutines for Android in 2021 — Part III

Photo by Fotis Fotopoulos on Unsplash

So this is it. The end of this small series. If you haven’t seen the first two parts, here are the links to it.

Quick Recap!

First of all, congrats for having progressed this far 👏.

  • We needed an extension for make retrofit calls safety ✔️.
  • We needed a way to parse the exceptions and return them into human readable objects✔️.
  • We needed to return a a success or a failure as result✔️.

And now we are going to add our middleware. This functionality will allow us to prevent the execution of the retrofit calls if any of its conditions is not supplied. Something like

if(middlewareConditionsAreSupplied) executeRetrofitCall else NOT!

Middleware Requirements

  • Extendable — Our app can have more than one Middleware. We could have a middleware that validates the network connection, another that validates some specific feature params, etc. Anything you can image in order to prevent the execution of the retrofit call.
  • Easy to inject — We need to create an object that can be easy to inject in our safe retrofit call wrapper extension.
  • Easy to mock — We need somehow to make this middleware easy to mock in order to prevent our unit tests become hard to test.
  • Retrieve all — We need a way to retrieve all our middlewares and validate each one of them.

Code time 🔥

Now that we set up the requirements for the Middleware, we can code. Let’s start with the first part. We are planning to integrate this functionality to our call wrapper extension, therefore, it means that the failure of a middleware is going to return a Failure object. That it’s our start point.

class NetworkMiddlewareFailure(
val middleWareExceptionMessage: String,
) : Failure.CustomFailure()

Easy cake. Let’s move to the next steep. Our app can have multiple middleware objects, and any of them needs to be validated somehow, let’s use the inheritance principle in order to accomplish this step.

This class will do the job. Every middleware we want to create will going to extend this class and override the isValid() method (here is the place to put our our logic) and the failure variable which extend from our custom failure from above.

Let’s create a simple middleware then!

Middleware that validates if the phone is connected to the internet.

The class from above is responsible for tell us if we are connected to the internet or not with the help of the connectivityUtils interface (the implementation class is somewhere hided).

If the isValid() method return false, then we are going to use the NetworkMiddlewareFailure with a custom message from our res/strings folder with the help of the resourceProvider interface. As you can see, our implementation is very flexible and allow us to use whatever we want to create a middleware.

Ok, we can create a lot of middlewares, and now what…? We need some way to provide all our middlewares and run the isValid() method on each of them 🤯!

Hey hey hey 👊💥! Don’t panic. We can solve this problem very easily with the dependency inversion principle. It is better for us to depend on abstractions rather than implementations. Let’s create an interface that would do what we want.

Interface with one method to retrieve all the BaseNetworkMiddleware instances.

Now is the turn for the implementation. We are going to create a class that implements our MiddlewareProvider interface and overrides that getAll() method in order to return all of our middleware objects. We can get a little bit fancy here and do it with a builder pattern.

MiddlewareProvider that store all the middleware instances in a private list.

As you can see, the class above is going to add all the middlewares you want. You only need to provide this class in your dependency injection graph which can be from dagger or koin or whatever.

Sample on how to provide your MiddlewareProvider to your DI graph.

Now we have a singleton instance of our middleware provider. Let’s modify the call wrapper extension!

Well done my friend 👏! You have implemented a middleware to our extension and make it even safer! Now you can use it as I show you in the first part of these series.

I hope you like it. If you have any suggestions, improvements, complaints, jokes, etc. Add a comment, file and issue, generate a PR, etc! Stay safe!

See how this implementation is used on this project

See you later! 👋

Sign up to discover human stories that deepen your understanding of the world.

Free

Distraction-free reading. No ads.

Organize your knowledge with lists and highlights.

Tell your story. Find your audience.

Membership

Read member-only stories

Support writers you read most

Earn money for your writing

Listen to audio narrations

Read offline with the Medium app

Nerd For Tech
Nerd For Tech

Published in Nerd For Tech

NFT is an Educational Media House. Our mission is to bring the invaluable knowledge and experiences of experts from all over the world to the novice. To know more about us, visit https://www.nerdfortech.org/.

Christopher Elias
Christopher Elias

No responses yet

Write a response