UI রাজ্যগুলি সংরক্ষণ করুন

এই নির্দেশিকাটি UI অবস্থা সম্পর্কে ব্যবহারকারীর প্রত্যাশা এবং অবস্থা সংরক্ষণের জন্য উপলব্ধ বিকল্পগুলি নিয়ে আলোচনা করে।

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

ব্যবহারকারীর প্রত্যাশা এবং সিস্টেম আচরণের মধ্যে ব্যবধান পূরণ করতে, নিম্নলিখিত পদ্ধতিগুলির সংমিশ্রণ ব্যবহার করুন:

  • ViewModel অবজেক্ট দেখুন।
  • সংরক্ষিত উদাহরণ নিম্নলিখিত প্রসঙ্গের মধ্যে উল্লেখ করে:
  • অ্যাপ এবং অ্যাক্টিভিটি ট্রানজিশনের সময় UI অবস্থা বজায় রাখার জন্য স্থানীয় স্টোরেজ।

সর্বোত্তম সমাধান আপনার UI ডেটার জটিলতা, আপনার অ্যাপের ব্যবহারের ক্ষেত্রে এবং ডেটা অ্যাক্সেসের গতি এবং মেমরি ব্যবহারের মধ্যে ভারসাম্য খোঁজার উপর নির্ভর করে।

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

ব্যবহারকারীর প্রত্যাশা এবং সিস্টেম আচরণ

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

ব্যবহারকারী-সূচিত UI রাজ্য বরখাস্ত

ব্যবহারকারী আশা করে যে যখন তারা একটি কার্যকলাপ শুরু করে, ব্যবহারকারীর কার্যকলাপ সম্পূর্ণরূপে বাতিল না করা পর্যন্ত সেই কার্যকলাপের ক্ষণস্থায়ী UI অবস্থা একই থাকে। ব্যবহারকারী নিম্নলিখিত কাজ করে একটি কার্যকলাপ সম্পূর্ণরূপে বরখাস্ত করতে পারেন:

  • ওভারভিউ (সাম্প্রতিক) স্ক্রীন থেকে কার্যকলাপ সোয়াইপ করা।
  • সেটিংস স্ক্রীন থেকে অ্যাপটিকে হত্যা করা বা জোর করে ছেড়ে দেওয়া।
  • ডিভাইস রিবুট করা হচ্ছে।
  • কিছু ধরণের "ফিনিশিং" অ্যাকশন সম্পূর্ণ করা (যা Activity.finish() দ্বারা সমর্থিত)।

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

সম্পূর্ণ বরখাস্ত সম্পর্কে এই নিয়মের কিছু ব্যতিক্রম রয়েছে—উদাহরণস্বরূপ, একজন ব্যবহারকারী ব্যাক বোতাম ব্যবহার করে ব্রাউজার থেকে প্রস্থান করার আগে একটি ব্রাউজার তাদের সঠিক ওয়েবপৃষ্ঠায় নিয়ে যাওয়ার আশা করতে পারে।

সিস্টেম-সূচিত UI রাজ্য বরখাস্ত

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

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

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

UI অবস্থা সংরক্ষণের জন্য বিকল্প

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

UI অবস্থা সংরক্ষণের জন্য প্রতিটি বিকল্প নিম্নলিখিত মাত্রাগুলির সাথে পরিবর্তিত হয় যা ব্যবহারকারীর অভিজ্ঞতাকে প্রভাবিত করে:

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

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

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

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

ViewModels স্বয়ংক্রিয়ভাবে সিস্টেম দ্বারা ধ্বংস হয়ে যায় যখন আপনার ব্যবহারকারী আপনার কার্যকলাপ বা খণ্ড থেকে ব্যাক আউট হয়ে যায় অথবা যদি আপনি finish() কল করেন, যার মানে এই পরিস্থিতিতে ব্যবহারকারীর প্রত্যাশা অনুযায়ী অবস্থা সাফ হয়ে যায়।

সংরক্ষিত দৃষ্টান্ত অবস্থার বিপরীতে, একটি সিস্টেম-সূচিত প্রক্রিয়া মৃত্যুর সময় ভিউ মডেলগুলি ধ্বংস হয়ে যায়। একটি ViewModel-এ একটি সিস্টেম-সূচিত প্রক্রিয়া মৃত্যুর পরে ডেটা পুনরায় লোড করতে, SavedStateHandle API ব্যবহার করুন৷ বিকল্পভাবে, যদি ডেটাটি UI-এর সাথে সম্পর্কিত হয় এবং ViewModel-এ রাখার প্রয়োজন না হয়, তাহলে View সিস্টেমে onSaveInstanceState() ব্যবহার করুন বা Jetpack Compose-এ rememberSaveable । যদি ডেটা অ্যাপ্লিকেশন ডেটা হয়, তাহলে এটি ডিস্কে চালিয়ে যাওয়া ভাল হতে পারে।

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

সিস্টেম-সূচিত প্রক্রিয়া মৃত্যু পরিচালনা করতে ব্যাকআপ হিসাবে সংরক্ষিত দৃষ্টান্ত স্থিতি ব্যবহার করুন

ভিউ সিস্টেমে onSaveInstanceState() কলব্যাক, জেটপ্যাক কম্পোজে rememberSaveable এবং ViewModels-এ SavedStateHandle একটি UI কন্ট্রোলারের অবস্থা পুনঃলোড করার জন্য প্রয়োজনীয় ডেটা সঞ্চয় করে, যেমন একটি কার্যকলাপ বা একটি খণ্ড, যদি সিস্টেমটি ধ্বংস করে এবং পরে সেই নিয়ামকটিকে পুনরায় তৈরি করে। onSaveInstanceState ব্যবহার করে কীভাবে সংরক্ষিত দৃষ্টান্ত স্থিতি প্রয়োগ করতে হয় তা শিখতে, অ্যাক্টিভিটি লাইফসাইকেল গাইডে অ্যাক্টিভিটি স্টেট সংরক্ষণ এবং পুনরুদ্ধার দেখুন।

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

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

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

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

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

যে ক্ষেত্রে UI ডেটা সংরক্ষণ করা সহজ এবং হালকা, আপনি আপনার রাজ্য ডেটা সংরক্ষণের জন্য একা সংরক্ষিত ইনস্ট্যান্স স্টেট API ব্যবহার করতে পারেন।

SavedStateRegistry ব্যবহার করে সংরক্ষিত অবস্থায় হুক করুন

ফ্র্যাগমেন্ট 1.1.0 বা এর ট্রানজিটিভ ডিপেন্ডেন্সি অ্যাক্টিভিটি 1.0.0 দিয়ে শুরু করে, UI কন্ট্রোলার, যেমন একটি Activity বা Fragment , SavedStateRegistryOwner প্রয়োগ করে এবং সেই কন্ট্রোলারের সাথে আবদ্ধ একটি SavedStateRegistry প্রদান করে। SavedStateRegistry উপাদানগুলিকে আপনার UI কন্ট্রোলারের সংরক্ষিত অবস্থায় এটিকে গ্রাস করতে বা এতে অবদান রাখার অনুমতি দেয়। উদাহরণস্বরূপ, ViewModel-এর জন্য সংরক্ষিত স্টেট মডিউল একটি SavedStateHandle তৈরি করতে SavedStateRegistry ব্যবহার করে এবং এটি আপনার ViewModel অবজেক্টে প্রদান করে। আপনি getSavedStateRegistry() কল করে আপনার UI কন্ট্রোলারের মধ্যে থেকে SavedStateRegistry পুনরুদ্ধার করতে পারেন।

যে উপাদানগুলি সংরক্ষিত অবস্থায় অবদান রাখে তাদের অবশ্যই SavedStateRegistry.SavedStateProvider প্রয়োগ করতে হবে, যা saveState() নামে একটি একক পদ্ধতি সংজ্ঞায়িত করে। saveState() পদ্ধতি আপনার কম্পোনেন্টকে সেই কম্পোনেন্ট থেকে সেভ করা উচিত এমন যেকোনো স্টেট ধারণকারী একটি Bundle ফেরত দিতে দেয়। UI কন্ট্রোলারের জীবনচক্রের সেভ স্টেট ফেজ চলাকালীন SavedStateRegistry এই পদ্ধতিটিকে কল করে।

কোটলিন

class SearchManager : SavedStateRegistry.SavedStateProvider {
    companion object {
        private const val QUERY = "query"
    }

    private val query: String? = null

    ...

    override fun saveState(): Bundle {
        return bundleOf(QUERY to query)
    }
}

জাভা

class SearchManager implements SavedStateRegistry.SavedStateProvider {
    private static String QUERY = "query";
    private String query = null;
    ...

    @NonNull
    @Override
    public Bundle saveState() {
        Bundle bundle = new Bundle();
        bundle.putString(QUERY, query);
        return bundle;
    }
}

একটি SavedStateProvider রেজিস্টার করতে, SavedStateRegistryregisterSavedStateProvider() কল করুন, প্রদানকারীর ডেটার সাথে সাথে প্রদানকারীর সাথে যুক্ত করার জন্য একটি কী পাস করুন৷ প্রদানকারীর জন্য পূর্বে সংরক্ষিত ডেটা SavedStateRegistry consumeRestoredStateForKey() কল করে, প্রদানকারীর ডেটার সাথে যুক্ত কীটি পাস করে সংরক্ষিত অবস্থা থেকে পুনরুদ্ধার করা যেতে পারে।

একটি Activity বা Fragment মধ্যে, আপনি super.onCreate() কল করার পরে onCreate() এ একটি SavedStateProvider নিবন্ধন করতে পারেন। বিকল্পভাবে, আপনি একটি SavedStateRegistryOwner এ একটি LifecycleObserver সেট করতে পারেন, যেটি LifecycleOwner প্রয়োগ করে, এবং ON_CREATE ইভেন্টটি ঘটলে SavedStateProvider নিবন্ধন করতে পারেন। একটি LifecycleObserver ব্যবহার করে, আপনি SavedStateRegistryOwner থেকে পূর্বে সংরক্ষিত অবস্থার রেজিস্ট্রেশন এবং পুনরুদ্ধার ডিকপল করতে পারেন।

কোটলিন

class SearchManager(registryOwner: SavedStateRegistryOwner) : SavedStateRegistry.SavedStateProvider {
    companion object {
        private const val PROVIDER = "search_manager"
        private const val QUERY = "query"
    }

    private val query: String? = null

    init {
        // Register a LifecycleObserver for when the Lifecycle hits ON_CREATE
        registryOwner.lifecycle.addObserver(LifecycleEventObserver { _, event ->
            if (event == Lifecycle.Event.ON_CREATE) {
                val registry = registryOwner.savedStateRegistry

                // Register this object for future calls to saveState()
                registry.registerSavedStateProvider(PROVIDER, this)

                // Get the previously saved state and restore it
                val state = registry.consumeRestoredStateForKey(PROVIDER)

                // Apply the previously saved state
                query = state?.getString(QUERY)
            }
        }
    }

    override fun saveState(): Bundle {
        return bundleOf(QUERY to query)
    }

    ...
}

class SearchFragment : Fragment() {
    private var searchManager = SearchManager(this)
    ...
}

জাভা

class SearchManager implements SavedStateRegistry.SavedStateProvider {
    private static String PROVIDER = "search_manager";
    private static String QUERY = "query";
    private String query = null;

    public SearchManager(SavedStateRegistryOwner registryOwner) {
        registryOwner.getLifecycle().addObserver((LifecycleEventObserver) (source, event) -> {
            if (event == Lifecycle.Event.ON_CREATE) {
                SavedStateRegistry registry = registryOwner.getSavedStateRegistry();

                // Register this object for future calls to saveState()
                registry.registerSavedStateProvider(PROVIDER, this);

                // Get the previously saved state and restore it
                Bundle state = registry.consumeRestoredStateForKey(PROVIDER);

                // Apply the previously saved state
                if (state != null) {
                    query = state.getString(QUERY);
                }
            }
        });
    }

    @NonNull
    @Override
    public Bundle saveState() {
        Bundle bundle = new Bundle();
        bundle.putString(QUERY, query);
        return bundle;
    }

    ...
}

class SearchFragment extends Fragment {
    private SearchManager searchManager = new SearchManager(this);
    ...
}

জটিল বা বড় ডেটার জন্য প্রক্রিয়া মৃত্যু পরিচালনা করতে স্থানীয় অধ্যবসায় ব্যবহার করুন

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

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

UI অবস্থা পরিচালনা: ভাগ করুন এবং জয় করুন

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

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

একটি উদাহরণ হিসাবে, এমন একটি কার্যকলাপ বিবেচনা করুন যা আপনাকে আপনার গানের লাইব্রেরির মাধ্যমে অনুসন্ধান করতে দেয়। এখানে বিভিন্ন ইভেন্ট কিভাবে পরিচালনা করা উচিত:

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

যখন ব্যবহারকারী একটি গানের জন্য অনুসন্ধান করে, ডাটাবেস থেকে আপনি যত জটিল গানের ডেটা লোড করুন না কেন, তা অবিলম্বে স্ক্রীন UI অবস্থার অংশ হিসাবে ViewModel অবজেক্টে সংরক্ষণ করা উচিত।

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

জটিল অবস্থা পুনরুদ্ধার করুন: টুকরা পুনরায় একত্রিত করা

যখন ব্যবহারকারীর কার্যকলাপে ফিরে আসার সময় হয়, তখন কার্যকলাপটি পুনরায় তৈরি করার জন্য দুটি সম্ভাব্য পরিস্থিতি রয়েছে:

  • সিস্টেম দ্বারা বন্ধ করার পরে কার্যকলাপ পুনরায় তৈরি করা হয়. সিস্টেমে একটি সংরক্ষিত ইনস্ট্যান্স স্টেট বান্ডেলে ক্যোয়ারী সেভ করা আছে এবং SavedStateHandle ব্যবহার না করা হলে UI-কে ViewModel এ ক্যোয়ারী পাস করা উচিত। ViewModel দেখে যে এটিতে কোনো অনুসন্ধানের ফলাফল ক্যাশে করা নেই এবং প্রদত্ত অনুসন্ধান ক্যোয়ারী ব্যবহার করে অনুসন্ধানের ফলাফল লোড করা প্রতিনিধিরা৷
  • একটি কনফিগারেশন পরিবর্তনের পরে কার্যকলাপ তৈরি করা হয়। যেহেতু ViewModel দৃষ্টান্তটি ধ্বংস করা হয়নি, তাই ViewModel মেমরিতে ক্যাশ করা সমস্ত তথ্য রয়েছে এবং এটিকে ডাটাবেস পুনরায় অনুসন্ধান করার প্রয়োজন নেই।

অতিরিক্ত সম্পদ

UI রাজ্যগুলি সংরক্ষণ করার বিষয়ে আরও জানতে, নিম্নলিখিত সংস্থানগুলি দেখুন৷

ব্লগ

{% শব্দার্থে %} {% endverbatim %} {% শব্দার্থে %} {% endverbatim %}