Why Dispatchers are being injected into repos but not usecases?

[arenshaee]

As I dug into the official guidelines asked around and searched the web, everyone seemed to agree that dispatchers are better to inject into use cases. but here is not the case. I'd appreciate it if someone could provide the reasoning behind this decision alongside some information on why the other way is not optimal.

Thanks.

[SimonMarquis]

@arenshaee can you share a specific example in this codebase and any relevant official guidance around this subject?

I suspect we do not inject any dispatchers in the usecases because they don't bring any value.
Most of the usecases are simply delegating calls to repositories, which already takes care of switching to a proper dispatcher.
One could say switching to the default dispatcher could be useful for the mapping code (from network model to domain model) is the right thing to do, but in practice, creating these small objects has a very limited impact on the actual performances, at the benefit of code clarity.

[arenshaee]

Can you provide links to these guidelines and discussions you are mentioning? That way we can make sure we are on the same page and better answer you.

This one for example(Please check its item 3). And as I mentioned, saying I saw it on official docs was an error on my side. I saw it on a couple of articles, and asked some people who are working on projects with great scale about it.

same thing, can you give an example of it?

The constructor of DefaultSearchContentsRepository.kt which is like below:

internal class DefaultSearchContentsRepository @Inject constructor(
    private val newsResourceDao: NewsResourceDao,
    private val newsResourceFtsDao: NewsResourceFtsDao,
    private val topicDao: TopicDao,
    private val topicFtsDao: TopicFtsDao,
    @Dispatcher(IO) private val ioDispatcher: CoroutineDispatcher,
) 

[SimonMarquis]

Then from what I read from your link, it pretty much says the same thing as I did:

any heavy operation is handled on a separate thread

Mapping a fairly small list of data classes is probably not considered a heavy operation.

On the other hand, if your usecase aggregates multiple sources of data, sorts large collections of items, or needs to execute other long running tasks, then switching dispatcher will be required to remain "thread safe" (i.e. not blocking the calling thread)

[arenshaee]

Yes you're right(Thanks for taking the time and answering btw).
But the main question is still unanswered(or maybe I'm not getting it).
Should dispatchers be injected into use cases or repos.?

[SimonMarquis]

As always, it depends.
You should only inject dispatchers when they serve a real purpose.
In most cases, you don't even need to handle dispatchers as libraries like Room (for database access) or Retrofit (for network calls) already switch threads for you.
And if the usecases are not doing anything worth switching threads, then you don't need to inject anything.

And, as a general rule (which might also answer your question), all suspend functions should be main safe. This means, coroutine functions should only explicitly switch thread when they are themselves executing the "heavy work". If they are only delegating to other suspending calls, they don't need to do anything special.

https://developer.android.com/kotlin/coroutines/coroutines-best-practices#main-safe

This pattern makes your app more scalable, as classes calling suspend functions don't have to worry about what Dispatcher to use for what type of work. This responsibility lies in the class that does the work.

[arenshaee]

Aha. Got it. Thank you.

[Jaehwa-Noh]

If you need to use another type of dispatcher over repositories, you can inject it into an usecase.