কার্যকলাপের অবস্থার পরিবর্তন

বিভিন্ন ঘটনা, যার মধ্যে কিছু ব্যবহারকারী-চালিত এবং কিছু সিস্টেম-চালিত, একটি Activity এক অবস্থা থেকে অন্য অবস্থায় রূপান্তরিত করতে পারে। এই ডকুমেন্টটিতে এমন কিছু সাধারণ পরিস্থিতি বর্ণনা করা হয়েছে যেখানে এই ধরনের রূপান্তর ঘটে এবং কীভাবে সেই রূপান্তরগুলি সামাল দিতে হয়।

অ্যাক্টিভিটি স্টেট সম্পর্কে আরও তথ্যের জন্য, অ্যাক্টিভিটি লাইফসাইকেল দেখুন। ViewModel ক্লাস কীভাবে আপনাকে অ্যাক্টিভিটি লাইফসাইকেল পরিচালনা করতে সাহায্য করতে পারে, তা জানতে ভিউমডেল ওভারভিউ দেখুন।

বেশিরভাগ অ্যাক্টিভিটি পরিবর্তনের ক্ষেত্রে, অ্যাক্টিভিটি লাইফসাইকেলে কলব্যাকগুলিতে সরাসরি সাড়া দেওয়ার প্রয়োজন হয় না। যেহেতু Compose স্টেট থেকে UI পুনর্নির্মাণ করে, তাই আপনি rememberSaveable বা ViewModel মতো উপযুক্ত স্থানে স্টেট সংরক্ষণ করে স্বয়ংক্রিয় পুনর্গঠনের সুবিধা নিতে পারেন।

কনফিগারেশন পরিবর্তন ঘটে

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

যখন কনফিগারেশনে কোনো পরিবর্তন ঘটে, তখন অ্যাক্টিভিটিটি ধ্বংস হয়ে যায় এবং পুনরায় তৈরি হয়। এর ফলে মূল অ্যাক্টিভিটি ইনস্ট্যান্সে নিম্নলিখিত কলব্যাকগুলো সক্রিয় হয়:

  1. onPause
  2. onStop
  3. onDestroy

অ্যাক্টিভিটিটির একটি নতুন ইনস্ট্যান্স তৈরি করা হয় এবং নিম্নলিখিত কলব্যাকগুলি ট্রিগার করা হয়:

  1. onCreate
  2. onStart
  3. onResume

কম্পোজে, এই কলব্যাকগুলির সাথে সরাসরি ইন্টারঅ্যাক্ট করা সাধারণত প্রচলিত নয়। এর পরিবর্তে, স্টেট পরিবর্তনগুলি পর্যবেক্ষণ করতে লাইফসাইকেল এপিআই (Lifecycle API) ব্যবহার করুন। কম্পোজে, আপনি বর্তমান লাইফসাইকেল পেতে LocalLifecycleOwner.current ব্যবহার করতে পারেন এবং একটি অবজারভার যোগ করতে পারেন, যা আপনাকে ইভেন্টগুলিতে সাড়া দেওয়ার সুযোগ দেয়।

কনফিগারেশন পরিবর্তনের পরেও একটি অ্যাক্টিভিটির UI স্টেট সংরক্ষণ করতে ViewModel ইনস্ট্যান্স, rememberSaveable , অথবা পারসিস্টেন্ট লোকাল স্টোরেজের একটি সংমিশ্রণ ব্যবহার করুন। এই বিকল্পগুলি কীভাবে একত্রিত করবেন তা নির্ভর করে আপনার UI ডেটার জটিলতা, আপনার অ্যাপের ব্যবহারের ক্ষেত্র এবং ডেটা পুনরুদ্ধারের গতি বনাম মেমরি ব্যবহারের বিবেচনার উপর। বেশিরভাগ ব্যবহারের ক্ষেত্রে, আপনার স্টেটকে একটি ViewModel এ হোইস্ট করা উচিত এবং rememberSaveable ব্যবহার করা উচিত, যাতে কনফিগারেশন পরিবর্তন এবং সিস্টেম-জনিত প্রসেস বন্ধ হয়ে যাওয়া—উভয় ক্ষেত্রেই স্টেট অক্ষুণ্ণ থাকে। আপনার অ্যাক্টিভিটির UI স্টেট সংরক্ষণ সম্পর্কে আরও তথ্যের জন্য, "Save UI states" দেখুন।

কনফিগারেশন পরিবর্তনের কারণে যখন কোনো অ্যাক্টিভিটি পুনরায় তৈরি করা হয়, তখন প্রাথমিক কম্পোজিশনটি বাতিল হয়ে যায়। ViewModel বা rememberSaveable ব্যবহার করলে নতুন কম্পোজিশনে আপনার UI স্টেট পুনরুদ্ধার হওয়া নিশ্চিত হয়।

আরও তথ্যের জন্য, Jetpack Compose-এর Lifecycle এবং State ও Jetpack Compose দেখুন।

একাধিক উইন্ডোর ক্ষেত্রে পরিচালনা করুন

যখন কোনো অ্যাপ মাল্টি-উইন্ডো মোডে প্রবেশ করে, যা অ্যান্ড্রয়েড ৭.০ (এপিআই লেভেল ২৪) এবং এর পরবর্তী সংস্করণগুলোতে উপলব্ধ, তখন সিস্টেম চলমান অ্যাক্টিভিটিকে একটি কনফিগারেশন পরিবর্তনের বিষয়ে অবহিত করে, যার ফলে পূর্বে বর্ণিত লাইফসাইকেল ট্রানজিশনগুলো সম্পন্ন হয়।

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

মাল্টি-উইন্ডো লাইফসাইকেল সম্পর্কে আরও তথ্যের জন্য, “সাপোর্ট মাল্টি-উইন্ডো মোড” -এ মাল্টি-উইন্ডো লাইফসাইকেলের ব্যাখ্যাটি দেখুন।

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

যখন ব্যবহারকারী অ্যাপ A থেকে অ্যাপ B-তে যান, তখন সিস্টেম অ্যাপ A-তে onPause এবং অ্যাপ B-তে onResume কল করে। প্রতিবার ব্যবহারকারী অ্যাপগুলোর মধ্যে টগল করার সময় এটি এই দুটি পদ্ধতির মধ্যে পরিবর্তন করে।

মাল্টি-উইন্ডো মোড সম্পর্কে আরও বিস্তারিত জানতে, "মাল্টি-উইন্ডো মোড সাপোর্ট" দেখুন।

অ্যাক্টিভিটি বা ডায়ালগ ফোরগ্রাউন্ডে প্রদর্শিত হয়।

যদি ফোরগ্রাউন্ডে কোনো নতুন অ্যাক্টিভিটি বা ডায়ালগ এসে ফোকাস নিয়ে নেয় এবং চলমান অ্যাক্টিভিটিটিকে আংশিকভাবে ঢেকে ফেলে, তাহলে ঢাকা পড়া অ্যাক্টিভিটিটি ফোকাস হারায় এবং পজড (Paused) অবস্থায় চলে যায়। এরপর, সিস্টেম সেটির উপর onPause কল করে।

যখন আবৃত অ্যাক্টিভিটিটি ফোরগ্রাউন্ডে ফিরে আসে এবং ফোকাস পুনরুদ্ধার করে, তখন সিস্টেম onResume কল করে।

যদি ফোরগ্রাউন্ডে কোনো নতুন অ্যাক্টিভিটি বা ডায়ালগ এসে ফোকাস নিয়ে নেয় এবং চলমান অ্যাক্টিভিটিটিকে সম্পূর্ণরূপে ঢেকে ফেলে, তাহলে ঢাকা পড়া অ্যাক্টিভিটিটি ফোকাস হারায় এবং 'স্টপড' অবস্থায় চলে যায়। এরপর সিস্টেম দ্রুত পরপর onPause ' এবং onStop কল করে।

যখন আচ্ছাদিত অ্যাক্টিভিটির একই ইনস্ট্যান্সটি ফোরগ্রাউন্ডে ফিরে আসে, তখন সিস্টেম অ্যাক্টিভিটিটির উপর onRestart , onStart এবং onResume কল করে। যদি আচ্ছাদিত অ্যাক্টিভিটির কোনো নতুন ইনস্ট্যান্স ব্যাকগ্রাউন্ডে আসে, তবে সিস্টেম onRestart কল করে না, কেবল onStart এবং onResume কল করে।

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

ব্যবহারকারী ট্যাপ বা অঙ্গভঙ্গি করে ফিরে যান

যদি কোনো অ্যাক্টিভিটি ফোরগ্রাউন্ডে থাকে এবং ব্যবহারকারী 'ব্যাক' বোতামে ট্যাপ বা জেসচার করেন, তাহলে অ্যাক্টিভিটিটি onPause , onStop এবং onDestroy কলব্যাকগুলোর মধ্য দিয়ে ট্রানজিশন করে। এরপর অ্যাক্টিভিটিটি ডেস্ট্রয় হয়ে যায় এবং ব্যাক স্ট্যাক থেকে অপসারিত হয়।

বেশিরভাগ কম্পোজ অ্যাপের মতো একটি একক-অ্যাক্টিভিটি অ্যাপে, নেভিগেশন ব্যাকস্ট্যাক থেকে কম্পোজেবলটি সরিয়ে ফেলা হলে rememberSaveable স্টেট বজায় রাখে না। এর কারণ হলো, যখন ব্যবহারকারী 'Back' ট্যাপ করেন, তখন তিনি একই ইনস্ট্যান্সে ফিরে আসবেন এমন কোনো প্রত্যাশা থাকে না, তাই সমস্ত স্টেট মুছে যায়।

কাস্টম 'ব্যাক' আচরণ প্রয়োগ করতে, যেমন ব্যবহারকারীকে আপনার অ্যাপ থেকে বের হতে চাওয়ার বিষয়টি নিশ্চিত করতে একটি ডায়ালগ দেখানো, NavigationEventHandler API ব্যবহার করুন।

সিস্টেম অ্যাপ প্রসেসটি বন্ধ করে দেয়।

যদি কোনো অ্যাপ ব্যাকগ্রাউন্ডে থাকে এবং সিস্টেমকে ফোরগ্রাউন্ডে থাকা কোনো অ্যাপের জন্য মেমরি খালি করার প্রয়োজন হয়, তবে সিস্টেম ব্যাকগ্রাউন্ড অ্যাপটিকে কিল করতে পারে। যখন সিস্টেম কোনো অ্যাপকে কিল করে, তখন অ্যাপটির মধ্যে onDestroy কল করা হবে এমন কোনো নিশ্চয়তা নেই।

সিস্টেম কীভাবে কোন প্রসেসগুলো ধ্বংস করার সিদ্ধান্ত নেয় সে সম্পর্কে আরও জানতে, “Activity state and ejection from memory” এবং “Processes and app lifecycle” পড়ুন।

সিস্টেম যখন আপনার অ্যাপ প্রসেস বন্ধ করে দেয়, তখন কীভাবে আপনার অ্যাক্টিভিটির UI স্টেট সংরক্ষণ করবেন তা জানতে, “ক্ষণস্থায়ী UI স্টেট সংরক্ষণ ও পুনরুদ্ধার” দেখুন।