Avoid THIS Fatal Coroutine Mistake in Kotlin

[@libinmathew2566]

An async block runs only in parallel if two blocks are in different threads. Otherwise, it runs concurrently.Above eg, it runs in parallel because the delay function block first async and thread become free and thread can be used by the second async. You can check it by removing the delay function function.

[@ayoubmazrou8800]

I was making 2 blocks of launch {} for each function . To run it in parallel

[@RinoSss]

The point here is not that using deferred() allow us to perform async code, because firstly we have to know what basically executing code with deferral means.
What it really matters is that we actually perform both network calls in 2 separated and concurrent coroutines.
As the execution finishes, whether or not we are interested in their return value that's when we speak about using a deferred() or a common launch() block.
Great insight by the way

[@ruavaen]

Nice opportunity to show the deferred requests for when you can make parallel network requests but you need the result of all of them to proceed

[@azizbekrasulmetov9293]

The point here is to launch coroutine separately to achieve concurrency

[@benjamin1313]

Just gotten into learning about coroutines. Thanks for the great tip.

[@sushilkafle6501]

Woww... this made the concept crystal clear... hats off 👏 🙌

[@jaidynbelbin4863]

Just like async let in Swift. Nice little video 🙂

[@aapipcps2311]

this help me to understanding coroutine, thanks

[@azizbekrasulmetov9293]

We can achieve it with launch as well if it doesn't return anything!

[@angelomarzocchi4202]

This man is the goat

[@dhruvsharma8839]

Without asyn it will come in single coroutine where as using async it will make both calls parallel.

[@shlusiak]

From "Fatal mistake" to "mistake" to "performance tip"... Bit sensational title, no?

Very nice 👍

[@zekininadresi]

async-await is to decompose a task into potentially multiple running subtasks, right? so how this can be used to run independent tasks?

[@leolr111]

This would be necessary when I use retrofit network calls?

[@josemejia-xg6oi]

Its like js async await

[@irineu333]

Muito bom

[@vengateshm2122]

It will still take two seconds even if you use async because runblocking doesn't execute them sequentially only.

[@PhilippLackner]

Did you watch the video?

[@hardendurorider]

fatal? no! not the best performance? yes! don't clickbait with these titles

[@PhilippLackner]

Lol, if you're making 100 network calls each taking a second, we're talking about 100s vs 1s of execution time. If that isn't fatal, what is?

[@hardendurorider]

​@@PhilippLackner most I did is 26 api calls in one screen :D still not fatal, haha, and if that is the case it's easy to spot the issue.
By the time you might consider it" fatal" you're gonna realize that you are doing something wrong.
My point being is that if you're doing 1-2-3 apoi calls sequential is not "fatal", many times you don't even realize (not saying it's ok to do them in sequence): the app will be slightly slower but you can use it. Between 100ms to 200ms is still a usable app, not fatal!

[@nesletchimaew9209]

​@@hardenduroriderits absolutely fatal if you're serious about performance. I cannot sleep if my code is not perfect

[@hardendurorider]

@@nesletchimaew9209 haha. True in absolute terms, won't complain

[@petrushoc]

awaitAll is better

[@ahmedmohammed9395]

Nice tip Phillip.
It's truly wrong to use coroutines like this with exception to scenarios where you actually need to make a network call first before another.