onResume اینڈرائیڈ لائف سائیکل کا ایک طریقہ ہے جو اس وقت کال کیا جاتا ہے جب Activity یا Fragment پیش منظر میں آتا ہے اور ان پٹ فوکس حاصل کرتا ہے۔ اس حالت میں، اسکرین صارف کے ساتھ تعامل کے لیے تیار ہوتی ہے: تمام ٹچ ایونٹس، کلید دباؤ اور اشارے اس جزو کو بھیجے جاتے ہیں۔ onResume Activity کی کام کرنے والی حالت ہے، جہاں ایپلی کیشن اپنا زیادہ تر وقت گزارتی ہے۔ یہیں پر کیمرہ کھولا جاتا ہے، ویڈیو پلے بیک شروع کیا جاتا ہے، تقریر کی شناخت شروع کی جاتی ہے، اور سینسر سننے والے رجسٹر کیے جاتے ہیں جنہیں خصوصی رسائی کی ضرورت ہوتی ہے۔ مکمل Activity لائف سائیکل کے بارے میں مزید معلومات کے لیے، مضمون پڑھیں Activity Lifecycle۔
اہم نکات
onResume — Activity لائف سائیکل کا تیسرا طریقہ، onStart کے بعد کال کیا جاتا ہے، جو اشارہ کرتا ہے کہ اسکرین صارف کے ساتھ مکمل تعامل کے لیے تیار ہے۔ اس لمحے، Activity بیک اسٹیک کے اوپر ہوتی ہے، سسٹم اسے تمام ان پٹ ایونٹس بھیجتا ہے، اور ایپلی کیشن صارف کی فعال شرکت کی ضرورت والی کوئی بھی کارروائی شروع کر سکتی ہے: ویڈیو کالز، گیمز، آڈیو ریکارڈنگ، Canvas پر ڈرائنگ۔
onResume “پیش منظر کی زندگی” (foreground lifetime) کا حصہ ہے — onResume اور onPause کے درمیان کا وقفہ۔ یہ Activity کا سب سے زیادہ فعال دورانیہ ہے، جب ایپلی کیشن سب سے زیادہ وسائل استعمال کرتی ہے: ٹچ پروسیسنگ کے لیے CPU، اینیمیشن رینڈرنگ کے لیے GPU، ویڈیو کیپچر کے لیے کیمرہ اور مائیکروفون۔ لائف سائیکل کی اس سطح کو سمجھنا توانائی کی کھپت کو بہتر بنانے کے لیے اہم ہے — onResume میں کھولے گئے وسائل onPause میں فوراً بند ہونے چاہئیں۔
Google I/O 2025 کے مطابق، Activity کا فی سیشن onResume حالت میں گزارا جانے والا اوسط وقت خبروں کی ایپلی کیشنز کے لیے 2–5 منٹ اور گیمز اور میسنجر کے لیے 15–30 منٹ ہے۔ باقی تمام وقت، Activity onPause، onStop یا onDestroy حالتوں میں ہوتی ہے۔ اس کا مطلب ہے کہ خاص طور پر onResume کوڈ کو بہتر بنانا کارکردگی اور بیٹری کی زندگی میں سب سے بڑا فائدہ دیتا ہے۔
Activity میں، onResume طریقہ ہر بار کال کیا جاتا ہے جب اسکرین ان پٹ فوکس حاصل کرتی ہے — پہلی بار لانچ کرنے پر، کسی دوسری Activity سے واپسی پر، ڈائیلاگ بند کرنے پر، ڈیوائس انلاک کرنے پر۔ یہ ایک “گرم” طریقہ ہے جو فی سیشن کئی بار کال کیا جا سکتا ہے، اور اس کا نفاذ جتنا ممکن ہو ہلکا ہونا چاہیے۔
class CameraActivity : AppCompatActivity() {
private var cameraProvider: ProcessCameraProvider? = null
private var preview: Preview? = null
override fun onResume() {
super.onResume()
val cameraProviderFuture = ProcessCameraProvider.getInstance(this)
cameraProviderFuture.addListener({
cameraProvider = cameraProviderFuture.get()
val cameraSelector = CameraSelector.DEFAULT_BACK_CAMERA
preview = Preview.Builder().build().also {
it.setSurfaceProvider(binding?.viewFinder?.surfaceProvider)
}
try {
cameraProvider?.unbindAll()
cameraProvider?.bindToLifecycle(
this, cameraSelector, preview
)
} catch (e: Exception) {
Log.e("Camera", "Failed to bind camera", e)
}
}, ContextCompact.getMainExecutor(this))
}
override fun onPause() {
super.onPause()
cameraProvider?.unbindAll()
preview = null
}
}
CameraX کی مثال onResume/onPause کے کلاسک استعمال کو ظاہر کرتی ہے: کیمرہ ایک خصوصی وسیلہ ہے جسے ایک وقت میں صرف ایک ایپلی کیشن استعمال کر سکتی ہے۔ bindToLifecycle کے ذریعے کیمرہ کو لائف سائیکل سے باندھنا onPause میں کیمرہ کو خود بخود بند کر دیتا ہے، لیکن واضح unbindAll کال فوری رہائی کی ضمانت دیتا ہے۔ Activities کے درمیان سوئچ کرتے وقت یہ خاص طور پر اہم ہے: کیمرہ کو اس سے پہلے آزاد کیا جانا چاہیے کہ کوئی دوسری Activity اسے کھولنے کی کوشش کرے۔
Fragment میں onResume اس Activity کے onResume حاصل کرنے کے بعد کال کیا جاتا ہے جس میں وہ موجود ہے۔ تاہم، FragmentManager اور ViewPager کی خصوصیات کی وجہ سے، Fragment کے لیے onResume کال کا وقت Activity کے مقابلے میں تاخیر کا شکار ہو سکتا ہے۔ مثال کے طور پر، offscreenPageLimit = 1 والے ViewPager میں Fragment کو onResume صرف اس وقت ملتا ہے جب یہ موجودہ صفحہ بن جائے، Activity شروع ہونے پر نہیں۔
class VideoPlayerFragment : Fragment() {
private var exoPlayer: ExoPlayer? = null
override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
super.onViewCreated(view, savedInstanceState)
exoPlayer = ExoPlayer.Builder(requireContext()).build()
binding?.playerView?.player = exoPlayer
}
override fun onResume() {
super.onResume()
exoPlayer?.play()
if (userVisibleHint) {
startBiometricAuth()
}
}
override fun onPause() {
exoPlayer?.pause()
stopBiometricAuth()
super.onPause()
}
}
Fragment.onResume میں userVisibleHint جانچ ViewPager کے لیے متعلقہ ہے: Fragment onResume حاصل کر سکتا ہے لیکن پڑوسی صفحہ سے چھپا ہوا ہو سکتا ہے (مثال کے طور پر، متحرک منتقلی کے دوران)۔ ایسے معاملات میں، مرئیت کی جانچ کیے بغیر onResume میں ویڈیو یا بایومیٹرکس شروع کرنا غیر متوقع رویے کا باعث بنے گا۔ Fragment 1.5.0 سے، ViewPager2 میں فریگمنٹس کے لائف سائیکل کے عین مطابق کنٹرول کے لیے FragmentTransaction.setMaxLifecycle() استعمال کرنے کی سفارش کی جاتی ہے۔
ڈویلپر اکثر onStart اور onResume کو الجھاتے ہیں، کوڈ کو غلط طریقہ میں رکھتے ہیں۔ بنیادی اصول: onStart — ان وسائل کے لیے جو مرئیت کے دوران کام کرتے ہیں؛ onResume — ان وسائل کے لیے جنہیں ان پٹ فوکس کی ضرورت ہوتی ہے۔ آئیے مخصوص منظرناموں اور صحیح طریقہ کے انتخاب کو دیکھتے ہیں۔
| کارروائی | طریقہ | استدلال |
|---|---|---|
| جیو لوکیشن سبسکرپشن | onStart / onStop | GPS جزوی مرئیت پر کام کر سکتا ہے |
| کیمرہ کھولنا | onResume / onPause | کیمرہ ایک خصوصی وسیلہ ہے |
| BroadcastReceiver | onStart / onStop | سسٹم ایونٹس کو فوکس کی ضرورت نہیں |
| ویڈیو پلے بیک | onResume / onPause | ویڈیو صارف کو دکھائی دینی چاہیے |
| بلوٹوتھ اسکیننگ | onStart / onStop | اسکیننگ پس منظر میں چل سکتی ہے |
| وائس ریکارڈر (MediaRecorder) | onResume / onPause | ریکارڈنگ کے لیے فعال UI ضروری ہے |
| سینسر سننے والے | onResume / onPause | گیمز اور اشاروں کے لیے سینسر |
| ڈیٹا اپ ڈیٹ | onStart | ظاہر ہونے پر تازہ ڈیٹا ضروری |
ایک عملی اصول: اگر کوئی کارروائی ڈائیلاگ ظاہر ہونے پر روک دی جانی چاہیے — onResume/onPause استعمال کریں۔ اگر کوئی کارروائی اسکرین کے جزوی طور پر ڈھکے ہونے پر بھی جاری رہ سکتی ہے — onStart/onStop استعمال کریں۔ مثال کے طور پر، ویڈیو پلیئر کو ڈائیلاگ کھلنے پر ویڈیو روک دینی چاہیے (onPause)، جبکہ جیو لوکیشن اپ ڈیٹ جاری رکھ سکتی ہے (onStart میں رہتی ہے)۔
خصوصی وسائل ڈیوائس کے وہ اجزاء ہیں جو ایک مخصوص وقت میں صرف ایک ایپلی کیشن استعمال کر سکتی ہے۔ کیمرہ، مائیکروفون، ویڈیو آؤٹ پٹ (MediaProjection)، پڑھنے کے موڈ میں NFC اڈاپٹر، لوازماتی موڈ میں USB ڈیوائسز — یہ تمام وسائل onResume میں کھولے جانے چاہئیں اور onPause میں آزاد کیے جانے چاہئیں۔
MediaRecorder آڈیو اور ویڈیو ریکارڈ کرنے کے لیے استعمال ہوتا ہے۔ اجازت کی درخواستیں اور MediaRecorder کی تیاری onCreate میں کی جاتی ہے، جبکہ ریکارڈنگ onResume میں شروع ہوتی ہے۔ اگر صارف کسی دوسری ایپلی کیشن پر سوئچ کرتا ہے، onPause ریکارڈنگ روک دیتا ہے اور onResume اسے دوبارہ شروع کرتا ہے۔ یہ وائس ریکارڈرز اور ویڈیو ریکارڈنگ ایپلی کیشنز کے لیے معیاری رویہ ہے۔
private var mediaRecorder: MediaRecorder? = null
private var isRecording = false
override fun onResume() {
super.onResume()
if (isRecording) {
mediaRecorder?.resume()
}
}
override fun onPause() {
if (isRecording) {
mediaRecorder?.pause()
}
super.onPause()
}
بایومیٹرک تصدیق (BiometricPrompt) صرف اس وقت کال کی جانی چاہیے جب Activity onResume میں ہو۔ اگر اسے onCreate یا onStart میں کال کیا جائے تو بایومیٹری ڈائیلاگ Activity کے ابتدائیہ مکمل کرنے سے پہلے ظاہر ہو سکتا ہے، جس کے نتیجے میں غلط پروسیسنگ ہو گی۔ onResume میں کال کرنا اس بات کو یقینی بناتا ہے کہ بایومیٹری ونڈو صحیح سیاق و سباق میں دکھائی جائے۔
آئیے تجارتی منصوبوں میں استعمال ہونے والے onResume کے ساتھ کام کرنے کے تین ثابت شدہ نمونوں کو دیکھتے ہیں: غیرفعالیتی ٹائمر ری سیٹ، دکھائی دینے والے ڈیٹا کی اپ ڈیٹ، اور Jetpack Navigation کے ساتھ انضمام۔
حساس ڈیٹا والی ایپلی کیشنز میں (بینکنگ، میڈیکل ریکارڈ)، onResume خودکار لاگ آؤٹ ٹائمر ری سیٹ کرنے کے لیے استعمال ہوتا ہے۔ اگر صارف ایپلی کیشن کے ساتھ فعال طور پر تعامل کر رہا ہے، تو ہر اسکرین منتقلی پر onResume کال کیا جاتا ہے اور ٹائمر ری سیٹ ہو جاتا ہے۔ اگر صارف ایپلی کیشن کو چھوٹا کرتا ہے، onPause ٹائمر روک دیتا ہے، اور واپسی پر onResume یا تو اسے ری سیٹ کرتا ہے یا دوبارہ تصدیق کی درخواست کرتا ہے۔
ایک فہرست جسے ہر بار اسکرین پر واپس آنے پر تازہ ترین ڈیٹا دکھانا چاہیے، onResume میں اپ ڈیٹ کی جاتی ہے۔ مثال کے طور پر، اگر صارف نے کسی دوسری Activity میں نیا اندراج بنایا اور واپس آیا، onResume مقامی ڈیٹابیس یا ViewModel کیشے سے فہرست دوبارہ لوڈ کرتا ہے۔ یہ دستی notifyDataSetChanged کال کے بغیر ڈیٹا کی مستقل مزاجی کو یقینی بناتا ہے۔
override fun onResume() {
super.onResume()
// ActivityResultLauncher نے نتیجہ لوٹایا — فہرست اپ ڈیٹ ہو رہی ہے
viewModel.refreshList()
// غیرفعالیتی ٹائمر ری سیٹ
inactivityTimer.reset()
}
Jetpack Navigation میں، فریگمنٹ کا onResume ہر بار کال کیا جاتا ہے جب آپ بیک نیویگیشن کے ذریعے اس پر واپس آتے ہیں۔ یہ خاصیت UI حالت ری سیٹ کرنے کے لیے استعمال ہوتی ہے: کی بورڈ چھپانا، تلاش کے فیلڈز صاف کرنا، ٹول بار کا عنوان اپ ڈیٹ کرنا۔ OnBackPressedCallback onResume کے ساتھ مل کر کوڈ کی تکرار کے بغیر نیویگیشن پر مکمل کنٹرول دیتا ہے۔
اکثر پوچھے گئے سوالات
onStart — اسکرین دکھائی دیتی ہے۔ onResume — اسکرین فعال اور تعامل کے لیے تیار ہے۔ تصور کریں: آپ ٹی وی دیکھ رہے ہیں (onStart)، لیکن آپ ریموٹ اٹھاتے ہیں (onResume)۔ ٹی وی ہمیشہ دکھائی دیتا ہے، لیکن تعامل صرف ریموٹ سے شروع ہوتا ہے۔ اگر کوئی ٹی وی کو پردے سے ڈھانپ دیتا ہے — اسکرین دکھائی دینا بند ہو جاتی ہے (onStop)۔ اگر کوئی آپ سے ریموٹ لے لیتا ہے — تعامل رک جاتا ہے (onPause)، لیکن ٹی وی اب بھی دکھائی دیتا ہے۔
onResume ہر بار کال کیا جاتا ہے جب Activity ان پٹ فوکس حاصل کرتی ہے۔ کم از کم ایک بار (لانچ پر)۔ زیادہ سے زیادہ استعمال کے منظرناموں پر منحصر ہے: اسکرینوں کے درمیان سوئچ کرنا، ڈائیلاگ کھولنا، ڈیوائس کو جلدی لاک اور انلاک کرنا — ایسا ہر منظرنامہ اسکرین پر واپسی پر onResume کال کرتا ہے۔
کیمرہ ایک خصوصی وسیلہ ہے جو ایک وقت میں صرف ایک ایپلی کیشن کے لیے دستیاب ہے۔ اگر آپ onCreate یا onStart میں کیمرہ کھولتے ہیں، تو یہ دوسری ایپلی کیشنز کے لیے اس وقت بھی مقفل رہے گا جب آپ کی ایپلی کیشن غیر فعال ہو۔ onResume اس بات کی ضمانت دیتا ہے کہ کیمرہ صرف اس وقت کھلا ہے جب Activity پیش منظر میں ہے، اور onPause اسے فوراً بند کر دیتا ہے۔ یہ اینڈرائیڈ ڈیویلپمنٹ کا ایک معیار ہے، جو CameraX اور Camera2 API کی دستاویزات میں قائم کیا گیا ہے۔
ہاں، onResume نہیں ہو سکتا اگر کسی Activity کو ظاہر ہونے کے فوراً بعد کسی دوسری Activity سے ڈھانپ دیا جائے۔ مثال کے طور پر، Activity A، onCreate یا onStart طریقہ میں Activity B شروع کرتی ہے۔ اس صورت میں، A onResume کو چھوڑتے ہوئے onStart → onPause → onStop حاصل کرتی ہے۔ سسٹم onResume کال نہیں کرتا کیونکہ Activity A کو کبھی ان پٹ فوکس نہیں ملا۔
onResume میں، لمبی ہم آہنگ کارروائیاں نہیں کرنی چاہئیں: نیٹ ورک سے بڑا ڈیٹا لوڈ کرنا، پیچیدہ SQL سوالات، تصویری پروسیسنگ۔ onResume UI تھریڈ پر چلتا ہے، اور 100–200 ms سے زیادہ کی کوئی بھی رکاوٹ انٹرفیس کی ردعمل میں تاخیر کا سبب بنتی ہے۔ تمام بھاری کارروائیاں غیر ہم آہنگ ہونی چاہئیں — coroutines، RxJava یا WorkManager کے ذریعے۔ نیز، بغیر جانچ کے onResume میں finish() کال کرنا تجویز نہیں کیا جاتا — یہ دوبارہ تخلیق کے لامتناہی لوپ کا باعث بن سکتا ہے۔
خلاصہ
ہم ایک موبائل ایپلیکیشن ٹرنکی تیار کریں گے
IT Sectr 2017 سے اسٹارٹ اپس اور کاروبار کے لیے iOS اور Android ایپلیکیشنز بناتا ہے۔ ہم آپ کو مشورہ دیں گے اور بہترین حل تجویز کریں گے۔
مزید پڑھیں