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

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

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

এইসব কনফিগারেশন পরিবর্তনের বেশিরভাগই ব্যবহারকারীর ইন্টার‍্যাকশনের কারণে ঘটে। যেমন, ডিভাইসটি রোটেট বা ফোল্ড করলে আপনার অ্যাপের জন্য উপলভ্য স্ক্রিন স্পেসের পরিমাণ পরিবর্তিত হয়। এক্সটার্নাল ডিসপ্লেতে কানেক্ট করা বা বিভিন্ন পিক্সেল ডেনসিটি সহ ডিসপ্লের মধ্যে কোনও অ্যাপ সরানো হলে স্ক্রিন ডেনসিটি এবং ডিসপ্লের সাইজ পরিবর্তিত হয়। একইভাবে, ডিসপ্লে স্কেলিং, ফন্ট সাইজ, ভাষা বা পছন্দের থিমের মতো ডিভাইস সেটিংস পরিবর্তন করলে, 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 অন্তর্ভুক্ত।
• ব্যবহারকারী সক্রিয়ভাবে অ্যাপ ব্যবহার করার সময় মেমরিতে UI-সম্পর্কিত স্টেট ম্যানেজ করার জন্য ViewModel ইনস্ট্যান্সের মতো রিটেন করা অবজেক্ট।
• rememberSaveable যাতে কনফিগারেশন পরিবর্তন এবং সিস্টেম-ইনিশিয়েটেড প্রসেস বন্ধ করার সময় ট্রানজিয়েন্ট UI স্টেট বজায় রাখা যায়। এটি এমন স্টেট-এর জন্য উপযুক্ত যা ব্যবহারকারীর ইনপুট, স্ক্রল পজিশন বা নেভিগেশনের উপর নির্ভর করে কিন্তু ViewModel-এর অন্তর্গত নয়।

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

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

নির্দিষ্ট কনফিগারেশন পরিবর্তনের জন্য আপনি অটোমেটিক অ্যাক্টিভিটি রিক্রিয়েশন বন্ধ করতে পারবেন। আধুনিক Compose-only অ্যাপে, আপনার 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 লেভেল ৩৭) থেকে শুরু করে, সিস্টেম আর ডিফল্ট হিসেবে অ্যাক্টিভিটি রিস্টার্ট করে না বেশ কিছু কনফিগারেশন পরিবর্তনের জন্য যেগুলি সাধারণত সম্পূর্ণ 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 অবজেক্টটি কম্পোজ UI হায়ারার্কিতে LocalConfiguration কম্পোজিশন লোকালের সাথে উপলভ্য। এটি পরিবর্তন হলেই, LocalConfiguration.current থেকে রিড করা কম্পোজেবল ফাংশন আবার কম্পোজ করে। কম্পোজিশন লোকাল কীভাবে কাজ করে সেই সম্পর্কে আরও তথ্যের জন্য, CompositionLocal-এর সাথে লোকাল স্কোপড ডেটা দেখুন।

উদাহরণ

নিচের উদাহরণে, একটি কম্পোজেবল নির্দিষ্ট ফর্ম্যাটে তারিখ দেখায়। কম্পোজেবল, 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 স্টেট সেভ করা

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

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