well, both! <https://github.com/gildor/kotlin-coro...
# androidj
jw
09/01/2017, 6:56 PM🎖️ 2
b
budioktaviyan
09/02/2017, 12:59 AMbudioktaviyan
09/02/2017, 1:00 AMwhich one is good ? I'd rather use this one. it has a wrapper for Call Adapter Factory
j
jw
09/02/2017, 1:55 AMBoth are good, they just have different approaches.
b
budioktaviyan
09/02/2017, 1:59 AMor did you have another best approach ? especially for coroutine. I have a plan to change my existing Rx into Coroutine ^^
j
jw
09/02/2017, 2:01 AMNope. I think both of those libraries each have their merits for the approach. It all comes down to which behavior you prefer for your integration. If we ever were to ship first-party support, though, it would probably be like the second library which you linked.
b
budioktaviyan
09/02/2017, 2:03 AMic, thanks for your info :)
g
gildor
09/03/2017, 7:18 AM@budioktaviyan I choose my approach for kotlin-coroutines-retrofit because it gives more flexible API and allow you work with existing retrofit interfaces without refactoring.
Also, approach from retrofit-coroutines forces you to use particular dispatcher for each retrofit interface and you cannot change it, only create new instance with another dispatcher.
But if you don’t have existing retrofit code and want to use it only from kotlin and you don’t need flexible dispatchers, it’s good approach, more natural for user of interface
b
budioktaviyan
09/03/2017, 7:21 AMsure, I will try to implement with your libs. thanks for your explanation ^^