Anyone of you can explain how retrofit / room are doing the main-safety stuff? I know that if I put suspend I can avoid the

withContext(<http://Dispatchers.IO|Dispatchers.IO>)

but what if I have some mappers and some business logic? Is it safe to remove the

withContext(<http://Dispatchers.IO|Dispatchers.IO>)

?

Anyone of you can explain how retrofit / room are doing the main-safety stuff?

Under the hood both Retrofit and Room are delegating to their own way of handling async calls. For Room see this article: https://medium.com/androiddevelopers/room-coroutines-422b786dc4c5 For Retrofit the

suspend

calls just delegate to the built in

Call<T>.enqueue

which uses it’s own background executor. see https://github.com/square/retrofit/blob/master/retrofit/src/main/java/retrofit2/KotlinExtensions.kt

I know that if I put suspend I can avoid the 

withContext(<http://Dispatchers.IO|Dispatchers.IO>)

 but what if I have some mappers and some business logic? Is it safe to remove the 

withContext(<http://Dispatchers.IO|Dispatchers.IO>)

 ?

If the business logic and mappers are exclusively working with Room and Retrofit calls then yes it’s fine to remove them.

mapping and all should be done in

Dispatchers.Default

because it can consume a bunch of CPU (as all allocation can).

@louiscad Even if the mapper is not that big? I mean from now I have

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

unnecessary I guess because retrofit has it's own stuff, but when I'm getting the DTO I'm doing some mappers and sort etc, but it's super fast, do I have to use

Dispatchers.Default

anyways?.... I thought I had to change the Dispatcher when I have some heavy task that could work the UI

@Pablo "Not that big" can have very different meanins from one person to the other, but if you go from

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

to

Dispatchers.Default

without going through the main thread in between, there's no actual thread switching, so it's worth doing any computation/allocation/mapping in

Dispatchers.Default

by default, an switch to

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

when needed.

@louiscad I create a CorutineScope that is actually a

MainScope()

so, once I have that I do something like

scope.launch{
//UI stuff
withContext(IO) { usecase call }
//UI stuff
}

The thing is my usecase calls my data source and datasource does a retrofit call, everything is suspend stuff, but the problem is once I have the DTO on datasource I do a mapper to convert it to domain, then in the use-case perhaps I sort or I'm doing something (not always...) For these cases do I have to change the dispatcher ? I mean I want to remove IO because I do not need it to call the retrofit call but under the hood I have more "logic" is not like get the data parsed from JSON and print it, no, I'm doing more stuff..

@Pablo IMO, only the strictly UI stuff should run on the main thread. You can wrap the whole everything else into

Dispatchers.Default { }

ok, so main thing like show dialog, show toast, and stuff like that is ok to run it on the

Dispatchers.Main

ok, but then if we have stuff like mappers/sortings/etc better on

Dispatchers.Default

The thing is that doing a retrofit call might not be the only work that you need to do

But obviously, inside of that is not only the call, there's mappers and stuff.. so you recomend to me to use

Dispatchers.Default

, right instead?

Same for Room

Correct, but as I said in the comments, I do mapper sorting comparators things, that's more work, perhaps not much like doing a for loop of 1000000 elements, but it's something...

Yes, that's why I recommended to use

Dispatchers.Default