Hi, I am trying to migrate my app architecture (which is basically Clean Architecture based on RxJava) to Clean Architecture based on kotlin coroutines. There is one thing that I am still struggling is coroutines dispatchers. Previously with RxJava it was common to place main thread and background Schedulers in UseCase and then use them when creating Observable. Right now I see that in some cases developers put coroutine dispatchers in UseCase and then triggering coroutine with specific dispatchers. In other cases I saw that UseCase was made basically just a suspend function and all work related to dispatching was moved to the caller of the UseCase. Any ideas what is more correct way to do this?

I’d say letting the caller decide the execution context is often a better solution for two reasons, this way you don’t have to differentiate between sync/async UseCases, and you can run some potentially expensive computations (like mapping domain to UI models) in a background thread from the caller

@sergio250 thanks, I was also more to this approach

I think I have some (very basic) example of this approach in a Kata we use for UI testing in my company

let me have a look

why don’t you join #coroutines

@oday because this topic relates more to general architecture rather than coroutines

You are right 🤔

On the other hand there is

coroutineScope {}

which as far as I understood creates a child scope based on the parent and allows to call async await coroutines

Yes, you can have an extension on CoroutineScope when launching coroutines