iOS میں ViewController Lifecycle: کلیدی تصورات، مراحل اور طریقے

ViewController Lifecycle کیا ہے

ViewController Lifecycle ان طریقوں کا ایک مجموعہ ہے جو UIViewController اپنے وجود کے دوران UIKit سے حاصل کرتا ہے۔ iOS ایپ میں ہر اسکرین ترتیب وار تخلیق، View لوڈنگ، اسکرین پر ظاہر ہونے، چھپنے اور میموری آزاد کرنے کے مراحل سے گزرتی ہے۔ UIKit ہر مرحلے پر متعلقہ طریقوں کو خود بخود کال کرتا ہے اور ڈیولپر اپنی منطق شامل کرنے کے لیے انہیں اوور رائڈ کرتا ہے۔

UIViewController آرکیٹیکچر UIKit کی بنیاد ہے اور SwiftUI دور میں بھی متعلقہ ہے — بہت سے پروجیکٹس اب بھی کلاسک طریقہ کار یا ہائبرڈ آرکیٹیکچر استعمال کرتے ہیں۔ Lifecycle کو سمجھنا آپ کو پیش گوئی کرنے دیتا ہے کہ subviews کب دستیاب ہیں، لے آؤٹ کو تبدیل کرنا کب محفوظ ہے اور اسکرین ظاہر یا چھپنے پر کون سی کارروائیاں کرنی چاہئیں۔

زندگی کے چکر کے ہر طریقہ کا ایک مخصوص مقصد ہوتا ہے: کچھ کنٹرولر کی پوری زندگی میں صرف ایک بار کال ہوتے ہیں، دوسرے — ہر ظاہر ہونے یا چھپنے پر۔ طریقوں کے درمیان منطق کو ملانا مشکل سے ملنے والے بگز کا سبب بنتا ہے: میموری لیک، غلط ڈیٹا اپ ڈیٹس اور غیر ضروری نیٹ ورک درخواستیں۔

UIViewController طریقوں کا مکمل چکر

چھ طریقے UIViewController کا مکمل زندگی کا چکر بناتے ہیں۔ کال کی ترتیب مقرر ہے اور نیویگیشن کے طریقہ کار پر منحصر نہیں ہے — push، present یا unwind segue سب ایک ہی نظام الاوقات کی پیروی کرتے ہیں۔

loadView — روٹ View بنانا

loadView چکر کا پہلا طریقہ ہے، جو اس وقت کال ہوتا ہے جب کنٹرولر کی View ابھی موجود نہ ہو۔ اگر آپ Storyboard استعمال کرتے ہیں، UIKit خود بخود xib فائل سے View لوڈ کرتا ہے۔ پروگرام کے ذریعے انٹرفیس بناتے وقت، آپ روٹ View کو دستی طور پر تفویض کرکے اس طریقہ کو اوور رائڈ کرتے ہیں۔ زیادہ تر پروجیکٹس میں، loadView کو چھوا نہیں جاتا — کام viewDidLoad میں کیا جاتا ہے۔

loadView کو اوور رائڈ کرنا صرف مخصوص صورتوں میں ضروری ہے: جب پورا انٹرفیس Storyboard کے بغیر کوڈ میں بنایا گیا ہو، یا جب روٹ View کو غیر معیاری کلاس کا ہونا ضروری ہو۔ Apple اوور رائڈ کرتے وقت super.loadView کو نہ کال کرنے کی سفارش کرتا ہے — آپ View بنانے کی پوری ذمہ داری لیتے ہیں۔

override func loadView() {
    view = UIView()
    view.backgroundColor = .white
}

viewDidLoad — ایک بار کا ابتدائیہ

viewDidLoad چکر کا سب سے زیادہ استعمال ہونے والا طریقہ ہے۔ یہ View کے میموری میں لوڈ ہونے کے بعد ایک بار کال ہوتا ہے لیکن ابھی اسکرین پر ظاہر نہیں ہوتا۔ یہاں subviews ترتیب دیے جاتے ہیں، ٹیبلز ڈیٹا سے بھری جاتی ہیں، سیلز رجسٹر کیے جاتے ہیں اور اطلاعات کو سبسکرائب کیا جاتا ہے جو کنٹرولر کی پوری زندگی تک رہتی ہیں۔

ایک اہم خصوصیت: اسکرین کے دوبارہ ظاہر ہونے پر viewDidLoad دوبارہ کال نہیں ہوتا۔ اگر آپ کو ہر بار اسکرین ظاہر ہونے پر ڈیٹا اپ ڈیٹ کرنے کی ضرورت ہے — viewWillAppear استعمال کریں۔ viewDidLoad میں صرف ایک بار کی کارروائیاں رکھیں جو بنیادی ترتیب کے لیے ضروری ہوں۔

viewWillAppear — ظاہر کرنے سے پہلے تیاری

viewWillAppear ہر بار View کے صارف کو نظر آنے سے ٹھیک پہلے کال ہوتا ہے۔ یہ طریقہ ایک animated پیرامیٹر وصول کرتا ہے جو بتاتا ہے کہ ظاہر ہونا اینی میٹڈ ہے یا نہیں۔ یہاں ڈیٹا اپ ڈیٹ کیا جاتا ہے، ٹیبلز دوبارہ لوڈ کی جاتی ہیں، NavigationBar ترتیب دیا جاتا ہے اور ایپلیکیشن کی حالت کے مطابق عناصر چھپائے یا دکھائے جاتے ہیں۔

اسکرینوں کے درمیان حالت کی ہم آہنگی کے لیے viewWillAppear استعمال کریں: اگر صارف پچھلی اسکرین پر ڈیٹا تبدیل کر سکتا تھا، یہ طریقہ انٹرفیس کو اپ ڈیٹ کرنے کے لیے صحیح جگہ ہے۔ viewWillAppear کی ہر کال اسکرین کے ظاہر ہونے سے پہلے ہوتی ہے، چائلڈ کنٹرولر سے واپسی پر بھی۔

viewDidAppear — اسکرین مکمل طور پر نظر آتی ہے

viewDidAppear مطلع کرتا ہے کہ View اسکرین پر مکمل طور پر ظاہر ہو چکی ہے اور تمام منتقلی اینی میشنز مکمل ہو چکی ہیں۔ اس مقام پر، اسکرین تعامل کے لیے تیار ہے — صارف مکمل انٹرفیس دیکھتا ہے اور اس کے ساتھ بات چیت کر سکتا ہے۔ یہ طریقہ ان اینی میشنز کو شروع کرنے کے لیے موزوں ہے جو ظاہر ہونے کے بعد شروع ہونی چاہئیں، ٹائمر شروع کرنے اور تجزیاتی امپریشنز کو ٹریک کرنے کے لیے۔

viewWillAppear کے برعکس، viewDidAppear ضمانت دیتا ہے کہ اسکرین نہ صرف نظر آ رہی ہے بلکہ مکمل طور پر رینڈر بھی ہو چکی ہے۔ اگر آپ viewWillAppear میں اینی میشن شروع کرتے ہیں، کچھ فریم چھوٹ سکتے ہیں کیونکہ UIKit نے ابھی منتقلی مکمل نہیں کی۔ ہموار اینی میشنز کے لیے، viewDidAppear استعمال کریں۔

viewWillDisappear — چھپانے کی تیاری

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

یاد رکھنا اہم ہے: viewWillDisappear ضمانت نہیں دیتا کہ View آخرکار غائب ہو جائے گی — اشارہ منسوخ کیا جا سکتا ہے۔ لہٰذا، اہم ڈیٹا کو viewDidDisappear میں بھی محفوظ کریں، جو صرف حقیقی غائب ہونے کے بعد کال ہوتا ہے۔

viewDidDisappear — اسکرین چھپی ہوئی ہے

viewDidDisappear ظاہر ہونے اور غائب ہونے کے چکر کو مکمل کرتا ہے۔ یہ View کے اسکرین سے چھپ جانے کے بعد کال ہوتا ہے۔ اس طریقہ میں، اینی میشنز آخرکار روک دی جاتی ہیں، عارضی اشیاء ہٹا دی جاتی ہیں اور viewWillDisappear میں شروع کردہ ڈیٹا کی محفوظ کرنے کی تصدیق کی جاتی ہے۔

یہ طریقہ کنٹرولر کے deinit سے پہلے بھی آتا ہے — اگر آپ کا UIViewController تباہ ہو رہا ہے، deinit کال ہونے سے پہلے viewDidDisappear Lifecycle کا آخری طریقہ ہوگا۔ آبجیکٹ کے تباہ ہونے سے پہلے حتمی صفائی کے لیے اسے استعمال کریں۔

ہر طریقہ کب کال ہوتا ہے

کالوں کا تسلسل اس بات پر منحصر ہے کہ اسکرین کیسے ظاہر ہوتی ہے: پہلی بار، واپس جانے پر یا موڈلی پیش کرنے پر۔ آئیے UIKit کے نقطہ نظر سے تین اہم منظرناموں پر غور کریں۔

پہلی بار کھولنے پر ترتیب

جب اسکرین پہلی بار ظاہر ہوتی ہے، UIKit مکمل تخلیق کے چکر سے گزرتا ہے: loadView کال ہوتا ہے، پھر viewDidLoad، جس کے بعد ظاہر ہونے کی اینی میشن شروع ہوتی ہے۔ اینی میشن کے دوران، viewWillAppear کال ہوتا ہے، اور مکمل ہونے کے بعد — viewDidAppear۔ یہ واحد منظرنامہ ہے جہاں loadView سے viewDidAppear تک تمام طریقے ترتیب وار فعال ہوتے ہیں۔

override func viewDidLoad() {
    super.viewDidLoad()
    print("viewDidLoad — View میموری میں لوڈ ہو گیا")
}

override func viewWillAppear(_ animated: Bool) {
    super.viewWillAppear(animated)
    print("viewWillAppear — جلد ظاہر ہوگا")
}

override func viewDidAppear(_ animated: Bool) {
    super.viewDidAppear(animated)
    print("viewDidAppear — اسکرین مکمل طور پر نظر آ رہی ہے")
}

واپس جانے پر ترتیب

جب صارف پچھلی اسکرین پر واپس جاتا ہے، UIKit دوبارہ viewDidLoad کال نہیں کرتا — View پہلے سے میموری میں لوڈ ہے۔ اس کے بجائے، واپس آنے والی اسکرین پر صرف viewWillAppear اور viewDidAppear کال ہوتے ہیں اور موجودہ اسکرین پر — viewWillDisappear اور viewDidDisappear۔ loadView اور viewDidLoad کو چھوڑ دیا جاتا ہے کیونکہ اسکرین پہلے سے نیویگیشن اسٹیک میں موجود ہے۔

Present اور dismiss کے خصوصی معاملات

موڈل پیشکش ایک ہی قواعد کی پیروی کرتی ہے: نیا کنٹرولر پہلی ظاہری شکل پر مکمل چکر سے گزرتا ہے، جبکہ موجودہ viewWillDisappear اور viewDidDisappear وصول کرتا ہے۔ Dismiss پر، ترتیب الٹ جاتی ہے: واپس آنے والا کنٹرولر دوبارہ viewWillAppear اور viewDidAppear حاصل کرتا ہے، جبکہ ہٹایا گیا کنٹرولر آخری طریقے حاصل کرتا ہے۔ یہ رویہ UIKit میں تمام منتقلی کی اقسام کے لیے یکساں ہے۔

عملی استعمال کے منظرنامے

آئیے چار اہم منظرناموں کو دیکھتے ہیں جہاں Lifecycle کو سمجھنا براہ راست کوڈ کے معیار اور صارف کے تجربے کو متاثر کرتا ہے۔ ہر منظرنامے کے لیے، ہم سفارشات کے ساتھ ایک مثال فراہم کرتے ہیں۔

viewDidLoad میں ڈیٹا کا ابتدائیہ

viewDidLoad ابتدائی ترتیب کے لیے جگہ ہے جو اسکرین کی نمائش پر منحصر نہیں ہے۔ یہاں collectionView ترتیب دیا جاتا ہے، خلیوں کے لیے nib فائلیں رجسٹر کی جاتی ہیں، ڈیٹا ذرائع اور لے آؤٹ بنائے جاتے ہیں۔ اگر آپ نیٹ ورک سے ڈیٹا لوڈ کر رہے ہیں، viewDidLoad میں صرف درخواست شروع کرنا بہتر ہے اور UI کو viewWillAppear میں اپ ڈیٹ کریں جب اسکرین ڈسپلے کے لیے تیار ہو۔

override func viewDidLoad() {
    super.viewDidLoad()
    tableView.register(
        MyCell.self,
        forCellReuseIdentifier: MyCell.identifier
    )
    viewModel.loadInitialData()
}

viewWillAppear میں مواد کی اپ ڈیٹ

ہر بار اسکرین ظاہر ہونے پر ڈیٹا کی ہم آہنگی کے لیے viewWillAppear استعمال کریں۔ مثال کے طور پر، اگر صارف پچھلی اسکرین پر سیٹنگز تبدیل کر سکتا تھا، یہاں ظاہر کردہ اقدار کو اپ ڈیٹ کیا جاتا ہے، ٹیبل دوبارہ لوڈ کی جاتی ہے اور NavigationBar کی حالت کو ایڈجسٹ کیا جاتا ہے۔ یہ ضمانت دیتا ہے کہ اسکرین کسی بھی نیویگیشن منظرنامے میں ہمیشہ تازہ ترین ڈیٹا دکھاتی ہے۔

override func viewWillAppear(_ animated: Bool) {
    super.viewWillAppear(animated)
    tableView.reloadData()
    navigationController?.setNavigationBarHidden(false, animated: animated)
}

viewDidAppear میں تجزیات اور اینی میشنز

viewDidAppear ان اینی میشنز کو شروع کرنے کے لیے مثالی ہے جو صارف کے اسکرین دیکھنے کے بعد شروع ہونی چاہئیں۔ یہاں آپ تجزیاتی واقعات بھی بھیجتے ہیں: اسکرین ویو، آن بورڈنگ شروع کرنا یا ویڈیو پلے بیک شروع کرنا۔ منتقلی مکمل ہونے سے پہلے اینی میشن شروع کرنا پھنسے ہوئے انٹرفیس کا سبب بنتا ہے — UIKit کے پاس کافی فریم تیار کرنے کا وقت نہیں ہوتا۔

viewWillDisappear میں حالت محفوظ کرنا

viewWillDisappear میں، ڈرافٹ محفوظ کیے جاتے ہیں، ٹائمر روکے جاتے ہیں اور NotificationCenter سے سبسکرپشن منسوخ کی جاتی ہے۔ یہ آخری لمحہ ہے جب اسکرین اب بھی نظر آ رہی ہے اور صارف کے سیاق و سباق کی ضرورت والی کارروائیوں کے لیے قابل رسائی ہے۔ اہم ڈیٹا کے لیے، منسوخ شدہ اشاروں سے تحفظ کے طور پر اضافی طور پر viewDidDisappear بھی استعمال کریں۔

Lifecycle کے ساتھ کام کرتے وقت عام غلطیاں

زندگی کے چکر کے طریقوں کا غلط استعمال iOS ایپس میں بگز کے سب سے عام ذرائع میں سے ایک ہے۔ آئیے UIViewController کے ساتھ کام کرنے کے مختلف مراحل میں ڈیولپرز کی عام غلطیوں کو دیکھتے ہیں۔

پہلی غلطی — Storyboard استعمال کرتے وقت init یا loadView میں subviews بنانا۔ اگر آپ Interface Builder استعمال کر رہے ہیں، ضرورت کے بغیر loadView کو اوور رائڈ نہ کریں۔ Storyboard موجود ہونے پر loadView میں View بنانا xib فائل کو نظر انداز کرنے اور خالی اسکرین کا سبب بنتا ہے۔

دوسری غلطی — viewDidLoad میں کی بورڈ اطلاعات کو سبسکرائب کرنا اور سبسکرپشن منسوخ نہ کرنا۔ اگر آپ نے UIResponder.keyboardWillShowNotification کو سبسکرائب کیا لیکن اسکرین چھپنے پر سبسکرپشن منسوخ نہیں کی، بلاک کنٹرولر کے deinit کے بعد بھی کال ہوتا رہے گا — یہ میموری لیک ہے جس میں ایپ کریش ہونے کا امکان ہے۔

تیسری غلطی — اسکرین ظاہر ہونے سے پہلے ٹائمر اور نیٹ ورک کی درخواستیں شروع کرنا۔ جب View ابھی نظر نہیں آ رہی ہو تو تصاویر لوڈ کرنا یا اینی میشن کرنا وسائل کا ضیاع ہے۔ بصری اپ ڈیٹس کو viewWillAppear یا viewDidAppear میں منتقل کریں۔

چوتھی غلطی — صرف viewWillDisappear میں ڈیٹا محفوظ کرنا۔ انٹرایکٹو پاپ اشارے کے ساتھ، صارف سوائپ شروع کر سکتا ہے اور اسے منسوخ کر سکتا ہے — طریقہ کال ہوا لیکن اسکرین غائب نہیں ہوئی۔ اہم محفوظ کرنے کو viewDidDisappear یا applicationDidEnterBackground ہینڈلر میں نقل کریں۔