viewDidAppear — UIKit کا ایک UIViewController طریقہ ہے جو اسکرین کے ڈسپلے پر مکمل طور پر ظاہر ہونے اور تمام ٹرانزیشن اینیمیشنز کے مکمل ہونے کے بعد کال کرتا ہے۔ Apple Developer Documentation کے مطابق، یہ طریقہ اس بات کی ضمانت دیتا ہے کہ View صارف کو دکھائی دے رہی ہے اور تعامل کے لیے تیار ہے۔ viewDidAppear اینیمیشنز شروع کرنے، ٹریکنگ اور غیر متزامن کارروائیوں کے لیے بہترین جگہ ہے۔
اہم نکات
viewDidAppear UIViewController کا ایک طریقہ ہے جسے UIKit اس وقت کال کرتا ہے جب View کو ونڈو کے درجہ بندی میں شامل کیا جا چکا ہو اور ٹرانزیشن اینیمیشن مکمل طور پر ختم ہو چکی ہو۔ اس لمحے اسکرین اپنی آخری حالت میں ہوتی ہے: یہ دکھائی دیتی ہے، اس کے ساتھ تعامل کیا جا سکتا ہے، UIKit کی تمام اینیمیشنز رک چکی ہوتی ہیں۔ ڈویلپر اس طریقہ کو ان کارروائیوں کے لیے اوور رائڈ کرتا ہے جن کے لیے ضروری ہے کہ اسکرین صارف کے سامنے ہونے کی ضمانت ہو۔
viewWillAppear کے برعکس، جہاں اسکرین صرف دکھانے کی تیاری کر رہی ہوتی ہے، viewDidAppear اشارہ کرتا ہے کہ صارف پہلے ہی انٹرفیس دیکھ رہا ہے۔ یہ ایک اہم فرق ہے: viewWillAppear میں اینیمیشن شروع کرنے سے فریم ڈراپ ہو سکتے ہیں کیونکہ UIKit ابھی ٹرانزیشن پر کارروائی کر رہا ہوتا ہے۔ viewDidAppear میں ٹرانزیشن مکمل ہو چکی ہوتی ہے اور کنٹرولر کے وسائل نئے مواد کی تیاری کے لیے استعمال کیے جا سکتے ہیں۔
یہ طریقہ viewWillAppear کی طرح animated نامی Bool پیرامیٹر لیتا ہے۔ اگر true — اسکرین کا ظہور اینیمیشن کے ساتھ ہوا تھا۔ اس پیرامیٹر کو UI رویے کو ڈھالنے کے لیے استعمال کیا جا سکتا ہے: مثلاً، غیر اینیمیٹڈ واپسی پر آنے والی اینیمیشن کو چھوڑنا۔
viewDidAppear ان تمام منظرناموں میں کہا جاتا ہے جب اسکرین ظہور کا عمل مکمل کر چکی ہو۔ iOS ڈویلپر کے نقطہ نظر سے اہم صورتوں پر غور کریں۔
UINavigationController کے push یا pop اینیمیشن مکمل کرنے کے بعد، ہدف کنٹرولر پر viewDidAppear کہا جاتا ہے۔ اسٹیک میں پہلی اسکرین کے لیے یہ ابتدائی اوپننگ اینیمیشن کے بعد متحرک ہوتا ہے۔ یہ بنیادی منظرنامہ ہے، اور viewDidAppear میں منطق رکھتے وقت اسی پر توجہ دی جاتی ہے۔
جب صارف موڈل طور پر پیش کردہ کنٹرولر کو بند کرتا ہے اور پچھلے کنٹرولر پر واپس آتا ہے، UIKit واپس آنے والے کنٹرولر پر viewDidAppear کال کرتا ہے۔ اس دوران animated پیرامیٹر اس بات کے مطابق ہوگا کہ dismiss اینیمیشن کے ساتھ ہوا یا نہیں۔ یہ لمحہ ذیلی اسکرین سے ڈیٹا حاصل کرنے کے بعد UI کو اپ ڈیٹ کرنے کے لیے اہم ہے۔
override func viewDidAppear(_ animated: Bool) {
super.viewDidAppear(animated)
logScreenView()
startOnboardingAnimation()
}
UITabBarController منتخب ٹیب کے کنٹرولر پر viewDidAppear کال کرتا ہے جب سوئچنگ مکمل ہو جاتی ہے۔ یہ viewWillAppear سے فرق ہے جو سوئچنگ شروع ہونے پر متحرک ہوتا ہے۔ اگر ٹیب میں خوش آمدید کی اینیمیشن ہے یا فعال وقت کو ٹریک کرنا ضروری ہے، تو viewDidAppear صحیح جگہ ہے۔
جب ایپلیکیشن بیک گراؤنڈ سے فور گراؤنڈ میں واپس آتی ہے، تو دکھائی دینے والے کنٹرولر پر viewWillAppear اور viewDidAppear کہا جا سکتا ہے، اگر View کا لائف سائیکل عارضی طور پر معطل کر دیا گیا تھا۔ تاہم، بیک گراؤنڈ سے واپسی کے قابل اعتماد ٹریکنگ کے لیے UIApplication.willEnterForegroundNotification کو الگ سے استعمال کریں۔
viewDidAppear ان کاموں کو حل کرتا ہے جن کے درست نفاذ کے لیے دکھائی دینے والی اسکرین ضروری ہوتی ہے۔ حقیقی منصوبوں میں استعمال کے اہم منظرناموں پر غور کریں۔
viewDidAppear کا سب سے عام کام اسکرین دیکھنے کا ٹریکنگ ہے۔ تجزیاتی نظام جیسے Firebase Analytics، Amplitude یا Mixpanel کو صرف اس وقت واقعات موصول ہونے چاہئیں جب اسکرین واقعی صارف کو دکھائی دے رہی ہو۔ viewWillAppear میں واقعہ بھیجنا دیکھنے کے وقت کو کم کر سکتا ہے اور غلط محرکات پیدا کر سکتا ہے۔
override func viewDidAppear(_ animated: Bool) {
super.viewDidAppear(animated)
Analytics.logEvent(
name: "screen_view",
parameters: [
"screen_name": "ProfileScreen",
"screen_class": String(describing: self)
]
)
}
اینیمیشنز جو اسکرین کے ظاہر ہونے کے بعد شروع ہونی چاہئیں — تاخیر سے عناصر کا ظاہر ہونا، پیرالیکس، ٹیوٹوریل — viewDidAppear میں شروع کی جاتی ہیں۔ اس لمحے گرافیکل سیاق مکمل طور پر تیار ہوتا ہے، اور اینیمیشن ہموار ہوگی، بغیر شروع میں فریم ڈراپ کے۔ یہ خاص طور پر UIViewPropertyAnimator کے ساتھ اینیمیشنز کے لیے اہم ہے۔
بھاری غیر متزامن کارروائیاں — ہائی ریزولوشن تصاویر لوڈ کرنا، بڑے JSON کو پارس کرنا، ویڈیو کی ابتدا — viewDidAppear میں شروع کرنا بہتر ہے، نہ کہ viewDidLoad یا viewWillAppear میں۔ طریقہ کال ہونے کے وقت صارف پہلے ہی انٹرفیس دیکھ رہا ہوتا ہے، لہذا اسکرین کے ظہور میں تاخیر کیے بغیر سکیلیٹن یا لوڈر دکھایا جا سکتا ہے۔
اگر اسکرین پر ایسے عناصر ہیں جنہیں متواتر اپ ڈیٹ کی ضرورت ہے — الٹی گنتی کا ٹائمر، لوڈنگ انڈیکیٹر، پیش رفت اینیمیشن — انہیں viewDidAppear میں شروع کیا جاتا ہے اور viewDidDisappear میں روکا جاتا ہے۔ یہ اسکرین کے دکھائی نہ دینے پر ٹائمرز کے کام کو روکتا ہے، بیٹری اور CPU وسائل بچاتا ہے۔
میڈیا مواد — ویڈیو، آڈیو، Lottie اینیمیشنز — کو viewDidAppear میں شروع کیا جاتا ہے، پہلے نہیں۔ اگر viewWillAppear میں پلے بیک شروع کیا جائے تو صارف پہلے چند سیکنڈ کھو دے گا جب اسکرین ابھی ظاہر ہو رہی ہوتی ہے۔ viewDidAppear میں آپ AVPlayer یا Lottie اینیمیشن اس یقین کے ساتھ شروع کر سکتے ہیں کہ صارف پہلے فریم سے مواد دیکھ رہا ہے۔ یہ خاص طور پر آن بورڈنگ اسکرینز اور اسپلش اسکرینز کے لیے اہم ہے جہاں درست ٹائمنگ ضروری ہے۔
اینیمیشن شروع کرنے کا صحیح لمحہ براہ راست انٹرفیس کی ہمواری کے احساس کو متاثر کرتا ہے۔ viewWillAppear اور viewDidAppear میں شروع کرنے کا فرق سادہ اینیمیشنز میں نمایاں نہیں ہو سکتا، لیکن پیچیدہ مناظر کے لیے اہم ہے۔
جب UIKit اسکرینوں کے درمیان push ٹرانزیشن انجام دیتا ہے، تو یہ اسکرین شاٹس بناتا ہے، انہیں اینیمیٹ کرتا ہے اور ساتھ ہی نئے کنٹرولر پر viewWillAppear کال کرتا ہے۔ اگر اس لمحے بھاری اینیمیشن شروع کی جائے — پیرالیکس، بلر، ٹرانسفارمیشن — تو UIKit ٹرانزیشن اینیمیشن کے فریم ڈراپ کر سکتا ہے، جھٹکے کا اثر پیدا کرتا ہے۔ viewDidAppear اس بات کی ضمانت دیتا ہے کہ ٹرانزیشن اینیمیشن مکمل ہو چکی ہے، اور آپ کو رینڈرنگ پر مکمل کنٹرول مل جاتا ہے۔
override func viewDidAppear(_ animated: Bool) {
super.viewDidAppear(animated)
UIView.animate(
withDuration: 0.6,
delay: 0.3,
usingSpringWithDamping: 0.8,
initialSpringVelocity: 0.5
) {
self.cardView.alpha = 1.0
self.cardView.transform = .identity
}
}
عناصر کی قدرتی جھرن دار ظاہری شکل بنانے کے لیے تاخیر اور ڈیمپنگ کا استعمال کریں۔ یہ نقطہ نظر انٹرفیس کے تصور کو بہتر بناتا ہے اور dwell time کو بڑھاتا ہے — صارف مواد کو زیادہ دیر تک دیکھتا ہے، جو رویاتی میٹرکس پر مثبت اثر ڈالتا ہے۔
غلط استعمال viewDidAppear کارکردگی کے مسائل، اینیمیشنز کے غیر متوقع رویے اور ضرورت سے زیادہ ٹریکنگ کا سبب بن سکتا ہے۔ عام غلطیوں پر غور کریں۔
پہلی غلطی — متعدد کالز۔ viewDidAppear بعض منظرناموں میں کئی بار کہا جا سکتا ہے: ٹیبز کی سوئچنگ، بیک گراؤنڈ سے واپسی، موڈل ٹرانزیشنز۔ اگر طریقہ میں بغیر کسی فلیگ چیک کے بھاری کارروائی کی جائے تو یہ نقل ہو جائے گی۔ ایک بار کی کارروائیوں کے لیے hasAppeared فلیگ یا dispatchOnce استعمال کریں۔
دوسری غلطی — چھپنے پر منسوخی کے بغیر نیٹ ورک کی درخواستیں شروع کرنا۔ اگر صارف درخواست مکمل ہونے سے پہلے اسکرین چھوڑ دیتا ہے، تو نتیجہ پہلے سے چھپی ہوئی View پر لاگو ہو سکتا ہے۔ منسوخ ہونے والے URLSessionTask استعمال کریں اور انہیں viewDidDisappear میں ختم کریں۔
تیسری غلطی — viewDidAppear کے بجائے viewWillAppear میں ٹریکنگ۔ کچھ ڈویلپر viewWillAppear میں analytics واقعات بھیجتے ہیں، لیکن یہ غلط محرکات پیدا کرتا ہے اگر اسکرین ظاہر نہیں ہوئی (مثلاً، منسوخ شدہ pop جیسچر پر)۔ viewDidAppear اس بات کا واحد قابل اعتماد اشارہ ہے کہ صارف نے واقعی اسکرین دیکھی ہے۔
چوتھی غلطی — super بھول جانا۔ super.viewDidAppear کا کال UINavigationController، UITabBarController اور UISplitViewController کے درست کام کے لیے ضروری ہے۔ اس کے بغیر نیویگیشن اور انٹرفیس اپ ڈیٹ کے معیاری طریقہ کار ٹوٹ سکتے ہیں۔
پانچویں غلطی — viewDidLayoutSubviews کو مدنظر رکھے بغیر اسکرین کی سمت یا سائز تبدیل کرنا۔ اگر viewDidAppear میں آپ کی اینیمیشن View کے حتمی سائز پر منحصر ہے، تو یاد رکھیں کہ viewDidLayoutSubviews viewDidAppear سے پہلے کئی بار کہا جا سکتا ہے۔ اسکرین کے پہلے ظہور پر layout viewDidAppear کال ہونے سے پہلے مکمل ہو جاتا ہے، لیکن بعد میں سائز کی تبدیلیوں پر — مثلاً، ڈیوائس گھمانے پر — viewDidAppear نہیں کہا جا سکتا، اور آپ کی اینیمیشن شروع نہیں ہوگی۔ ایسے معاملات میں firstLayout فلیگ کے ساتھ viewDidLayoutSubviews استعمال کریں۔
درست نفاذ میں اینیمیشن آبجیکٹ کا حوالہ محفوظ کرنا اور اسکرین چھوڑتے وقت اسے واضح طور پر منسوخ کرنا شامل ہے۔ چھٹی غلطی — رکنے کے فلیگ کے بغیر لامتناہی اینیمیشنز شروع کرنا۔ اگر آپ viewDidAppear میں دہرائی جانے والی اینیمیشن شروع کرتے ہیں (مثلاً، پلسیٹنگ انڈیکیٹر یا گھومنے والا لوڈر)، لیکن اسے viewDidDisappear میں نہیں روکتے، تو اینیمیشن GPU وسائل استعمال کرتی رہے گی، چاہے اسکرین چھپی ہوئی ہو۔ ہمیشہ فعال اینیمیشن کا حوالہ محفوظ رکھیں اور لائف سائیکل کے متعلقہ تکمیلی طریقہ میں removeAllAnimations یا setCompletion کال کریں۔
ساتویں غلطی — سرگرمیوں کو روکنے کے لیے viewDidDisappear کو نظر انداز کرنا۔ اگر آپ نے viewDidAppear میں GPS، ایکسلرومیٹر یا جائروسکوپ کی سننا شروع کیا ہے، تو اسے viewDidDisappear میں ضرور روکیں۔ ورنہ سینسرز بیک گراؤنڈ میں کام کرتے رہیں گے، بیٹری خرچ کرتے رہیں گے، چاہے صارف بہت پہلے دوسری اسکرین پر چلا گیا ہو۔ لائف سائیکل کے متعلقہ طریقوں میں start اور stop کے جوڑے استعمال کریں — یہ ڈیوائس کے وسائل کے درست انتظام کی ضمانت دیتا ہے۔
اکثر پوچھے جانے والے سوالات
viewWillAppear ظہور کی اینیمیشن سے پہلے کہا جاتا ہے، جب اسکرین ابھی دکھائی نہیں دے رہی ہوتی۔ viewDidAppear اینیمیشن کے مکمل طور پر ختم ہونے کے بعد کہا جاتا ہے، جب اسکرین دکھائی دے رہی ہوتی ہے اور تعامل کے لیے دستیاب ہوتی ہے۔
viewDidAppear میں UIKit کی ٹرانزیشن اینیمیشن پہلے ہی مکمل ہو چکی ہوتی ہے، اور تمام رینڈرنگ وسائل آپ کے کنٹرولر کے لیے دستیاب ہوتے ہیں۔ پہلے اینیمیشن شروع کرنے سے فریم ڈراپ اور جھٹکے والا انٹرفیس ہو سکتا ہے۔
عام لائف سائیکل میں نہیں — viewDidAppear ہمیشہ viewWillAppear کے بعد آتا ہے۔ تاہم، حالت کی بحالی کے بعض منظرناموں میں نظام صرف viewDidAppear کال کر سکتا ہے۔
firstAppearance فلیگ کی جانچ شامل کریں یا کاؤنٹر اور اسکرین نام کا مجموعہ استعمال کریں۔ مثال کے طور پر، screen_view واقعہ صرف firstAppearance = true پر بھیجیں، پھر فلیگ کو ری سیٹ کریں۔
بیک گراؤنڈ سے واپسی پر UIKit دکھائی دینے والے کنٹرولر پر viewDidAppear کال کر سکتا ہے، اگر View میموری سے ان لوڈ کر دی گئی تھی۔ قابل اعتماد ٹریکنگ کے لیے AppDelegate کے نوٹیفکیشنز استعمال کریں۔
خلاصہ
ہم ایک موبائل ایپلیکیشن ٹرنکی تیار کریں گے
IT Sectr 2017 سے اسٹارٹ اپس اور کاروبار کے لیے iOS اور Android ایپلیکیشنز بناتا ہے۔ ہم آپ کو مشورہ دیں گے اور بہترین حل تجویز کریں گے۔
مزید پڑھیں