It's parellel dispatch and you can even use it for async mapper. You can make the code shorter if you want: val firstNames = userIds.map { userId -> async { getFirstName(userId) } }.awaitAll()
Hi, do you mind answering some of my questions regarding this async? When using async and awaitAll() to get data, is there a chance that the order of name lists retrieved will be changing every time the operation is done? Because I thought since it's being done parallel, there's a time when some data in API are obtained faster than others, making the order of the list changing every time based on how the network performance is right? Or the list will be always the same?
@@pradiptapriya7546 It's same with async { getFirstName(userIds[0]) } + async { getFirstName(userIds[1]) } + async { getFirstName(userIds[2]) }... So, it should be the same order.
Hi @Philipp Lackner for the great video! However I believe, that there is "mistake" in mistake #3. Right now networkCall() is thread-safe since it's using delay(), which is non-blocking operation. Thus I will not block underlying thread/dispatcher. Perhaps If you would like to demo blocking IO call - you can use Thread.sleep(2000) instead.
I don't know how to express how helpful this video was. blogs and tutorials often tell us what to do, but it's important to understand what not to do as well. Looking forward to more videos like this
Pay attention, that when you use .awaitAll() function in the list of deferred items and if any of these will throw exception, you'll get exception for the whole operation. So, you should use .awaitAll() only in case, when you except full success of all async calls. In other case to handle exceptions for specific items, you can use list.map { it.await() } and try/catch block.
Like this? suspend fun getUserFirstNames(userIds: List): List { // Alternative solution - executed in parallel, but allows for each item to cause exception val firstNames4 = coroutineScope { userIds.map { userId -> async { try { getFirstNameWithExceptions(userId + 1000) } catch (e: Exception) { println("Exception in getUserFirstNames: $e") "Error for id=${userId+1000}: $e" } }.also { } } }.also { }.awaitAll() return firstNames4 } suspend fun getFirstNameWithExceptions(userId: Int): String { delay(500) println("getFirstName: $userId") if (userId > 1005) { // simulate an error throw Exception("userId > 505") } return "John $userId" } // note: I am using the `.also{}` blocks in order to let the IDE show the type at that point in execution
This is so good and clear! This also explains some minor issues I have to understand some of the functionality with coroutines. I'm going to use this video as code snippets when coding my coroutines 😀
Mistake 4. If you make this suspending function return coroutineScope ( The suspend function you also used for mistake 2) or even withContext. Then the cancellation exception will be actually propagated to the outer scopes even if you explicitly catch in inside riskyTask e.g suspend fun riskyTask() = withContext() {}
Why it necessary to call async function inside coroutine scope? 🤔 We can call a suspend function in other suspend function right? Or we call coroutine scope so that the function inside coroutine scope works independently?
Usually your coroutines code runs sequentially. We use async so that we can immediately loop and call async again for the new iteration. This way you start all jobs initially and then wait for all of them to finish with "awaitAll".
@@ackerman6992 Its for that reason. If you don't you will run everything sequentially. Usually you don't need to if you're fine with that. Good name btw, I'm in love by Shingeki no Kyogin. :D
@@ackerman6992 coroutinescope, in this context , this is required because u r launching the coroutines with async, and to control them u need coroutinescope here !! And inside a suspend function we can't launch a coroutine !!
@PhilippLackner @17:36 you mention needing to cancel the long-living CoroutineScope, but did you mean any Jobs that were started with the long-living CoroutineScope, and not cancelling the CoroutineScope itself? I dont see any way to cancel the CoroutineScope, just jobs associated with the scope. Please advise.
And in example 1 there is an interesting moment: Since we use coroutineScope{}, we dont need to await all deffered elements, because, With the rules of "Structured Concurrency", the Deffered, which is being launched under the hood in coroutineScope{} will not be completed until all children get completed, so this call of coroutineScope will wait until all async{} will give us the result. After this, we can use non-suspend method getCompleted() to just collect values.
Very helpful explanations! At 4:07, with what keystrokes did you move the whole for loop up together? Ah, looks like Shift+Cmd+Up on Mac. Very useful! (Unfortunately, the video title is misleading clickbait. These are not mistakes that "nobody tells you about." Making your suspend functions main-safe, for example, is a principle thoroughly discussed in Android documentation about coroutines.) On mistake #5, the point is valid that the lifecycleScope is too short-lived for the purpose of posting data to an API, and using the viewModelScope is an improvement. But the ViewModel too can be destroyed (for example if the user navigates to another activity) while data is being posted to the API, and that is not what the user wants either. Android docs recommend that "business-oriented operations," such as uploading users' data, should survive even process death. For that, WorkManager is recommended.
In mistake #1 since we have multiple coroutines spawned by async, and they all access the mutableListOf concurrently, shouldn’t we use thread safe data structure, for example COW list instead?
Hello, thanks for the amazing videos but one question always concerns me: isn't sometimes the overhead of creating a lot of coroutines defies the purpose of performing tasks in parallel? or wouldn't it be a problem?
Great video. Rather than checking if an exception is a CancellationException in a try-catch block, you could use runCatching instead which does not catch CancellationExceptions
Google says Don't hardcode Dispatchers when creating new coroutines or calling withContext. inject Dispatchers This dependency injection pattern makes testing easier as you can replace those dispatchers in unit and instrumentation tests with a TestCoroutineDispatcher to make your tests more deterministic
I'm glad you're here to tell me about those mistakes, you are the best. I see the next video coming: "5 Fatal Kotlin Flows Mistakes Nobody Tells You About" :D
my question is ? will its good or bad to use repository class in the last mistake ? i think so viewModel should not interact with your api , repository class should interact with your api and give data to viewModel and then viewModel give data to activity or fragment ui right ???
Everyone is providing video ideas so I would say it too: Running android Junit and Android tests on Gitlab's CI on every commit. If you're had any experience with this it would be a great video. Maybe with docker maybe without it.
Wow thank you, didn't realize I made a lot of inefficient coroutine calls in my app! 😅 Does your paid course cover this extensively? Will need to check it out
I think mistake 2 is misleading, because that code should be safe as written. But I agree, with components that aren't coroutine safe, like long running calculations, you should do a check before continuing them whenever it makes sense.
Even without async just with the launch, we can have parallel execution because both are non-suspending calls !! Async is specifically useful when you want to get something out from a coroutine !!
For Mistake #1, doesn't creating a new coroutineScope inside a suspend function loose the parent scope? I mean, if some error is thrown inside that coroutineScope, the parent will not get cancelled...
The coroutineScope function creates a CoroutineScope that inherits the context of the parent and forwards cancellations/exceptions to the parent scope. More info: kotlin.github.io/kotlinx.coroutines/kotlinx-coroutines-core/kotlinx.coroutines/coroutine-scope.html
IMHO mistake 4 should be about using CancelationExceptions in the first place. Making flow-control with a callstack dependent concept is already the mistake. Quite disappointed to learn that kotlin uses Exception to control the active state of its routines. I hoped they learned from the broken InterruptedException from java I just wonder why and how this can be overlooked when designing a new language. TL;DR mistake 4 the mistake is the CancelationException and not the people forget to handle this one Exception differently.
There's something weird with the first example... isn't appending to the list synchronous in here? Why didn't we include it in the async block? I don't know the first thing about Kotlin, I use different tools, but to me this didn't fix anything, unless using "coroutineScope" makes appending asynchronous somehow... Also won't adding the firstNames to the async block become a race condition? Is the memory reserved for the result ahead of time thanks to the type DeferredString?
@@PhilippLackner thanks, Phillip! You mean you would launch such a coroutine with GlobalScope? I thought it's a bad practice to use it, so I was looking for ways to avoid it. Even looking into using WorkManager... 🙂 For more context: my activity is used for reordering and/or adding items to a list, after user presses back/up button, I want to update the list in a Room database. I was using viewModelScope, but it wouldn't manage to save in time before the viewmodel gets destroyed. Btw, amazing content Phillip!
#5 so let's say that button is a "save and close" button for the current activity. What then? You pass the "finish()" method as callback to the viewmodel method?
Randomly being suggested your video, decide to watch it. Well the 4th mistake, you are partially wrong there with your explanation: if you throw a cancellation exception in your code, yes, you would eat that up. But in most cases the cancellation exception you would be catching would be from a suspendable function, your delay in this case. And what would happen there is that the coroutines would have been calcelled, regardless of you catching the exception or not. BUT if you cancel the exception and then try to execute some more suspendable call after that it would fail. So your solution is correct, you should be doing that (checking for cancellation / avoid catching cancellation exception. But your explanation is not entirely correct. :-) hope I was helpful
Hi, mistake 2 can also be handled with a withTimeout block right? it'll throw an exception if the operation within takes longer than specified time. Please correct if I'm wrong
Kudos to you for making this video...Learned very tricky points related to coroutines by watching this..Thank you mate.keep making these awesome videos
One thing worth mentioning for Mistake1 is the fact that coroutineScope will suspend until all the async calls finish. Therefore reading the result code like this could be confusing since you aren't really waiting for anything outside of the coroutineScope block.
Be careful while using async in web backend development, if the function is going to be triggered by client request, and you expect high QPS on this function, then you have to create your own thread pool for this async to use Never use default thread pool, because it’s small and might exhausted and cause other client requests await
Nice video! But Mistake #3 is not a mistake at all: The function "networkCall" *suspends* for 3 seconds. It does not *block* for 3 seconds. Since "networkCall" is not blocking, there is no need to fix it by using a "withContext". If you wrote/coded "Thread.sleep(3000L)" instead, then this example would have been a real mistake, since you could have *blocked* (not suspended) the main thread.
The issue is not that he thought it was blocking, but that the function was not main-safe, which is a mistake. Changing the context to Dispatchers.IO was the right thing to do. Of course, as he mentions, if you use Retrofit you don't need to worry about this since it does it for you.
@@etiennebeaulac8148 If the "networkCall()"'s body contained "Thread.sleep(3000L)" (or has some actual blocking call like waiting for a socket), then switching the context to Dispatchers.IO would have made perfect sense Written as it is, the code in Mistake -#3, is entirely main safe, since there is no blocking code, only suspending code. Replacing 'delay' with 'Thread.sleep' will make it blocking and not main-safe. It's a bit of nit-picking, but I think details are important sometimes 🙂
You're right that suspend functions should not be exposed to the UI and I'm with you 200%, but have you seen Google's paging library? that thing not only uses suspend functions to submit data to the adapters, but it also seems to run load queries on the UI by passing the paging source to the list's adapter, it's actually the only library that I promised that I will never use
@@PhilippLackner I will test it out but I don't think it does it on the view model, you post a paging source (which in effect is an object that contains suspending functions to load the data) to your paging adapter through the fragment or activity's lifecycle scope, so it's pretty much impossible to run something on viewmodelscope, though I guess you could create the adapter on viewmodel and let the observer attach it to the paged list, but adapters in the view model are a bitch to unit test without robolectric
![ได้เวลา! พาน้องแฝดฉีดวัคซีนครบ 1 เดือน🫣 [cc] แดนแพทตี้ SS2 | EP.52 |](http://i.ytimg.com/vi/IzeLtaXBLNE/mqdefault.jpg)
It's parellel dispatch and you can even use it for async mapper. You can make the code shorter if you want:
val firstNames = userIds.map { userId ->
async { getFirstName(userId) }
}.awaitAll()
Hi, do you mind answering some of my questions regarding this async? When using async and awaitAll() to get data, is there a chance that the order of name lists retrieved will be changing every time the operation is done? Because I thought since it's being done parallel, there's a time when some data in API are obtained faster than others, making the order of the list changing every time based on how the network performance is right? Or the list will be always the same?
@@pradiptapriya7546 It's same with
async { getFirstName(userIds[0]) } +
async { getFirstName(userIds[1]) } +
async { getFirstName(userIds[2]) }...
So, it should be the same order.
@@marksunghunpark I see! Thank you very much! With this, I can improve my code a bit!
Async mapper 엄청나네요!! 감사합니다!!👍👍👍👍
Dope 😍
Hi @Philipp Lackner for the great video! However I believe, that there is "mistake" in mistake #3.
Right now networkCall() is thread-safe since it's using delay(), which is non-blocking operation. Thus I will not block underlying thread/dispatcher.
Perhaps If you would like to demo blocking IO call - you can use Thread.sleep(2000) instead.
But for example if I have one thousand client IDs this works? Can I have one thousand async task at the same time running?
Hmmm, that's a lot of gotchas for a beginner.
I don't know how to express how helpful this video was.
blogs and tutorials often tell us what to do, but it's important to understand what not to do as well.
Looking forward to more videos like this
Glad it helped! 🙏
This changes everything!
Above dialogue is said by Bulma from Dragon ball Super when Goku arrive when frizza attacked earth.
Pay attention, that when you use .awaitAll() function in the list of deferred items and if any of these will throw exception, you'll get exception for the whole operation. So, you should use .awaitAll() only in case, when you except full success of all async calls. In other case to handle exceptions for specific items, you can use list.map { it.await() } and try/catch block.
Correct, thanks for mentioning :)
@@PhilippLackner you’re welcome)
OK🤙
Like this?
suspend fun getUserFirstNames(userIds: List): List {
// Alternative solution - executed in parallel, but allows for each item to cause exception
val firstNames4 =
coroutineScope {
userIds.map { userId ->
async {
try {
getFirstNameWithExceptions(userId + 1000)
} catch (e: Exception) {
println("Exception in getUserFirstNames: $e")
"Error for id=${userId+1000}: $e"
}
}.also {
}
}
}.also {
}.awaitAll()
return firstNames4
}
suspend fun getFirstNameWithExceptions(userId: Int): String {
delay(500)
println("getFirstName: $userId")
if (userId > 1005) { // simulate an error
throw Exception("userId > 505")
}
return "John $userId"
}
// note: I am using the `.also{}` blocks in order to let the IDE show the type at that point in execution
thank you for your correctly idea.
Sir why are you not becoming a Google Developer Expert? Because you provide an amazing and helpful content...
So true!
*JetBrains Developer Expert
Free google sales person = GDE
that doesnt give money!
great timing. i was just about to make the "mistake 1" one for retrieving images. Really appreciated
Your solution to mistake #2 still has a mistake: If cancellation happens while delay is suspended, job will never be cancelled.
True
This is so good and clear!
This also explains some minor issues I have to understand some of the functionality with coroutines.
I'm going to use this video as code snippets when coding my coroutines 😀
At 16:46, Shouldn't we use Dispatcher.IO
Mistake 4. If you make this suspending function return coroutineScope ( The suspend function you also used for mistake 2) or even withContext. Then the cancellation exception will be actually propagated to the outer scopes even if you explicitly catch in inside riskyTask e.g suspend fun riskyTask() = withContext() {}
Why it necessary to call async function inside coroutine scope? 🤔 We can call a suspend function in other suspend function right? Or we call coroutine scope so that the function inside coroutine scope works independently?
Usually your coroutines code runs sequentially. We use async so that we can immediately loop and call async again for the new iteration. This way you start all jobs initially and then wait for all of them to finish with "awaitAll".
@@skullkrum20 yes i undestood that, but i was asking why we need to call async inside coroutine scope.
@@ackerman6992 Its for that reason. If you don't you will run everything sequentially. Usually you don't need to if you're fine with that.
Good name btw, I'm in love by Shingeki no Kyogin. :D
@@skullkrum20 ohk got it, Thanks 😂
@@ackerman6992 coroutinescope, in this context , this is required because u r launching the coroutines with async, and to control them u need coroutinescope here !! And inside a suspend function we can't launch a coroutine !!
@PhilippLackner @17:36 you mention needing to cancel the long-living CoroutineScope, but did you mean any Jobs that were started with the long-living CoroutineScope, and not cancelling the CoroutineScope itself? I dont see any way to cancel the CoroutineScope, just jobs associated with the scope. Please advise.
And in example 1 there is an interesting moment: Since we use coroutineScope{}, we dont need to await all deffered elements, because, With the rules of "Structured Concurrency", the Deffered, which is being launched under the hood in coroutineScope{} will not be completed until all children get completed, so this call of coroutineScope will wait until all async{} will give us the result. After this, we can use non-suspend method getCompleted() to just collect values.
Very helpful explanations!
At 4:07, with what keystrokes did you move the whole for loop up together? Ah, looks like Shift+Cmd+Up on Mac. Very useful!
(Unfortunately, the video title is misleading clickbait. These are not mistakes that "nobody tells you about." Making your suspend functions main-safe, for example, is a principle thoroughly discussed in Android documentation about coroutines.)
On mistake #5, the point is valid that the lifecycleScope is too short-lived for the purpose of posting data to an API, and using the viewModelScope is an improvement. But the ViewModel too can be destroyed (for example if the user navigates to another activity) while data is being posted to the API, and that is not what the user wants either. Android docs recommend that "business-oriented operations," such as uploading users' data, should survive even process death. For that, WorkManager is recommended.
In mistake #1 since we have multiple coroutines spawned by async, and they all access the mutableListOf concurrently, shouldn’t we use thread safe data structure, for example COW list instead?
Hello, thanks for the amazing videos but one question always concerns me:
isn't sometimes the overhead of creating a lot of coroutines defies the purpose of performing tasks in parallel? or wouldn't it be a problem?
Great video. Rather than checking if an exception is a CancellationException in a try-catch block, you could use runCatching instead which does not catch CancellationExceptions
Mistake 3 is actually main safe but I get your point. Delay doesn't block the calling thread.
Google says Don't hardcode Dispatchers when creating new coroutines or calling withContext.
inject Dispatchers
This dependency injection pattern makes testing easier as you can replace those dispatchers in unit and instrumentation tests with a TestCoroutineDispatcher to make your tests more deterministic
I'm glad you're here to tell me about those mistakes, you are the best. I see the next video coming: "5 Fatal Kotlin Flows Mistakes Nobody Tells You About" :D
My Android Studio (Bumble bee); not implementing github dependencies! Who resolved this problem?
In mistake 3, shouldn't "networkCall" just return a string (or throw an exception)? I don't see the point of wrapping it in a Result in this case.
I skipped start of the video and wondering what are all of those methods and I don't know them cuz I was thinkin that it is Java Script language xD
my question is ? will its good or bad to use repository class in the last mistake ? i think so viewModel should not interact with your api , repository class should interact with your api and give data to viewModel and then viewModel give data to activity or fragment ui right ???
Do I need to call suspend functions of Retrofit and Room on a background thread?
Can i update UI like async(first) method?
as always with your videos, very interesting for self learners !
Everyone is providing video ideas so I would say it too:
Running android Junit and Android tests on Gitlab's CI on every commit.
If you're had any experience with this it would be a great video.
Maybe with docker maybe without it.
I'm refactoring all my Mistake 5 now 😃
In the first example, you could have mapped over the incoming IDs and avoided some code and mutability.
The content you are providing is not available on highly paid sites. You are doing great work. Keep it up buddy 🎉🎉
Wow thank you, didn't realize I made a lot of inefficient coroutine calls in my app! 😅 Does your paid course cover this extensively? Will need to check it out
My paid courses cover lots of topics and best practices in a bigger practical project 😄
@@PhilippLackner bought it, thanks!
I think mistake 2 is misleading, because that code should be safe as written. But I agree, with components that aren't coroutine safe, like long running calculations, you should do a check before continuing them whenever it makes sense.
Agreed, I think the example was not realistic
Even without async just with the launch, we can have parallel execution because both are non-suspending calls !! Async is specifically useful when you want to get something out from a coroutine !!
lol the mistake is failing to DDoS your server?
Hi! Make video about Maps Compose, Please!
Great tips! Thanks in advance! Brazil!
So bad That I could not guess any of the mistakes
rythmeur
Can you please handle paginate data with retrofit
So clients will make unbounded concurrent requests... you like getting DDOS?
What? 😂
For Mistake #1, doesn't creating a new coroutineScope inside a suspend function loose the parent scope? I mean, if some error is thrown inside that coroutineScope, the parent will not get cancelled...
The coroutineScope function creates a CoroutineScope that inherits the context of the parent and forwards cancellations/exceptions to the parent scope.
More info: kotlin.github.io/kotlinx.coroutines/kotlinx-coroutines-core/kotlinx.coroutines/coroutine-scope.html
Thanks for super awesome tutorial!!👍👍👍👍❤️
Thanks for super awesome tutorial!!👍👍👍👍❤️
Thanks for super awesome tutorial!!👍👍👍👍❤️
Great video, thank you!
Pure gold. Thanks a lot!
IMHO mistake 4 should be about using CancelationExceptions in the first place. Making flow-control with a callstack dependent concept is already the mistake. Quite disappointed to learn that kotlin uses Exception to control the active state of its routines. I hoped they learned from the broken InterruptedException from java I just wonder why and how this can be overlooked when designing a new language.
TL;DR mistake 4 the mistake is the CancelationException and not the people forget to handle this one Exception differently.
There's something weird with the first example...
isn't appending to the list synchronous in here?
Why didn't we include it in the async block?
I don't know the first thing about Kotlin, I use different tools, but to me this didn't fix anything, unless using "coroutineScope" makes appending asynchronous somehow...
Also won't adding the firstNames to the async block become a race condition?
Is the memory reserved for the result ahead of time thanks to the type DeferredString?
What should I do if I want a suspend function in viewmodel (Room function to update entity) to finish the work even after viewmodel gets destroyed?
Use an application scope instead of viewmodelscope
@@PhilippLackner thanks, Phillip! You mean you would launch such a coroutine with GlobalScope? I thought it's a bad practice to use it, so I was looking for ways to avoid it. Even looking into using WorkManager... 🙂
For more context: my activity is used for reordering and/or adding items to a list, after user presses back/up button, I want to update the list in a Room database. I was using viewModelScope, but it wouldn't manage to save in time before the viewmodel gets destroyed.
Btw, amazing content Phillip!
Really very helpful thanks for sharing @Philipp
Glad it was helpful!
#5 so let's say that button is a "save and close" button for the current activity. What then?
You pass the "finish()" method as callback to the viewmodel method?
Randomly being suggested your video, decide to watch it.
Well the 4th mistake, you are partially wrong there with your explanation: if you throw a cancellation exception in your code, yes, you would eat that up. But in most cases the cancellation exception you would be catching would be from a suspendable function, your delay in this case. And what would happen there is that the coroutines would have been calcelled, regardless of you catching the exception or not. BUT if you cancel the exception and then try to execute some more suspendable call after that it would fail. So your solution is correct, you should be doing that (checking for cancellation / avoid catching cancellation exception. But your explanation is not entirely correct.
:-) hope I was helpful
please make this a weekly video series.🙏
Hi, mistake 2 can also be handled with a withTimeout block right? it'll throw an exception if the operation within takes longer than specified time. Please correct if I'm wrong
Kudos to you for making this video...Learned very tricky points related to coroutines by watching this..Thank you mate.keep making these awesome videos
best corotuines video ever
I wish you'd make a video like this for Lua. Lua coroutines continuously befuddled me.
Thanks for video! So usefull. What is that IDE? Visual Code or something else?
One thing worth mentioning for Mistake1 is the fact that coroutineScope will suspend until all the async calls finish. Therefore reading the result code like this could be confusing since you aren't really waiting for anything outside of the coroutineScope block.
Am I the only one who's missing that mechanical keyboard sound??? xD
I think using launch would be better as async would bring all parent the scope down if once job fails to retrieve the name (unless it's supervised).
Love all your videos. Please do more Android studio projects. Thank you so much!!!!!!!
Be careful while using async in web backend development, if the function is going to be triggered by client request, and you expect high QPS on this function, then you have to create your own thread pool for this async to use
Never use default thread pool, because it’s small and might exhausted and cause other client requests await
Is what you are saying applicable to Java as well ?
not in this video
How to create and manage cancelation of our own scope, for example in case we want to have a scope binded to our whole application?
Can you please, make several hours of such kind examples) so amazing stuff
Thanks for this awesome video. I learned A LOT. I use coroutines a lot so I will need to review those.
Love your videos, love your work. Always great content! Thank you very much :)
"Fatal" tho, lmao
Very helpful. Using coroutines means coding in a new way.
nice video to watch before sleep ) easy listening, very clear and positive 👍
Great videos! They are very informative and have help me a lot in my shift to kotlin. Keep up to good work!
Thank you for sharing! super helpful! love it!
Really useful content/ Thank you very much!!!
(I'm not Kotlin fluent, actually, I know nothing about) when I first read "suspend fun", I got sad.
its not as scary as it looks but also sometimes it is
i'm addicted to your videos man, i can't sleep.
amazing video and good explaination
Thanks Philipp
Extremely helpful please make more such videos
This video is very helpful , please make more videos like this
Sehr tolles Video. You should make more like this :D
Wow you look so much healthier now, great work!
is not retrofit call main safe?
It is
what an explanation Philip . You earned a like .
nice issues were mentioned here , especially the defered one
Waiting for the day you'll call it co-routine
Your best video as far as I'm concerned 👍
I see a Philipp Lackner video, I click.
Nice video!
But Mistake #3 is not a mistake at all:
The function "networkCall" *suspends* for 3 seconds. It does not *block* for 3 seconds. Since "networkCall" is not blocking, there is no need to fix it by using a "withContext".
If you wrote/coded "Thread.sleep(3000L)" instead, then this example would have been a real mistake, since you could have *blocked* (not suspended) the main thread.
The issue is not that he thought it was blocking, but that the function was not main-safe, which is a mistake. Changing the context to Dispatchers.IO was the right thing to do. Of course, as he mentions, if you use Retrofit you don't need to worry about this since it does it for you.
@@etiennebeaulac8148 If the "networkCall()"'s body contained "Thread.sleep(3000L)" (or has some actual blocking call like waiting for a socket), then switching the context to Dispatchers.IO would have made perfect sense
Written as it is, the code in Mistake -#3, is entirely main safe, since there is no blocking code, only suspending code.
Replacing 'delay' with 'Thread.sleep' will make it blocking and not main-safe.
It's a bit of nit-picking, but I think details are important sometimes 🙂
Really nice model of videos. Keep up, man.
Excellent content as always! Please make a series about those mistakes. Appreciate your hard work. 🙌
Thank you so much, your videos are awesome
Damn this was a very good video! it seems I'v been making alot of mistakes :/
Time to stop making them😁
Very informative vedio👍👍😉😉😉
Can you tell me please: What is your Color theme?
This is such a beautiful theme
shld be Xcode-dark
You're right that suspend functions should not be exposed to the UI and I'm with you 200%, but have you seen Google's paging library? that thing not only uses suspend functions to submit data to the adapters, but it also seems to run load queries on the UI by passing the paging source to the list's adapter, it's actually the only library that I promised that I will never use
I don't like the paging library either, but the load queries are done in the viewmodel afaik
@@PhilippLackner I will test it out but I don't think it does it on the view model, you post a paging source (which in effect is an object that contains suspending functions to load the data) to your paging adapter through the fragment or activity's lifecycle scope, so it's pretty much impossible to run something on viewmodelscope, though I guess you could create the adapter on viewmodel and let the observer attach it to the paged list, but adapters in the view model are a bitch to unit test without robolectric
❤️❤️