Using runBlocking at implementation level is generally not recommended (see https://www.billjings.net/posts/title/foot-marksmanship-with-runblocking/?up=). A more idiomatic to Kotlin approach is to simply expose coroutine in public API, make sure internal coroutines are ran on appropriate dispatchers and let the consumer use the API as needed.
Additional cleanup coroutine change: remove unnecessary async + await(). Instead call the suspending coroutine directly, there's no functional difference here.
Note a new kotlin coroutines test dependency is added to be able to use coroutine test infrastructure in tests. Practically speaking, the main change there is just to wrap a test into a runTest.
kirillzh
commented
3 months ago
Using
runBlockingat implementation level is generally not recommended (see https://www.billjings.net/posts/title/foot-marksmanship-with-runblocking/?up=). A more idiomatic to Kotlin approach is to simply expose coroutine in public API, make sure internal coroutines are ran on appropriate dispatchers and let the consumer use the API as needed.Additional cleanup coroutine change: remove unnecessary
async + await(). Instead call the suspending coroutine directly, there's no functional difference here.Note a new kotlin coroutines test dependency is added to be able to use coroutine test infrastructure in tests. Practically speaking, the main change there is just to wrap a test into a
runTest.