https://kotlinlang.org logo
#orbit-mvi
Title
# orbit-mvi
k

Kshitij Patil

10/31/2023, 1:34 PM
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
@Mikolaj Leszczynski have raised a PR for adding these. Let me know your thoughts on same
m

Mikolaj Leszczynski

11/06/2023, 3:16 PM
@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:
Copy code
// Old test framework
MyContainerHost().liveTest(
    buildSettings = {
        dispatcher = myCustomDispatcher
    }
)

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

Kshitij Patil

11/06/2023, 5:28 PM
@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
m

Mikolaj Leszczynski

11/07/2023, 10:44 AM
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.