Trying to upgrade orbit from

4.2.0

to

6.1.0

. Not able to find how we provide custom

CoroutineDispatcher

for intents. Earlier, there used to be one parameter

intentDispatcher

in the

Container.Settings

class constructor

@Kshitij Patil We removed it because it was not needed for testing (you can set the dispatcher in test options), and having the option to set it for production code seemed unnecessary and dangerous. As far as testing goes, I personally find there is limited value in overriding the dispatcher. I've literally never done this for the ViewModels I wrote and tested in a large code base. This is even more true if you're using the new testing framework, there should be no need to set the dispatcher in 99% of cases. In the 1% case, you can still set the dispatcher in the test settings:

// Old test framework
MyContainerHost().liveTest(
    buildSettings = {
        dispatcher = myCustomDispatcher
    }
)

// New test framework
MyContainerHost().test(this,
    settings = TestSettings(
        dispatcherOverride = myCustomDispatcher
    )
)

@Mikolaj Leszczynski But I noticed by default you use

Dispatchers.Default

for intent. What if I want to change this to

<http://Dispatchers.IO|Dispatchers.IO>

or some custom dispatcher of dedicated thread pool. Also, when we try to run this with

runTest { }

from kotlinx-coroutines-test, it should get replaced with

UnconfiedTestDispatcher

to avoid any unexpected issues in the test I remember this slide from Dev Summit’19 on Testing coroutines in Android. Not able to understand how things have changed lately

But I noticed by default you use

Dispatchers.Default

for intent. What if I want to change this to

<http://Dispatchers.IO|Dispatchers.IO>

or some custom dispatcher of dedicated thread pool.

Can you give a specific example of why you would need to do that? You can always switch the coroutine context on a case by case basis within your intents or use cases.

Also, when we try to run this with

runTest { }

from kotlinx-coroutines-test, it should get replaced with

UnconfiedTestDispatcher

to avoid any unexpected issues in the test

This is a pretty large topic to discuss 😅 Here is my take on it: 1. 99% of code in mobile apps is not truly concurrent and can be tested without any special ordering requirements, so injecting dispatchers is in most cases unnecessary. 2. Orbit should be treated as a black box - just as the caller doesn't have to know what context a suspending function is running in. 3. By changing orbit's dispatchers you are artificially changing how the code behaves under test - in a way you are departing from testing actual production code 4. Only inject dispatchers where it's necessary. For example, we inject the dispatchers only for our network layer. 5. Coroutines testing has changed a lot since 2019 - these days I find that largely I don't have to change the code under test so much, as

runTest

ensures safe testing of coroutines 6. Orbit's new testing framework is designed to work with

runTest

to ensure you don't need to mess around with dispatchers in the 99% case.