@elizarov How would you simplify that Ion integrat...
# coroutines
@elizarov How would you simplify that Ion integration? With cancel in consideration and that coroutine should be used instead of threads... Im not sure what parts of that implementation are necessary and what not? This is just an example, but ive seen other integrations that also do complex things for what I thought should have been simple. I wonder if they want to avoid an extra dependency, or people are still not grasping how to do the integration properly... maybe a set of guidlines would have been good in such a case...?
For example do not write own async coroutine builder, AsyncContext and Continuation implementation with cancel
And just write simple wrapper for
What about the context, would this block a thread or use suspension until response received?
How context and blocking related?
No, of course, you should use async api and shouldn’t block thread, it’s actually violates “contract” and philosophy of coroutines
kotlinx.coroutines provides very useful more high level components/building blocks to build such integration with support of cancellation and other features without implement it yourself. Of course, if you want to have minimalistic library with coroutine support and do not want to have dependency on kotlinx.coroutines you can implement that yourself, even in this example not so many code.
This function is full code of integration (in this file you can find just a couple additional apis),so you can see this is very simple adapter code to convert callback to coroutine. And this is because I use kotlinx.coroutines
But nothing wrong with own ad-hoc implementation
Thanks for the example! That example is completely async, or it blocks a thread until the response is received?
Async. Retrofit has async API based on OkHttp async API under the hood