@StateObject: یہ کیا ہے، ObservableObject کی تخلیق اور انتظام

SwiftUI میں @StateObject کیا ہے

@StateObject ایک property wrapper ہے جو iOS 14 میں متعارف کرایا گیا، جو View کو ObservableObject پروٹوکول کی تعمیل کرنے والی کلاس کی مثال بنانے اور اس کی ملکیت رکھنے کی اجازت دیتا ہے۔ @State کے برعکس، جو قدر کی اقسام (structs) کے ساتھ کام کرتا ہے، @StateObject حوالہ جاتی اقسام — وہ کلاسیں جو SwiftUI کو اپنی خصوصیات میں تبدیلیوں کے بارے میں مطلع کر سکتی ہیں — کے لیے ڈیزائن کیا گیا ہے۔

جب کوئی View @StateObject var viewModel: MyViewModel استعمال کرتی ہے، SwiftUI خود بخود View کے پہلی بار ظاہر ہونے پر MyViewModel کی ایک مثال بناتا ہے اور اسے فریم ورک کے ایک خاص ذخیرہ میں محفوظ کرتا ہے۔ ہر View اپ ڈیٹ پر (مثال کے طور پر، جب والدین کی حالت بدلتی ہے)، SwiftUI آبجیکٹ کو دوبارہ نہیں بناتا — وہ موجودہ مثال اس وقت تک استعمال کرتا ہے جب تک View درجہ بندی سے ہٹا نہیں دی جاتی۔

Apple WWDC Session 10137 (2024) کے مطابق، @StateObject iOS 13 میں موجود ڈیٹا کے نقصان کے مسئلے کو حل کرتا ہے جب Views دوبارہ تعمیر ہوتی تھیں، جس سے ڈویلپرز کو والدین View میں ObservableObject بنانے اور اسے ابتدائیہ دینے والے کے ذریعے منتقل کرنے پر مجبور ہونا پڑتا تھا۔ اس سے کوڈ کی نقل اور غلطی سے آبجیکٹ کے دوبارہ بننے کا خطرہ تھا۔

import SwiftUI

class CounterViewModel: ObservableObject {
    @Published var count: Int = 0
    
    func increment() {
        count += 1
    }
}

struct CounterView: View {
    @StateObject var viewModel = CounterViewModel()
    
    var body: some View {
        VStack {
            Text("Count: \(viewModel.count)")
            Button("Increment", action: viewModel.increment)
        }
    }
}

@StateObject کیسے کام کرتا ہے

@StateObject کا طریقہ کار SwiftUI کے Combine فریم ورک کے ساتھ انضمام پر مبنی ہے۔ جب ObservableObject اپنی خصوصیات کو @Published وصف سے نشان زد کرتا ہے، SwiftUI خود بخود ObservableObject پروٹوکول میں موجود پبلشر کے ذریعے تبدیلیوں کو سبسکرائب کرتا ہے۔ جب کوئی شائع شدہ خصوصیت بدلتی ہے، آبجیکٹ objectWillChange پبلشر کے ذریعے سگنل بھیجتا ہے، جو اس آبجیکٹ کو دیکھنے والی تمام Views کی دوبارہ ڈرائنگ کو متحرک کرتا ہے۔

SwiftUI ObservableObject مثال کو ایک خاص View مثال سے منسلک ایک خاص ذخیرہ میں محفوظ کرتا ہے۔ یہ ذخیرہ پہلی رینڈرنگ کے دوران ایک بار بنتا ہے اور View کے تباہ ہونے تک موجود رہتا ہے۔ یہی وجہ ہے کہ @StateObject حوالہ کے استحکام کی ضمانت دیتا ہے — SwiftUI میموری کو خود بخود منظم کرتا ہے، View کے ابتدائیہ دینے والے پر انحصار کیے بغیر۔

objc.io — Thinking in SwiftUI (2025) کے مطابق، @StateObject کا اندرونی نفاذ @State جیسا طریقہ کار استعمال کرتا ہے لیکن حوالہ جاتی اقسام کے لیے: SwiftUI آبجیکٹ کے گرد ایک باکسنگ ریپر بناتا ہے اور اپنے مختص کنندہ کے ذریعے اس کی زندگی کا چکر منظم کرتا ہے، جو بار بار View درجہ بندی کی دوبارہ تعمیر کے لیے بہتر بنایا گیا ہے۔

@StateObject کا زندگی کا چکر

• تخلیق — جب View پہلی بار اسکرین پر ظاہر ہوتی ہے، SwiftUI آبجیکٹ کے ابتدائیہ دینے والے کو کال کرتا ہے اور حوالہ محفوظ کرتا ہے۔
• دوبارہ تعمیر — جب والدین View اپ ڈیٹ ہوتا ہے، آبجیکٹ دوبارہ نہیں بنتا؛ موجودہ مثال استعمال ہوتی ہے۔
• تباہی — جب View اسکرین چھوڑتی ہے اور درجہ بندی سے ہٹا دی جاتی ہے، SwiftUI آبجیکٹ کا deinit کال کرتا ہے۔

@StateObject بمقابلہ @ObservedObject: کلیدی فرق

@StateObject اور @ObservedObject کے درمیان بنیادی فرق یہ ہے کہ آبجیکٹ کا مالک کون ہے۔ @StateObject آبجیکٹ بناتا اور محفوظ کرتا ہے — وہ مالک ہے۔ @ObservedObject صرف اس آبجیکٹ کو دیکھتا ہے جو کہیں اور بنایا گیا اور ابتدائیہ دینے والے یا خصوصیت کے ذریعے منتقل کیا گیا۔

قاعدہ آسان ہے: اگر View ObservableObject بناتی ہے — @StateObject استعمال کریں۔ اگر View صرف والدین سے پہلے سے بنا ہوا آبجیکٹ وصول کرتی ہے — @ObservedObject استعمال کریں۔ اس قاعدے کی خلاف ورزی یا تو ڈیٹا کے نقصان (اگر ملکیت کے لیے @ObservedObject استعمال کیا جائے) یا ضرورت سے زیادہ آبجیکٹ تخلیق (اگر مشاہدے کے لیے @StateObject استعمال کیا جائے) کا باعث بنتی ہے۔

@StateObject کب استعمال کریں

@StateObject کو ان Views میں استعمال کیا جانا چاہیے جو ڈیٹا کے مخصوص سیٹ کے لیے ماخذ حقیقت ہیں۔ عام منظرناموں میں اپنے view model والی اسکرینیں، نیویگیشن اسٹیک کی جڑی اسکرینیں، اور موڈل پریزنٹیشنز شامل ہیں جو اپنی حالت خود منظم کرتی ہیں۔

• View model والی اسکرین — ہر اسکرین جو اپنے ڈیٹا اور منطق کو منظم کرتی ہے، @StateObject کے ذریعے اپنا view model بنانا چاہیے۔
• جڑ View — NavigationStack یا TabView کے درجہ بندی میں، جڑ عنصر ڈیٹا بناتا ہے، اور ذیلی عناصر @ObservedObject کے ذریعے ڈیٹا وصول کرتے ہیں۔
• موڈل ونڈوز — .sheet اور .fullScreenCover کو اکثر فارم یا عمل کو منظم کرنے کے لیے اپنے @StateObject کی ضرورت ہوتی ہے۔
• قابل تدوین فہرست — فہرست کی ہر قطار جس میں تدوین فارم ہے، اس کا اپنا @StateObject ہونا چاہیے۔

struct ProfileView: View {
    @StateObject var viewModel = ProfileViewModel()
    
    var body: some View {
        NavigationStack {
            Form {
                TextField("Name", text: $viewModel.name)
                TextField("Email", text: $viewModel.email)
                Button("Save") {
                    viewModel.saveProfile()
                }
            }
            .navigationTitle("Profile")
        }
    }
}

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

@StateObject کو پیرامیٹرز کے ساتھ ابتدائیہ دینے کے لیے خاص نحو درکار ہے، کیونکہ SwiftUI آبجیکٹ کی تخلیق خود منظم کرتا ہے۔ آپ ابتدائیہ دینے والے میں صرف پیرامیٹرز منتقل نہیں کر سکتے — آپ کو ایک فرار ہونے والا closure یا علیحدہ فیکٹری طریقہ استعمال کرنا ہوگا۔

Swift by Sundell (2024) کے مطابق، سب سے صاف طریقہ فیکٹری طریقہ یا closure استعمال کرنا ہے جسے SwiftUI آبجیکٹ کی پہلی تخلیق پر کال کرے گا۔ ایک متبادل طریقہ ObservableObject کو والدین View میں ابتدائیہ دینا اور معیاری ابتدائیہ دینے والے کا استعمال کرتے ہوئے @StateObject کے ذریعے منتقل کرنا ہے۔

class UserViewModel: ObservableObject {
    @Published var user: User
    
    init(user: User) {
        self.user = user
    }
}

struct UserDetailView: View {
    @StateObject var viewModel: UserViewModel
    
    init(user: User) {
        _viewModel = StateObject(wrappedValue: UserViewModel(user: user))
    }
    
    var body: some View {
        Text(viewModel.user.name)
    }
}

یہ یاد رکھنا ضروری ہے کہ @StateObject کے ساتھ View ابتدائیہ دینے والا property wrapper تک رسائی کے لیے خصوصیت کے نام سے پہلے زیرخط (_viewModel) استعمال کرنا چاہیے، نہ کہ اس کی قدر۔ یہ ابتدائیہ دینے والوں میں property wrappers کے ساتھ کام کرنے کے لیے ایک معیاری Swift نمونہ ہے۔

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

سب سے عام غلطی اس View کے لیے جسے آبجیکٹ کا مالک ہونا چاہیے، @StateObject کے بجائے @ObservedObject استعمال کرنا ہے۔ اس صورت میں، ہر بار جب والدین دوبارہ تعمیر ہوتا ہے، آبجیکٹ دوبارہ بنایا جائے گا، جس سے تمام جمع شدہ ڈیٹا ضائع ہو جائے گا۔ یہ غلطی NavigationStack یا TabView کے ساتھ پیچیدہ درجہ بندیوں میں خاص طور پر خطرناک ہے۔

• نیویگیشن کے دوران ڈیٹا کا نقصان — اگر کوئی ذیلی اسکرین اپنے view model کے لیے @ObservedObject استعمال کرتی ہے، تو پیچھے جانے اور دوبارہ کھولنے پر ڈیٹا ری سیٹ ہو جائے گا۔
• میموری لیک — والدین View میں @StateObject بنانا جو کبھی نہیں ہٹتا، آبجیکٹ جمع ہونے کا باعث بن سکتا ہے اگر ہر ذیلی اسکرین بھی بغیر کنٹرول کے @StateObject بنائے۔
• آبجیکٹ کی نقل — ایک ObservableObject کو مختلف Views میں متعدد @StateObject میں منتقل کرنے سے کئی آزاد مثالیں بنتی ہیں جو ایک دوسرے کے ساتھ ہم آہنگ نہیں ہوتیں۔

ان مسائل سے بچنے کے لیے، ایک سادہ قاعدہ پر عمل کریں: فی ماخذ حقیقت ایک @StateObject۔ اگر ڈیٹا کو متعدد اسکرینوں میں مشترکہ ہونا چاہیے — جڑ View میں ایک بار @StateObject بنائیں اور @ObservedObject یا @EnvironmentObject کے ذریعے ذیلی عناصر کو منتقل کریں۔

// ❌ Wrong: @ObservedObject for owning an object
struct BadView: View {
    @ObservedObject var vm = ViewModel() // will be recreated on each update!
}

// ✅ Correct: @StateObject for owning
struct GoodView: View {
    @StateObject var vm = ViewModel() // created once for View lifetime
}