হ্যান্ডেল কনফিগারেশন পরিবর্তন

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

• অ্যাপ ডিসপ্লে সাইজ
• স্ক্রিন ডেনসিটি (ডিসপ্লে স্কেলিং)
• স্ক্রিন ওরিয়েন্টেশন
• ফন্ট সাইজ ও ওজন
• লোকেল
• ডার্ক থিম বনাম লাইট থিম
• কীবোর্ডের উপলভ্যতা

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

এইসব প্যারামিটার সাধারণত আপনার অ্যাপ্লিকেশনের UI-তে যথেষ্ট বড় পরিবর্তন করতে হয়, তাই Android প্ল্যাটফর্মে এগুলি পরিবর্তন করার জন্য একটি বিশেষ মেকানিজম আছে। এই মেকানিজম হল Activity রিক্রিয়েশন।

অ্যাক্টিভিটি রিক্রিয়েশন

কনফিগারেশনে পরিবর্তন হলে সিস্টেম একটি Activity আবার তৈরি করে। এটি করতে, সিস্টেম onDestroy কল করে এবং আগে থেকে থাকা Activity ইনস্ট্যান্স ধ্বংস করে দেয়। তারপরে এটি onCreate ব্যবহার করে একটি নতুন ইনস্ট্যান্স তৈরি করে এবং এই নতুন Activity ইনস্ট্যান্সটি নতুন, আপডেট করা কনফিগারেশন দিয়ে ইনিশিয়ালাইজ করা হয়। এর অর্থ হল, সিস্টেম নতুন কনফিগারেশন সহ UI-ও আবার তৈরি করে।

সাধারণত, Activity কম্পোজ করার উপযুক্ত আইটেমের হোস্ট হিসেবে কাজ করে। Activity আবার তৈরি করা হলে, Compose নতুন কনফিগারেশন ভ্যালু ব্যবহার করে আপনার UI-ও আবার তৈরি করে।

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

রিক্রিয়েশন সংক্রান্ত উদাহরণ

এমন একটি কম্পোজ করার মতো আইটেম বিবেচনা করুন যা স্ট্রিং রিসোর্স ব্যবহার করে একটি স্ট্যাটিক শীর্ষক দেখায়:

// In the res/values/strings.xml file
// <string name="compose">Jetpack Compose</string>

// In your Compose code
Text(
    text = stringResource(R.string.compose)
)
ResourcesSnippets.kt

Activity তৈরি হলে, Text কম্পোজ করার উপযুক্ত আইটেম বর্তমান কনফিগারেশন (যেমন, ভাষা) পড়ে এবং উপযুক্ত স্ট্রিং রিসোর্স সমাধান করে।

ভাষা পরিবর্তন করা হলে, সিস্টেম অ্যাক্টিভিটি আবার তৈরি করে। এটি ঘটলে, Compose UI আবার তৈরি করে। কারণ stringResource বর্তমান কনফিগারেশন থেকে পড়ে, তাই টাইটেল অটোমেটিক সঠিক লোকাল ভ্যালুতে আপডেট হয়ে যায়।

এছাড়াও, রিক্রিয়েশন Activity-এ ফিল্ড হিসেবে রাখা যেকোনও স্টেট মুছে দেয়।

কনফিগারেশনে পরিবর্তন করা সত্ত্বেও UI স্টেট বজায় রাখতে, সাজেস্ট করা স্টেট ম্যানেজমেন্ট প্যাটার্ন ব্যবহার করুন। ডেটা ও বিজনেস লজিকের জন্য ViewModel এবং UI-লেভেল স্টেটের জন্য rememberSaveable ব্যবহার করুন। এইসব মেকানিজমের সাহায্যে, আপনার স্টেট রিক্রিয়েশন Activity থেকে বেঁচে যায়, একই সাথে UI আপডেট হয়ে নতুন কনফিগারেশন প্রতিফলিত করে।

Compose-এ স্টেট সেভ করা সম্পর্কে আরও জানতে, Compose-এ UI স্টেট সেভ করা দেখুন।

ব্যবহারকারীর প্রত্যাশা

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

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

• ডিভাইস ঘোরানো
• মাল্টি-উইন্ডো মোডে প্রবেশ করা
• একাধিক উইন্ডো মোড বা ফ্রি-ফর্ম উইন্ডোতে থাকাকালীন অ্যাপ্লিকেশন রিসাইজ করা
• একাধিক ডিসপ্লে সহ ফোল্ড করা যায় এমন ডিভাইস ফোল্ড করা
• সিস্টেম সেটিংস থেকে ডিসপ্লে সাইজ বা ডিসপ্লে স্কেলিং পরিবর্তন করা
• বিভিন্ন স্ক্রিন ডেনসিটি (যেমন কানেক্ট করা এক্সটার্নাল মনিটর বা ফোল্ড করা যায় এমন ডিভাইসের ডিসপ্লে) সহ ডিসপ্লের মধ্যে অ্যাপ সরানো
• সিস্টেম থিম পরিবর্তন করা, যেমন ডার্ক থিম বনাম লাইট থিম
• ফন্ট সাইজ পরিবর্তন করা
• সিস্টেম বা অ্যাপের ভাষা পরিবর্তন করা
• হার্ডওয়্যার কীবোর্ড কানেক্ট বা ডিসকানেক্ট করা
• ডক কানেক্ট বা ডিসকানেক্ট করা

রিক্রিয়েশনেরActivity মাধ্যমে প্রাসঙ্গিক স্টেট সেভ করার জন্য আপনি বিভিন্ন পদ্ধতি অবলম্বন করতে পারেন। কোনটি ব্যবহার করবেন তা নির্ভর করে আপনি কোন ধরনের স্টেট সংরক্ষণ করতে চান:

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

এইগুলির প্রত্যেকটির API সম্পর্কে বিস্তারিত জানতে, এবং কখন কোনটি ব্যবহার করা উপযুক্ত, তা জানতে UI স্টেট সেভ করা দেখুন।

অ্যাক্টিভিটি রিক্রিয়েশন সীমিত করা

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

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

Compose-এ সরাসরি কনফিগারেশন পরিবর্তন ম্যানেজ করার অনেক সুবিধা আছে:

• উন্নত পারফর্ম্যান্স: সম্পূর্ণ অ্যাক্টিভিটি রিক্রিয়েশন সাইকেলের তুলনায় UI রিকম্পোজ করা কম খরচসাপেক্ষ, বিশেষ করে ছোটখাটো পরিবর্তনের ক্ষেত্রে।
• সাবলীল অ্যানিমেশন: অ্যাক্টিভিটি রিস্টার্ট করা এড়ানো আপনাকে কনফিগারেশন পরিবর্তন জুড়ে একটানা অ্যানিমেশন চালাতে দেয়, যেমন ডিভাইস ঘোরানোর সময় মসৃণ লেআউট ট্রানজিশন।
• স্টেট প্রিজার্ভেশন: অ্যাক্টিভিটি ইনস্ট্যান্স ধরে রাখলে স্ক্রিন ঘোরানোর মতো ইভেন্টের সময় ক্ষণস্থায়ী UI স্টেট হারানোর ঝুঁকি কমে যায়। মনে রাখবেন যে সিস্টেম-ইনিশিয়েটেড প্রসেস ডেথের জন্য আপনাকে অবশ্যই স্টেট প্রিজার্ভেশন ম্যানেজ করতে হবে।

নির্দিষ্ট কনফিগারেশন পরিবর্তনের জন্য অ্যাক্টিভিটি রিক্রিয়েশন বন্ধ করতে, আপনার AndroidManifest.xml ফাইলে <activity> এন্ট্রিতে android:configChanges কনফিগারেশনের ধরন যোগ করুন। android:configChanges অ্যাট্রিবিউটের জন্য ডকুমেন্টেশনে সম্ভাব্য ভ্যালু দেখানো হয়।

নিচের ম্যানিফেস্ট কোডটি MyActivity-এর জন্য Activity রিক্রিয়েশন বন্ধ করে দেয়, যখন স্ক্রিন ওরিয়েন্টেশন ও কীবোর্ডের উপলভ্যতা পরিবর্তন হয়:

<activity
    android:name=".MyActivity"
    android:configChanges="orientation|screenSize|screenLayout|keyboardHidden"
    android:label="@string/app_name">

Android 17

Android 17 (API লেভেল 37) থেকে শুরু করে, সিস্টেম আর ডিফল্ট হিসেবে সেইসব অ্যাক্টিভিটি রিস্টার্ট করে না যেগুলি সাধারণত সম্পূর্ণ UI রিক্রিয়েট করার প্রয়োজন হয় না। এর পরিবর্তে, অ্যাক্টিভিটি চালু থাকে এবং onConfigurationChanged() কলব্যাকের মাধ্যমে আপডেট পায়। নির্দিষ্ট কনফিগারেশন পরিবর্তনের মধ্যে এগুলি অন্তর্ভুক্ত:

• CONFIG_KEYBOARD
• CONFIG_KEYBOARD_HIDDEN
• CONFIG_NAVIGATION
• CONFIG_TOUCHSCREEN
• CONFIG_COLOR_MODE
• CONFIG_UI_MODE (শুধুমাত্র UI মোড UI_MODE_TYPE_DESK-এ পরিবর্তন হলে অথবা UI_MODE_TYPE_DESK থেকে অন্য কোনও ধরনের মোডে পরিবর্তন হলে)

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

<activity
    android:name=".MyActivity"
    android:recreateOnConfigChanges="keyboard|keyboardHidden|navigation|colorMode|touchscreen|...">
    ...
</activity>

কনফিগারেশনে হওয়া পরিবর্তন অনুযায়ী কাজ করা

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

Configuration অবজেক্টটি Compose UI হায়ারার্কিতে LocalConfiguration কম্পোজিশন লোকালের সাথে উপলভ্য। এটি যখনই পরিবর্তিত হয়, LocalConfiguration.current থেকে কম্পোজ করা যায় এমন ফাংশন আবার কম্পোজ হয়। কম্পোজিশন লোকাল কীভাবে কাজ করে সেই সম্পর্কে আরও জানতে, কম্পোজিশন লোকালের সাথে লোকাল স্কোপ করা ডেটা দেখুন।

উদাহরণ

নিচের উদাহরণে, একটি কম্পোজ করার উপযুক্ত আইটেম নির্দিষ্ট ফর্ম্যাটে তারিখ দেখায়। সিস্টেম লোকেল কনফিগারেশনে পরিবর্তন হলে কম্পোজ করার উপযুক্ত আইটেমটি LocalConfiguration.current সহ ConfigurationCompat.getLocales কল করে প্রতিক্রিয়া জানায়।

@Composable
fun DateText(year: Int, dayOfYear: Int) {
    val dateTimeFormatter = DateTimeFormatter.ofPattern(
        "MMM dd",
        ConfigurationCompat.getLocales(LocalConfiguration.current)[0]
    )
    Text(
        dateTimeFormatter.format(LocalDate.ofYearDay(year, dayOfYear))
    )
}

লোকেল পরিবর্তন হলে Activity রিক্রিয়েশন এড়াতে, Activity হোস্টিং কম্পোজ কোডকে লোকেল কনফিগারেশন পরিবর্তন থেকে অপ্ট-আউট করতে হবে। এটি করতে, আপনাকে android:configChanges-এর মান locale|layoutDirection হিসেবে সেট করতে হবে।

কনফিগারেশন সংক্রান্ত পরিবর্তন: মূল ধারণা ও পেশাদার পদ্ধতি

কনফিগারেশন পরিবর্তন করার সময় আপনাকে এইসব মূল ধারণা সম্পর্কে জানতে হবে:

• কনফিগারেশন: ডিভাইস কনফিগারেশন নির্ধারণ করে যে কীভাবে UI ব্যবহারকারীকে দেখানো হবে, যেমন অ্যাপ ডিসপ্লে সাইজ, স্ক্রিন ডেনসিটি, লোকেল বা সিস্টেম থিম। Compose-এ, আপনি LocalConfiguration ব্যবহার করে কনফিগারেশন ভ্যালু অ্যাক্সেস করতে পারবেন।
• কনফিগারেশনে পরিবর্তন: ব্যবহারকারীর ইন্টার‍্যাকশনের মাধ্যমে কনফিগারেশনে পরিবর্তন হয়। যেমন, ব্যবহারকারী ডিভাইস সেটিংস পরিবর্তন করতে পারেন অথবা ডিভাইসের সাথে কীভাবে ফিজিক্যালি ইন্ট্যার‍্যাক্ট করবেন তা পরিবর্তন করতে পারেন। কনফিগারেশনে পরিবর্তন আটকানোর কোনও উপায় নেই।
• Activity রিক্রিয়েশন: কনফিগারেশনে পরিবর্তন করা হলে, ডিফল্ট হিসেবে Activity রিক্রিয়েশন করা হয়। নতুন কনফিগারেশনের জন্য অ্যাপ স্টেট আবার চালু করার এটি একটি বিল্ট-ইন মেকানিজম।
• Activity ধ্বংস: Activity রিক্রিয়েশন করলে সিস্টেম পুরনো Activity ইনস্ট্যান্সকে ধ্বংস করে তার জায়গায় নতুন ইনস্ট্যান্স তৈরি করে। পুরনো ইনস্ট্যান্স এখন আর ব্যবহার করা যাবে না। লাইফসাইকেল-স্কোপ করা অবজেক্টের রেফারেন্স সেগুলির উদ্দেশ্যমূলক স্কোপের বাইরে ধরে রাখা এড়িয়ে চলুন।
• স্টেট: পুরনো Activity ইনস্ট্যান্সে থাকা স্টেট নতুন Activity ইনস্ট্যান্সে নেই, কারণ এগুলি দুটি আলাদা অবজেক্ট ইনস্ট্যান্স। অ্যাক্টিভিটির সাথে স্টেটকে যুক্ত না করে, UI স্টেট সেভ করুন-এ বর্ণিত অ্যাপ ও ব্যবহারকারীর স্টেট সংরক্ষণ করতে সাজেস্ট করা API ব্যবহার করুন।
• বেরিয়ে আসা: কোনও ধরনের কনফিগারেশনের জন্য অ্যাক্টিভিটি রিক্রিয়েশন থেকে বেরিয়ে আসতে পরিবর্তনের জন্য আপনার অ্যাপকে নতুন কনফিগারেশনের প্রতিক্রিয়া হিসেবে সঠিকভাবে আপডেট করতে হবে।

ব্যবহারকারীদের ভালো অভিজ্ঞতা দিতে, নিম্নলিখিত পেশাদার পদ্ধতি মেনে চলুন:

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

হ্যান্ডেলের সাইজ অনুযায়ী কনফিগারেশনে পরিবর্তন

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

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

সাইজ-ভিত্তিক কনফিগারেশন পরিবর্তনের জন্য অ্যাক্টিভিটি রিক্রিয়েশন সীমাবদ্ধ করা

সাইজ-ভিত্তিক কনফিগারেশন পরিবর্তনের জন্য Activity রিক্রিয়েশন বন্ধ করে দিলে, সিস্টেম Activity রিক্রিয়েট করে না। পরিবর্তে, এটি Activity.onConfigurationChanged-এ কল রিসিভ করে। নতুন সাইজ দেখানোর জন্য LocalConfiguration.current যেকোনও কম্পোজ করার উপযুক্ত আইটেম অটোমেটিক আবার কম্পোজ করা হয়।

সাইজ-ভিত্তিক কনফিগারেশন পরিবর্তনের জন্য Activity রিক্রিয়েশন বন্ধ করা হয়, যখন আপনার android:configChanges="screenSize|smallestScreenSize|orientation|screenLayout" মেনিফেস্ট ফাইলে থাকে।

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

কনফিগারেশন সংক্রান্ত পরিবর্তন ম্যানেজ করা সম্পর্কে আরও তথ্য পেতে, নিম্নলিখিত অতিরিক্ত রিসোর্স দেখুন:

ডকুমেন্টেশন

• Compose-এ UI স্টেট সেভ করা

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

• কনফিগারেশন সংক্রান্ত পরিবর্তন ম্যানেজ করা (ভিউ)