iOS میں viewWillDisappear — طریقے کا جوہر اور اسے صحیح طریقے سے کیسے استعمال کیا جائے

viewWillDisappear کیا ہے

viewWillDisappear UIViewController کا ایک طریقہ ہے جسے UIKit اس سے عور پہلے بلاتا ہے کہ کنٹرولر کا ویو سکرین سے غائب ہونا شروع کرتا ہے۔ اس لمحے سکرین صاحب استعمال کو اب بھی نظر آتی ہے، لیکن تبدیلی پہلے ہی شروع ہو چکی ہے: NavigationController نے push/pop اینیمیشن شروع کر دیا ہے، موڈل ویو بند ہونا شروع ہو گئی ہے، یا TabBar نے کسی اور ٹیز پر سوئچ کرنا شروع کر دیا ہے۔ ڈیویلپر اس طریقے کو ان کاموں کے لیے اووررائیڈ کرتا ہے جنہیں سکرین کا اب بھی رسائی ممکن ہونا چاہیے لیکن چھوپانے کی تیاری ہو۔

viewDidDisappear کے برعکس، جو سکرین چھپنے کے بعد فعال ہوتا ہے، viewWillDisappear اس دوران ڈیٹا محفوظ کرنے اور وسائل آزاد کرنے کا آخری موقع فراہم کرتا ہے جب کہ صاحب استعمال اب بھی انٹرفیس دیکھ سکتا ہے۔ یہ UX کے لیے انتہائی اہم ہے — مسودہ محفوظ کرنا یا ٹائمر روکنا صاحب استعمال کے دوسری سکرین پر جانے سے پہلے ہونا چاہیے۔

طریقہ animated پارامیٹر وصول کرتا ہے، جو اس بات کو ظاہر کرتا ہے کہ غائبی اینیمیٹڈ ہے یا نہیں۔ true کا مطلب ہے کہ UIKit ایک اینیمیٹڈ تبدیلی کر رہا ہے، false کا مطلب ہے کہ سکرین فوری غائب ہو جاتی ہے، مثالاً اینیمیشن کے بغیر dismiss یا پروگرامیٹکلی درجہ بندی سے ہٹانے پر۔

viewWillDisappear کب بلایا جاتا ہے

viewWillDisappear ان تمام مناظروں میں بلایا جاتا ہے جہاں موجودہ سکرین فعال ہونا بند کر دیتی ہے۔ iOS ڈیویلپمنٹ کے لیے مخصوص اهم معاملات کا جائزہ لیتے ہیں۔

نئی سکرین push کرتے وقت

جب UINavigationController ایک نئے کنٹرولر کا push کرتا ہے، تبدیلی اینیمیشن کے آغاز پر موجودہ کنٹرولر پر viewWillDisappear بلایا جاتا ہے۔ اس لمحے موجودہ سکرین اس کے اوپر سرکنے والے نئے کنٹرولر کے نیچے اب بھی نظر آتی ہے۔ یہ معیاری منظر ہے جہاں viewWillDisappear animated = true کے ساتھ فعال ہوتا ہے۔

موجودہ سکرین pop کرتے وقت

جب صاحب استعمال واپس بٹن دباتا ہے یا ایک انٹریکٹیو سوائپ واپس کرتا ہے، تو موجودہ کنٹرولر پر viewWillDisappear بلایا جاتا ہے۔ انٹریکٹیو اشارے کے ساتھ یہ کال منسوخ ہو سکتا ہے اگر صاحب استعمال اپنا ارادہ بدل لیتا ہے اور سکرین کو اپنی جگہ واپس لاتا ہے۔ حالت محفوظ کرنے کے نقشے بناتے وقت یہ ایک اہم خصوصیت ہے جیسے ذہن میں رکھنا چاہیے۔

override func viewWillDisappear(_ animated: Bool) {
    super.viewWillDisappear(animated)
    saveDraftData()
    NotificationCenter.default.removeObserver(self)
}

کنٹرولر dismiss کرتے وقت

موڈل ویو بند کرتے وقت، dismiss اینیمیشن کے آغاز پر بند ہونے والے کنٹرولر پر viewWillDisappear بلایا جاتا ہے۔ اس مقام پر آپ ڈیلیگیٹ یا کلوزر کے ذریعے نتائج واپس بھیج سکتے ہیں، کیونکہ جس کنٹرولر نے موڈل پیش کیا تھا اسے اب تک اختیار واپس نہیں ملا ہے۔

TabBar ٹیٹز بدلتے وقت

UITabBarController صاحب استعمال کے کسی اور ٹیٹ کو چھونے کے فوراں بعد چھوڑی جانے والے ٹیٹ کے کنٹرولر پر viewWillDisappear بلاتا ہے۔ اگر موجودہ ٹیٹ پر فعال عملیے ہیں — میڈیا پلے بیک، فائل ڈائن لوڈ، ٹائمر — تو انہیں یہاں موقوف یا روکنا چاہیے۔

viewWillDisappear میں عملی کام

viewWillDisappear وسائل اور حالت کے انتظام سے متعلق مخصوص کاموں کو حل کرتا ہے۔ کوڈ کی مثالوں کے ساتھ اہم مناظروں کا جائزہ لیتے ہیں۔

صاحب استعمال کا ڈیٹا محفوظ کرنا

viewWillDisappear کا سب سے اہم کام موجودہ سکرین پر صاحب استعمال کے درج یا ترمیم کردہ ڈیٹا کو محفوظ کرنا ہے۔ پیغام کے مسودے، ترمیم شدہ فارم فیلڈز، منتخب ترتیبات — یہ سب سکرین غائب ہونے سے پہلے محفوظ کیا جانا چاہیے۔ مستقلیم کے لیے Core Data، UserDefaults یا فائل ذخیرہ استعمال کریں۔

override func viewWillDisappear(_ animated: Bool) {
    super.viewWillDisappear(animated)
    guard hasUnsavedChanges else { return }
    draftStorage.save(currentDraft)
}

اطلاعات سے رکنی منسوخ کرنا

viewWillAppear یا viewDidLoad میں جن NotificationCenter، KVO اور Combine پبلیشرز کی رکنی لی تھی وہ viewWillDisappear میں منسوخ کی جانی چاہیے۔ ایسا نہ کرنے پر، اطلاعات چھپی ہوئی سکرین پر آئیں گی، جس سے صاحب استعمال کو نظر نہ آنے والی UI اپڈیٹس ہونے گیں، یا — اس سے بھی بُرا — پہلے ہی ڈی الوکیٹ کی گئی آبجیکٹس تک رسائی سے کریش ہو گا۔

اینیمیشنز اور ٹائمرز کو روکنا

viewDidAppear میں شروع کی گئی UIView اینیمیشنز اور Timer یا DispatchSource کے ذریعے چلنے والے ٹائمرز کو viewWillDisappear میں روکنا چاہیے۔ چھپی ہوئی سکرین پر جاری اینیمیشنز صاحب استعمال کے لیے کسی فائدے کے بغیر GPU اور بیٹری ضائع کرتی ہیں۔ ٹائمرز پر invalidate اور لیرز پر removeAllAnimations کو کال کرکے انہیں واضح طور پر روکیں۔

override func viewWillDisappear(_ animated: Bool) {
    super.viewWillDisappear(animated)
    countdownTimer?.invalidate()
    countdownTimer = nil
    loadingIndicator.layer.removeAllAnimations()
}

ڈیٹا واپس بھیجنا

اگر کوئی کنٹرولر نتیجہ حاصل کرنے کے لیے کھولا گیا تھا — ایک آئٹم کا انتخاب، متن درج کرنا، کسی عمل کی تصدیق — viewWillDisappear آخری لمحہ ہے جب اصلی کنٹرولر اب بھی اسٹیک میں موجود ہے اور ڈیٹا وصول کر سکتا ہے۔ deinit کال ہونے سے پہلے ڈیلیگیٹ یا کلوزر کو کال کریں۔

حالت محفوظ کرنے کی حکمت عملی

قابل بھروسہ حالت محفوظ کرنا iOS ڈیویلپمنٹ میں سب سے مشکل کاموں میں سے ایک ہے۔ viewWillDisappear حکمت عملی کا ایک اہم لیکن واحید عنصر نہیں ہے۔ آئیے ایک جامع نظریہ پر غور کریں۔

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

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

سطح 3 — ایپ اطلاعات کے ذریعے محفوظ کرنا۔ UIApplication.willResignActiveNotification اور UIApplication.didEnterBackgroundNotification ایپ کے پس منظر ہونے کو پکڑتے ہیں۔ اگر صاحب استعمال نے ایپ کو چہوٹا کیا، تو viewWillDisappear شاید نہ بلایا گیا ہو — لیکن ان اطلاعات کے ذریعے محفوظی سیشن کے اختتام پر ڈیٹا کی سالمیت کی ضمانت دیتی ہے۔

سفارش: تنقیدی صاحب استعمال ڈیٹا کے لیے تینوں سطحوں کا مرکب استعمال کریں۔ غیر تنقیدی حالت کے لیے پہلا سطح کافی ہے۔ ایک ہی ڈیٹا کو بار بار محفوظ نہ کرنا اہم ہے — ایک dirty جھنڈا استعمال کریں جو اس بات کو ظاہر کرتا ہے کہ پچھلی محفوظی کے بعد سے ڈیٹا بدل گیا ہے۔

CRUD سکرینز کے لیے حکمت عملی پر خاص توجہ دی جانی چاہیے جہاں صاحب استعمال ڈیٹا درج کرتا ہے۔ ایسی سکرینز پر viewWillDisappear میں ہر کی سٹروک کو محفوظ کرنے کی سفارش نہیں کی جاتی — یہ ضرورت سے زیادہ ہے۔ Timer کے ذریعے تاخیر (debounce) کے ساتھ خودکار محفوظی استعمال کریں، اور viewWillDisappear کو صرف آخری جبری محفوظی کے لیے استعمال کریں اگر غیر محفوظ تبدیلیاں ہوں۔ یہ نظریہ کارکردگی اور ڈیٹا سالمیت کے درمیان توازن بناتا ہے۔

Core Data استعمال کرنے والے ایپس کے لیے، ایک اضافی اقدام یہ ہے کہ صرف اس وقت viewWillDisappear میں saveContext کو کال کریں جب managed object context میں حقیقی تبدیلیاں ہوں۔ محفوظی سے پہلے context.hasChanges کی جانچ persistent store میں ضرورت سے زیادہ لکھائی کو روکتی ہے اور ڈیوائس کی بیٹری لائف کو بڑھاتی ہے۔ اس جانچ کو applicationDidEnterBackground میں عام محفوظی کے ساتھ ملا کریں۔

viewWillDisappear میں عام غلطیاں

غلط استعمال viewWillDisappear کے نتیجہ میں ڈیٹا کا نقصان، میموری لیکیج اور غیر مستقل ایپ رویہ ہو سکتا ہے۔ آئیے اکثر iOS ڈیویلپر غلطیوں کا جائزہ لیتے ہیں۔

پہلی غلطی — صرف viewWillDisappear میں ڈیٹا محفوظ کرنا۔ جیسا که اوپر بات کی گئی، انٹریکٹیو pop اشارے کے ساتھ طریقہ تب بھی بلایا جاتا ہے جب سکرین غائب نہیں ہوئی۔ اگر محفوظی کے مضری پہلوں حاصل ہیں — سرور پر ڈیٹا بھیجنا، حالت بدلنا — تو یہ جھوٹے اکسائرز کا سبب بن سکتا ہے۔ isBeingDismissed یا isMovingFromParent کی جانچ شامل کریں۔

دوسری غلطی — NotificationCenter سے رکنی منسوخ نہ کرنا۔ iOS میں یہ سب سے عام میموری لیکوں میں سے ایک ہے۔ اگر آپ نے viewWillAppear میں UIResponder.keyboardWillShowNotification کی رکنی لی لیکن viewWillDisappear میں منسوخ نہیں کی، تو کلوزر بلایا جاتا رہے گا۔ کنٹرولر کے deinit پر، کلوزر ایک ڈی الوکیٹ آبجیکٹ کا حوالہ دے گا — ایپ کریش یقینی۔

تیسری غلطی — بھاری هم آہنگ کارروائیاں کرنا۔ viewWillDisappear میں بڑی مقدار میں ڈیٹا محفوظ کرنا، Core Data یا فائل سیسٹم میں لکھنا مرکزی تھریڈ کو بلاک کرتا ہے۔ اگر کارروائی تبدیلی اینیمیشن سے زیادہ دیر کرتی ہے، UIKit تھریڈ کو موقوف کر دیتا ہے اور انٹرفیس منجمد ہو جاتا ہے۔ بھاری محفوظی کو پس منظر کی قطاروں میں ڈالیں۔

چوتھی غلطی — super کو کال کرنا بھول جانا۔ super.viewWillDisappear کو نہ بلانے سے UINavigationController اور UITabBarController ٹوٹ سکتے ہیں جو اپنی اندرونی حالتوں کے لیے اس طریقے کا استعمال کرتے ہیں۔ Apple دستاویز کے مطابق super کو ہمیشہ پہلے یا آخر میں کال کریں۔

یہ مسئلہ فعال ملٹی ٹاسکنگ اور ایپ سوئچنگ والے iOS پر اور بڑھ جاتا ہے۔ پانچویں غلطی — viewWillDisappear میں محفوظی کے بعد DispatchQueue.main.async کا استعمال کرنا۔ اگر آپ super.viewWillDisappear کو کال کرنے کے بعد مرکزی قطار میں غیر هم آہنگ طور پر ایک بلاک بھیجتے ہیں، تو اس بات کی کوئی ضمانت نہیں ہے کہ بلاک کے انفاذ کے وقت کنٹرولر اب بھی موجود ہے۔ ڈی الوکیٹ میموری تک رسائی اور ایپ کریش سے بچنے کے لیے کلوزرز کے اندر ہمیشہ کمزور حوالہ [weak self] استعمال کریں۔