মাল্টি-রিজিউম

Android 9 (এবং এর আগের যেকোনও ভার্সনে), অ্যাপগুলি PAUSED স্টেটে প্রবেশ করত যখন:

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

এইসব পরিস্থিতি অ্যাপকে কতক্ষণ পজ করতে হবে তার ভিত্তিতে আলাদা হয়, তবে অ্যাপ লেভেলে এগুলি আলাদা করে বোঝা যায় না।

Android 10-এ, দৃশ্যমান স্ট্যাকের মধ্যে থাকা সব টপ-ফোকাসযোগ্য অ্যাক্টিভিটি RESUMED স্টেটে থাকে। এটি UI রিফ্রেশ করা বন্ধ করতে এবং ব্যবহারকারীর সাথে ইন্টার‍্যাক্ট করার জন্য onStop()-এর পরিবর্তে onPause() ব্যবহার করে এমন অ্যাপের জন্য মাল্টি-উইন্ডো এবং MD মোডের সাথে সামঞ্জস্য উন্নত করে। এর অর্থ হল:

• স্প্লিট-স্ক্রিনে দুটি অ্যাক্টিভিটিই আবার চালু করা হয়েছে।
• ফ্রি-ফর্ম উইন্ডো মোডে সবচেয়ে উপরে দৃশ্যমান সব অ্যাক্টিভিটি আবার চালু করা হয়।
• একই সময়ে একাধিক স্ক্রিনে অ্যাক্টিভিটি আবার শুরু করা যেতে পারে।

ছবি ১. ফোল্ড করা যায় এমন ডিভাইসে মাল্টি-রিজিউম

ছবি ২. ডেস্কটপ মোডে মাল্টি-রিজিউম

অ্যাক্টিভিটি PAUSED অবস্থায় থাকতে পারে যখন সেগুলির উপর ফোকাস করা যায় না বা সেগুলি আংশিকভাবে ঢাকা থাকে, যেমন:

• মিনিমাইজ করা স্প্লিট-স্ক্রিনে (একদিকে লঞ্চার সহ), সবচেয়ে উপরের অ্যাক্টিভিটি আবার চালু করা হয় না কারণ এটি ফোকাস করা যায় না।
• পিকচার-ইন-পিকচার মোডে, অ্যাক্টিভিটি আবার শুরু করা হয় না কারণ এটি ফোকাস করা যায় না।
• একই স্ট্যাকের মধ্যে অন্যান্য স্বচ্ছ অ্যাক্টিভিটি দ্বারা অ্যাক্টিভিটি কভার করা হলে।

এই পদ্ধতি অ্যাপকে ইঙ্গিত দেয় যে কোনও অ্যাক্টিভিটি শুধুমাত্র RESUMED স্টেটে থাকাকালীনই ব্যবহারকারীর থেকে ইনপুট পেতে পারে। Android 10-এর আগে, অ্যাক্টিভিটি PAUSED স্ট্যাটাসেও ইনপুট পেতে পারত (যেমন, Android 9-এ রান করা ডিভাইসে স্প্লিট-স্ক্রিনে একই সাথে দুটি অ্যাক্টিভিটি টাচ করার চেষ্টা করুন)।

আগের Android রিলিজ থেকে আবার চালু করা সিগন্যাল সেভ করতে (এবং কখন অ্যাপের এক্সক্লুসিভ-অ্যাক্সেস বা সিঙ্গলটন রিসোর্সে অ্যাক্সেস পাওয়া উচিত তা জানাতে), Android 10-এ একটি নতুন কলব্যাক অন্তর্ভুক্ত করা হয়েছে:

Activity#onTopResumedActivityChanged(boolean onTop)

ইনভোক করা হলে, এই কলব্যাক Activity#onResume() এবং Activity#onPause()-এর মধ্যে কল করা হয়। এই কলব্যাক ঐচ্ছিক এবং এড়িয়ে যাওয়া যায়, তাই কোনও অ্যাক্টিভিটি সিস্টেমের সবচেয়ে উপরে না থেকেও RESUMED থেকে PAUSED স্টেটে যেতে পারে। যেমন, মাল্টি-উইন্ডো মোডে। এই কলব্যাক ঐচ্ছিক হওয়ায়, এটি অ্যাক্টিভিটি লাইফসাইকেলের অংশ নয় এবং খুব কমই ব্যবহার করা উচিত।

আগের সবচেয়ে বেশি বার আবার চালু করা অ্যাক্টিভিটি পরের সবচেয়ে বেশি বার আবার চালু করা অ্যাক্টিভিটি onTopResumedActivity(true) পাওয়ার আগে onTopResumedActivity(false) পায় এবং সেটির এক্সিকিউশন সম্পূর্ণ করে, যদি না আগের অ্যাক্টিভিটি মেথড কল হ্যান্ডেল করতে অনেক বেশি সময় নেয় এবং ৫০০ মিলিসেকেন্ডের টাইম-আউট হিট করে।

মানানসই

মাল্টি-রিজিউম প্রয়োগ করার সময় মানানসইতা বজায় রাখতে, এইসব সমাধান বিবেচনা করুন।

একটি অ্যাপ প্রসেসে একাধিক আবার চালু করা অ্যাক্টিভিটি

• সমস্যা। Android 9 ও তার আগের ভার্সনে, সিস্টেমে শুধুমাত্র একটি অ্যাক্টিভিটি একবারে আবার চালু করা হয়। অ্যাক্টিভিটির মধ্যে সব ট্রানজিশনে অন্য অ্যাক্টিভিটি আবার শুরু করার আগে একটি অ্যাক্টিভিটি পজ করা হয়। কিছু অ্যাপ ও ফ্রেমওয়ার্ক (যেমন, Flutter বা Android-এর LocalActivityManager) এই তথ্য ব্যবহার করে এবং আবার চালু করা অ্যাক্টিভিটি সংক্রান্ত স্টেট সিঙ্গলটনে স্টোর করে।
• সমাধান। Android 9 ও তার আগের ভার্সনে, একই প্রসেস থেকে দুটি অ্যাক্টিভিটি রিজিউম করা হলে, সিস্টেম শুধুমাত্র সেই অ্যাক্টিভিটি রিজিউম করে যেটি Z-অর্ডারে বেশি। Android 10-এর জন্য তৈরি করা অ্যাপ একই সাথে একাধিক অ্যাক্টিভিটি আবার চালু করতে পারে।

একই সাথে ক্যামেরা অ্যাক্সেস করা

• সমস্যা। এইসব সমস্যা Android 9 ও তার আগের ভার্সনেও দেখা যায়। যেমন, ফুলস্ক্রিন ও আবার চালু করা অ্যাক্টিভিটি, ছবির-মধ্যে-ছবি মোডে উপরে পজ করা অ্যাক্টিভিটির জন্য ক্যামেরার ফোকাস হারাতে পারে, তবে মাল্টি-উইন্ডো ও মাল্টি-ডিসপ্লে মোড আরও বেশি করে গ্রহণ করার ফলে আরও বেশি এক্সপোজড হয়ে যায়।
  • RESUME স্টেটে পরিবর্তন করার কারণে, আবার চালু করার পরেও অ্যাপগুলি ক্যামেরা থেকে ডিসকানেক্ট হয়ে যেতে পারে। এটি সমাধান করতে, অ্যাপগুলিকে ক্র্যাশ না করেই ক্যামেরা ডিসকানেক্ট হওয়ার বিষয়টি ম্যানেজ করতে হবে। ডিসকানেক্ট হয়ে গেলে, অ্যাপ একটি ডিসকানেক্টেড কলব্যাক পায় এবং API-তে করা সব কল CameraAccessException দেখাতে শুরু করে।
  • resizeableActivity=false এক্সক্লুসিভ ক্যামেরা অ্যাক্সেসের গ্যারান্টি দেয় না, কারণ ক্যামেরা ব্যবহার করা অন্যান্য অ্যাপ অন্য ডিসপ্লেতে খোলা যেতে পারে।
• সমাধান। ক্যামেরা থেকে কোনও অ্যাপ ডিসকানেক্ট হলে, ডেভেলপারদের সেই সংক্রান্ত লজিক অন্তর্ভুক্ত করতে হবে। কোনও অ্যাপ ক্যামেরা থেকে ডিসকানেক্ট হয়ে গেলে, ক্যামেরা উপলভ্যতার কলব্যাক লক্ষ্য করে আবার কানেক্ট করার চেষ্টা করা এবং ক্যামেরা ব্যবহার চালিয়ে যাওয়া উচিত। আগে থেকে থাকা CameraManager#AvailabilityCallback#onCameraAvailable() কলব্যাক ছাড়াও, Android 10 CameraManager#AvailabilityCallback#onCameraAccessPrioritiesChanged() যোগ করেছে, যা সেইসব ক্ষেত্রে কাজ করে যেখানে একাধিক আবার চালু করা অ্যাক্টিভিটির মধ্যে ফোকাস (এবং ক্যামেরা প্রায়োরিটি) পরিবর্তন হয়। ক্যামেরার অ্যাক্সেস পাওয়ার জন্য উপযুক্ত সময় নির্ধারণ করতে, অ্যাপ ডেভেলপারদের এই দুটি কলব্যাকই ব্যবহার করা উচিত।

মাল্টি-রিজিউম

Android 10-এ, অ্যাক্টিভিটি লাইফসাইকেল স্টেট, দৃশ্যমানতা ও Z-অর্ডার দ্বারা নির্ধারিত হয়। অ্যাক্টিভিটিতে ভিজিবিলিটি আপডেট করার পরে সঠিক স্টেট নিশ্চিত করতে এবং কোন লাইফসাইকেল স্টেট প্রযোজ্য তা মূল্যায়ন করতে, বিভিন্ন লোকেশন থেকে ActivityRecord#makeActiveIfNeeded() মেথড ইনভোক করুন। Android 10-এ, অ্যাক্টিভ বলতে RESUMED অথবা PAUSED বোঝায় এবং এই দুটি ক্ষেত্রেই শুধু কাজ করে।

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

সবচেয়ে বেশিবার আবার চালু করা অ্যাক্টিভিটি কলব্যাক

টপ অ্যাক্টিভিটিতে পরিবর্তন হতে পারে এমন অ্যাকশনের পরে (যেমন, অ্যাক্টিভিটি লঞ্চ, আবার চালু করা বা Z-অর্ডার পরিবর্তন), ActivityStackSupervisor#updateTopResumedActivityIfNeeded() ইনভোক করা হয়। এই পদ্ধতিটি চেক করে যে সবচেয়ে উপরে থাকা আবার চালু করা অ্যাক্টিভিটি পরিবর্তন হয়েছে কিনা এবং প্রয়োজন হলে আপডেট করে। আগের টপ-রিজিউমড অ্যাক্টিভিটি টপ-রিজিউমড স্টেট রিলিজ না করলে, সেটিকে টপ-রিজিউমড-স্টেট-লস মেসেজ পাঠানো হয় এবং সার্ভার সাইডে একটি টাইমআউট শিডিউল করা হয় (ActivityStackSupervisor#scheduleTopResumedStateLossTimeout())। আগের অ্যাক্টিভিটি স্টেট রিলিজ করার পরে বা টাইমআউট হলে, পরবর্তী অ্যাক্টিভিটিকে টপ-রিজিউমড স্টেটের রিপোর্ট পাঠানো হয় (ব্যবহার দেখুন:

ActivityStackSupervisor#scheduleTopResumedActivityStateIfNeeded()

ক্লায়েন্টদের টপ-রিজিউমড স্টেট পরিবর্তন সম্পর্কে জানাতে একটি নতুন TopResumedActivityChangeItem ট্রানজ্যাকশন আইটেম যোগ করা হয়েছে এবং এটি Android 9 থেকে ActivityLifecycler আর্কিটেকচার ব্যবহার করে।

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