Jetpack Compose বনাম React Native — অফলাইন ও ডিভাইস ফিচার তুলনা

আপনি আসলে কী তুলনা করছেন

“ডিভাইস ফিচার” বলতে সাধারণত ফোনের সাথে অ্যাপকে অবশ্যভাবে যুক্ত করে এমন অংশগুলোকে বোঝায়: ক্যামেরা ক্যাপচার, GPS, Bluetooth স্ক্যানিং, পুশ নোটিফিকেশন, ফাইল অ্যাক্সেস (ডাউনলোড, PDF, অ্যাটাচমেন্ট), এবং ব্যাকগ্রাউন্ড টাস্ক যেমন স্টেপ কাউন্টিং বা নেটওয়ার্ক স্ট্যাটাস। আসল প্রশ্নটা হলো “এটা কি করতে পারে?” না, বরং “হার্ডওয়্যার পর্যন্ত পৌঁছানোর পথটা কতটা সরাসরি এবং এটা ডিভাইস ও OS ভার্সন জুড়ে কতটা পূর্বনির্ধারিত?”

অফলাইন মোড পুরো কাজটাই বদলে দেয়। এটা কোনো সুইচ নয় যা বলে “ইন্টারনেট ছাড়াই কাজ করে।” আপনার লোকাল স্টোরেজ লাগবে, কোন ডেটা স্টেল হতে পারে তার সুনির্দিষ্ট ধারণা লাগবে, এবং পরিবর্তন সংঘর্ষ হলে কী হবে তার নিয়ম লাগবে (উদাহরণ: ব্যবহারকারী অফলাইনে একটি অর্ডার এডিট করেছে, একই অর্ডার সার্ভারে আপডেট হয়েছে)। একবার আপনি সিঙ্ক যুক্ত করলে, আপনি একটি ছোট সিস্টেম ডিজাইন করছেন, কেবল একটি স্ক্রিন নয়।

Compose বনাম React Native প্রায়ই নেটিভ বনাম ক্রস-প্ল্যাটফর্ম হিসেবে ফ্রেম করা হয়, কিন্তু অফলাইন ও ডিভাইস কাজের ক্ষেত্রে পার্থক্য সিলের কাছে দেখা যায়: আপনি কতগুলি ব্রিজ, প্লাগইন ও ওয়ার্কঅ্যারাউন্ডের ওপর নির্ভর করছেন, এবং যখন কোনো নির্দিষ্ট ফোন মডেলে কিছু ভেঙে যায় তখন ডিবাগ করা কতটা সহজ।

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

ডিভাইস ফিচারে অ্যাক্সেস: প্লম্বিং কিভাবে ভিন্ন

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

Android-এ Jetpack Compose হলো UI লেয়ার। আপনার কোড তখনও সাধারণ Android SDK এবং একই নেটিভ লাইব্রেরি ব্যবহার করে যা “ক্লাসিক” Android অ্যাপ ব্যবহার করে। ডিভাইস ফিচারগুলো সরাসরি মনে হয়: আপনি Android API কল করেন, পারমিশন হ্যান্ডেল করেন, এবং SDK ইন্টিগ্রেট করেন কোনো অনুবাদ স্তরের দরকার ছাড়াই। কোনো ভেন্ডার যদি স্ক্যানার বা MDM টুলের জন্য Android লাইব্রেরি দেয়, আপনি সাধারণত তা যোগ করে সোজাসুজি ব্যবহার করতে পারবেন।

React Native বেশিরভাগ অ্যাপ লজিকের জন্য JavaScript চালায়, তাই ডিভাইসে অ্যাক্সেস নেটিভ মডিউলের মধ্য দিয়ে যায়। একটি মডিউল হলো ছোট একটি Android (Kotlin/Java) এবং iOS (Swift/Obj-C) কোড যা একটি ডিভাইস ফিচারকে JavaScript-এ এক্সপোজ করে। অনেক সাধারণ ফিচার বিদ্যমান মডিউলগুলো কভার করে, কিন্তু আপনি তখনও ব্রিজ (বা নতুন JSI/TurboModules পদ্ধতি) ব্যবহার করে নেটিভ ও JavaScript’র মধ্যে ডেটা পাঠাবেন।

যখন আপনি এমন একটি ফিচারে পৌঁছান যা কভার করা নেই, পথগুলো ভিন্ন হয়ে যায়। Compose-এ আপনি বেশি নেটিভ কোড লিখেন। React Native-এ আপনি একটি কাস্টম নেটিভ মডিউল লিখবেন এবং সেটি দুই প্ল্যাটফর্মের জন্য মেইনটেইন করতে হবে। এটাই যেখানে “আমরা ক্রস-প্ল্যাটফর্ম বেছে নিয়েছি” ধীরে ধীরে হয়ে ওঠে “এখন আমাদের তিনটি কোডবেস আছে: JS, Android নেটিভ, iOS নেটিভ।”

টিম ফিট ভাবার একটি বাস্তব দিক:

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

ব্যবহারিক পারফরম্যান্স: ব্যবহারকারীরা কোথায় ফিল করে

বাস্তব “ফিল” পার্থক্য কয়েকটি মুহূর্তে দেখা দেয়: অ্যাপ খোলার সময়, স্ক্রিনের মধ্যে চলাচলের সময়, এবং যখন UI কাজ করছে অথচ ব্যবহারকারী এখনও ট্যাপ করছে।

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

লোডের নিচে রেসপন্সিভনেস পরের বড় বিষয়। যদি আপনি বড় JSON পার্স করেন, একটি দীর্ঘ তালিকা ফিল্টার করেন, বা ফর্মের জন্য মোট হিসাব করেন, Compose অ্যাপ সাধারণত সেই কাজগুলো Kotlin coroutines-এ ঠেলে দিয়ে মেইন থ্রেডকে মুক্ত রাখে। React Native-এ, কিছুই JS থ্রেড ব্লক করলে ট্যাপ ও এনিমেশন “স্টিকি” লাগতে পারে, তাই প্রায়ই ব্যয়বহুল কাজ নেটিভ কোডে সরাতে হয় বা সাবধানে শিডিউল করতে হয়।

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

ব্যাটারি ও ব্যাকগ্রাউন্ড কাজ প্রায়ই আপনার সিঙ্ক পদ্ধতির ওপর নির্ভর করে। Android-এ Compose অ্যাপগুলো প্ল্যাটফর্ম টুল যেমন WorkManager-এর ওপর নির্ভর করতে পারে পূর্বানুমেয় শিডিউলিংয়ের জন্য। React Native-এ ব্যাকগ্রাউন্ড সিঙ্ক নেটিভ মডিউল ও OS সীমার উপর নির্ভর করে, তাই নির্ভরতায় ভিন্নতা বেশি থাকে। অতিরিক্ত পোলিং দুটো ক্ষেত্রেই ব্যাটারি খেয়ে ফেলে।

যদি পারফরম্যান্স হয় প্রধান ঝুঁকি, একটি “সমস্যা স্ক্রিন” প্রথমে বানান: আপনার সবথেকে ভারী তালিকা এবং একটি অফলাইন ফর্ম বাস্তব ডেটা ভলিউম নিয়ে। এটি মিড-রেঞ্জ ডিভাইসে মাপুন, শুধুই ফ্ল্যাগশিপ নয়।

অফলাইন মোডের মৌলিক: ডেটা স্টোরেজ ও স্টেট

অফলাইন মোড মূলত একটি ডেটা সমস্যা, UI সমস্যা নয়। যেই UI স্ট্যাকই নিন, কঠিন অংশ হল আপনি কি ডিভাইসে রাখবেন, অফলাইনে UI কি দেখাবে, এবং পরে পরিবর্তন কিভাবে মিলবে—এগুলো নির্ধারণ করা।

লোকাল স্টোরেজ: সঠিক টুল বাছাই করুন

একটি সহজ নিয়ম: গুরুত্বপূর্ণ ইউজার-উৎপন্ন ডেটা বাস্তব ডেটাবেসে রাখুন, অনুচিত কেভ্যালু ফিল্ডে নয়।

স্ট্রাকচর্ড ডেটা যা আপনি কোয়েরি ও সোরট করবেন (অর্ডার, লাইন আইটেম, কাস্টমার, ড্রাফট) তার জন্য ডেটাবেস ব্যবহার করুন। ছোট সেটিংস (টিউটোরিয়াল দেখা হয়েছে কি না, টোকেন, শেষ নির্বাচিত ফিল্টার) জন্য কেভ্যালু স্টোর ব্যবহার করুন। ব্লবগুলোর জন্য ফাইল ব্যবহার করুন (ফটো, PDF, cached exports, বড় অ্যাটাচমেন্ট)।

Android-এ Compose নিয়ে টিমরা প্রায়ই Room বা অন্যান্য SQLite-ভিত্তিক অপশন ব্যবহার করে ছোট কেভ্যালু স্টোর যোগ করে। React Native-এ সাধারণত আপনি SQLite/Realm-স্টাইল স্টোরেজের জন্য একটি লাইব্রেরি যোগ করবেন এবং সেটিংসের জন্য আলাদা কেভ্যালু স্টোর (AsyncStorage/MMKV-like) রাখবেন।

অফলাইন-ফার্স্ট ফ্লো: লোকালকে সোর্স অফ ট্রুথ ভাবুন

অফলাইন-ফার্স্ট মানে create/edit/delete আগে লোকালেই ঘটে, পরে সিঙ্ক করা হয়। একটি বাস্তব ধাঁচ হচ্ছে: লোকাল DB-এ লিখুন, লোকাল DB-থেকে UI আপডেট করুন, এবং ফলে পরিবর্তনগুলো ব্যাকগ্রাউন্ডে সার্ভারে পুশ করুন যখন সম্ভব। উদাহরণ: একজন সেলসম্যান প্লেনে অর্ডার এডিট করে, তা তাদের তালিকায় সাথে সাথেই দেখে, এবং অ্যাপ সিঙ্ক টাস্ক কিউ করে পরে চালায়।

কনফ্লিক্ট হয় যখন একই রেকর্ড দুই ডিভাইসে পরিবর্তিত হয়। সাধারণ কৌশল হলো last-write-wins (সরল, ডেটা হারাতে পারে), merge (নোটস মত সংযোজনধর্মী ক্ষেত্রে ভাল), বা user review (দাম বা পরিমাণের মতো ক্ষেত্রে সঠিকতা জরুরি হলে সেরা)।

বাগ এড়াতে পরিস্কারভাবে “ত্রুৎ” নির্ধারণ করুন:

• UI স্টেট সাময়িক (ব্যবহারকারী এখন যা টাইপ করছে)।
• স্টোরড স্টেট স্থায়ী (ক্র্যাশের পরে রিলোড করা যায়)।
• সার্ভার স্টেট শেয়ার্ড (অন্য ডিভাইসগুলো পরে দেখবে)।

এই সীমা রাখলে এবং অফলাইন আচরণ স্পষ্ট রাখলে ফর্ম ও তালিকা বড় হলেও পূর্বানুমেয় থাকে।

ব্যাকগ্রাউন্ড সিঙ্ক নির্ভরযোগ্যতা: কী ভাঙে এবং কেন

ব্যাকগ্রাউন্ড সিঙ্ক প্রায়ই ফোনের কারণে ব্যর্থ হয় আপনার কোডের কারণে নয়। Android ও iOS উভয়ই ব্যাটারি, ডেটা, ও পারফরম্যান্স রক্ষা করতে ব্যাকগ্রাউন্ডে অ্যাপ কী করতে পারে তা সীমিত করে। ব্যবহারকারী যদি ব্যাটারি সেভার চালু করে, ব্যাকগ্রাউন্ড ডাটা নিষ্ক্রিয় করে, বা অ্যাপকে ফোর্স-কিল করে, তাহলে আপনার “প্রতি ৫ মিনিটে সিঙ্ক” প্রতিশ্রুতি হয়ে যায় “OS যখন ইচ্ছে তখন সিঙ্ক”।

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

Compose ও React Native-এর মধ্যে মূল পার্থক্য হলো ব্যাকগ্রাউন্ড কাজ কোথায় থাকে। Compose অ্যাপগুলো সাধারণত নেটিভ কোডে ব্যাকগ্রাউন্ড টাস্ক চালায়, তাই শিডিউলিং ও রিট্রাই লজিক OS-এর কাছাকাছি থাকে। React Native সম্পর্কে বলতে গেলে, এটি ভালোও হতে পারে, কিন্তু ব্যাকগ্রাউন্ড টাস্ক প্রায়ই অতিরিক্ত নেটিভ সেটআপ ও তৃতীয়-পক্ষ মডিউলের ওপর নির্ভর করে। সাধারণ ত্রুটির মধ্যে আছে: টাস্ক ঠিকভাবে রেজিস্টার না করা, হেডলেস টাস্ক OS দ্বারা মারা পড়া, অথবা JS রানটাইম প্রত্যাশা অনুযায়ী জাগ্রত না হওয়া।

সিঙ্ক কাজ করছে কি না প্রমাণ করার জন্য এটাকে প্রোডাকশন ফিচারের মতো আচরণ করুন এবং পরিমাপ করুন। লগ রাখুন যে “এটা চলেছে কি?” এবং “এটা শেষ হয়েছে কি?” উত্তর করে এমন তথ্য। ট্র্যাক করুন কখন একটি সিঙ্ক জব শিডিউল করা হয়েছিল, চালু হয়েছে এবং শেষ হয়েছে; নেটওয়ার্ক ও ব্যাটারি-সেভার স্টেট; কিউ করা আইটেম, আপলোড করা, ব্যর্থ ও রিট্রাই করা (এরর কোডসহ); প্রতি ব্যবহারকারী/ডিভাইসের শেষ সফল সিঙ্ক থেকে সময়; এবং কনফ্লিক্ট আউটকাম।

একটি সহজ টেস্ট: ফোনটি জ্যাকেটে রাখুন বা পকেটে রেখে রাত কাটান। যদি সকালে ডিভাইস জুড়ে সিঙ্ক সফল হয়, আপনি সঠিক পথে রয়েছেন।

জটিল ফর্ম: ভ্যালিডেশন, ড্রাফট এবং UX বিশদ

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

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

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

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

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

লম্বা তালিকা: স্মুথ স্ক্রোলিং ও মেমরি ব্যবহার

লম্বা তালিকায় ব্যবহারকারীরা প্রথমেই সমস্যা টিপে: স্ক্রোলিং, ট্যাপিং, ও দ্রুত ফিল্টারিং। উভয়ই দ্রুত হতে পারে, কিন্তু বিভিন্ন কারণে ধীর হয়।

Compose-এ লম্বা তালিকা সাধারণত LazyColumn (এবং LazyRow) দিয়ে নির্মিত হয়। এটা স্ক্রিনে যা দরকার শুধুই সেটাই রেন্ডার করে, যা মেমরি ব্যবহারে সাহায্য করে। তবুও প্রতিটি রো কম দামে আঁকতে হবে। আইটেম কম্পোজেবলগুলোর ভিতরে ভারী কাজ হলে, বা স্টেট পরিবর্তনগুলো বিস্তৃত রিকম্পোজিশন ট্রিগার করলে স্টাটার হতে পারে।

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

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

আপনার অ্যাপের জন্য বেছে নেওয়ার ধাপে ধাপে উপায়

প্রথমে প্রয়োজনীয়তাগুলো প্লেইন ভাষায় লিখুন, ফ্রেমওয়ার্ক টার্মে নয়। “অল্প আলোতে বারকোড স্ক্যান করা”, “প্রতি অর্ডারে ১০টি ছবি অ্যাটাচ করা”, “২ দিন কোনো সিগন্যাল ছাড়াই কাজ করা”, এবং “ফোন লক থাকাকালীন নীরবে সিঙ্ক করা” মত শর্তগুলো ট্রেডঅফগুলো স্পষ্ট করে।

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

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

ব্যবহারকারীরা আসলে যা অনুভব করে তা পরিমাপ করুন: কোল্ড স্টার্ট টাইম, স্ক্রল স্মুথনেস, এবং ক্র্যাশ-ফ্রি সেশন। পারফেক্ট বেঞ্চমার্কের পেছনে না ছুটে একটি সহজ বেসলাইন বারবার পুনরাবৃত্তি করা ভাল।

সাধারণ ভুল ও ফাঁদ

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

একটি সাধারণ ফাঁদ হলো ব্যাকগ্রাউন্ড সিঙ্ককে ধরে নেওয়া যে এটি আপনার নির্দেশ মতো সবসময় চলবে। Android ও iOS ব্যাটারি ও ডেটা বাঁচাতে কাজগুলো বিলম্ব বা বন্ধ করবে। আপনার ডিজাইন যদি তাত্ক্ষণিক আপলোড ধরে, আপনি “মিসিং আপডেট” রিপোর্ট পাবেন যা আসলে OS শিডিউলিং করছে।

আরেকটা ফাঁদ হলো UI আগে বানিয়ে ডেটা মডেল পরে ঠিক করা। অফলাইন কনফ্লিক্টগুলো চালু হয়ে গেলে পরে ঠিক করা অনেক কঠিন। আগে ঠিক করে নিন একই রেকর্ড দুবার এডিট হলে কী হবে, বা একটি জিনিস ডিলিট করলে যা কখনো আপলোড হয়নি সে ব্যাপারে কী হবে।

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

এই প্যাটার্নগুলো নজর রাখুন:

• ব্যাকগ্রাউন্ড কাজকে টায়মারে রান করবে বলে ধরে নেওয়া বদ। OS-র নিয়ম অনুসারে এটি best-effort।
• অফলাইনকে একটি টগল হিসেবে না দেখে ডেটা ও কনফ্লিক্ট মডেলের মূল অংশ হিসেবে নেওয়া।
• একটি ফর্মকে একসঙ্গে তিনটি জিনিস (ড্রাফট, সেভড লোকাল, সিঙ্কড) হিসেবে রেখে স্পষ্ট নিয়ম না থাকা।
• কেবল দ্রুত ফোন ও স্থিতিশীল Wi-Fi-তে পরীক্ষা করা এবং পরে ধীর তালিকা ও আটকে যাওয়া আপলোডে বিস্মিত হওয়া।
• অনেক থার্ড-পার্টি প্লাগইন যোগ করা, পরে একটি আনমেইনটেইনড বা এজ-কেসে ব্যর্থ হওয়া।

একটি দ্রুত বাস্তবতা চেক: একজন ফিল্ড রিপ বেসমেন্টে সিগন্যাল ছাড়া অর্ডার তৈরি করে, তাকে দুবার এডিট করে, তারপর বাইরে চলে যায়। যদি অ্যাপ ব্যাখ্যা করতে না পারে কোন ভার্সন সিঙ্ক হবে, বা ব্যাটারি সীমাবদ্ধতার কারণে সিঙ্ক ব্লক হয়, রিপ অ্যাপকেই দোষ দেবে, নেটওয়ার্ককে নয়।

কমিট করার আগে দ্রুত চেকলিস্ট

স্ট্যাক বেছে নেওয়ার আগে একটি ছোট “রিয়েল” স্লাইস বানান এবং স্কোর দিন। যদি একটি আইটেম ফেল করে, তা পরে সপ্তাহের কাজ হয়ে দাঁড়ায়।

প্রথমে অফলাইন কমপ্লিশন চেক করুন: ব্যবহারকারীরা কি নেটওয়ার্ক ছাড়াই উপরের তিনটি টাস্ক শেষ করতে পারে, ত্রুটিমুক্ত খালি স্টেট বা ডুপ্লিকেট আইটেম ছাড়া? তারপর সিঙ্ক চাপ দিন: দুর্বল Wi-Fi-এ রিট্রাই ও ব্যাকঅফ, আপলোড মাঝখানে অ্যাপ কিল হওয়া, এবং ব্যবহারকারী-বোধগম্য স্ট্যাটাস যেমন “Saved on device” বনাম “Sent”। দীর্ঘ, শর্তসাপেক্ষ ফ্লো দিয়ে ফর্ম ভ্যালিডেট করুন: ড্রাফট ক্র্যাশ বা ফোর্সড ক্লোজের পরে ঠিক যেখানে ছিল সেখানে পুনরায় খোলা উচিত। হাজার হাজার রো সহ তালিকাকে টেনে দেখুন, ফিল্টার ও ইন-প্লেস আপডেট দিয়ে, ড্রপ হওয়া ফ্রেম ও মেমরি স্পাইক লক্ষ্য করে। অবশেষে, পারমিশন “only while using”, ব্যাটারি সেভার অন, ব্যাকগ্রাউন্ড ডাটা সীমাবদ্ধ—এসব অবস্থায় ডিভাইস ফিচারগুলো পরীক্ষা করুন এবং নম্রভাবে ব্যাকফল ব্যাবহার করুন।

একটি ব্যবহারিক টিপ: টেস্ট সময়বদ্ধ করুন—প্রতি পদ্ধতির জন্য ২–৩ দিন। যদি এই সময়ের মধ্যে “অফলাইন + সিঙ্ক + লম্বা তালিকা + জটিল ফর্ম” স্লাইসটি মসৃণ করতে না পারেন, ভবিষ্যতে চালিয়ে যেতে অসুবিধা হবে।

উদাহরণ সিনারিও: মাঠের সেলস অ্যাপ অফলাইন অর্ডারসহ

ধরা যাক একটি মাঠ সেলস টিম ছোট দোকানে বিক্রি করে। অ্যাপটিতে অফলাইন অর্ডার, ছবি ক্যাপচার (শেলফ ও রসিদ), বড় প্রোডাক্ট ক্যাটালগ, এবং দৈনিক সিঙ্ক লাগবে HQ-তে।

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

দিনভর: কানেক্টিভিটি ঘণ্টাখানেক জন্য বন্ধ। রিপ পাঁচটি অর্ডার তৈরি করে, প্রতিটিতে ডিসকাউন্ট, নোট, ও ছবি। অফলাইন মোড কেবল লোকাল স্টোরেজ নয়—এটি কনফ্লিক্ট রুল (যদি প্রাইস লিস্ট পরিবর্তিত হয়), স্পষ্ট স্ট্যাটাস (Saved, Pending Sync, Synced), এবং সুরক্ষিত ড্রাফট—ফর্ম ফোন কল, ক্যামেরা ব্যবহার, বা অ্যাপ রিস্টার্ট সহ টিকে থাকবে—এসবকেও কভার করে।

সন্ধ্যা: রিপ যখন কভারেজে ফিরে আসে। এই টিমের জন্য “পর্যাপ্ত নির্ভরযোগ্য” ব্যাকগ্রাউন্ড সিঙ্ক মানে হলো অর্ডারগুলো নেটওয়ার্ক ফিরে আসার পর কয়েক মিনিটের মধ্যে অটোমেটিক আপলোড হওয়া, ব্যর্থ আপলোড গুলো ডুপ্লিকেট ছাড়া রিট্রাই হওয়া, ছবিগুলো কিউ ও কম্প্রেস করে যাতে সিঙ্ক আটকে না যায়, এবং রিপ “Sync now” ট্যাপ করলে কি হয়েছে তা দেখতে পারা।

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

পরবর্তী ধাপ: ছোট বিল্ড দিয়ে আপনার পছন্দ যাচাই করুন

আপনি অদলবদল করে থাকলে একটি স্বল্প, কেন্দ্রীভূত স্পাইক চালান। আপনাকে পুরো অ্যাপ শেষ করতে হবে না—আপনি প্রথম বাস্তব সীমাটি খুঁজে বের করতে চান।

সোজা পরিকল্পনা ব্যবহার করুন: এমন একটি ডিভাইস ফিচার বেছে নিন যা আপনি কমপ্রোমাইজ করতে পারবেন না (উদাহরণ: বারকোড স্ক্যান প্লাস ফটো), একটি অফলাইন ওয়ার্কফ্লো সিলেক্ট করুন (তৈরি করা, এডিট, ড্রাফট সেভ, ফোন রিবুট, পুনরায় খুলে সাবমিট), এবং একটি সিঙ্ক জব বাছুন (অফলাইনে অ্যাকশন কিউ করা, দুর্বল নেটওয়ার্কে রিট্রাই, সার্ভার রিজেক্ট হ্যান্ডল, স্পষ্ট এরর স্টেট দেখানো)।

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

যদি আপনাকে ব্যাকএন্ড ও অ্যাডমিন UI-ও একসাথে বানাতে হয়, AppMaster (AppMaster) আপনার জন্য একটি ব্যবহারিক বেসলাইন হতে পারে: এটি প্রোডাকশন-রেডি ব্যাকএন্ড, ওয়েব, এবং নেটিভ মোবাইল কোড জেনারেট করে, যাতে আপনি ডেটা মডেল ও ওয়ার্কফ্লো ত্বরান্বিতভাবে ভ্যালিডেট করতে পারেন।