অ্যাক্টিভিটি লাইফসাইকেল

ব্যবহারকারী আপনার অ্যাপে নেভিগেট করার সময়, অ্যাপ থেকে বেরিয়ে যাওয়ার সময় এবং অ্যাপে ফিরে আসার সময়, আপনার অ্যাপের Activity ইনস্ট্যান্সগুলি তাদের লাইফসাইকেলে বিভিন্ন অবস্থার মধ্যে দিয়ে ট্রানজিশন করে। Activity ক্লাসটি বেশ কয়েকটি কলব্যাক প্রদান করে যা অ্যাক্টিভিটিকে জানতে দেয় কখন একটি স্টেট পরিবর্তিত হয় বা সিস্টেম একটি অ্যাক্টিভিটি তৈরি, বন্ধ বা পুনরায় শুরু করছে অথবা অ্যাক্টিভিটি যে প্রসেসে আছে তা ধ্বংস করছে।

লাইফসাইকেল কলব্যাক পদ্ধতির মধ্যে, ব্যবহারকারী অ্যাক্টিভিটি থেকে বেরিয়ে গেলে এবং আবার প্রবেশ করলে, আপনার অ্যাক্টিভিটি কীভাবে কাজ করবে তা আপনি ঘোষণা করতে পারবেন। যেমন, আপনি যদি কোনও স্ট্রিমিং ভিডিও প্লেয়ার তৈরি করেন, তাহলে ব্যবহারকারী অন্য কোনও অ্যাপে সুইচ করলে আপনি ভিডিওটি পজ করতে এবং নেটওয়ার্ক কানেকশন বন্ধ করতে পারেন। ব্যবহারকারী ফিরে এলে, আপনি নেটওয়ার্কে আবার কানেক্ট করতে পারেন এবং ব্যবহারকারীকে একই জায়গা থেকে ভিডিওটি আবার শুরু করতে দিতে পারেন।

প্রতিটি কলব্যাক আপনাকে নির্দিষ্ট কাজ করতে দেয় যা প্রদত্ত পরিবর্তনের জন্য উপযুক্ত। সঠিক সময়ে সঠিক কাজ করা এবং ট্রানজিশন সঠিকভাবে ম্যানেজ করার মাধ্যমে আপনার অ্যাপ আরও শক্তিশালী ও পারফর্ম্যান্স-ভিত্তিক হয়ে ওঠে। যেমন, লাইফসাইকেল কলব্যাক ভালভাবে প্রয়োগ করলে আপনার অ্যাপ নিম্নলিখিত সমস্যা এড়াতে পারবে:

• আপনার অ্যাপ ব্যবহার করার সময় ব্যবহারকারী ফোন কল রিসিভ করলে বা অন্য অ্যাপে সুইচ করলে ক্র্যাশ করা।
• ব্যবহারকারী সক্রিয়ভাবে ব্যবহার না করলেও মূল্যবান সিস্টেম রিসোর্স ব্যবহার করা।
• ব্যবহারকারী আপনার অ্যাপ ছেড়ে চলে গেলে এবং পরে ফিরে আসলে তার প্রোগ্রেস হারিয়ে যাওয়া।
• ল্যান্ডস্কেপ ও পোর্ট্রেট ওরিয়েন্টেশনের মধ্যে স্ক্রিন রোটেট করার সময় ক্র্যাশ করা বা ব্যবহারকারীর প্রোগ্রেস হারিয়ে যাওয়া।

এই ডকুমেন্টে অ্যাক্টিভিটি লাইফসাইকেল সম্পর্কে বিস্তারিত ব্যাখ্যা করা হয়েছে। ডকুমেন্টের শুরুতে লাইফসাইকেল প্যারাডাইম সম্পর্কে বর্ণনা করা হয়েছে। এরপর, এটি প্রতিটি কলব্যাক ব্যাখ্যা করে: সেগুলি এক্সিকিউট করার সময় অভ্যন্তরীণভাবে কী ঘটে এবং সেগুলি চলাকালীন আপনাকে কী বাস্তবায়ন করতে হবে।

তারপর এটি অ্যাক্টিভিটি স্টেট এবং সিস্টেমের মাধ্যমে কোনও প্রসেস বন্ধ হয়ে যাওয়ার সম্ভাবনার মধ্যে সম্পর্ক সংক্ষেপে ব্যাখ্যা করে। সবশেষে, এটি অ্যাক্টিভিটি স্ট্যাটাসের মধ্যে ট্রানজিশন সম্পর্কিত বিভিন্ন বিষয় নিয়ে আলোচনা করে।

লাইফসাইকেল ম্যানেজ করা সম্পর্কে তথ্য, যার মধ্যে পেশাদার পদ্ধতি সম্পর্কে নির্দেশিকাও অন্তর্ভুক্ত, পেতে Jetpack Compose-এ লাইফসাইকেল এবং UI স্টেট সেভ করুন দেখুন। আর্কিটেকচার কম্পোনেন্টের সাথে অ্যাক্টিভিটি ব্যবহার করে কীভাবে একটি শক্তিশালী, প্রোডাকশন-কোয়ালিটি অ্যাপ তৈরি করতে হয় তা জানতে, অ্যাপ আর্কিটেকচারের নির্দেশিকা দেখুন।

অ্যাক্টিভিটি-লাইফসাইকেল সংক্রান্ত ধারণা

অ্যাক্টিভিটি লাইফসাইকেলের বিভিন্ন পর্যায়ের মধ্যে ট্রানজিশন নেভিগেট করতে, Activity ক্লাস ছয়টি কলব্যাকের একটি কোর সেট প্রদান করে: onCreate, onStart, onResume, onPause, onStop এবং onDestroy। অ্যাক্টিভিটি নতুন অবস্থায় প্রবেশ করলে, সিস্টেম এইসব কলব্যাকের প্রত্যেকটি ইনভোক করে।

ছবি ১-এ এই প্যারাডাইমের ভিজ্যুয়াল উপস্থাপনা দেখানো হয়েছে।

ছবি ১. অ্যাক্টিভিটি লাইফসাইকেলের একটি সহজ ইলাস্ট্রেশন।

ব্যবহারকারী অ্যাক্টিভিটি থেকে বেরিয়ে আসতে শুরু করলে, সিস্টেম অ্যাক্টিভিটি বন্ধ করার জন্য মেথড কল করে। কিছু ক্ষেত্রে, অ্যাক্টিভিটি শুধুমাত্র আংশিকভাবে বন্ধ করা হয় এবং এখনও মেমরিতে থাকে, যেমন ব্যবহারকারী অন্য অ্যাপে স্যুইচ করলে। এই ক্ষেত্রে, অ্যাক্টিভিটি এখনও ফোরগ্রাউন্ডে ফিরে আসতে পারে।

ব্যবহারকারী অ্যাক্টিভিটিতে ফিরে এলে, তিনি যেখানে ছেড়েছিলেন সেখান থেকে এটি আবার শুরু হয়। কিছু ব্যতিক্রম ছাড়া, ব্যাকগ্রাউন্ডে চলাকালীন অ্যাপকে অ্যাক্টিভিটি শুরু করা থেকে সীমাবদ্ধ করা হয়।

কোনও প্রসেস এবং তার মধ্যে থাকা অ্যাক্টিভিটি বন্ধ করার সম্ভাবনা, সেই সময় অ্যাক্টিভিটির স্ট্যাটাসের উপর নির্ভর করে। স্টেট এবং ইজেকশনের প্রতি দুর্বলতার মধ্যে সম্পর্ক সম্পর্কে আরও তথ্যের জন্য, অ্যাক্টিভিটি স্টেট এবং মেমরি থেকে ইজেকশন সম্পর্কিত বিভাগটি দেখুন।

আপনার অ্যাক্টিভিটির জটিলতার উপর নির্ভর করে, আপনাকে সম্ভবত সব লাইফসাইকেল পদ্ধতি প্রয়োগ করতে হবে না। তবে, প্রতিটি নীতি বোঝা এবং ব্যবহারকারীর প্রত্যাশা অনুযায়ী অ্যাপের আচরণ বজায় রাখার জন্য সেগুলি প্রয়োগ করা গুরুত্বপূর্ণ।

Compose এবং লাইফসাইকেল

Compose-এ, onStart বা onResume-এর মতো অ্যাক্টিভিটি কলব্যাকের মধ্যে সরাসরি বিজনেস লজিক বা ম্যানুয়াল অবজারভার সেট-আপ করা এড়িয়ে চলুন। পরিবর্তে, লাইফসাইকেল-সচেতন এফেক্ট এবং স্টেট-সচেতন অবজারভার ব্যবহার করুন যা স্ক্রিনে UI-এর উপস্থিতির সাথে অটোমেটিক অ্যালাইন হয়।

• লাইফসাইকেল-অ্যাওয়ার কালেকশন: আপনার ViewModel থেকে ফ্লো ব্যবহার করতে collectAsStateWithLifecycle ব্যবহার করুন। UI যখন 'শুরু হয়েছে' স্ট্যাটাসে প্রবেশ করে তখন এই API অটোমেটিক সংগ্রহ করা শুরু করে এবং ব্যাকগ্রাউন্ডে গেলে বন্ধ হয়ে যায়, যার ফলে অপ্রয়োজনীয় রিসোর্স খরচ হওয়া আটকানো যায়। স্টেট হিসেবে ফ্লো সংগ্রহ করার পরে, লাইফসাইকেল ইভেন্ট ঘটলে কোড রান করার জন্য আপনি LifecycleEffects ব্যবহার করতে পারবেন।
• লজিকের ফ্লো: এই API ব্যবহার করে, UI কম্পোজিশন ট্রির মাধ্যমে স্বাভাবিকভাবেই লাইফসাইকেল স্টেটে প্রতিক্রিয়া জানায়, এটি নিশ্চিত করে যে ব্যবহারকারী যখন কম্পোনেন্টের সাথে সক্রিয়ভাবে ইন্টার‍্যাক্ট করছেন শুধুমাত্র তখনই বিজনেস লজিক কার্যকর হয়।

Compose ও লাইফসাইকেল সম্পর্কে আরও জানতে, Jetpack Compose-এ লাইফসাইকেল দেখুন।

লাইফসাইকেল কলব্যাক

এই বিভাগে অ্যাক্টিভিটি লাইফসাইকেল চলাকালীন ব্যবহৃত কলব্যাক পদ্ধতি সম্পর্কে ধারণাগত এবং বাস্তবায়ন সংক্রান্ত তথ্য প্রদান করা হয়েছে।

কিছু অ্যাকশন অ্যাক্টিভিটি লাইফসাইকেল মেথডের মধ্যে পড়ে। তবে, অ্যাক্টিভিটি লাইফসাইকেল মেথডের পরিবর্তে, কম্পোনেন্টে ডিপেন্ডেন্ট কম্পোনেন্টের অ্যাকশন প্রয়োগ করে এমন কোড রাখুন। এটি করতে, আপনাকে ডিপেন্ডেন্ট কম্পোনেন্টকে লাইফসাইকেল-অ্যাওয়ার করতে হবে। আপনার ডিপেন্ডেন্ট কম্পোনেন্ট কীভাবে লাইফসাইকেল-অ্যাওয়ার করবেন তা জানতে, Jetpack Compose-এ লাইফসাইকেল দেখুন।

onCreate

আপনাকে অবশ্যই এই কলব্যাক প্রয়োগ করতে হবে, যা সিস্টেম প্রথমবার অ্যাক্টিভিটি তৈরি করার সময় ফায়ার করে। অ্যাক্টিভিটি তৈরি করার সময়, অ্যাক্টিভিটি তৈরি করা হয়েছে স্ট্যাটাসে প্রবেশ করে। onCreate পদ্ধতিতে, প্রাথমিক অ্যাপ্লিকেশন স্টার্টআপ লজিক পারফর্ম করুন যা অ্যাক্টিভিটির সম্পূর্ণ লাইফসাইকেলে শুধুমাত্র একবারই ঘটে।

যেমন, আপনার onCreate-এর ইমপ্লিমেন্টেশন ডেটাকে তালিকার সাথে বাইন্ড করতে পারে, অ্যাক্টিভিটিকে ViewModel-এর সাথে যুক্ত করতে পারে এবং কিছু ক্লাস-স্কোপ ভেরিয়েবল ইনস্ট্যান্টিয়েট করতে পারে। এই পদ্ধতি savedInstanceState প্যারামিটার পায়, যা হল Bundle অবজেক্ট, এতে অ্যাক্টিভিটির আগে সেভ করা স্ট্যাটাস থাকে। অ্যাক্টিভিটি আগে কখনও না থাকলে, Bundle অবজেক্টের ভ্যালু ফাঁকা থাকে।

আপনার অ্যাক্টিভিটির লাইফসাইকেলের সাথে যুক্ত কোনও লাইফসাইকেল-অ্যাওয়ার কম্পোনেন্ট থাকলে, এটি ON_CREATE ইভেন্ট পায়। @OnLifecycleEvent-এর সাথে অ্যানোটেট করা পদ্ধতিকে কল করা হয় যাতে আপনার লাইফসাইকেল-অ্যাওয়ার কম্পোনেন্ট তৈরি করা স্ট্যাটের জন্য প্রয়োজনীয় যেকোনও সেট-আপ কোড পারফর্ম করতে পারে।

নিম্নলিখিত উদাহরণে দেখানো হয়েছে যে কীভাবে একটি Text কম্পোজেবলকে একটি ন্যূনতম অ্যাক্টিভিটিতে ইন্টিগ্রেট করতে হয়:

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

        setContent { // In here, we can call composables!
            MaterialTheme {
                Greeting(name = "compose")
            }
        }
    }
}

@Composable
fun Greeting(name: String) {
    Text(text = "Hello $name!")
}
InteroperabilityAPIsSnippets.kt

আপনার অ্যাক্টিভিটি 'তৈরি করা হয়েছে' স্ট্যাটাসে থাকে না। onCreate মেথড এক্সিকিউশন শেষ করার পরে, অ্যাক্টিভিটি শুরু হয়েছে স্ট্যাটাসে প্রবেশ করে এবং সিস্টেম onStart এবং onResume মেথড দ্রুত একের পর এক কল করে।

onStart

অ্যাক্টিভিটি শুরু হওয়ার অবস্থায় এলে, সিস্টেম onStart চালু করে। এই কলটি ব্যবহারকারীকে অ্যাক্টিভিটি দেখায় কারণ অ্যাপটি অ্যাক্টিভিটি ফোরগ্রাউন্ডে প্রবেশ করার এবং ইন্টার‍্যাক্টিভ হওয়ার জন্য প্রস্তুত হয়। যেমন, এই মেথড হল সেই জায়গা যেখানে UI বজায় রাখার কোড ইনিশিয়ালাইজ করা হয়।

অ্যাক্টিভিটি শুরু হওয়ার অবস্থায় গেলে, অ্যাক্টিভিটির লাইফসাইকেলের সাথে যুক্ত যেকোনও লাইফসাইকেল-অ্যাওয়ার কম্পোনেন্ট ON_START ইভেন্ট পায়।

onStart পদ্ধতি দ্রুত সম্পূর্ণ হয় এবং, Created স্টেটের মতো, অ্যাক্টিভিটি Started স্টেটে থাকে না। এই কলব্যাক শেষ হয়ে গেলে, অ্যাক্টিভিটি রিসিউম করা হয়েছে স্ট্যাটাসে প্রবেশ করে এবং সিস্টেম onResume পদ্ধতি চালু করে।

onResume

অ্যাক্টিভিটি আবার শুরু হওয়ার অবস্থায় এলে, এটি ফোরগ্রাউন্ডে আসে এবং সিস্টেম onResume কলব্যাক চালু করে। এই অবস্থায় অ্যাপটি ব্যবহারকারীর সাথে ইন্টার‍্যাক্ট করে। অ্যাপটি এই অবস্থায় থাকে যতক্ষণ না এমন কিছু ঘটে যা অ্যাপ থেকে ফোকাস সরিয়ে নেয়, যেমন ডিভাইসে ফোন কল আসা, ব্যবহারকারী অন্য অ্যাক্টিভিটিতে নেভিগেট করা বা ডিভাইসের স্ক্রিন বন্ধ হয়ে যাওয়া।

অ্যাক্টিভিটি Resumed স্টেটে চলে গেলে, অ্যাক্টিভিটির লাইফসাইকেলের সাথে যুক্ত লাইফসাইকেল-অ্যাওয়ার কম্পোনেন্ট ON_RESUME ইভেন্ট পায়। এখানেই লাইফসাইকেল কম্পোনেন্ট এমন যেকোনও কার্যকারিতা চালু করতে পারে যা কম্পোনেন্টটি দৃশ্যমান এবং ফোরগ্রাউন্ডে থাকাকালীন রান করতে হবে, যেমন ক্যামেরা প্রিভিউ চালু করা।

কোনও বাধা সৃষ্টিকারী ইভেন্ট ঘটলে, অ্যাক্টিভিটি পজ করা অবস্থায় চলে যায় এবং সিস্টেম onPause কলব্যাক চালু করে।

অ্যাক্টিভিটি পজ করা অবস্থা থেকে আবার শুরু করা অবস্থায় ফিরে এলে, সিস্টেম আবার onResume মেথড কল করে। এই কারণে, onPause-এর সময় রিলিজ করা কম্পোনেন্ট ইনিশিয়ালাইজ করতে এবং অ্যাক্টিভিটি Resumed অবস্থায় প্রবেশ করার সময় প্রতিবার অবশ্যই করতে হবে এমন অন্য কোনও ইনিশিয়ালাইজেশন পারফর্ম করতে onResume প্রয়োগ করুন।

এখানে লাইফসাইকেল-অ্যাওয়ার কম্পোনেন্টের একটি উদাহরণ দেওয়া হল যা ক্যামেরা অ্যাক্সেস করে যখন কম্পোনেন্টটি ON_RESUME ইভেন্ট পায়:

class CameraComponent : LifecycleObserver {
    ...
    @OnLifecycleEvent(Lifecycle.Event.ON_RESUME)
    fun initializeCamera() {
        if (camera == null) {
            getCamera()
        }
    }
    ...
}

LifecycleObserver ON_RESUME ইভেন্ট পাওয়ার পরে পূর্ববর্তী কোড ক্যামেরা শুরু করে। তবে, মাল্টি-উইন্ডো মোডে, আপনার অ্যাক্টিভিটি পজ করা অবস্থায় থাকলেও সম্পূর্ণভাবে দেখা যেতে পারে। যেমন, অ্যাপটি মাল্টি-উইন্ডো মোডে থাকলে এবং ব্যবহারকারী এমন উইন্ডোতে ট্যাপ করলে যেখানে আপনার অ্যাক্টিভিটি নেই, সেক্ষেত্রে আপনার অ্যাক্টিভিটি পজ হয়ে যায়।

আপনি যদি চান যে অ্যাপটি আবার চালু হলে (ফোরগ্রাউন্ডে দৃশ্যমান এবং সক্রিয়) তবেই ক্যামেরা সক্রিয় হোক, তাহলে আগে দেখানো ON_RESUME ইভেন্টের পরে ক্যামেরা শুরু করুন। অ্যাক্টিভিটি পজ করা থাকলেও আপনি যদি ক্যামেরা অ্যাক্টিভ রাখতে চান, যেমন মাল্টি-উইন্ডো মোডে, তাহলে ON_START ইভেন্টের পরে ক্যামেরা ইনিশিয়ালাইজ করুন।

তবে, আপনার অ্যাক্টিভিটি পজ করা থাকাকালীন ক্যামেরা অ্যাক্টিভ থাকলে, মাল্টি-উইন্ডো মোডে অন্য কোনও রিজুম করা অ্যাপে ক্যামেরা অ্যাক্সেস করা যাবে না। আপনার অ্যাক্টিভিটি পজ করা থাকলেও, কখনও কখনও ক্যামেরা চালু রাখা প্রয়োজন হয়, তবে আপনি এটি করলে, ব্যবহারকারীর সামগ্রিক অভিজ্ঞতা আসলে খারাপ হতে পারে।

এই কারণে, মাল্টি-উইন্ডো মোডের প্রসঙ্গে শেয়ার করা সিস্টেম রিসোর্সের নিয়ন্ত্রণ নেওয়ার জন্য লাইফসাইকেলের কোন অংশটি সবচেয়ে উপযুক্ত তা ভালভাবে ভেবে দেখুন। মাল্টি-উইন্ডো মোড সাপোর্ট করা সম্পর্কে আরও জানতে, মাল্টি-উইন্ডো মোড সাপোর্ট করা দেখুন।

ইনিশিয়ালাইজেশন অপারেশন পারফর্ম করার জন্য আপনি যে বিল্ড-আপ ইভেন্টই বেছে নিন না কেন, রিসোর্স রিলিজ করার জন্য সংশ্লিষ্ট লাইফসাইকেল ইভেন্ট ব্যবহার করতে ভুলবেন না। ON_START ইভেন্টের পরে আপনি কিছু শুরু করলে, ON_STOP ইভেন্টের পরে সেটি রিলিজ বা বন্ধ করুন। আপনি ON_RESUME ইভেন্টের পরে ইনিশিয়ালাইজ করলে, ON_PAUSE ইভেন্টের পরে রিলিজ করুন।

আগের কোড স্নিপেটটি ক্যামেরা ইনিশিয়ালাইজেশন কোডকে একটি লাইফসাইকেল-অ্যাওয়ার কম্পোনেন্টে রাখে। আপনি এর পরিবর্তে এই কোডটি সরাসরি অ্যাক্টিভিটি লাইফসাইকেল কলব্যাকে রাখতে পারেন, যেমন onStart এবং onStop, তবে আমরা এটি করার সুপারিশ করি না। একটি স্বাধীন, লাইফসাইকেল-সচেতন কম্পোনেন্টে এই লজিক যোগ করলে আপনি ডুপ্লিকেট কোড ছাড়াই একাধিক অ্যাক্টিভিটি জুড়ে কম্পোনেন্টটি পুনরায় ব্যবহার করতে পারবেন। লাইফসাইকেল-অ্যাওয়ার কম্পোনেন্ট কীভাবে তৈরি করতে হয় তা জানতে, Jetpack Compose-এ লাইফসাইকেল দেখুন।

onPause

সিস্টেম এই পদ্ধতিকে প্রথম ইঙ্গিত হিসেবে কল করে যে ব্যবহারকারী আপনার অ্যাক্টিভিটি ছেড়ে চলে যাচ্ছেন, যদিও এর অর্থ সবসময় এই নয় যে অ্যাক্টিভিটি ধ্বংস হয়ে যাচ্ছে। এটি ইঙ্গিত করে যে অ্যাক্টিভিটি আর ফোরগ্রাউন্ডে নেই, তবে ব্যবহারকারী মাল্টি-উইন্ডো মোডে থাকলে এটি এখনও দেখা যায়। কোনও অ্যাক্টিভিটি এই অবস্থায় আসার একাধিক কারণ থাকতে পারে:

• অ্যাপ এক্সিকিউশনে বাধা দেয় এমন কোনও ইভেন্ট, যেমন onResume কলব্যাক সম্পর্কে বিভাগে বর্ণনা করা হয়েছে, বর্তমান অ্যাক্টিভিটি পজ করে। এটি সবচেয়ে সাধারণ কেস।
• মাল্টি-উইন্ডো মোডে, যেকোনও সময়ে শুধুমাত্র একটি অ্যাপে ফোকাস থাকে এবং সিস্টেম অন্য সব অ্যাপ পজ করে দেয়।
• ডায়ালগের মতো নতুন, আংশিক-স্বচ্ছ অ্যাক্টিভিটি খুললে, এটি যে অ্যাক্টিভিটি কভার করে তা পজ হয়ে যায়। অ্যাক্টিভিটি আংশিকভাবে দেখা গেলেও ফোকাসে না থাকলে, এটি পজ করা থাকে।

কোনও অ্যাক্টিভিটি পজ করা অবস্থায় চলে গেলে, অ্যাক্টিভিটির লাইফসাইকেলের সাথে যুক্ত লাইফসাইকেল-অ্যাওয়ার কম্পোনেন্ট ON_PAUSE ইভেন্ট পায়। এখানেই লাইফসাইকেল কম্পোনেন্ট এমন যেকোনও কার্যকারিতা বন্ধ করতে পারে যা কম্পোনেন্টটি ফোরগ্রাউন্ডে না থাকার সময় চালানোর প্রয়োজন হয় না, যেমন ক্যামেরা প্রিভিউ বন্ধ করা।

Activity পজ করা অবস্থায়, যেসব অপারেশন চালিয়ে যাওয়া যাবে না বা মডারেশন সহ চালিয়ে যাওয়া যেতে পারে এবং আপনি যেগুলি শীঘ্রই আবার শুরু করতে চান, সেগুলি পজ বা অ্যাডজাস্ট করতে onPause পদ্ধতি ব্যবহার করুন।

এছাড়াও, আপনার অ্যাক্টিভিটি পজ করা থাকলে এবং ব্যবহারকারীর প্রয়োজন না হলে, সিস্টেম রিসোর্স, সেন্সর (যেমন, জিপিএস) বা ব্যাটারির আয়ুকে প্রভাবিত করে এমন যেকোনও রিসোর্স রিলিজ করার জন্য আপনি onPause পদ্ধতি ব্যবহার করতে পারেন।

তবে, onResume-এর বিভাগে যেমন উল্লেখ করা হয়েছে, অ্যাপ মাল্টি-উইন্ডো মোডে থাকলে, পজ করা অ্যাক্টিভিটি এখনও সম্পূর্ণভাবে দেখা যেতে পারে। মাল্টি-উইন্ডো মোড আরও ভালোভাবে সাপোর্ট করার জন্য UI-সম্পর্কিত রিসোর্স ও অপারেশন সম্পূর্ণভাবে রিলিজ বা অ্যাডজাস্ট করতে onPause-এর পরিবর্তে onStop ব্যবহার করার কথা বিবেচনা করুন।

ON_PAUSE ইভেন্টে LifecycleObserver-এর প্রতিক্রিয়া জানানোর নিম্নলিখিত উদাহরণটি আগের ON_RESUME ইভেন্টের উদাহরণের সাথে সম্পর্কিত, ON_RESUME ইভেন্ট পাওয়ার পরে শুরু হওয়া ক্যামেরা রিলিজ করা:

class CameraComponent : LifecycleObserver {
    ...
    @OnLifecycleEvent(Lifecycle.Event.ON_PAUSE)
    fun releaseCamera() {
        camera?.release()
        camera = null
    }
    ...
}

এই উদাহরণে, LifecycleObserver-এর মাধ্যমে ON_PAUSE ইভেন্ট পাওয়ার পরে ক্যামেরা রিলিজ কোড দেখানো হয়েছে।

onPause এক্সিকিউশন খুব সংক্ষিপ্ত এবং সেভ অপারেশন করার জন্য পর্যাপ্ত সময় নাও দিতে পারে। এই কারণে, অ্যাপ্লিকেশন বা ব্যবহারকারীর ডেটা সেভ করতে, নেটওয়ার্ক কল করতে বা ডেটাবেস ট্রানজ্যাকশন এক্সিকিউট করতে onPause ব্যবহার করবেন না। পদ্ধতি সম্পূর্ণ হওয়ার আগে এই ধরনের কাজ সম্পূর্ণ নাও হতে পারে।

পরিবর্তে, onStop-এর সময় হেভি-লোড শাটডাউন অপারেশন পারফর্ম করুন। onStop-এর সময় উপযুক্ত অপারেশন পারফর্ম করার ব্যাপারে আরও তথ্যের জন্য, পরবর্তী বিভাগ দেখুন। ডেটা সেভ করার ব্যাপারে আরও তথ্যের জন্য, স্টেট সেভ ও রিস্টোর করা সংক্রান্ত বিভাগ দেখুন।

onPause পদ্ধতি সম্পূর্ণ করার অর্থ এই নয় যে অ্যাক্টিভিটি পজ করা অবস্থা থেকে বেরিয়ে আসবে। বরং, অ্যাক্টিভিটি আবার শুরু না হওয়া পর্যন্ত অথবা ব্যবহারকারীর কাছে সম্পূর্ণ অদৃশ্য না হওয়া পর্যন্ত অ্যাক্টিভিটি এই অবস্থাতেই থাকে। অ্যাক্টিভিটি আবার শুরু হলে, সিস্টেম আরও একবার onResume কলব্যাককে আহ্বান করে।

অ্যাক্টিভিটি পজ করা অবস্থা থেকে আবার চালু করা অবস্থায় ফিরে এলে, সিস্টেম Activity ইনস্ট্যান্স মেমরিতে রেখে দেয় এবং সিস্টেম onResume ইনভোক করলে সেই ইনস্ট্যান্স রিকল করে। এই পরিস্থিতিতে, Resumed স্ট্যাটাসে পৌঁছানোর আগে কলব্যাক পদ্ধতির মাধ্যমে তৈরি করা কম্পোনেন্ট আপনাকে আবার ইনিশিয়ালাইজ করতে হবে না। অ্যাক্টিভিটি সম্পূর্ণ অদৃশ্য হয়ে গেলে, সিস্টেম onStop কল করে।

onStop

আপনার অ্যাক্টিভিটি ব্যবহারকারী আর দেখতে না পেলে, এটি বন্ধ হয়ে গেছে স্ট্যাটাসে চলে যায় এবং সিস্টেম onStop কলব্যাক চালু করে। নতুন চালু করা অ্যাক্টিভিটি সম্পূর্ণ স্ক্রিন জুড়ে থাকলে এটি হতে পারে। অ্যাক্টিভিটি চলা শেষ হলে এবং বন্ধ হওয়ার ঠিক আগে সিস্টেম onStop-কে কল করে।

অ্যাক্টিভিটি বন্ধ হয়ে গেলে, অ্যাক্টিভিটির লাইফসাইকেলের সাথে যুক্ত যেকোনও লাইফসাইকেল-অ্যাওয়ার কম্পোনেন্ট ON_STOP ইভেন্ট পায়। এখানেই লাইফসাইকেল কম্পোনেন্ট এমন যেকোনও কার্যকারিতা বন্ধ করতে পারে যা চালানোর প্রয়োজন নেই যখন কম্পোনেন্টটি স্ক্রিনে দৃশ্যমান হয় না।

onStop পদ্ধতিতে, অ্যাপটি ব্যবহারকারীকে না দেখানোর সময় প্রয়োজন নেই এমন রিসোর্স রিলিজ বা অ্যাডজাস্ট করুন। যেমন, আপনার অ্যাপ অ্যানিমেশন পজ করতে পারে অথবা সুনির্দিষ্ট থেকে অনির্দিষ্ট লোকেশন আপডেটে সুইচ করতে পারে। onPause-এর পরিবর্তে onStop ব্যবহার করার অর্থ হল, ব্যবহারকারী মাল্টি-উইন্ডো মোডে আপনার অ্যাক্টিভিটি দেখলেও, UI-সম্পর্কিত কাজ চলতে থাকে।

এছাড়াও, তুলনামূলকভাবে CPU-ইনটেনসিভ শাটডাউন অপারেশন পারফর্ম করতে onStop ব্যবহার করুন। যেমন, আপনি যদি ডেটাবেসে তথ্য সেভ করার জন্য আরও ভালো সময় খুঁজে না পান, তাহলে আপনি onStop-এর সময় তা করতে পারেন। নিম্নলিখিত উদাহরণে onStop-এর প্রয়োগ দেখানো হয়েছে যা ড্রাফ্ট নোটের কন্টেন্ট পারসিস্টেন্ট স্টোরেজে সেভ করে:

override fun onStop() {
    super.onStop()

    // Delegate the save operation to the ViewModel, which handles the
    // background thread operations (e.g., using Kotlin Coroutines and Room).
    noteViewModel.saveDraft()
}

আপনার অ্যাক্টিভিটি বন্ধ অবস্থায় প্রবেশ করলে, Activity অবজেক্টটি মেমরিতে রেসিডেন্ট হিসেবে রাখা হয়: এটি সব অবস্থা ও মেম্বার সংক্রান্ত তথ্য বজায় রাখে, কিন্তু উইন্ডো ম্যানেজারের সাথে অ্যাটাচ করা থাকে না। অ্যাক্টিভিটি আবার শুরু হলে, এটি এই তথ্য মনে করিয়ে দেয়।

বন্ধ থাকা অবস্থা থেকে, অ্যাক্টিভিটি হয় ব্যবহারকারীর সাথে ইন্টার‍্যাক্ট করার জন্য ফিরে আসে, অথবা অ্যাক্টিভিটি রান করা শেষ করে এবং চলে যায়। অ্যাক্টিভিটি ফিরে এলে, সিস্টেম onRestart চালু করে। Activity রান করা শেষ হলে, সিস্টেম onDestroy কল করে।

onDestroy

অ্যাক্টিভিটি নষ্ট হওয়ার আগে onDestroy কল করা হয়। সিস্টেম দুটি কারণে এই কলব্যাকটি আহ্বান করে:

1. অ্যাক্টিভিটি শেষ হচ্ছে, কারণ ব্যবহারকারী সম্পূর্ণভাবে অ্যাক্টিভিটি বাতিল করে দিয়েছেন অথবা অ্যাক্টিভিটিতে finish কল করা হয়েছে।
2. ডিভাইস ঘোরানো বা মাল্টি-উইন্ডো মোডে প্রবেশ করার মতো কনফিগারেশন পরিবর্তনের কারণে সিস্টেম সাময়িকভাবে অ্যাক্টিভিটি বন্ধ করে দিচ্ছে।

অ্যাক্টিভিটি ধ্বংস হয়ে যাওয়ার অবস্থায় চলে গেলে, অ্যাক্টিভিটির লাইফসাইকেলের সাথে যুক্ত লাইফসাইকেল-অ্যাওয়ার কম্পোনেন্ট ON_DESTROY ইভেন্ট পায়। Activity ধ্বংস হওয়ার আগে লাইফসাইকেল কম্পোনেন্টকে যা কিছু পরিষ্কার করতে হবে, তা এখানেই করতে হবে।

আপনার Activity কেন নষ্ট হয়ে যাচ্ছে তা নির্ধারণ করার জন্য লজিক প্রয়োগ করার পরিবর্তে, আপনার Activity-এর জন্য প্রাসঙ্গিক ভিউ ডেটা ধারণ করতে ViewModel অবজেক্ট ব্যবহার করুন। কনফিগারেশন পরিবর্তনের কারণে Activity আবার তৈরি করা হলে, ViewModel-কে কিছু করতে হবে না, কারণ এটি সংরক্ষিত থাকে এবং পরবর্তী Activity ইনস্ট্যান্সকে দেওয়া হয়।

Activity আবার তৈরি না হলে, ViewModel-এ onCleared মেথড কল করা হয়, যেখানে এটি নষ্ট হওয়ার আগে প্রয়োজনীয় যেকোনও ডেটা ক্লিন-আপ করতে পারে। আপনি isFinishing পদ্ধতির মাধ্যমে এই দুটি পরিস্থিতির মধ্যে পার্থক্য করতে পারবেন।

অ্যাক্টিভিটি শেষ হয়ে গেলে, onDestroy হল অ্যাক্টিভিটির পাওয়া চূড়ান্ত লাইফসাইকেল কলব্যাক। কনফিগারেশন পরিবর্তনের ফলে onDestroy কল করা হলে, সিস্টেম অবিলম্বে একটি নতুন অ্যাক্টিভিটি ইনস্ট্যান্স তৈরি করে এবং তারপরে নতুন কনফিগারেশনে সেই নতুন ইনস্ট্যান্সে onCreate কল করে।

onDestroy কলব্যাক সেইসব রিসোর্স রিলিজ করে যেগুলি আগের কলব্যাক রিলিজ করেনি, যেমন onStop।

অ্যাক্টিভিটি স্টেট এবং মেমরি থেকে ইজেকশন

RAM খালি করার প্রয়োজন হলে সিস্টেম প্রসেস বন্ধ করে দেয়। সিস্টেম কোনও প্রসেস বন্ধ করে দেবে কিনা তা নির্ভর করে সেই সময় প্রসেসটি কোন অবস্থায় আছে তার উপর। প্রসেসের স্ট্যাটাস, প্রসেসে চলা অ্যাক্টিভিটির স্ট্যাটাসের উপর নির্ভর করে। টেবিল ১-এ প্রসেস স্টেট, অ্যাক্টিভিটি স্টেট এবং সিস্টেমের প্রসেস বন্ধ করে দেওয়ার সম্ভাবনার মধ্যে পারস্পরিক সম্পর্ক দেখানো হয়েছে। এই সারণীটি শুধুমাত্র তখনই প্রযোজ্য হয় যদি কোনও প্রক্রিয়া অন্যান্য ধরনের অ্যাপ্লিকেশন উপাদান না চালায়।

হত্যা হওয়ার সম্ভাবনা	প্রসেসের স্ট্যাটাস	অ্যাক্টিভিটির চূড়ান্ত স্ট্যাটাস
সর্বনিম্ন	ফোরগ্রাউন্ড (ফোকাস আছে বা পেতে চলেছে)	পুনরায় শুরু করেছেন
কম	দৃশ্যমান (কোনও ফোকাস নেই)	চালু/পজ করা হয়েছে
আরও ভাল	ব্যাকগ্রাউন্ড (অদৃশ্য)	থামানো হয়েছে
সর্বোচ্চ	ফাঁকা	ধ্বংস করা হয়েছে

সারণী ১. প্রসেস লাইফসাইকেল ও অ্যাক্টিভিটি স্টেটের মধ্যে সম্পর্ক।

মেমরি খালি করার জন্য সিস্টেম কখনই সরাসরি কোনও অ্যাক্টিভিটি বন্ধ করে দেয় না। পরিবর্তে, এটি অ্যাক্টিভিটি যে প্রসেসে চলে সেটি বন্ধ করে দেয়, শুধু অ্যাক্টিভিটিই নয়, প্রসেসে চলা অন্য সবকিছুও বন্ধ করে দেয়। সিস্টেম-ইনিশিয়েটেড প্রসেস বন্ধ করার ঘটনা ঘটলে, কীভাবে আপনার অ্যাক্টিভিটির UI স্টেট প্রিজার্ভ ও রিস্টোর করবেন তা জানতে, স্টেট সেভ ও রিস্টোর করা সংক্রান্ত বিভাগ দেখুন।

ব্যবহারকারী সেটিংসের অধীনে অ্যাপ্লিকেশন ম্যানেজার ব্যবহার করে সংশ্লিষ্ট অ্যাপটি বন্ধ করার জন্য একটি প্রসেস বন্ধ করতে পারেন।

প্রসেস সম্পর্কে আরও তথ্যের জন্য, প্রসেস ও থ্রেড ওভারভিউ দেখুন।

ট্রানজিয়েন্ট UI স্টেট সেভ ও রিস্টোর করা

ব্যবহারকারী আশা করেন যে কনফিগারেশন পরিবর্তন, যেমন, রোটেশন বা মাল্টি-উইন্ডো মোডে পাল্টানোর সময়, অ্যাক্টিভিটির UI স্ট্যাটাস একই থাকবে। তবে, এই ধরনের কনফিগারেশন পরিবর্তন হলে, সিস্টেম ডিফল্ট হিসেবে অ্যাক্টিভিটি নষ্ট করে দেয়, অ্যাক্টিভিটি ইনস্ট্যান্সে স্টোর করা যেকোনও UI স্টেট মুছে দেয়।

একইভাবে, ব্যবহারকারী সাময়িকভাবে আপনার অ্যাপ থেকে অন্য অ্যাপে সুইচ করে আবার আপনার অ্যাপে ফিরে এলে UI স্টেট একই থাকবে বলে আশা করেন। তবে, ব্যবহারকারী দূরে থাকলে এবং আপনার অ্যাক্টিভিটি বন্ধ থাকলে, সিস্টেম আপনার অ্যাপ্লিকেশনের প্রসেস নষ্ট করে দিতে পারে।

সিস্টেমের সীমাবদ্ধতা অ্যাক্টিভিটি নষ্ট করে দিলে, ViewModel (জটিল বিজনেস লজিক ও স্ক্রিন স্টেটের জন্য), Jetpack Compose rememberSaveable API (হালকা UI স্টেটের জন্য) এবং/অথবা লোকাল স্টোরেজের কম্বিনেশন ব্যবহার করে ব্যবহারকারীর ট্রানজিয়েন্ট UI স্টেট সংরক্ষণ করুন। সিস্টেমের আচরণ এবং সিস্টেম-ইনিশিয়েটেড অ্যাক্টিভিটি ও প্রসেস বন্ধ করার সময় জটিল UI স্টেট ডেটা কীভাবে সবচেয়ে ভালোভাবে সংরক্ষণ করা যায় তার সাথে ব্যবহারকারীর প্রত্যাশার তুলনা সম্পর্কে আরও জানতে, UI স্টেট সেভ করুন দেখুন।

rememberSaveable অটোমেটিক কনফিগারেশন পরিবর্তন এবং সিস্টেম-ইনিশিয়েটেড প্রসেস বন্ধ করা, এই দুটি ক্ষেত্রেই টিকে থাকে। এটি করার জন্য এটি স্টেটকে আড়ালে বান্ডেল করে, যার ফলে অ্যাক্টিভিটি-লেভেল বয়লারপ্লেটের প্রয়োজন ছাড়াই একটি নিরবচ্ছিন্ন অভিজ্ঞতা প্রদান করে।

মনে রাখবেন: কনফিগারেশন পরিবর্তন, প্রয়োজন হলে অ্যাক্টিভিটি রিক্রিয়েশন কীভাবে সীমাবদ্ধ করবেন এবং Jetpack Compose-এ কনফিগারেশন পরিবর্তনের ক্ষেত্রে কীভাবে প্রতিক্রিয়া জানাবেন সেই সম্পর্কে আরও জানতে, কনফিগারেশন পরিবর্তন ম্যানেজ করুন পৃষ্ঠা দেখুন।

Instance-এর স্ট্যাটাস

এমন কিছু পরিস্থিতি আছে যেখানে অ্যাপের স্বাভাবিক আচরণের কারণে আপনার অ্যাক্টিভিটি নষ্ট হয়ে যায়, যেমন ব্যবহারকারী ফিরে যান বোতাম প্রেস করলে অথবা আপনার অ্যাক্টিভিটি finish মেথড কল করে নিজের ধ্বংসের সিগন্যাল দিলে।

ব্যবহারকারী'ফিরে যান' বোতাম প্রেস করার কারণে আপনার অ্যাক্টিভিটি নষ্ট হয়ে গেলে অথবা অ্যাক্টিভিটি নিজেই শেষ হয়ে গেলে, সিস্টেম ও ব্যবহারকারী উভয়ের কাছেই সেই Activity ইনস্ট্যান্স চিরতরে মুছে যায়। এইসব ক্ষেত্রে, ব্যবহারকারীর প্রত্যাশা সিস্টেমের আচরণের সাথে মিলে যায় এবং আপনাকে অতিরিক্ত কোনও কাজ করতে হয় না।

তবে, সিস্টেমের সীমাবদ্ধতার কারণে (যেমন, কনফিগারেশন পরিবর্তন বা মেমরি প্রেসার) সিস্টেম অ্যাক্টিভিটি নষ্ট করে দিলে, প্রকৃত Activity ইনস্ট্যান্স চলে গেলেও, সিস্টেম মনে রাখে যে এটি ছিল। ব্যবহারকারী যদি অ্যাক্টিভিটিতে ফিরে যাওয়ার চেষ্টা করেন, তাহলে সিস্টেম সেই অ্যাক্টিভিটির একটি নতুন ইনস্ট্যান্স তৈরি করে। এটি করার জন্য, সিস্টেমটি সেভ করা ডেটার একটি সেট ব্যবহার করে যা অ্যাক্টিভিটি ধ্বংস হওয়ার সময় তার অবস্থা বর্ণনা করে।

সিস্টেম আগের অবস্থায় ফিরিয়ে আনার জন্য যে সেভ করা ডেটা ব্যবহার করে তাকে ইনস্ট্যান্স স্টেট বলা হয়। এটি আসলে কী-ভ্যালু পেয়ারের একটি সংগ্রহ। ডিফল্ট হিসেবে, সিস্টেম ইনস্ট্যান্স স্টেট ব্যবহার করে আপনার UI লেআউট সম্পর্কে প্রাথমিক তথ্য সেভ করে, যেমন ব্যবহারকারীর টেক্সট ইনপুট বা স্ক্রল পজিশন।

আপনি rememberSaveable ব্যবহার করে এই সিস্টেমের আচরণে হুক করেন। আপনার অ্যাক্টিভিটি ইনস্ট্যান্স নষ্ট হয়ে আবার তৈরি হলে, rememberSaveable-এ র‌্যাপ করা যেকোনও UI স্টেট অটোমেটিক রিস্টোর হয়ে যায়, এর জন্য আপনাকে অতিরিক্ত অ্যাক্টিভিটি-লেভেল কোড লিখতে হয় না।

তবে, আপনার অ্যাক্টিভিটিতে আরও জটিল স্টেট তথ্য থাকতে পারে যা আপনি রিস্টোর করতে চান, যেমন ব্যবহারকারীর ডেটা, নেটওয়ার্ক রেসপন্স বা মেম্বার ভেরিয়েবল যা ব্যবহারকারীর অগ্রগতি ট্র্যাক করে। ইনস্ট্যান্স স্টেট মেকানিজম (এবং, এক্সটেনশন দ্বারা, rememberSaveable) সামান্য পরিমাণ ডেটার বেশি ডেটা সংরক্ষণের জন্য উপযুক্ত নয়, কারণ এটির জন্য মূল থ্রেডে সিরিয়ালাইজেশন প্রয়োজন এবং এটি সিস্টেম-প্রসেস মেমরি ব্যবহার করে।

খুব অল্প পরিমাণ ডেটার চেয়ে বেশি ডেটা সংরক্ষণ করতে, পারসিস্টেন্ট লোকাল স্টোরেজ, ViewModel ক্লাস ও কম্পোজ স্টেট হয়েস্টিং ব্যবহার করে একটি সম্মিলিত পদ্ধতি গ্রহণ করুন, যেমনটি UI স্টেট সেভ করুন-এ উল্লেখ করা হয়েছে।

rememberSaveable ব্যবহার করে সহজ, লাইটওয়েট UI স্টেট সেভ করা

আপনার অ্যাক্টিভিটি বন্ধ হতে শুরু করলে, সিস্টেম ইনস্ট্যান্স স্টেট বান্ডেলে স্টেট সংক্রান্ত তথ্য সেভ করার জন্য প্রস্তুত হয়। এই সিস্টেমের আচরণে হুক করতে, আপনি সরাসরি আপনার কম্পোজেবল ফাংশনের মধ্যে rememberSaveable ব্যবহার করেন। rememberSaveable অটোমেটিক ট্রানজিয়েন্ট UI স্টেট সেভ ও রিস্টোর করে, যেমন অ্যাক্টিভিটি রিক্রিয়েশন জুড়ে ব্যবহারকারীর টেক্সট ইনপুট বা স্ক্রল পজিশন।

কাস্টম, লাইটওয়েট স্ট্যাটাস সংক্রান্ত তথ্য (যেমন, গেমে ব্যবহারকারীর অগ্রগতি) সেভ করতে, rememberSaveable ব্যবহার করে আপনার স্ট্যাটাস ঘোষণা করুন। Compose ফ্রেমওয়ার্ক ইনস্ট্যান্স স্টেট বান্ডেলে সিরিয়ালাইজেশন ব্যাকগ্রাউন্ডে ম্যানেজ করে:

var userTypedQuery by rememberSaveable(typedQuery, stateSaver = TextFieldValue.Saver) {
    mutableStateOf(
        TextFieldValue(text = typedQuery, selection = TextRange(typedQuery.length))
    )
}
StateOverviewSnippets.kt

মনে রাখবেন: সিস্টেমের ইনস্ট্যান্স স্টেট মেকানিজম (এবং সেইজন্য rememberSaveable) ট্রিগার হয় না যখন ব্যবহারকারী স্পষ্টভাবে অ্যাক্টিভিটি বন্ধ করেন অথবা অন্যান্য ক্ষেত্রে যখন finish কল করা হয়।

ব্যবহারকারীর পছন্দ বা ডেটাবেসের জন্য ডেটার মতো স্থায়ী ডেটা সেভ করতে, আপনার অ্যাক্টিভিটি ফোরগ্রাউন্ডে থাকাকালীন উপযুক্ত সুযোগ নিন। এই ধরনের কোনও সুযোগ না থাকলে, onStop মেথড চলাকালীন পারসিস্টেন্ট ডেটা সেভ করুন।

সেভ করা ইনস্ট্যান্স স্টেট ব্যবহার করে অ্যাক্টিভিটি UI স্টেট ফিরিয়ে আনা

আপনার অ্যাক্টিভিটি আগে নষ্ট হয়ে যাওয়ার পরে আবার তৈরি করা হলে, স্ট্যাটাস অটোমেটিক রিস্টোর হয়ে যায়। আপনি rememberSaveable ব্যবহার করলে, আপনাকে কোনও স্পষ্ট রিস্টোরেশন লজিক লিখতে, নাল বান্ডেল চেক করতে বা অ্যাক্টিভিটি কলব্যাক ওভাররাইড করতে হবে না। যে কোড আপনার স্টেট শুরু ও সেভ করে, সেটি অ্যাক্টিভিটি ফিরে এলে নির্বিঘ্নে তা রিস্টোরও করে:

var userTypedQuery by rememberSaveable(typedQuery, stateSaver = TextFieldValue.Saver) {
    mutableStateOf(
        TextFieldValue(text = typedQuery, selection = TextRange(typedQuery.length))
    )
}
StateOverviewSnippets.kt

অ্যাক্টিভিটি ও নেভিগেশন

অ্যাপের লাইফটাইমে এটি এক স্ক্রিন থেকে অন্য স্ক্রিনে অনেকবার ট্রানজিশন করতে পারে, যেমন ব্যবহারকারী ডিভাইসের 'ফিরে যান' বোতামে ট্যাপ করলে বা নতুন কোনও গন্তব্য বেছে নিলে। Modern Android অ্যাপ সাধারণত সিঙ্গল-অ্যাক্টিভিটি আর্কিটেকচার ব্যবহার করে। প্রতিটি স্ক্রিনের জন্য নতুন Activity শুরু করার পরিবর্তে, আপনার অ্যাপ একটি Activity হোস্ট করে এবং সেই অ্যাক্টিভিটির মধ্যে কম্পোজেবল স্ক্রিন অদলবদল করতে Navigation কম্পোনেন্ট ব্যবহার করে।

আধুনিক, Compose-ফার্স্ট নেভিগেশন কীভাবে প্রয়োগ করতে হয় তা জানতে, Jetpack Compose Navigation 3 লাইব্রেরি-এর গাইড দেখুন।

একটি অ্যাক্টিভিটি থেকে অন্যটি শুরু করা

কোনও অ্যাক্টিভিটি চলাকালীন অন্য কোনও অ্যাক্টিভিটি শুরু করার প্রয়োজন হতে পারে। যেমন, কোনও অ্যাপকে বর্তমান স্ক্রিন থেকে নতুন স্ক্রিনে যেতে হলে, এই অ্যাক্সেসের প্রয়োজন হয়।

আপনার অ্যাক্টিভিটি, শুরু হতে চলা নতুন অ্যাক্টিভিটি থেকে কোনও ফলাফল চায় কিনা তার উপর নির্ভর করে, আপনি startActivity পদ্ধতি অথবা startActivityForResult পদ্ধতি ব্যবহার করে নতুন অ্যাক্টিভিটি শুরু করেন। যেকোনও ক্ষেত্রে, আপনি একটি Intent অবজেক্ট পাস করেন।

Intent অবজেক্টটি আপনি ঠিক যে অ্যাক্টিভিটি শুরু করতে চান তা নির্দিষ্ট করে অথবা আপনি যে ধরনের অ্যাকশন পারফর্ম করতে চান তা বর্ণনা করে। সিস্টেম আপনার জন্য উপযুক্ত অ্যাক্টিভিটি বেছে নেয়, যা অন্য কোনও অ্যাপ্লিকেশন থেকেও হতে পারে। এছাড়াও, Intent অবজেক্টে অল্প পরিমাণে ডেটা থাকতে পারে যা শুরু করা অ্যাক্টিভিটি ব্যবহার করতে পারে। Intent ক্লাস সম্পর্কে আরও তথ্যের জন্য, ইনটেন্ট এবং ইনটেন্ট ফিল্টার দেখুন।

মনে রাখবেন: Compose-এ, আমরা আপনার অ্যাপ্লিকেশন জুড়ে একটি সিঙ্গেল-অ্যাক্টিভিটি আর্কিটেকচার ব্যবহার করার সাজেস্ট করি। তবে, এটি করা সম্ভব না হলে, আপনাকে একটি অ্যাক্টিভিটি থেকে অন্যটি শুরু করতে হতে পারে।

startActivity

নতুন শুরু করা অ্যাক্টিভিটির ফলাফল দেখানোর প্রয়োজন না হলে, বর্তমান অ্যাক্টিভিটি startActivity মেথড কল করে এটি শুরু করতে পারে।

আপনার নিজের অ্যাপ্লিকেশনের মধ্যে কাজ করার সময়, আপনাকে প্রায়শই একটি পরিচিত অ্যাক্টিভিটি চালু করতে হয়। যেমন, নিম্নলিখিত কোড স্নিপেট থেকে বোঝা যায় যে কীভাবে SignInActivity নামের অ্যাক্টিভিটি লঞ্চ করতে হয়।

val context = LocalContext.current

Button(onClick = {
    val intent = Intent(context, SignInActivity::class.java)
    context.startActivity(intent)
}) {
    Text("Sign In")
}

এক্সটার্নাল অ্যাক্টিভিটি শুরু হচ্ছে

Navigation-এর মাধ্যমে ইন্টার্নাল অ্যাপ নেভিগেশন ম্যানেজ করা হলেও, আপনার Activity-কে মাঝে মাঝে অন্যান্য অ্যাক্টিভিটি শুরু করতে হবে। সাধারণত আপনি যখন কোনও নির্দিষ্ট অ্যাকশন পারফর্ম করার জন্য এক্সটার্নাল অ্যাপ ব্যবহার করতে চান, যেমন, ওয়েব ব্রাউজার খোলা, ইমেল পাঠানো বা ফটো তোলা, তখন এটি ঘটে।

এটি করার জন্য, আপনি যে ধরনের অ্যাকশন করতে চান তা বর্ণনা করতে Intent অবজেক্ট ব্যবহার করেন এবং সিস্টেম অন্য অ্যাপ্লিকেশন থেকে উপযুক্ত অ্যাক্টিভিটি লঞ্চ করে।

যেমন, আপনি যদি ব্যবহারকারীকে ইমেল মেসেজ পাঠাতে দিতে চান, তাহলে আপনি নিম্নলিখিত ইনটেন্ট তৈরি করতে পারেন:

val intent = Intent(Intent.ACTION_SEND).apply {
    putExtra(Intent.EXTRA_EMAIL, recipientArray)
}
startActivity(intent)

আপনাকে যদি কোনও এক্সটার্নাল অ্যাক্টিভিটি লঞ্চ করতে হয় এবং ফলাফল পেতে হয় (যেমন, ক্যামেরা অ্যাপকে ফটো তুলতে এবং ছবি ফেরত দিতে বলা), তাহলে পুরনো startActivityForResult কলব্যাকের পরিবর্তে আধুনিক Activity ফলাফল API ব্যবহার করুন।

অ্যাক্টিভিটি কোঅর্ডিনেট করা

একটি অ্যাক্টিভিটি অন্যটি শুরু করলে, দুটিই লাইফসাইকেল ট্রানজিশন অনুভব করে। প্রথম অ্যাক্টিভিটি কাজ করা বন্ধ করে দেয় এবং পজ করা বা বন্ধ করা অবস্থায় চলে যায়, যখন অন্য অ্যাক্টিভিটি তৈরি করা হয়। এইসব অ্যাক্টিভিটি ডিস্ক বা অন্য কোথাও সেভ করা ডেটা শেয়ার করলে, এটি বোঝা গুরুত্বপূর্ণ যে দ্বিতীয় অ্যাক্টিভিটি তৈরি হওয়ার আগে প্রথম অ্যাক্টিভিটি সম্পূর্ণভাবে বন্ধ হয় না। বরং, দ্বিতীয়টি শুরু করার প্রসেস প্রথমটি বন্ধ করার প্রসেসের সাথে ওভারল্যাপ করে।

লাইফসাইকেল কলব্যাকের ক্রম ভালভাবে সংজ্ঞায়িত করা থাকে, বিশেষত যখন দুটি অ্যাক্টিভিটি একই প্রসেসে থাকে—অন্যভাবে বলতে গেলে, একই অ্যাপে—এবং একটি অন্যটিকে শুরু করে। অ্যাক্টিভিটি A, অ্যাক্টিভিটি B শুরু করলে, যেসব অপারেশন হয় তার ক্রম এখানে দেওয়া হল:

1. অ্যাক্টিভিটি A-এর onPause পদ্ধতি এক্সিকিউট করে।
2. onCreate, onStart এবং onResume পদ্ধতি অনুসারে অ্যাক্টিভিটি B-এর পদ্ধতিগুলি চালানো হয়। অ্যাক্টিভিটি B-তে এখন ব্যবহারকারীর ফোকাস আছে।
3. স্ক্রিনে অ্যাক্টিভিটি A আর দেখা না গেলে, এর onStop পদ্ধতি রান করে।

লাইফসাইকেল কলব্যাকের এই ক্রম আপনাকে একটি অ্যাক্টিভিটি থেকে অন্য অ্যাক্টিভিটিতে তথ্য ট্রানজিশন ম্যানেজ করতে দেয়।

অতিরিক্ত রিসোর্স

অ্যাক্টিভিটি লাইফসাইকেল সম্পর্কে আরও জানতে, নিম্নলিখিত অতিরিক্ত রিসোর্স দেখুন:

কন্টেন্ট দেখে

• অ্যাক্টিভিটি লাইফসাইকেল (ভিউ)