Почему поток изменился на основной поток в обратном вызове? - PullRequest
Новая
       4

Почему поток изменился на основной поток в обратном вызове?

0 голосов
/ 11 февраля 2020

Я разрабатываю приложение android с использованием Kotlin и Rx Java.

. Я разработал биллинг в приложении с использованием android новейшего API.

Но библиотека поддерживает только асин c обратный вызов.

Поэтому я делаю код вроде: 

private fun consumePlayStore(consumeParams: ConsumeParams, secKey: String, purchase: Purchase): Single<Pair<String, Purchase>> {
    return Single.create<Pair<String, Purchase>> { emitter ->
        Log.d("TEST", "[Billing] consumePlayStore") // IO Thread

        // Google InApp Library call
        playStoreBillingClient?.consumeAsync(consumeParams) { result, _ ->

            // In here, thread is Main!!! Why!!!
            Log.d("TEST", "[Billing] consumePlayStore - response")  // Main Thread
        }
    }
}


fun consume() {

    verifyCompletable.andThen(consumePlayStore())
            .flatMap(otherJob)
            .subscribeOn(ioScheduler)
            .observeOn(uiScheduler)
            .subscribe()


}

Я не знаю, почему поток изменяется в обратном вызове?

Кто-нибудь, скажите мне, почему?

И как я могу решить эту проблему ???

или лучший дизайн ???

1 Ответ

1 голос
/ 12 февраля 2020

Я нашел причину и решение.

Во-первых, причина в том, что библиотека Google InApp поддерживает только основной поток.

Все методы должны вызываться из поток Ui и все асинхронные обратные вызовы также будут возвращаться в потоке UI.

см .: https://developer.android.com/reference/com/android/billingclient/api/BillingClient.html?hl=ko

Поэтому я исправил свой код следующим образом : 

fun consume() {
    verifyCompletable.subscribeOn(ioScheduler)
            .observeOn(uiScheduler)
            .andThen(consumePlayStore())
            .observeOn(ioScheduler)
            .flatMap(otherJob)
            .subscribeOn(ioScheduler)
            .observeOn(uiScheduler)
            .subscribe()
}

Этот код отлично работает, но я не знаю, что это красивое решение.

Планировщики выглядят очень сложными ...

...