How to determine where code runs in Swift Concurrency

Рет қаралды 2,325

Күн бұрын

Learn everything you need to know about how you can determine where your code will run when you're using Swift Concurrency. We'll look at tasks, functions, and all the rules that go into determining actor isolation.
This video accompanies this blog post: www.donnywals.com/how-to-dete...
If you want to learn more about Swift Concurrency, I highly recommend that you take a look at my book practicalswiftconcurrency.com
If you're interested in deepening your iOS skills, take a look at my books here: donnywals.com/books.

Пікірлер: 21

@user-jj2jf7hf5q Ай бұрын

Kudos to the author. First time I hear simple and elaborated explanation about threads which will be used to run task or specific method.

@DonnyWalsdev Ай бұрын

Thank you!

@chovuse 4 ай бұрын

Your style of tutorial makes it more easier to understand Swift coding. Thanks a Lot !

@DonnyWalsdev 4 ай бұрын

Thanks! Happy to hear that

@FloWritesCode 5 ай бұрын

This is an interesting topic, thanks a ton for sharing!

@pmatar 5 ай бұрын

Great video, thanks for sharing! And what about the assigning of the result of async func to UI-related piece? How exactly it works and should we care about main thread the same way as with gcd?

@DonnyWalsdev 5 ай бұрын

Yes you should make sure you assign on the main actor. The easiest way is to make sure that the property you’re assigning too is main actor annotated. That way you’ll never forget because all access to the property will be isolated to the main actor. Alternatively you can use MainActor.run to run a piece of code on the main actor

@pmatar 5 ай бұрын

@@DonnyWalsdev oh I see what you mean. Thank you for your response!

@bobdel 3 ай бұрын

This video is very helpful. I am still confused by the body property. As I understand it, Body is annotated via a protocol to run on MainActor. Is this correct: a view such as the one in your example that does not have a @MainActor annotation, but the function is called from a task modifier inside the Body will run on the MainActor.

@DonnyWalsdev 3 ай бұрын

It's the opposite, unless the function definition itself has a @Mainactor annotation (or in other words, is isolated to the main actor) it doesn't matter where you call it from. The function itself decides where it runs and if it's not isolated to the main actor explicitly it will run in the background even if it was called from a main actor isolated spot

@alperenunal3975 5 ай бұрын

Btw what’s your xcode theme ? Looks very cool :)

@DonnyWalsdev 4 ай бұрын

It's "Material theme Ocean high contrast" in VS code

@alperenunal3975 5 ай бұрын

If we are using @observable macro on our viewmodel, should we use @mainactor at the same time ?

@DonnyWalsdev 5 ай бұрын

I would advice that you do on the view, SwiftUI views aren’t main actor isolated by default

@alperenunal3975 5 ай бұрын

@@DonnyWalsdev so we should mark View as a main actor ?

@DonnyWalsdev 4 ай бұрын

@@alperenunal3975IMO, yes that would be a good idea. It's honestly a little surprising to me that Apple doesn't enforce this

@alperenunal3975 4 ай бұрын

@@DonnyWalsdev oh, I got it. Thanks for explanation :)

@pmatar 5 ай бұрын

private var imageUrl: String? { didSet { dowloadImage() } } func setImage(_ imageUrl: String?, placeholder: UIImage?) { self.image = placeholder self.imageUrl = imageUrl } private func dowloadImage() { guard let imageUrl else { return } Task { @MainActor in do { let loadedImage = try await ImageLoader.shared.downloadImage(from: imageUrl) if imageUrl == self.imageUrl { image = loadedImage } } catch { debugPrint(error) } } } That’s the example of what I mean

@DonnyWalsdev 5 ай бұрын

This would work perfectly fine. Your task is run on the main thread which means the assignment you do at the end is on the main actor

@pmatar 5 ай бұрын

@@DonnyWalsdev but won’t the download will also happen on the main thread, instead of global/background?

@DonnyWalsdev 5 ай бұрын

@@pmatar no, because the download function itself most likely is defined non isolated. If not, you can be certain that URLSession’s networking is non isolated. So that code run on the global executor. While you await, the main thread is free to work on other stuff because an await doesn’t block; it frees the actor up for other work