Elegant way of handling error using Retrofit + Kotlin Flow

Question

I have a favorite way of doing network request on Android (using Retrofit). It looks like this:

// NetworkApi.kt

interface NetworkApi {
  @GET("users")
  suspend fun getUsers(): List<User>
}

And in my ViewModel:

// MyViewModel.kt

class MyViewModel(private val networkApi: NetworkApi): ViewModel() {
  val usersLiveData = flow {
    emit(networkApi.getUsers())
  }.asLiveData()
}

Finally, in my Activity/Fragment:

//MyActivity.kt

class MyActivity: AppCompatActivity() {
  private viewModel: MyViewModel by viewModels()

  override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)
    setContentView(R.layout.activity_main)

    viewModel.usersLiveData.observe(this) {
      // Update the UI here
    }
  }
}

The reason I like this way is because it natively works with Kotlin flow, which is very easy to use, and has a lot of useful operations (flatMap, etc).

However, I am not sure how to elegantly handle network errors using this method. One approach that I can think of is to use Response<T> as the return type of the network API, like this:

// NetworkApi.kt

interface NetworkApi {
  @GET("users")
  suspend fun getUsers(): Response<List<User>>
}

Then in my view model, I can have an if-else to check the isSuccessful of the response, and get the real result using the .body() API if it is successful. But it will be problematic when I do some transformation in my view model. E.g.

// MyViewModel.kt
class MyViewModel(private val networkApi: NetworkApi): ViewModel() {
  val usersLiveData = flow {
    val response = networkApi.getUsers()
    if (response.isSuccessful) {
      emit(response.body()) // response.body() will be List<User>
    } else {
       // What should I do here?
    }
  }.map { // it: List<User>
    // transform Users to some other class
    it?.map { oneUser -> OtherClass(oneUser.userName) }
  }.asLiveData()

Note the comment "What should I do here?". I don't know what to do in that case. I could wrap the responseBody (in this case, a list of Users) with some "status" (or simply just pass through the response itself). But that means that I pretty much have to use an if-else to check the status at every step through the flow transformation chain, all the way up to the UI. If the chain is really long (e.g. I have 10 map or flatMapConcat on the chain), it is really annoying to do it in every step.

What is the best way to handle network errors in this case, please?

You should use a repository to handle your network request not your viewmodel, with your approach, your viewmodel will be messy and hard to test. Also from the repository class, you can wrap your network call inside a try catch — Wale, Jun 02 '21 at 21:04
Thank you for replying, @Wale. Even if I add a repository layer between my view model and my network APIs, how would it help exactly? — seemuch, Jun 02 '21 at 21:28
Like I said, it enables your ViewModel more testable, you're increasing your ViewModel responsibilities! How it would help? when you have a repository, you relatively will find it easier how to handle the error, here is a tip, create a Object, like a DTO that handles the data and errors from API to UI, in your repository, you do the single check of responseBody and parse appropriate values to the DTO, that way your model has. nothing to do than to just send the liveData to the UI. — Wale, Jun 02 '21 at 23:39
Secondly, when you take the approach of a repository, it will help you reduce the duplicity of that if statement in your ViewModel that's frustrating you. How? if you have n(ViewModels) they can all talk to the repository and you will not have the conditional logics implemented in each of them...that alone is priceless. — Wale, Jun 02 '21 at 23:42
My take away from your comments are: 1) Create a repository layer, and put the "data mapping" process inside it, rather than inside ViewModel. ViewModel should only be responsible for sending data to UI; and 2) In the repository layer, I could have some DTO that contains both "real" data and, say, a status. That makes sense. Thank you very much! — seemuch, Jun 02 '21 at 23:53
What about doing 'throw Kotlin.Exception(string fault msg)', and write a catch block where you observe the flow? — March3April4, Jan 27 '22 at 14:26

Teo · Accepted Answer · 2021-06-04T02:36:47.790

You should have a sealed class to handle for different type of event. For example, Success, Error or Loading. Here is some of the example that fits your usecases.

enum class ApiStatus{
    SUCCESS,
    ERROR,
    LOADING
}  // for your case might be simplify to use only sealed class

sealed class ApiResult <out T> (val status: ApiStatus, val data: T?, val message:String?) {

    data class Success<out R>(val _data: R?): ApiResult<R>(
        status = ApiStatus.SUCCESS,
        data = _data,
        message = null
    )

    data class Error(val exception: String): ApiResult<Nothing>(
        status = ApiStatus.ERROR,
        data = null,
        message = exception
    )

    data class Loading<out R>(val _data: R?, val isLoading: Boolean): ApiResult<R>(
        status = ApiStatus.LOADING,
        data = _data,
        message = null
    )
}

Then, in your ViewModel,

class MyViewModel(private val networkApi: NetworkApi): ViewModel() {

  // this should be returned as a function, not a variable
  val usersLiveData = flow {
    emit(ApiResult.Loading(true))   // 1. Loading State
    val response = networkApi.getUsers()
    if (response.isSuccessful) {
      emit(ApiResult.Success(response.body()))   // 2. Success State
    } else {
       val errorMsg = response.errorBody()?.string()
       response.errorBody()?.close()  // remember to close it after getting the stream of error body
       emit(ApiResult.Error(errorMsg))  // 3. Error State
    }
  }.map { // it: List<User>
    // transform Users to some other class
    it?.map { oneUser -> OtherClass(oneUser.userName) }
  }.asLiveData()

In your view (Activity/Fragment), observe these state.

 viewModel.usersLiveData.observe(this) { result ->
      // Update the UI here
    when(result.status) {
      ApiResult.Success ->  {
         val data = result.data  <-- return List<User>
      }
      ApiResult.Error ->   {
         val errorMsg = result.message  <-- return errorBody().string()
      }
      ApiResult.Loading ->  {
         // here will actually set the state as Loading 
         // you may put your loading indicator here.  
      }
    }
 }

Thank you for the answer. I have a question though. `ApiResult` looks great. But how should I make Retrofit return `ApiResult`? I need to adapt the output of my Retrofit method to `ApiResult` somehow, right? Where/how should I do it? — seemuch, Jun 03 '21 at 16:26
One approach I can think of is to combine what you said with what Wale said in the comments above. I.e. create a repository layer, and inside it, I convert the output of Retrofit (e.g. a `Response`) to a `ApiStatus` you mentioned. I mean, I can see that `ApiStatus` has "loading" state that `Response` does not have. But do we really need this many layers of data wrapper? It looks excessive. — seemuch, Jun 03 '21 at 16:55
`ApiResult` is just a wrapper for your datatype, similar to `Response`. I had edited my answer so that you can get your data in the view. — Teo, Jun 04 '21 at 02:34
`ApiResult` is a sealed class that holding state. Please refer this video to know more. https://www.youtube.com/watch?v=OyIRuxjBORY — Teo, Jun 04 '21 at 02:38

omran elshawy · Answer 2 · 2022-01-20T14:25:55.640

//this class represent load statement management operation /*

What is a sealed class
A sealed class is an abstract class with a restricted class hierarchy.
Classes that inherit from it have to be in the same file as the sealed class.
This provides more control over the inheritance. They are restricted but also allow freedom in state representation.
Sealed classes can nest data classes, classes, objects, and also other sealed classes.
The autocomplete feature shines when dealing with other sealed classes.
This is because the IDE can detect the branches within these classes.
*/

ٍٍٍٍٍ

sealed class APIResponse<out T>{

    class Success<T>(response: Response<T>): APIResponse<T>() {
        val data = response.body()
    }


    class Failure<T>(response: Response<T>): APIResponse<T>() {
        val message:String = response.errorBody().toString()
    }


    class Exception<T>(throwable: Throwable): APIResponse<T>() {
        val message:String? = throwable.localizedMessage
    }


}

create extention file called APIResponsrEX.kt and create extextion method

fun <T> APIResponse<T>.onSuccess(onResult :APIResponse.Success<T>.() -> Unit) : APIResponse<T>{
    if (this is APIResponse.Success) onResult(this)
    return this
}

fun <T> APIResponse<T>.onFailure(onResult: APIResponse.Failure<*>.() -> Unit) : APIResponse<T>{
    if (this is APIResponse.Failure<*>)
        onResult(this)
    return this
}

fun <T> APIResponse<T>.onException(onResult: APIResponse.Exception<*>.() -> Unit) : APIResponse<T>{
    if (this is APIResponse.Exception<*>) onResult(this)
    return this
}

merge it with Retrofit

inline fun <T> Call<T>.request(crossinline onResult: (response: APIResponse<T>) -> Unit) {
    enqueue(object : retrofit2.Callback<T> {
        override fun onResponse(call: Call<T>, response: Response<T>) {
            if (response.isSuccessful) {
               // success
                onResult(APIResponse.Success(response))
            } else {
               //failure 
                onResult(APIResponse.Failure(response))
            }
        }

        override fun onFailure(call: Call<T>, throwable: Throwable) {
            onResult(APIResponse.Exception(throwable))
        }
    })
}

Elegant way of handling error using Retrofit + Kotlin Flow

2 Answers2