|
Hi, Wonder if anyone has any insights. I've a sync process in my app, consisting of a half doezen steps, all of which need to call our to a network API and do some work. They're running on background tasks, to not lock up the UI (some can take a while to finish). I'd like to report the progress back to the UI -- things like; how many files actually uploaded, how many failed etc.. I'm really struggling to see an easy way to do this without having data-race warning.
Can anyone suggest an approach here? Back in my C# days, I used |
|
Hello, It wasn't an easy question... interesting! 🤔 I'm trying to learn more about the latest advances in SwiftUI and Swift concurrency. I have tried several solutions and understand that it is really clever... not easy. Does a simple example work in your case? Or do you have a more sophisticated sync solution? I'm attaching my simple solution, so the forum has an alternative to discuss:
If your synchronization process is straightforward and doesn’t involve complex state updates, error handling, or the need for cancellation. (Options: Actors, Combine, or AsyncStream to handle more complex synchronization scenarios and avoid concurrency issues.) I'm sharing what I've been working on today, and am curious to follow your question. /Martin |
|
Hello, Now I have read more about nonisolated and it is easy to use. I have made an example with class and @MainActor, as well as the nonisolated on the network function. Now we have a solution that runs the network call on a background thread and the rest on the main thread. (Without the extra code and functionality that actor implies). Tip: Set a breakpoint in Xcode on simulateNetworkCall and one in ContentView to see how it switches between threads.
|
|
Hello, I have read Paul's book on "Swift Concurrency by Example" and gained quite a new insight. (It will be interesting to read the new version that will be released shortly.) I have edited my previous post about actors as it did not follow Paul's advice: Do not use actors for your SwiftUI data models. You should use a class that conforms to the ObservableObject protocol instead. If needed, you can optionally also mark that class with @MainActor to ensure it does any UI work safely, but keep in mind that using @StateObject or @ObservedObject automatically makes a view's code run on the main actor. If you desperately need to be able to carve off some async work safely, you can create a sibling actor – a separate actor that does not use @MainActor, but does not directly update the UI. Read more: Important: Do not use an actor for your SwiftUI data models Sharing my new actor example:
|
|
Hi, Have you progressed in your question How to: "Observing progress of asynchronous work"? I didn't give many explanations to my previous posts, sorry! Paul writes in What's new in Swift 6.0: "Swift concurrency remains a bit of a moving target, but if you'd like to know more I highly recommend Matt Massicotte's blog – I don't think anyone is doing more to educate Swift developers about effective adoption of Swift concurrency." Can Matt's article "Concurrency Step-by-Step: A Network Request" help you further in your question? |
SPONSORED Ready to dive into the world of Swift? try! Swift Tokyo is the premier iOS developer conference will be happened in April 9th-11th, where you can learn from industry experts, connect with fellow developers, and explore the latest in Swift and iOS development. Don’t miss out on this opportunity to level up your skills and be part of the Swift community!
Sponsor Hacking with Swift and reach the world's largest Swift community!
You need to create an account or log in to reply.
All interactions here are governed by our code of conduct.
Link copied to your pasteboard.