Hi all! I've a question more philosophy than coroutines.. Having functions that does not are declare...

# coroutines

[Roberto Fernandez Montero]

Hi all! I've a question more philosophy than coroutines..
Having functions that does not are declared as suspend but inside them there is a scope.launch is a good practice or is better to do the scope.launch{} outside of the function but on each method invocation so each one can decide the scope to run it?
For example:

fun start() {
        coroutineScope.launch {
            socketIoServer.startAsync()
        }
    }

//Another class
socket.start()

or

fun start() {
   socketIoServer.startAsync()
 }
//Another class

scope.launch{ socket.start() }

[Robert Williams]

Pretty much always better to make things suspend and handle the scope at the top level

[Robert Williams]

Launching things in other scopes breaks structured concurrency and can lead to quite subtle bugs if you call this from another suspend fun

[Roberto Fernandez Montero]

So, do you mean option B but making suspend fun start(){}..?

[Robert Williams]

yes, any reason you don't want that?

[Roberto Fernandez Montero]

No, mostly because I'm totally new on coroutines so still trying to understand best practices

[Roberto Fernandez Montero]

Do you know any post or article showing the reasons and so on about that?

[Roberto Fernandez Montero]

and thanks for the answer of course.

[Robert Williams]

If you're familiar with Android this is very similar and relevant (and shows that even Google gets it wrong sometimes): https://medium.com/androiddevelopers/repeatonlifecycle-api-design-story-8670d1a7d333

[Roberto Fernandez Montero]

actually I'm doing an android app right now, so perfect, thanks for it!

[Roberto Fernandez Montero]

Yeah, I saw in official documentation some contradictions even between themselves

[Roberto Fernandez Montero]

btw, I read something that is a good practise to pass the dispatcherProvider to the classes that are going to make some scope.launch. Is that true? Or is better to keep simple and don't do it? I was trying but it gets hard to test if you are not able to send the dispatcherProvider as argument if you need to use the UnconfirmedDispatcher for example

[Riccardo Lippolis]

I'm not an Android developer but have used coroutines on the JVM, but my 2 cents: read about the concept of Structured Concurrency (also mentioned by Robert) to help you decide on the theory of how to properly define / use coroutine scopes, which will help figure out the 'why' part 🙂 (maybe this article by Roman Elizarov will be a good starting point)

[Robert Williams]

Indeed, this video (also by Roman) is excellent:

https://www.youtube.com/watch?v=Mj5P47F6nJg▾

[Robert Williams]

For the Dispatchers question we normally inject CoroutineContext which all dispatchers implement and is suitable for thread switching but not much else

[Robert Williams]

My not great advice is to say don't worry about this too much until you have application wide DI set up after which point it should be pretty simple

[Robert Williams]

But also you probably don't need to use Dispatchers as much as you think you do, especially if you're used to other frameworks like Rx

[Roberto Fernandez Montero]

My concern comes because I'm working in an already existing app, which has no DI (Still..) and there are some classes that make usage of coroutines and I want to test them without send that dispatcherProvider for me seems impossible to do it, unless I take the approach that you suggested up here.

[Roberto Fernandez Montero]

But I will take a look on the video and the post to understand it completely before touch anything

[streetsofboston]

I wrote a blog post a while ago about CoroutineScopes (and when you'd want to cross from one into another)
https://link.medium.com/WFG3lOFtCvb
Hopefully you'll find it useful