ခဏလေး ဒီလိုပဲ စဉ်းစားကြည့်
`Task { }` က asynchronous work ကို start ဖို့ 'container' ပါ — SwiftUI View ထဲမှာ `.task { }` modifier ကို (View ပေါ်လာချိန် automatic run, `.onAppear` + `Task` ပေါင်းစပ်ထားတဲ့ shortcut) သုံးလေ့ရှိပါတယ်။ `@MainActor` ကို class/function ပေါ် annotate ထားရင် 'ဒီ code ကို UI thread ပေါ်မှာသာ run ပါ' လို့ compiler ကို ပြောတာပါ — `@Published` property update (ViewModel lesson) ကို main thread ပေါ်မှာသာ လုပ်ရမှာမို့, ViewModel class ပေါ် `@MainActor` ထားလေ့ရှိပါတယ်.
လက်တွေ့ scenario နဲ့ ချိတ်ကြည့်မယ်
`WeatherScreen` ထဲမှာ `.onAppear { Task { ... } }` ရေးမယ့်အစား `.task { weather = try? await fetchWeather(city: "Yangon") }` လို့ ရေးရင် ပိုရှင်းပါတယ် — `.task` modifier က View ကွယ်သွားရင် automatic cancel ပါ ပေးပါတယ် (`.onAppear` + manual `Task` ကတော့ manual cancel ရေးရပါမယ်).
အတူတူ ကြည့်မယ်
@MainActor
class WeatherViewModel: ObservableObject {
@Published var weather: WeatherResponse?
func loadWeather(city: String) async {
weather = try? await fetchWeather(city: city)
}
}
struct WeatherScreen: View {
@StateObject private var viewModel = WeatherViewModel()
var body: some View {
Text(viewModel.weather?.city ?? "Loading...")
.task {
await viewModel.loadWeather(city: "Yangon")
}
}
}Screen ဆီ ရောက်လာတာနဲ့ 'Loading...' → weather city name ဆိုပြီး automatic update ဖြစ်တာ တွေ့ရမည်။၅ မိနစ် စမ်းကြည့်
`WeatherViewModel`/`WeatherScreen` ကို `.task { }` modifier သုံးပြီး ကိုယ်တိုင် ရေးကြည့်ပါ — screen ကနေ ချက်ချင်း navigate ထွက်ကြည့်ပြီး (`.task` ရဲ့ auto-cancel behavior ကို) observe ကြည့်ပါ။
သတိလေးတစ်ချက်
`Task { }` ထဲက error ကို catch မလုပ်ဘဲ `try?` ကို overuse ရင် (silent failure) — error ဖြစ်နေတာကို user/developer ဘယ်သူမှ မသိတော့ဘဲ debug ရခက်ခဲသွားနိုင်ပါတယ်။