body: یہ کیا ہے، SwiftUI میں View کی computed property

SwiftUI میں body کیا ہے؟

body ایک computed property ہے جو View پروٹوکول کی واحد لازمی ضرورت ہے۔ View کے مطابق ہر ساخت کو body لاگو کرنا چاہیے۔ یہ پراپرٹی وہ مواد لوٹاتی ہے جو SwiftUI اسکرین پر ظاہر کرتا ہے — یہ متن، تصویر، بٹن، اندرونی عناصر والا کنٹینر یا View پروٹوکول کے مطابق کوئی اور قسم ہو سکتی ہے۔

body کا دستخط ہمیشہ مقرر ہوتا ہے: var body: some View { get }. واپسی کی قسم some View (غیر شفاف قسم) ہے، کوئی ٹھوس قسم نہیں۔ اس کا مطلب ہے کہ مختلف Views body میں مختلف ٹھوس اقسام واپس کر سکتے ہیں، لیکن Swift کمپائلر ہر نفاذ کے لیے مرتب وقت پر ٹھوس قسم مقرر کرتا ہے۔

WWDC 2022 کے مطابق، body اعلانیہ انٹرفیس کی وضاحت کا داخلہ نقطہ ہے۔ UIKit کے برعکس، جہاں آپ UIView کو لازمی طور پر بناتے اور ترتیب دیتے ہیں، SwiftUI میں آپ اعلانیہ طور پر بیان کرتے ہیں کہ کیا ظاہر ہونا چاہیے، اور SwiftUI خود حساب لگاتا ہے کہ اسے کیسے لاگو کرنا ہے۔

body خالص فعل کے طور پر

body کو خالص فعل کی طرح برتاؤ کرنا چاہیے — ایک ہی ان پٹ (ساخت کی خصوصیات اور حالت) کے ساتھ اسے وہی View درخت لوٹانا چاہیے۔ اگر body بیرونی متغیر حالت (عالمی متغیرات، @AppStorage ریپر کے بغیر UserDefaults) پر منحصر ہے، تو رویہ غیر متوقع ہو جاتا ہے اور SwiftUI اسکرین کو غلط طریقے سے دوبارہ کھینچ سکتا ہے۔

Computed property body کیسے کام کرتی ہے

Computed property body کوئی قدر ذخیرہ نہیں کرتی — یہ ہر بار رسائی حاصل کرنے پر شمار کی جاتی ہے۔ جب SwiftUI تعین کرتا ہے کہ حالت تبدیل ہو گئی ہے، تو یہ View ساخت کو دوبارہ بناتا ہے اور ظاہر کرنے کے لیے موجودہ عناصر کا درخت حاصل کرنے کے لیے body کی نئی قدر پڑھتا ہے۔

struct CounterView: View {
    @State private var count = 0

    var body: some View {
        VStack {
            Text("شمار کنندہ: \(count)")
                .font(.largeTitle)
            Button("اضافہ") {
                count += 1
            }
            .padding()
            .background(.blue)
            .foregroundColor(.white)
            .cornerRadius(8)
        }
    }
}

اس مثال میں، body ایک VStack لوٹاتی ہے جس میں Text اور modifiers کے ساتھ ایک بٹن ہے۔ جب بٹن دبایا جاتا ہے، @State پراپرٹی count بڑھ جاتی ہے، SwiftUI CounterView ساخت کو دوبارہ بناتا ہے اور نئی Text قدر کے ساتھ اپ ڈیٹ شدہ درخت حاصل کرنے کے لیے body کو دوبارہ کال کرتا ہے۔

Modifiers (.font, .padding, .background, .foregroundColor, .cornerRadius) اصل View میں ترمیم نہیں کرتے بلکہ اسے ModifiedContent — ایک نئی قسم میں لپیٹ دیتے ہیں جو ترمیم شامل کرتی ہے۔ ہر modifier nesting کی ایک اور سطح بناتا ہے، جو کارکردگی کے لیے غور کرنا ضروری ہے۔

body اور غیر شفاف قسم some View

body کی واپسی کی قسم میں some View صرف ایک روایت نہیں بلکہ کمپائلر کی ضرورت ہے۔ Swift کو ضرورت ہے کہ body میں واپسی کے تمام راستوں کی ایک جیسی ٹھوس قسم ہو۔ @ViewBuilder کے بغیر آپ ایک شاخ میں Text اور دوسری میں Button واپس نہیں کر سکتے — کمپائلر خرابی دے گا۔

struct ConditionalView: View {
    var isReady: Bool

    @ViewBuilder
    var body: some View {
        if isReady {
            Text("تیار")
                .foregroundColor(.green)
        } else {
            ProgressView()
        }
    }
}

body پر @ViewBuilder کمپائلر کی خرابیوں کے بغیر مشروط منطق (if/else, switch) استعمال کرنے دیتا ہے۔ ViewBuilder خود بخود مختلف شاخوں کو ConditionalContent — ایک خاص قسم میں لپیٹ دیتا ہے جو ٹھوس اقسام کے فرق کو چھپاتی ہے۔ متحرک انٹرفیس بنانے کے لیے یہ ایک اہم صلاحیت ہے۔

@ViewBuilder کے بغیر کمپائلر واپسی کے تمام راستوں کے لیے ایک قسم کا اندازہ لگانے کی کوشش کرتا ہے۔ اگر اقسام مختلف ہیں — خرابی پیدا ہوتی ہے۔ یہی وجہ ہے کہ SwiftUI View اعلانات میں body پر مضمر طور پر @ViewBuilder لاگو کرتا ہے، اگرچہ صارف کوڈ میں آپ کو کسٹم طریقوں اور خصوصیات کے لیے واضح طور پر تشریح شامل کرنی ہوتی ہے جو متعدد Views لوٹاتے ہیں۔

Some View کی کارکردگی

ٹھوس قسم کے بجائے some View استعمال کرنے سے کارکردگی کم نہیں ہوتی — کمپائلر مرتب وقت پر صحیح قسم جانتا ہے اور متحرک ڈسپیچ کے بغیر براہ راست کوڈ تخلیق کرتا ہے۔ AnyView، اس کے برعکس، وجودی کنٹینر میں لپیٹنے کے اضافی بوجھ کے ساتھ قسم مٹانے (type erasure) کا استعمال کرتا ہے۔

body کی زندگی کا دور: کب اور کیسے کال کی جاتی ہے

body SwiftUI کے ذریعے تین اہم منظرناموں میں کال کی جاتی ہے: جب View پہلی بار ظاہر ہوتا ہے، جب @State/@Binding/@ObservedObject/@StateObject تبدیل ہوتا ہے، اور جب والد View ابتدا کار کے ذریعے نئی اقدار منتقل کرتا ہے۔ SwiftUI ماحول کی اقدار (@Environment) تبدیل ہونے پر بھی body کو کال کر سکتا ہے۔

body کالوں کی تعدد آپ کو پریشان نہیں کرنی چاہیے — SwiftUI شناخت کے طریقہ کار کے ذریعے دوبارہ ڈرائنگ کو بہتر بناتا ہے۔ درجہ بندی میں ہر View کا ایک منفرد شناخت کنندہ ہوتا ہے۔ اگر شناخت اور ان پٹ ڈیٹا تبدیل نہیں ہوا — body کال نہیں کی جاتی چاہے والد View دوبارہ کھینچا جائے۔ یہ Equatable موازنہ اور ساختی استحکام کے ذریعے حاصل کیا جاتا ہے۔

struct ParentView: View {
    var body: some View {
        ChildView(name: "Alice") // مستحکم شناخت
    }
}

struct ChildView: View {
    let name: String
    var body: some View {
        Text("ہیلو، \(name)!")
    }
}

اس مثال میں، اگر ParentView دوبارہ کھینچا جائے لیکن وہی name قدر منتقل کرے — ChildView.body کال نہیں ہوتی۔ SwiftUI ساخت کے ان پٹ ڈیٹا کا موازنہ کرتا ہے اور، اگر تبدیل نہیں ہوا، تو بچے کے جزو کی دوبارہ ڈرائنگ چھوڑ دیتا ہے۔ یہ ویو تفریق کا طریقہ کار ہے۔

جب body غیر متوقع طور پر کال کی جائے

کئی پھندے ہیں جو body کے غیر متوقع کال کا سبب بنتے ہیں: ObservableObject کے بغیر کلاسز کا استعمال، body کے اندر بنائے گئے closures کو منتقل کرنا (ہر closure تخلیق ایک نئی شناخت دیتا ہے)، اور EquatableView کا غلط استعمال۔ اگر body بہت بار کال کی جاتی ہے — تمام بچوں کے اجزاء کی شناخت کے استحکام کو چیک کریں۔

body کے ساتھ کام کرنے کے بہترین طریقے

پہلا قاعدہ: body کم سے کم ہونی چاہیے۔ پیچیدہ منطق کو علیحدہ computed properties یا طریقوں میں منتقل کریں جو View لوٹاتے ہیں۔ اس سے پڑھنے کی اہلیت بہتر ہوتی ہے اور SwiftUI کو زیادہ درست طریقے سے تعین کرنے دیتا ہے کہ درجہ بندی کے کون سے حصے تبدیل ہوئے ہیں۔ بڑی bodies کو واضح ذمہ داری کی حدود والے ذیلی اجزاء میں تقسیم کریں۔

دوسرا قاعدہ: کام انجام دینے کے لیے body استعمال نہ کریں۔ ڈیٹا لوڈنگ، نیٹ ورک آپریشنز، ڈیٹابیس تحریر — یہ سب body سے باہر، کاموں (tasks)، onChange modifiers یا ObservableObject کے ذریعے ہونا چاہیے۔ body صرف انٹرفیس کے اعلان کے لیے ہے۔

تیسرا قاعدہ: اگر معیاری ساختی موازنہ ناکافی ہے تو Views کے لیے EquatableView پراپرٹی یا کسٹم Equatable پروٹوکول استعمال کریں۔ یہ آپ کو SwiftUI کو واضح طور پر بتانے دیتا ہے کہ بچے کے View کو کب دوبارہ ڈرائنگ کی ضرورت ہے اور غیر ضروری body کالوں سے بچتا ہے۔

چوتھا قاعدہ: اگر body میں پیچیدہ حسابات (فارمیٹنگ، فلٹرنگ، ترتیب) ہیں — نتیجہ کو کیش کرنے کے لیے @State استعمال کریں یا حسابات کو علیحدہ طریقے میں منتقل کریں جو onChange سے کال کیا جائے۔ ہر حالت کی تازہ کاری پر body میں بار بار حسابات اینیمیشن سست ہونے کی ایک عام وجہ ہیں۔

پانچواں قاعدہ: فہرستوں (List, ForEach) کے لیے id پیرامیٹر کے ذریعے مستحکم شناخت کنندگان کو یقینی بنائیں۔ مستحکم شناخت کے بغیر، ForEach کسی بھی تبدیلی پر تمام عناصر کو دوبارہ بناتا ہے، ہر ایک کے لیے body کو کال کرتا ہے، چاہے صرف ایک عنصر تبدیل ہوا ہو۔