@StateObject: یہ کیا ہے، @ObservedObject سے فرق اور مثالیں

SwiftUI میں @StateObject کیا ہے؟

@StateObject ایک Property Wrapper ہے جو SwiftUI 2.0 (iOS 14) میں متعارف کیا گیا، جو @ObservedObject اور @State کی صلاحیتوں کو اکٹھا کرتا ہے۔ @ObservedObject کی طرح، یہ ObservableObject میں تبدیلیوں کی سبسکرائیب کرتا ہے۔ @State کی طرح، یہ ضمانت دیتا ہے کہ ڈیٹا view کے ضابطہ کے بار بار ابتدائیہ سے بچ جاتا ہے۔ @StateObject آبجیکٹ ایک بار تب بناتا ہے جب view پہلی بار سکرین پر آتا ہے اور اسے SwiftUI کے ہیپ میں ذخیرہ کرتا ہے۔

@StateObject سے پہلے، ڈیولپرز تمام ObservableObjects کے لیے @ObservedObject استعمال کرتے تھے، جن میں view میں بنائے گئے آبجیکٹ بھی شامل ہیں۔ اس سے اکثر ڈیٹا کا نقصان ہوتا تھا جب پیرنٹ view اپڈیٹ ہوتا تھا، جس سے view کا ضابطہ دوبارہ بنتا تھا اور @ObservedObject کی مثال اپنے ساتھ لے جاتا تھا۔ @StateObject نے استحکام کی ضمانت شامل کرکے اس مسئلے کو حل کیا۔

بنیادی قاعدہ: @StateObject اس view میں استعمال ہوتا ہے جو پہلے سے طے کے ابتدائیہ (let model = ViewModel()) میں آبجیکٹ بناتا ہے۔ چائلڈ view جو یہ آبجیکٹ وصول کرتے ہیں @ObservedObject استعمال کرتے ہیں۔ یہ علاحدگی پورے درجہ بندی میں سچ کا ایک ذریعہ یقینی بناتی ہے۔

@StateObject کا لائف سائکل

SwiftUI @State کے مشابہ اسٹوریج مینجر کے ذریعہ @StateObject کے لائف سائکل کا انتظام کرتا ہے۔ جب view پہلی بار ظاہر ہوتا ہے، SwiftUI آبجیکٹ کے لیے میمری مختص کرتا ہے اور اسے ایک مستقل علاقے میں ذخیرہ کرتا ہے۔ بعد کے رینڈر (body کول) پر، آبجیکٹ دوبارہ نہیں بنتا—موجودہ مثال استعمال ہوتی ہے۔ آبجیکٹ تب تک زندہ رہتا ہے جب تک view درجہ بندی میں ہے۔

جب view کو درجہ بندی سے ہٹایا جاتا ہے، SwiftUI @StateObject کو ختم کر دیتا ہے، deinit کو کول کرتا ہے۔ جب view واپس درجہ بندی میں شامل کیا جاتا ہے، ایک نئی مثال بنائی جاتی ہے۔ ڈزائن کرتے وقت اس پر غور کرنا اہم ہے: اگر آپ کو view ہٹانے کے درمیان ڈیٹا محفوظ رکھنے کی ضرورت ہے، تو استقلال کے لیے ایک سروس پرت (singleton یا DI) یا @AppStorage استعمال کریں۔

class TimerViewModel: ObservableObject {
    @Published var seconds: Int = 0
    private var timer: Timer?

    func start() {
        timer = Timer.scheduledTimer(withTimeInterval: 1, repeats: true) { _ in
            self.seconds += 1
        }
    }

    deinit {
        timer?.invalidate()
    }
}

struct TimerView: View {
    @StateObject var viewModel = TimerViewModel()

    var body: some View {
        Text("\(viewModel.seconds)s")
            .onAppear { viewModel.start() }
    }
}

مثال میں، TimerViewModel @StateObject کے ذریعہ بنایا گا ہے اور تب تک زندہ رہتا ہے جب تک TimerView سکرین پر ہے۔ ٹائیمر onAppear میں شروع ہوتا ہے اور deinit میں رکتا ہے۔ اگر @ObservedObject استعمال کیا جاتا، تو TimerView کے ہر رینڈر پر seconds = 0 کے ساتھ ایک نئا TimerViewModel بنتا، اور ٹائیمر کبھی صحیح طریقے سے کام نہیں کرتا۔ @StateObject ضمانت دیتا ہے کہ viewModel منفرد اور مستحکم ہے۔

@StateObject بنام @ObservedObject: موازنہ

@StateObject اور @ObservedObject کے درمیان انتخاب اس بات پر منحصر ہے کہ آبجیکٹ کا مالک کون ہے۔ اگر view آبجیکٹ بناتا ہے—@StateObject۔ اگر view تیار آبجیکٹ وصول کرتا ہے—@ObservedObject۔ یہ قاعدہ اتنا اہم ہے کہ Xcode ایک انتباہ کرتا ہے جب @StateObject ایک چائلڈ view میں استعمال کیا جاتا ہے جو ایک ابتدائیہ کے ذریعہ آبجیکٹ وصول کرتا ہے۔

عمل میں، پروجیکٹ کے شروع میں، @StateObject اکثر جڒ view میں اور @ObservedObject تمام چائلڈ view میں استعمال ہوتا ہے۔ جیسے جیسے ایپلیکیشن بڑھتا ہے، درجہ بندی کو سادہ کرنے کے لیے کچھ @StateObject انسٹنسز کو @EnvironmentObject سے بدلا جا سکتا ہے۔ تاہم، @StateObject اپنے منطق کے ساتھ ماڈیولر سکرین کے لیے بہترین چوناو رہتا ہے۔

@StateObject کے استعمال کے پٹرن

پہلا پٹرن—@StateObject کے ساتھ MVVM۔ ObservableObject کے طور پر ViewModel @StateObject کے ذریعہ view میں بنایا جاتا ہے۔ ViewModel میں @Published خوصیات اور کاروباری منطق ہوتا ہے۔ View تبدیلیوں کی سبسکرائیب کرتا ہے اور انٹرفیس کو اپڈیٹ کرتا ہے۔ یہ نظریہ تجربہ قابل علاحدگی فراھم کرتا ہے: ViewModel کو سیڈھے ایک مثال بنا کر UI کے بغیر ٹیسٹ کیا جا سکتا ہے۔

دوسرا پٹرن—انحصارات کے ساتھ @StateObject۔ اگر ViewModel کو خدمات کی ضرورت ہے، تو پیرامیٹر کے ساتھ ابتدائیہ استعمال کریں۔ مثال کے طور پر، @StateObject var viewModel = UserViewModel(api: APIClient.shared)۔ تاہم پرِ احتیاط کریں: پیرامیٹر ہر body رینڈر پر حساب کیے جاتے ہیں، لیکن آبجیکٹ صرف ایک بار بنتا ہے۔ SwiftUI @StateObject کے بعد کے ابتدائیوں کو نظرانداز کرتا ہے۔

تیسرا پٹرن—نیژٹڈ @StateObject۔ SwiftUI میں، آپ ایک view میں متعدد @StateObject رکھ سکتے ہیں، لیکن یہ شاید ھی جائز ہے۔ عام طور پر ایک @StateObject view کے پورے ڈیٹا سیٹ کو سنبھالتا ہے۔ اگر منطق بہت زیادہ پیچیدہ ہو جائے، تو اسے ایک @StateObject کے اندر @ObservedObject خدمات کی ترکیب میں تقسیم کریں۔

struct AppView: View {
    @StateObject var router = NavigationRouter()
    @StateObject var auth = AuthViewModel()

    var body: some View {
        ContentView()
            .environmentObject(router)
            .environmentObject(auth)
    }
}

مثال میں، AppView دو @StateObject بناتا ہے: نیویگیشن کے انتظام کے لیے NavigationRouter اور مصداقہ کے لیے AuthViewModel۔ دونوں آبجیکٹ environmentObject کے ذریعہ Environment میں انجکٹ کیے جاتے ہیں۔ کوئی بھی چائلڈ view ابتدائیہ زنجیر سے گزرے بغیر @EnvironmentObject کے ذریعہ ان تک رسائی حاصل کر سکتا ہے۔

@StateObject اور پیرامیٹر کے ساتھ ابتدائیہ

@StateObject کسی بھی پیرامیٹر کے ساتھ ابتدائیہ کی حمایت کرتا ہے، لیکن ایک اہم شرط کے ساتھ: ابتدائیہ صرف ایک بار کول ہوتا ہے۔ بعد کے body رینڈر پر، پیرامیٹر میں نئی قیمتیں نظرانداز کر دی جاتی ہیں۔ اس کا مطلب ہے کہ اگر آپ @State var id: Int = 5 کو @StateObject var vm = ViewModel(id: id) میں پہنچاتے ہیں، تو جب id بدلتا ہے، ViewModel نئی قیمت وصول نہیں کرے گا۔

اس مسئلے کو حل کرنے کے لیے، مطابقت کے لیے onReceive یا onAppear استعمال کریں۔ Combine کے ذریعہ ViewModel کے اندر پیرامیٹر تبدیلیوں کی سبسکرائیب کریں یا view کی سطح پر .onChange(of:) طریقے سے پیرامیٹر پہنچائیں۔ ایک متبادل یہ ہے کہ اگر آبجیکٹ کو بیرونی تبدیلیوں پر متحرک طور پر رد عمل کرنا چاہیے تو @StateObject کے بجائے @ObservedObject استعمال کریں۔

struct DetailView: View {
    let itemId: Int
    @StateObject var viewModel = DetailViewModel()

    var body: some View {
        Text(viewModel.title)
            .onAppear { viewModel.load(id: itemId) }
    }
}

صحیح نظریہ: DetailView itemId کو let خاصیت کے طور پر وصول کرتا ہے (ساخت کے ابتدائیہ کے ذریعہ پہنچایا گیا)، اور @StateObject بغیر پیرامیٹر کے DetailViewModel بناتا ہے۔ onAppear میں، پہنچائے گئے ID کے لیے ڈیٹا لوڈ کرنے کے لیے load(id:) طریقہ کول کیا جاتا ہے۔ یہ یقینی بناتا ہے کہ ViewModel @StateObject میکنزم سے بنایا گیا ہے، لیکن ڈیٹا موجودہ ID کے ساتھ ہر view ظاہر ہونے پر لوڈ ہوتا ہے۔

@StateObject کے ساتھ عام غلطیاں

بڒ غلطی—ایسے چائلڈ view میں @StateObject استعمال کرنا جو والد سے آبجیکٹ وصول کرتے ہیں۔ اگر ParentView @StateObject model بناتا ہے اور ChildView @StateObject var model: ModelType (ڈفلٹ پیرامیٹر کے ساتھ) کا اعلان کرتا ہے، تو ChildView اپنی آزاد مثال بنائے گا۔ والد اور بچے کے آبجیکٹ آپس میں منصل نہیں ہوں گے، اور ایک میں تبدیلیاں دوسرے میں منعکس نہیں ہوں گیں۔

دوسری غلطی—List یا ForEach میں @StateObject رکھنا۔ فہرست کا ہر عنصر اپنا @StateObject بناتا ہے، جس سے متعدد آزاد مثالیں بنتی ہیں۔ فہرستوں کے لیے، صحیح نظریہ یہ ہے کہ @ObservedObject کے ذریعہ تمام عناصر کو ایک ObservableObject پہنچائیں یا List کے اندر @State کے ساتھ Identifiable ساختیں استعمال کریں۔

تیسرا مسئلہ—deinit صفائی کی کمی۔ @StateObject view کے پورے لائف سائکل کے لیے زندہ رہتا ہے۔ اگر آبجیکٹ ٹائیمرز، Combine سبسکرائیپشنز یا نیٹورک درخواستیں بناتا ہے، تو deinit کو انہیں منسوخ کرنا چاہیے۔ بالکر میمری لیک اور سکرین بند ہونے کے بعد بھی پس منظر کا کام جاری رہنا ناگزیر ہے۔ ہمیشہ Combine Cancellable اسٹور استعمال کریں یا deinit میں ٹائیمرز کو ناکارہ کریں۔