A modern programming language that makes developers happier.

kotlinlang

image.png

I am referring this talk by *`Márton Braun`* .
<https://youtu.be/nKCsIHWircA?t=1124>

Does this mean `async` is always preferred over `launch`  even when fire and forget works for my functionality?
<https://kotlinlang.slack.com/files/UPQU769PU/F07Q66B5WAG/image.png>
<https://kotlinlang.slack.com/files/UPQU769PU/F07QGBQLUUR/image.png>

I think I'd agree with the general point he's making, that starting async work without giving callers a way to wait for it isn't very helpful. But there's no reason to return Deferred&lt;Unit&gt;; the Job returned by launch will do just as well

The timestamp is about 18:42 for anyone else looking at the video

I am trying to test a method in my view model which has `viewModelScope.launch { }` .
When using `StandardTestDispatcher` , I am not sure how to launch the coroutines.

I always understood it as async is for if you care about the return value as well as the job and launch is if you don't care about the value

Hi Blake,

Yes, I refer to the same guidelines when deciding between `launch` or `async`. That's why I found this situation a bit confusing.

I'm trying to understand if there's anything else I should consider when making the choice.

I just watched the portion relating to your question. I'm in agreement with Sam. If you need to wait for it in a test, just return the Job from the launch

In my case, I am launching coroutines that collect continuously.
So, even if I do `return viewModelScope.launch {}` , I am not sure how that helps.
This is the actual issue - <https://kotlinlang.slack.com/archives/C1CFAFJSK/p1727888646418719>.

I see what you're saying. I was looking at a previous example of mine where I was using `UnconfinedTestDispatcher` and I was able to launch stuff with the  `backgroundScope` . Would it make sense to break up the two different launches into separate functions so that you can use call them for tests?

Okay, in my actual code, they are in separate methods, but they are `private` .

I would prefer not to expose them just for testing.

Also, it is not possible in all places to split multiple continuous flow collectors.