хорошая идея или не хорошая: использовать сопрограммы для ответа Kotlin - PullRequest
Новая
       11

хорошая идея или не хорошая: использовать сопрограммы для ответа Kotlin

0 голосов
/ 08 апреля 2019

хочу спросить у хороших разработчиков.Может быть, кто-нибудь может лучше объяснить.Где-то в сети я обнаружил, что немногие авторы используют сопрограммы вместо, например, асинктаск.Просто пытаюсь улучшить себя.Вот небольшая часть кода, который я использовал.Просто хочу знать - хорошо это или нет.Если нет - как сделать это лучше или, может быть, в конечном итоге я использую это неправильно. 

 fun demoCall(callback: OnResponse) {
       CoroutineScope(Dispatchers.Main).launch {
          val result = withContext(Dispatchers.IO) {
             Api.getResponse("GET", ApiConstants.test_endpoint)//networkOnMainThread exception if i will not use withContext
          }
          callback?.onResponse(result))
       }
  }

Этот пример работает.Но я не уверен, что это хорошее использование.Если вернуться в прошлое,

getResponse

было в asyncTask.Вызов был таким же, как и анонимный обратный вызовЕсли использовать этот способ хорошо, похоже, я могу использовать эту часть без обратного вызова?Точно так же 

fun demoCall() {
 CoroutineScope(Dispatchers.Main).launch {
    val result = withContext(Dispatchers.IO) {
       Api.getResponse("GET", ApiConstants.test_endpoint)
    }
    //do anything with result
    //populate views , make new response etc.. 
}

будет очень рад, если кто-нибудь скажет мне - нормально это или нет :) С уважением

1 Ответ

1 голос
/ 09 апреля 2019

Я предпочитаю, чтобы асинхронные вызовы рассматривались как синхронные в представлении вызывающего абонента с использованием ключевого слова suspend.

Например, 

suspend fun demoCall(): String {
    return withContext(Dispatchers.IO) {
        Api.getResponse("GET", ApiConstants.test_endpoint) // let's assume it would return string
    }
}

и вызывающий абонент может использовать его 

CoroutineScope(Dispatchers.Main).launch {
    val result = demoCall() //this is async task actually, but it seems like synchronous call here.
    //todo something with result
}
...