Swift 5.5: Async Await Operations (Xcode 13, iOS 15, 2022) - iOS for Beginners
HTML-код
- Опубликовано: 4 сен 2024
- In this video we will learn to use the new async await attributed to perform async operations in Swift. Newly available as of 2021 and Swift 5.5, this new style greatly improves upon closures, callbacks, and other concurrent patterns in Swift & iOS. We'll be working in Xcode 13 and Swift 5.5
💻 Source Code: / iosacademy
🎥 Subscribe for more: www.youtube.co...
😎 Like my teaching style? Check out some of my most popular courses! courses.iosaca...
#swift #asyncawait #wwdc2021
** Like my teaching style? Check out some of my most popular courses!
courses.iosaca...
Join this channel to get access to perks, code, groups, and more:
Building Instagram: courses.iosaca...
Building TikTok: / @iosacademy
SwiftUI for Beginners: ios-academy.te...
Join the iOS Academy Community: iosacademy.io/
** Get Skillshare free for 2 Months and learn iOS
www.skillshare...
** Manage all your investments from app earnings on Betterment!
bit.ly/3eBwlI9
** Grow your own RUclips tech channel with TubeBuddy:
www.tubebuddy....
Nice. I think a whole series of tutorials on this is needed, with simple to complex use cases. I would buy the course if you made one :)
Coming soon!
@@iOSAcademy And include all the nested network calls . like populating a table view with users, their photos, etc all separate calls, proper error handling , etc. all the pain-in-the-ass stuff. Just my $.02. regards and keep up the great work
@@iOSAcademy any ETA on this?
Man that so fast, it doesn't take a week and you already make tutorial for new features. Keep going bro!
Thanks, will do!
These videos are absolutely outstanding summaries thank you 🙏
Thanks
Great video. I'm a senior iOS engineer but trying to catch up on some APIs I've been lazy to learn.
Nice!
same
Some imminent deprecation on the "async { ... }" call. Need to change it (going forward) to "Task { ... } "
Yep
can be use Task instead of async for concurrent or parallel proccesing?
`async throws -> T` is a better option than `async -> Result` but by now I know you will say “It’s Subjective” 😝 which of course it is.
I actually love generics but a bit advanced for the general audience
@@iOSAcademy oh, sorry, I actually meant `async throws -> [User]`
but i really like ur content. hope u hit ur 50k target soon :)
If a network error has occurredit is better to inform to view layer, don't you think?
It may be necessary to handler the type of error or inform the user.
I think...
throws or result - either is good depending on the use case.
Great! simply great, thanks!!
You’re welcome
Easy to understand 👏🏻
Thanks
yeah ima call you professor iOS now
haha thanks!
The syntax is much better, it makes sense. completion handlers didn't make sense as they are part of the function parameters but when you call them, the closure is outside the params ().
Well, no they don't have to be at all. You can certainly put a closure inside the function parenthesis. What you are talking about is a trailing closure syntax, which is only if you have a closure that is the last argument of the function. You don't have to use trailing closure syntax if you don't want to.
You saved my life.
good job! thanks mate!
Youre welcome
Simple and clear, thanks mate!
Youre welcome
Really good video, thanks for sharing that. It was concise and easy to understand.
Thanks
async {} is now Task.init(operation: {})
Or just "Task { }" - which is the same thing. You don't have to use init and the only argument can be done with a trailing closure.
Beautiful video. Bravo!
Thanks
Nice, looking forward to some practice about it
Nice
They are making it easy.
Yep!
Thank you for the great explanation
if use Task what would happen?
I wish these tutorials were done in SwiftUI, much cleaner, and much faster. Instead of spending like 8 minutes setting up the project due to UIkit nonsense, just add List (user) and be done.
But what if we are using alamofire which returns a Result type data, from which it’s not possible to return data as we can’t return anything inside cases of result, how to handle that any help would be appreciated.
Async await it's pretty cool and very simple ❤️. Thank you for u tutorial sir. Please, if is possible, make a tutorial about repository sir. 😁
Sure I will
Is concurrency is async?
Yes
how did you do that without adding import _Concurrency? I get error about couldn't found async. Also imported concurrency but couldn't found that module.
It should work in xcode 13
can you or someone please tell me what is the different of the tableview variable you wrote that looks the same as lazy variable definition, but without the lazy keyword.
is it behave like lazy? is this variable create only once and only when someone access to it?
at 03:55
from javascript
Literally lol
Yep!
I know right ? What took so long ??? Apple is a $2T company.
Thanks for the content, btw which theme in Xcode do you use?
Midnight
Do you have a video on how to use a REST API with Swift?
Yes, just search for API on the channel
@@iOSAcademy Great!
so is @escaping completion handlers obsolete now?
No. Both are still valid
@@iOSAcademy but its possible to replace the completion Blocks with it, right?
We all know async calls do not block execution until the async operation is completed.
With await being introduced are we still doing that or are we waiting on the async operation being completed?
Waiting
@@iOSAcademy Got it. So anything that we do NOT want to wait for async call should be outside the "Task" block?
Bad quality of the video. Please fix this. You hurt our eyes. Besides that, thanks for the content. It's very helpful.
You wasted almost half the video setting up the project before showing the concept. Next time, have the project already prepared.
I think the weak self attempt was correct.
async { [weak self] in
guard let _self = self else {
return
}
let users = await fetchUsers()
_self.users = users
DispatchQueue.main.async {
_self.tableView.reloadData()
}
}
🙃
As of Swift 5, you can use "let self = self "
setting users property in 8:54 should also happen on main thread. Does "async" in line 31 dispatch closure on current thread? that would make DispatchQueue.main.asynch from line 35 unneccesary.
AFAIK you can perfectly do that on non-main threads. Only updating the UI (like reloading the table view) needs to be on the main thread.
@@MrLinusunil You can if you use some kind of synchronization.
Otherwise you have potential data race or inconsistent state because two threads are accessing the same property, one changing it.
For example: property is read on main thread in table view data source method numberOfRows,
then propeerty is changed on non-main thread before cellForRowAt call, then you have crash "index out of range".