Ошибка api android

There could be many ways of handling API responses coming from servers in android but do you use a good way of handling it? In this article, we’ll see API responses handled with the help of Kotlin Sealed Class while using the Retrofit library for API calls. This sealed class approach fits perfectly in this case: If the user is expecting data in UI, then we need to send the errors all the way to our UI to notify the user & to make sure the user won’t just see a blank screen or experience unexpected UI.

Make Sealed Class

Note: We are following MVVM Architecture and using Retrofit with Kotlin Coroutines for api calls in background.

Just create a generic sealed class named Resource in a separate file in your data package or utils/others package. We have named it Resource & created it generic because we’ll use this class to wrap our different types of API responses. Basically, we need to update our UI on these three events i.e. Success, Error, Loading. So, we have created these as child classes of Resources to represent different states of UI. Now, in case of success, we’ll get data so we’ll wrap it with Resource. Success and in case of error, we’ll wrap the error message with Resource. Error & in case of loading we’ll just return Resource.Loading object (you can also alter it to wrap your loading data according to your needs).

Let’s also have a look at our ApiService Interface (see just below), here in every suspended API call function we are wrapping our API call response with Retrofit’s Response class because it provides us some extra info about API calls. For example: whether calls getting successful or not, error code, etc. We’ll call these suspended functions from our repositories… we’ll see that in while. Don’t get confused in our custom Resource class and Retrofit’s Response class. Resource class just represents different states of UI while Retrofit’s Response class gives us extra info about API calls.

Now let’s jump on to the main part of API success/error handling

You must be having different repositories in your project according to your needs and all your api calls must be happening through these repositories we need to do error handling of each & every API call. So, we need to wrap each API call inside the try-catch block. But wait… writing a try-catch block for every api call isn’t a good idea. So, let’s create a BaseRepository & write a common suspend function there named safeApiCall  (any name which you like) which will be responsible to handle api responses of each & every api call.

safeApiCall is having suspended lambda function named ‘api’  that returns data wrapped in Resource so that safeApiCall could be able to receive our every api call function. As safeApiCall is a suspend function so we are using withContext coroutine scope with Dispatchers.IO, this way all network calls will run on the Input/Output background thread. Whenever a network call fails it throws an exception so we need to call our lambda function ‘apiToBeCalled’ inside the try-catch block and here if api call gets successful then we’ll wrap our success response data in Resource. Success object & we’ll return it through safeApiCall and if api call gets failed then we’ll catch that particular exception in one of the following catch blocks:

• When something will went wrong on the server when processing an HTTP request then it’ll throw an HTTP Exception.
• When the user won’t be having valid internet/wifi connection then it’ll throw a Java IO Exception.
• If any other exception will occur then it’ll simply come in general Exception block (put that block in last). You can also add other exceptions catch block according to your specific case before that last one general exception catch block.

Now in catch blocks, we can simply send our own customize error messages or error messages getting from exceptions in Resource.Error object. 

Note: In case if network call doesn’t fail & doesn’t throw an exception instead if it is sending it’s own custom error json response (sometimes happens in case of Authentication failure/Token expires/Invalid api key/etc) then we won’t get an exception instead Retrofit’s Response class will help us determine by returning true/false on response.is Successful. In the above code also we are handling that inside try block, if it returns false then inside else case we’ll parse that api’s own custom error json response (see example below) into a pojo class created by us i.e. ExampleErrorResponse. For parsing this json response to our ExampleErrorResponse pojo, we are using Moshi library in our convertErrorBody function that’ll return ExampleErrorResponse object & then we can get API’s custom error response.

{
   “status”: ”UnSuccessful”,
   “failure_message” : ”Invalid api key or api key expires”
}

So, ultimately our safeApiCall function will return our response wrapped in Resource class. it could be either Success or Error. If you have understood up till this much then shoutout to you. You have won most of the battle.

Now let’s change the way of calling Apis in your current repositories

We’ll extend our all repositories from BaseRepo so that we can access safeApiCall function there. And inside our repo’s functions like getPopularArticles we’ll pass our ApiService’s function ( for ex: apiService.fetchPopularArticles() ) as a lambda argument in safeApiCall and then safeApiCall will simply handle its success/error part then ultimately it’ll return Resource<T> that’ll go all the way top to UI through ViewModel.

Note: Remember when we’ll call getPopularArticles function in viewmodel (see example below) then first we’ll post Resource.Loading object in mutable live data such that our fragment/activity can observe this loading state and can update the UI to show loading state and then as we’ll get our api response ready, it’ll be posted in mutable live data again so that UI can get this response (success/error) update again and can show data in UI or update itself accordingly.

ViewModel

That’s it, now we can observe all the states i.e. Success, Error, Loading in our UI easily. That was about api error handling or api response handling in a better way.

Last Updated :
10 Jan, 2023

Like Article

Save Article

Может быть много способов обработки ответов API, поступающих от серверов в Android, но используете ли вы хороший способ обработки? В этой статье мы увидим, как ответы API обрабатываются с помощью Kotlin Sealed Class при использовании библиотеки Retrofit для вызовов API. Этот подход с закрытым классом идеально подходит в этом случае: если пользователь ожидает данные в пользовательском интерфейсе, нам нужно отправить ошибки в наш пользовательский интерфейс, чтобы уведомить пользователя и убедиться, что пользователь не просто увидит пустой экран. или столкнуться с неожиданным пользовательским интерфейсом.

Сделать запечатанный класс

Просто создайте универсальный запечатанный класс с именем Resource в отдельном файле в вашем пакете данных или пакете utils/others. Мы назвали его Resource и сделали его универсальным, потому что мы будем использовать этот класс для переноса наших различных типов ответов API. По сути, нам нужно обновить наш пользовательский интерфейс для этих трех событий, т. е. Success, Error, Loading. Итак, мы создали их как дочерние классы ресурсов для представления различных состояний пользовательского интерфейса. Теперь, в случае успеха, мы получим данные, поэтому обернем их Resource. Успех и в случае ошибки мы завернем сообщение об ошибке в Resource. Ошибка, и в случае загрузки мы просто вернем объект Resource.Loading (вы также можете изменить его, чтобы обернуть данные загрузки в соответствии с вашими потребностями).

Kotlin

sealed class Resource<T>(

    val data: T? = null,

    val message: String? = null

) {

    class Success<T>(data: T) : Resource<T>(data = data)

    class Error<T>(errorMessage: String) : Resource<T>(message = errorMessage)

    class Loading<T> : Resource<T>()

}

Давайте также взглянем на наш интерфейс ApiService (см. чуть ниже), здесь в каждой приостановленной функции вызова API мы оборачиваем наш ответ на вызов API классом Retrofit Response, потому что он предоставляет нам дополнительную информацию о вызовах API. Например: будут ли вызовы успешными или нет, код ошибки и т. д. Мы будем вызывать эти приостановленные функции из наших репозиториев… мы увидим это через какое-то время. Не запутайтесь в нашем пользовательском классе Resource и классе Response Retrofit. Класс Resource просто представляет различные состояния пользовательского интерфейса, в то время как класс Response Retrofit дает нам дополнительную информацию о вызовах API.

Kotlin

interface ExampleApiService {

    @GET("example/popular_articles")

    suspend fun fetchPopularArticles(): Response<PopularArticlesResponse>

    @GET("example/new_articles")

    suspend fun fetchNewArticles(): Response<NewArticlesResponse>

}

Теперь давайте перейдем к основной части обработки успеха/ошибки API.

У вас должны быть разные репозитории в вашем проекте в соответствии с вашими потребностями, и все ваши вызовы API должны происходить через эти репозитории, нам нужно выполнять обработку ошибок каждого вызова API. Итак, нам нужно обернуть каждый вызов API внутри блока try-catch. Но подождите… писать блок try-catch для каждого вызова API — плохая идея. Итак, давайте создадим BaseRepository и напишем там общую функцию приостановки с именем safeApiCall (любое имя, которое вам нравится), которая будет отвечать за обработку ответов API на каждый вызов API.

Kotlin

abstract class BaseRepo() {

    suspend fun <T> safeApiCall(apiToBeCalled: suspend () -> Response<T>): Resource<T> {

        return withContext(Dispatchers.IO) {

            try {

                val response: Response<T> = apiToBeCalled()

                if (response.isSuccessful) {

                    Resource.Success(data = response.body()!!)

                } else {

                    val errorResponse: ExampleErrorResponse? = convertErrorBody(response.errorBody())

                    Resource.Error(errorMessage = errorResponse?.failureMessage ?: "Something went wrong")

                }

            } catch (e: HttpException) {

                Resource.Error(errorMessage = e.message ?: "Something went wrong")

            } catch (e: IOException) {

                Resource.Error("Please check your network connection")

            } catch (e: Exception) {

                Resource.Error(errorMessage = "Something went wrong")

            } 

        }

    }

    private fun convertErrorBody(errorBody: ResponseBody?): ExampleErrorResponse? {

        return try {

            errorBody?.source()?.let {

                val moshiAdapter = Moshi.Builder().build().adapter(ExampleErrorResponse::class.java)

                moshiAdapter.fromJson(it)

            }

        } catch (exception: Exception) {

            null

        }

    }

}

safeApiCall имеет приостановленную лямбда-функцию с именем «api», которая возвращает данные, завернутые в Resource, чтобы safeApiCall мог получать каждую нашу функцию вызова API. Поскольку safeApiCall является функцией приостановки, мы используем область сопрограммы withContext с Dispatchers.IO, таким образом, все сетевые вызовы будут выполняться в фоновом потоке ввода/вывода. Всякий раз, когда сетевой вызов терпит неудачу, он выдает исключение, поэтому нам нужно вызвать нашу лямбда-функцию «apiToBeCalled» внутри блока try-catch, и здесь, если вызов API будет успешным, мы завернем наши данные об успешном ответе в Resource. Объект Success, и мы вернем его через safeApiCall, и если вызов API завершится неудачно, мы перехватим это конкретное исключение в одном из следующих блоков catch:

• Когда что-то пойдет не так на сервере при обработке HTTP-запроса, он выдаст исключение HTTP.
• Когда у пользователя не будет действительного подключения к Интернету/Wi-Fi, он выдаст исключение ввода-вывода Java.
• Если произойдет какое-либо другое исключение, оно просто появится в общем блоке исключений (поместите этот блок последним). Вы также можете добавить другой блок перехвата исключений в соответствии с вашим конкретным случаем перед последним общим блоком перехвата исключений.

Теперь в блоках catch мы можем просто отправлять собственные сообщения об ошибках или сообщения об ошибках, полученные из исключений в объекте Resource.Error.

Примечание. В случае, если сетевой вызов не завершается ошибкой и вместо этого не выдает исключение, если он отправляет свой собственный ответ json об ошибке (иногда это происходит в случае сбоя аутентификации / истечения срока действия токена / недействительного ключа API / и т. д.), тогда мы выиграли ’ не получите исключение, вместо этого класс Response Retrofit поможет нам определить, возвращая true/false в response.isSuccessful. В приведенном выше коде мы также обрабатываем этот внутренний блок try, если он возвращает false, то внутри другого случая мы будем анализировать собственный пользовательский ответ json об ошибке API (см. Пример ниже) в созданный нами класс pojo, т.е. ExampleErrorResponse. Для разбора этого json-ответа на наш pojo ExampleErrorResponse мы используем библиотеку Moshi.в нашей функции convertErrorBody, которая вернет объект ExampleErrorResponse, а затем мы сможем получить собственный ответ API об ошибке.

{
   “status”: ”UnSuccessful”,
   “failure_message” : ”Invalide api key or api key expires”
}

Итак, в конечном итоге наша функция safeApiCall вернет наш ответ, завернутый в класс Resource. это может быть либо успех, либо ошибка. Если вы поняли до этого, то привет вам. Вы выиграли большую часть битвы.

Теперь давайте изменим способ вызова Apis в ваших текущих репозиториях.

Мы расширим все наши репозитории из BaseRepo, чтобы мы могли получить доступ к функции safeApiCall. И внутри функций нашего репозитория, таких как getPopularArticles, мы передадим нашу функцию ApiService (например: apiService.fetchPopularArticles()) в качестве лямбда-аргумента в safeApiCall, а затем safeApiCall просто обработает свою часть успеха/ошибки, после чего в конечном итоге вернет Resource это дойдет до пользовательского интерфейса через ViewModel.

Примечание. Помните, что когда мы будем вызывать функцию getPopularArticles в модели представления (см. пример ниже), то сначала мы разместим объект Resource.Loading в изменяемых оперативных данных, чтобы наш фрагмент/активность мог наблюдать за этим состоянием загрузки и мог обновить пользовательский интерфейс, чтобы показать загрузку. состояние, а затем, когда мы подготовим наш ответ API, он будет снова опубликован в изменяемых оперативных данных, чтобы пользовательский интерфейс мог снова получить этот ответ (успех/ошибка) и может отображать данные в пользовательском интерфейсе или обновлять себя соответственно.

Kotlin

class ExampleRepo(private val apiService: ExampleApiService) : BaseRepo() {

    suspend fun getPopularArticles() : Resource<PopularArticlesResponse> {

        return safeApiCall { apiService.fetchPopularArticles() }

    }

    suspend fun getPublishedArticles() : Resource<NewlyPublishedArticlesResponse> = safeApiCall { apiService.fetchPublishedArticles() }

}

ViewModel

Kotlin

class ExampleViewModel (private val exampleRepo: ExampleRepo) {

    private val _popularArticles = MutableLiveData<Resource<PopularArticlesResponse>>()

    val popularArticles: LiveData<Resource<PopularArticlesResponse>> = _popularArticles

    init {

        getPopularArticles()

    }

    private fun getPopularArticles() = viewModelScope.launch {

        _popularArticles.postValue(Resource.Loading())

        _popularArticles.postValue(exampleRepo.getPopularArticles())

    }

}

Вот и все, теперь мы можем легко наблюдать все состояния, т.е. Успех, Ошибка, Загрузка в нашем пользовательском интерфейсе. Это было об обработке ошибок API или об обработке ответов API в лучшем виде.