onCreate — یہ کیا ہے، Android میں Activity کا آغاز

Android میں onCreate کیا ہے

onCreate ایک کال بیک طریقہ ہے جسے Android Activity یا Fragment کی نئی انسٹنس بناتے وقت بلاتا ہے۔ یہ یوزر سکرین کوڈ میں پہلا داخلی نقطہ ہے؛ onCreate بلائے جانے سے پہلے کوئی یوزر کوڈ نہیں چلتا۔ سیسٹم طریقے میں ایک Bundle پیرامیٹر پاس کرتا ہے، جس میں پہلے سے محفوظ کردہ ڈیٹا (دوبارہ تخلیق پر) یا null (پہلی لائنچ پر) ہوتا ہے۔

onCreate طریقہ کلاس android.app.Activity اور کلاس androidx.fragment.app.Fragment میں تعریف کیا گیا ہے۔ دونوں قسمیں ایک جیسے کام کرتے ہیں: کمپونینٹ کا آغاز، UI کی ترتیب اور کیفیت کی بحالی۔ تاہم، مختص نفاذ مختلف ہے — Activity لی آؤٹ لوڈ کرنے کے لیے setContentView استعمال کرتی ہے، جبکہ Fragment onCreateView کے ذریعے ایک View واپس کرتا ہے۔ ڈیولپر کو Activity میں کم سے کم onCreate کو اووررائیڈ کرنا چاہیے — اس کے بغیر، Android سکرین ڈسپلے نہیں کر سکتا۔

onCreate ایک Activity انسٹنس کے مکمل لائف سائیکل میں سختی سے ایک بار بلایا جاتا ہے۔ سکرین گھومنے پر بھی، ایک نئی Activity انسٹنس پځڄلے انسٹنس سے Bundle کے ساتھ ایک نئا onCreate کال وصول کرتی ہے۔ یہ onCreate کو ایک بار کے آغاز کے لیے موزون مقام بناتا ہے: ڈیٹا لوڈ کرنا، اڈاپٹرز بنانا، Dagger یا Hilt کے ذریعے DI کمپونینٹز ترتیب دینا۔

Activity میں onCreate

Activity میں، onCreate طریقہ چار اہم کام کرتا ہے: لی آؤٹ مارک اپ لوڈ کرنا، View اجزاء کو آغاز کرنا، Bundle سے کیفیت بحال کرنا اور بنیادی ایونٹ ہینڈلر ترتیب دینا۔ onCreate میں لازمی کم از کم کوڈ super.onCreate(savedInstanceState) اور setContentView(R.layout.activity_main) کو بلانا ہے۔

class MainActivity : AppCompatActivity() {
    private var binding: ActivityMainBinding? = null

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)

        // ViewBinding — findViewById کا ایک جدید متبادل
        binding = ActivityMainBinding.inflate(layoutInflater)
        setContentView(binding?.root)

        // binding کا استعمال کرتے ہوئے آغاز
        binding?.apply {
            welcomeText.text = getString(R.string.welcome)
            startButton.setOnClickListener { startGame() }
        }

        // کیفیت کی بحالی
        if (savedInstanceState != null) {
            score = savedInstanceState.getInt("score", 0)
            binding?.scoreText?.text = score.toString()
        }
    }
}

جدید مشق findViewById کے بجائے ViewBinding استعمال کرتی ہے۔ ViewBinding کمپائل ٹائم پر کلاس ActivityMainBinding تیار کرتا ہے، جو غلط IDs سے خطا کو ختم کرتا ہے اور بوائلرپلیٹ کوڈ کو کم کرتا ہے۔ Google Android Studio 3.6 سے شروع کرتے ہوئے Activity اور Fragment میں View تک رسائی کا معیاری طریقہ کے طور پر ViewBinding کی سفارش کرتا ہے۔

onCreate میں کاروائی کا ترتیب سخت ہونا چاہیے: پہلے super، پھر setContentView، پھر باقی سب کچھ۔ setContentView سے پہلے findViewById کو بلانا null واپس کرتا ہے — لی آؤٹ ابھی تک لوڈ نہیں ہوئی، اور View اجزاء درجہ بندی میں موجود نہیں ہیں۔ یہ شروعاتی Android ڈیولپرز کی سب سے عام غلطیوں میں سے ایک ہے۔

Fragment میں onCreate

Fragment میں onCreate Activity سے مختلف ہے: یہاں setContentView نہیں بلایا جاتا، صرف UI سے غیر متعلق ڈیٹا کا آغاز کیا جاتا ہے۔ Fragment کمپونینٹ تخلیق اور View تخلیق کو دو علاحدہ طریقوں میں تقسیم کرتا ہے: onCreate (ایک بار بلایا جاتا ہے) اور onCreateView (جب بھی View بنائی یا دوبارہ بنائی جاتی ہے تب بلایا جاتا ہے)۔

class UserListFragment : Fragment() {
    private lateinit var viewModel: UserViewModel
    private var binding: FragmentUserListBinding? = null

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)

        // ViewModel کا آغاز — View کی دوبارہ تخلیق سے بچ جاتا ہے
        viewModel = ViewModelProvider(this)[UserViewModel::class.java]

        // FragmentManager سے ارگومنٹس
        arguments?.let {
            viewModel.loadUser(it.getString("user_id") ?: "")
        }

        // گھومنے پر محفوظ کرنا
        retainInstance = true
    }

    override fun onCreateView(
        inflater: LayoutInflater,
        container: ViewGroup?,
        savedInstanceState: Bundle?
    ): View {
        binding = FragmentUserListBinding.inflate(inflater, container, false)
        return binding!!.root
    }
}

Activity اور Fragment onCreate کے درمیان بنیادی فرق: Fragment میں onCreate میں View سے متعلق کوڈ نہیں ہونا چاہیے، کیونکہ View تباہ اور دوبارہ بنائی جا سکتی ہے (مثال کے طور پر، ViewPager ٹیب کی تبادلہ کرتے وقت)، جبکہ onCreate صرف ایک بار بلایا جاتا ہے۔ ڈیٹا لوڈینگ، ViewModel سیٹ اپ اور اڈاپٹر آغاز onCreate کے کام ہیں، جبکہ View کو باندھنا onViewCreated کا کام ہے۔

savedInstanceState اور کیفیت کی بحالی

onCreate میں savedInstanceState پیرامیٹر Activity یا Fragment کی عارضی کیفیت کو محفوظ اور بحال کرنے کا ایک میکانزم ہے۔ جب سیسٹم Activity کو تباہ کرتا ہے (سکرین گھومنا، میموری کی کمی)، یہ onSaveInstanceState() کو بلاتا ہے، جہاں ڈیولپر Bundle میں کی-ویلیو اینٹری ڈالتا ہے۔ جب ایک نئی انسٹنس بنائی جاتی ہے، تو یہ Bundle onCreate میں واپس کیا جاتا ہے۔

Bundle مندرجہ ذیل ڈیٹا اقسام کی حمایت کرتا ہے: String, Integer, Boolean, Long, Float, Double، ان کے ارے، اور Parcelable اور Serializable آبجیکٹ۔ پیچیدہ آبجیکٹ کے لیے، Parcelable استعمال کیا جاتا ہے — Android کے لیے ایک زیادہ کارگر سیریلائیزیشن میکانزم۔ Bundle کا حجم تقریبناں 500 KB تک محدود ہے — حد سے تجاوز کرنے سے TransactionTooLargeException ہوتا ہے۔

companion object {
    private const val KEY_USER_NAME = "user_name"
    private const val KEY_SCORE = "score"
}

override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)
    setContentView(R.layout.activity_game)

    if (savedInstanceState != null) {
        userName = savedInstanceState.getString(KEY_USER_NAME) ?: ""
        currentScore = savedInstanceState.getInt(KEY_SCORE)
    }
}

override fun onSaveInstanceState(outState: Bundle) {
    super.onSaveInstanceState(outState)
    outState.putString(KEY_USER_NAME, userName)
    outState.putInt(KEY_SCORE, currentScore)
}

یہ سمجھنا اہم ہے: onSaveInstanceState تب نہیں بلایا جاتا جب یوزر finish() یا واپس بٹن کے ذریعے Activity کو واضح طور پر بند کرتا ہے۔ سیسٹم سمجھتا ہے کہ یوزر شعوری طور پر کام ختم کر رہا ہے اور کیفیت محفوظ کرنے کی ضرورت نہیں ہے۔ لہذا، آپ طویل مدت کے ڈیٹا ذخیرہ کے لیے صرف savedInstanceState پر انحصار نہیں کر سکتے — Room، DataStore یا SharedPreferences استعمال کریں۔

onCreate کا وقت اور محدودیتیں

onCreate مرکزی (UI) ثریڈ پر عمل کرتا ہے، اور سیسٹم Activity کو سکرین پر ڈسپلے کرنے سے پہلے اس کے مکمل ہونے کا انتظار کرتا ہے۔ اگر onCreate میں 5 سیکنڈ سے زیادہ وقت لگتا ہے، تو سیسٹم ایک ANR (Application Not Responding) ڈائیالوگ ڈکھاتا ہے اور یوزر کو ایپلیکیشن بند کرنے کا اختیار دیتا ہے۔ لمبے آپریشن، جیسے نیٹورک سے ڈیٹا لوڈ کرنا یا ڈیٹابیس سے پڑھنا، کو بےک گراؤنڈ ثریڈ میں لے جانا چاہیے۔

Google Android Performance (2025) کی سفارشات کے مطابق، درمیانے درجے کے آلات پر onCreate کو 1 سیکنڈ سے کم میں مکمل ہونا چاہیے۔ اسے حاصل کرنے کے لیے: سست آغاز (Kotlin میں lazy delegate) استعمال کریں، بھاری ڈیٹا لوڈینگ کو onResume یا کوروٹینز پر موختور کریں، شاید ہی استعمال ہونے والے UI کمپونینٹز کے لیے ViewStub لاگو کریں، اور Android Vitals کے ذریعے آغاز کا وقت پروفائل کریں۔

override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)
    setContentView(R.layout.activity_main)

    // سست آغاز — آبجیکٹ صرف پہلی رسائی پر بنتا ہے
    val heavyData by lazy {
        HeavyDataLoader.load()
    }

    // lifecycleScope کے ذریعے بےک گراؤنڈ ثریڈ میں ڈیٹا لوڈ کرنا
    lifecycleScope.launch(Dispatchers.IO) {
        val users = userDao.getAllUsers()
        withContext(Dispatchers.Main) {
            adapter.submitList(users)
        }
    }
}

پروفائلنگ آلات: Android Studio Profiler (CPU ٹیب) ہر طریقے کا سطیح عمل کا وقت ڈکھاتا ہے۔ Android Vitals (Google Play Console) میں، آپ «کولڈ سٹارٹ ٹائم» میٹرک ٹریک کر سکتے ہیں — اگر آپکے Activity کا onCreate 500 ms سے تجاوز کرتا ہے، تو کنسول اسے کارکردگی کا مسئلہ قرار دیتا ہے۔ IT Sectr میں، ہم CI پائپ لائن میں ہر Activity کے آغاز کے وقت کے خودکار کنٹرول کے لیے Macrobenchmark ٹیسٹ استعمال کرتے ہیں۔

ViewModel اور onCreate

ViewModel onCreate میں اس ڈیٹا کو آغاز کرنے کا بہترین طریقہ ہے جو سکرین گھومنے سے بچ سکتا ہے۔ ViewModel onCreate میں ViewModelProvider کے ذریعے بنایا جاتا ہے اور کنفگریشن تبدیلیوں پر خودکار طور پر محفوظ رہتا ہے۔ گھومنے کے بعد Activity دوبارہ بنائی جاتی ہے، تو ViewModel میموری میں رہتا ہے، اور onCreate بغیر ڈیٹا کے نقصان کے وہی ViewModel وصول کرتا ہے۔

override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)
    setContentView(R.layout.activity_profile)

    // ViewModel ایک بار بنتا ہے اور کنفگریشن تبدیلیوں سے بچ جاتا ہے
    val viewModel: ProfileViewModel =
        ViewModelProvider(this)[ProfileViewModel::class.java]

    // LiveData کا مشاہدہ — ڈیٹا بدلنے پر UI خودکار طور پر اپڈیٹ ہوتا ہے
    viewModel.user.observe(this) { user ->
        binding?.userName?.text = user.name
        binding?.userEmail?.text = user.email
    }

    // اگر ViewModel ابھی بنایا گیا ہو تو ڈیٹا لوڈ کرنا
    if (savedInstanceState == null) {
        viewModel.loadProfile(userId)
    }
}

ViewModel + LiveData/StateFlow کا امتزاج Bundle میں دستی بچت کے بغیر سکرین گھومنے کے مسئلے کو حل کرتا ہے۔ ViewModel میموری میں ڈیٹا ذخیرہ کرتا ہے، LiveData دوبارہ تخلیق پر Activity کو خودکار طور پر دوبارہ سبسکرائیب کرتا ہے، اور StateFlow (Kotlin Coroutines سے) کوروٹین کی حمایت کے ساتھ ری اکٹیویٹی کا اضافہ کرتا ہے۔ Google کے Guide to App Architecture میں سفارش کردہ معیاری آرکی ٹیکچر یہی ہے۔

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

تجربہ کار ڈیولپر بھی onCreate میں معمولی غلطیاں کرتے ہیں۔ آئیے پانچ سب سے عام مسائل اور ان سے بچنے کے طریقے پر غور کریں۔

setContentView سے پہلے View کے ساتھ کام کرنا

سب سے عام غلطی setContentView کو بلانے سے پہلے findViewById کے ذریعے View تلاش کرنے کی کوشش کرنا ہے۔ تمام View اجزاء لی آؤٹ انفلیشن کے وقت بنتے ہیں، لہذا setContentView سے پہلے کوئی بھی findViewById کال null واپس کرتا ہے اور View استعمال کرنے کی کوشش پر NullPointerException کا سبب بنتا ہے۔ حل: سخت ترتیب — پہلے super، پھر setContentView، پھر findViewById یا ViewBinding۔

لمبے آپریشنوں سے UI ثریڈ کو بلاک کرنا

نیٹورک سے ڈیٹا لوڈ کرنا، ڈیٹابیس سے پڑھنا یا بڑے ارے کو سیدھے onCreate میں پروسیس کرنا پہلے فرےم کی رینڈرنگ کو بلاک کرتا ہے۔ یوزر کو onCreate مکمل ہونے تک ایک کالی سکرین نظر آتی ہے، جو ایپلیکیشن کی رفتار کے ادراک کو خراب کرتا ہے۔ حل: غیر هم آهنگ آپریشنوں کے لیے lifecycleScope.launch استعمال کریں، لوڈنگ مکمل ہونے تک ایک کنکال (UI placeholder) ڈکھائیں۔

savedInstanceState کو نظر انداز کرنا

اگر آپ سکرین گھومنے پر Bundle سے کیفیت بحال نہیں کرتے، تو یوزر سارے غیر محفوظ انپٹ کو کھو دیتا ہے: فارم فیلڈز میں ٹیکسٹ، اسکرول پوزیشن، منتخب آئٹمز۔ حل: ڈیٹا بحال کرنے کے لیے ہمیشہ onCreate میں savedInstanceState != null چک کریں، چاہے کیفیت کے نقصان کا امکان کم ہی لگے۔

گمنام کلاسوں کے ذریعے میموری لیک

onCreate میں گمنام کلاسیں اور لیمبڈا تباہی کے بعد بھی ایک Activity کا حوالہ اضمری طور پر تھام سکتے ہیں۔ مثال کے طور پر، onCreate میں بنایا گیا Handler Activity تباہ ہونے کے بعد بھی موخر کاموں کو انجام دیتا رہتا ہے۔ حل: LifecycleObserver، ViewModel اور lifecycleScope استعمال کریں، جو تباہی پر خودکار طور پر کاموں کو منسوخ کرتے ہیں۔

Fragment.onCreate میں ضرورت سے زیادہ آگاز

Fragment.onCreate میں View کو آغاز کرنا ایک منطقی غلطی ہے، کیونکہ View کو onCreate ڨو بلائے دوبارہ تخلیق کیا جا سکتا ہے۔ اگر آپ onCreate میں ایک سننے والا لگاتے ہیں لیکن View کو onCreateView میں باندھتے ہیں، تو دوبارہ تخلیق پر سننے والا پرانی View پر رہ جائے گا۔ حل: تمام View-سے متعلق کام onViewCreated میں کریں، onCreate کو صرف ڈیٹا لیر کے آغاز کے لیے چھوڑ دیں۔