SQLite বনাম Realm: ফিল্ড অ্যাপে অফলাইন-প্রাথমিক স্টোরেজ

একটি ফিল্ড অ্যাপকে আসলে কী লাগে অফলাইন-প্রথম হিসেবে\n\nঅফলাইন-প্রথম মানে কেবল “ইন্টারনেট ছাড়া কাজ করে” নয়। এর মানে হলো অ্যাপ দরকারী ডেটা লোড করতে পারে, নতুন ইনপুট গ্রহণ করতে পারে, এবং যতক্ষণ না সিঙ্ক হয় প্রতিটি এডিট নিরাপদে রাখে।\n\nফিল্ড কাজ কিছু পূর্বানুমেয় সীমা যোগ করে: সিগন্যাল মাঝে মধ্যে চলে আসে-যায়, সেশনগুলো দীর্ঘ হয়, ডিভাইসগুলো পুরোনো হতে পারে, এবং ব্যাটারি-সেভার মোড সাধারণ। মানুষ দ্রুত কাজ করে। তারা একটি কাজ খুলে, দীর্ঘ তালিকা স্ক্রল করে, ছবি তোলে, ফর্ম পূরণ করে, এবং পরের কাজে ঝাঁপিয়ে পড়ে—স্টোরেজ সম্পর্কে বেশি ভাবেন না।\n\nব্যবহারকারীরা যা লক্ষ্য করে তা সহজ: এডিট হারালে তাদের আস্থা চলে যায়, যখন তালিকা ও সার্চ অফলাইনে ধীর হলে বা অ্যাপ স্পষ্টভাবে উত্তর দেয় না “আমার কাজ সেভ হয়েছে কি?”, যখন রেকর্ড নকল হয় বা সংযোগের পর মিসিং হয়ে যায়, অথবা কোনো আপডেট অদ্ভুত আচরণ করে।\n\nএই কারণেই SQLite বনাম Realm বেছে নেওয়া মূলত দৈনন্দিন ব্যবহার-আচরণ সম্পর্কিত, বেঞ্চমার্ক নয়।\n\nলোকাল ডাটাবেস বাছার আগে চারটি বিষয়ে পরিষ্কার হন: আপনার ডেটা মডেল বদলাবে, আপনার কুয়েরিগুলো বাস্তব ওয়ার্কফ্লোর সাথে মিলতে হবে, অফলাইন সিঙ্ক কনফ্লিক্ট তৈরি করবে, এবং টুলিং আপনার মাঠে সমস্যা নির্ণয়ের গতি নির্ধারণ করবে।\n\n### 1) আপনার ডেটা বদলাবে\n\nযতই অ্যাপ স্থিতিশীল মনে হোক না কেন উন্নতি আসে: নতুন চেকবক্স, স্ট্যাটাস রেনেম, নতুন স্ক্রিন। যদি মডেল পরিবর্তন কষ্টসাধ্য হয়, আপনি হয়তো কম ফিচার পাঠাবেন বা বাস্তবে ডিভাইসগুলো ভাঙিয়ে ফেলবেন।\n\n### 2) কুয়েরিগুলো বাস্তব ওয়ার্কফ্লোর সাথে মিলতে হবে\n\nফিল্ড অ্যাপগুলোকে দ্রুত ফিল্টার দরকার যেমন “আজকের কাজ”, “কাছের সাইট”, “সিঙ্ক হয়নি এমন ফর্ম”, এবং “গত ২ ঘন্টার মধ্যে এডিট করা আইটেম”। যদি ডাটাবেস এসব কুয়েরি অদ্ভুত করে দেয়, UI ধীর হয় বা কোড জটিল হয়ে যায়।\n\n### 3) অফলাইন সিঙ্ক কনফ্লিক্ট তৈরি করে\n\nদুই ব্যক্তি একই রেকর্ড এডিট করতে পারে, বা এক ডিভাইস পুরানো ডেটা আজকাল পর্যন্ত এডিট করতে পারে। আপনাকে পরিষ্কার সিদ্ধান্ত করতে হবে কী জিনিস জিতবে, কী মার্জ করা হবে, এবং কী ক্ষেত্রে মানুষের হস্তক্ষেপ লাগবে।\n\n### 4) টুলিং গুরুত্বপূর্ণ\n\nফিল্ডে কিছু ভুল হলে আপনাকে ডেটা পরীক্ষা করতে, সমস্যার পুনরাবৃত্তি করতে, এবং বোঝতে হবে কী হয়েছে—শকত অনুমান ছাড়া।\n\n## মাইগ্রেশন: ব্যবহারকারীদের ব্যাহত না করে ডেটা মডেল পরিবর্তন করা\n\nফিল্ড অ্যাপগুলি বেশিরভাগ সময় স্থির থাকে না। কয়েক সপ্তাহ পর আপনি একটি চেকবক্স যোগ করেন, একটি স্ট্যাটাস রেনেম করেন, বা “নোটস” ফিল্ডকে কাঠামোবদ্ধ ফিল্ডে ভাগ করেন। মাইগ্রেশনেই অফলাইন অ্যাপগুলো প্রায়ই ব্যর্থ হয়, কারণ ফোনে ইতিমধ্যেই বাস্তব ডেটা থাকে।\n\nSQLite টেবিল ও কলামে ডেটা রাখে। Realm অবজেক্ট ও প্রোপার্টি হিসেবে ডেটা রাখে। এই পার্থক্য দ্রুত স্পষ্ট হয়:\n\n- SQLite-এ সাধারণত আপনি স্পষ্ট স্কিমা পরিবর্তন লেখেন (ALTER TABLE, নতুন টেবিল, ডেটা কপি)।\n- Realm-এ সাধারণত আপনি স্কিমা ভার্সন বাড়ান এবং একটি মাইগ্রেশন ফাংশন চালান যা অবজেক্টগুলো ব্যবহারের সময় আপডেট করে।\n\nফিল্ড যোগ করা উভয় সিস্টেমেই সহজ: SQLite-এ একটি কলাম যোগ করুন, Realm-এ একটি প্রোপার্টি ডিফল্টের সাথে যোগ করুন। রেনেম ও স্প্লিটই কষ্টকর। SQLite-এ রেনেম নির্ভর করে আপনার সেটআপের ওপর, তাই দলগুলো প্রায়ই নতুন টেবিল তৈরি করে এবং ডেটা কপি করে। Realm-এ আপনি পুরানো প্রোপার্টি পড়ে মাইগ্রেশনের সময় নতুনগুলিতে লিখতে পারবেন, কিন্তু টাইপ, ডিফল্ট এবং নাল-হ্যান্ডলিং নিয়ে সাবধান থাকতে হবে।\n\nঅন-ডিভাইসে বড় আপডেটগুলো অতিরিক্ত সতর্কতা চায়। প্রতিটি রেকর্ড রিরাইট করা মাইগ্রেশন পুরনো ফোনে ধীর হতে পারে, এবং একজন টেকনিশিয়ান পার্কিং-এ স্পিনার দেখছে—এটা অনাকাঙ্ক্ষিত। মাইগ্রেশন সময় পরিকল্পনা করুন, এবং ভারী রূপান্তরগুলো একাধিক রিলিজে ভাগ করে দেওয়া বিবেচনা করুন।\n\nমাইগ্রেশন ন্যায্যভাবে টেস্ট করতে, সেগুলোকে সিঙ্কের মতো বিবেচনা করুন:\n\n- পুরনো বিল্ড ইনস্টল করুন, বাস্তবসমমত ডেটা তৈরি করুন, তারপর আপগ্রেড করুন।\n- ছোট ও বড় ডেটাসেট পরীক্ষা করুন।\n- মাইগ্রেশনের মাঝখানেই অ্যাপ বন্ধ করে পুনরায় চালু করুন।\n\n- কম-স্টোরেজ পরিস্থিতি পরীক্ষা করুন।\n\nউদাহরণ: যদি “equipmentId” হয়ে “assetId” হয় এবং পরে সেটা ভাগ হয়ে “assetType” ও “assetNumber” হয়, মাইগ্রেশনটি পুরানো ইন্সপেকশনগুলো ব্যবহার যোগ্য রাখবে—লগআউট বা ডাটা মুছে ফেলা চাপাস্বৰি নয়।\n\n## কুয়েরি নমনীয়তা: আপনি আপনার ডেটা থেকে কী জিজ্ঞাসা করতে পারবেন\n\nফিল্ড অ্যাপগুলো তালিকা স্ক্রিনেই বাঁচে বা মরে: আজকের কাজ, কাছের অ্যাসেট, খোলা টিকিটসহ কাস্টমার, এই সপ্তাহে ব্যবহৃত পার্টস। আপনার স্টোরেজ অপশনগুলো এসব প্রশ্নকে সহজে প্রকাশ করতে, দ্রুত চালাতে, এবং ছয় মাস পরও ভুল না পড়ার মতো হতে হবে।\n\nSQLite আপনাকে SQL দেয়, যা বড় ডেটাসেট ফিল্টার ও সোর্ট করার সবচেয়ে নমনীয় উপায়। আপনি শর্ত মিশ্রিত করতে পারেন, টেবিল জয়েন করতে পারেন, গ্রুপ করতে পারেন, এবং কোনো স্ক্রিন ধীর হলে ইনডেক্স যোগ করতে পারেন। যদি আপনার অ্যাপে “Region A তে থাকা অ্যাসেটগুলোর সব ইন্সপেকশন, Team 3-কে অ্যাসাইন করা এবং যেগুলোতে কোনো failed checklist আইটেম আছে” ধরনের জটিল কুয়েরি লাগে, SQL সাধারণত সেটি পরিষ্কারভাবে প্রকাশ করে।\n\nRealm অবজেক্ট ও উচ্চ-স্তরের কুয়েরি API-এর ওপর ঝুঁকে পড়ে। অনেক অ্যাপের জন্য এটি প্রাকৃতিক লাগে: Job অবজেক্ট কুয়েরি করুন, স্ট্যাটাস দ্বারা ফিল্টার করুন, ডিউ ডেট অনুযায়ী সোর্ট করুন, সম্পর্কিত অবজেক্টগুলো অনুসরণ করুন। ট্রেডঅফ হচ্ছে—যেসব প্রশ্ন SQL-এ সহজ (বিশেষত একাধিক সম্পর্ক জুড়ে রিপোর্ট-স্টাইল কুয়েরি), সেগুলো প্রকাশ করতে Realm-এ বেশি পরিকল্পনা লাগতে পারে, অথবা আপনাকে ডেটাকে কুয়েরিগুলোর অনুকূল করে রিশেপ করতে হতে পারে।\n\n### সার্চ ও সম্পর্ক\n\nবহু ফিল্ড জুড়ে আংশিক টেক্সট সার্চের জন্য (জব টাইটেল, কাস্টমার নাম, ঠিকানা), SQLite আপনাকে সচেতন ইনডেক্সিং বা একটি ডেডিকেটেড ফুল-টেক্সট পদ্ধতির দিকে ঠেলে দিতে পারে। Realm টেক্সট ফিল্টার করতে পারে, কিন্তু পারফরম্যান্স এবং বড় স্কেলে “contains” কীভাবে কাজ করে সে বিষয়ে ভাবতে হবে।\n\nসম্পর্কগুলোও বাস্তবব্যবহার সমস্যা। SQLite ওয়ান-টু-মেনি এবং মেনি-টু-মেনি জয়েন টেবিল দিয়ে হ্যান্ডেল করে, যা “এই দুই ট্যাগসহ অ্যাসেট” ধরনের প্যাটার্নগুলো সহজ করে তোলে। Realm লিঙ্কগুলো কোডে নেভিগেট করা সহজ করে, কিন্তু মেনি-টু-মেনি ও ‘কুয়েরি থ্রু’ প্যাটার্নগুলো দ্রুত পড়ার জন্য বেশি পরিকল্পনা প্রয়োজন।\n\n### র’ কুয়েরি বনাম মেন্টেইনেবল কোড\n\nরক্ষণাবেক্ষণ-বান্ধব প্যাটার্ন হলো named কুয়েরির একটি ছোট সেট রাখা যা সরাসরি স্ক্রিন ও রিপোর্টগুলোর সাথে মিলে যায়: আপনার মূল তালিকা ফিল্টার ও সোর্ট, একটি ডিটেইল ভিউ কুয়েরি (এক রেকর্ড ও সম্পর্কিত রেকর্ড), সার্চ ডেফিনিশন, কয়েকটি কাউন্টার (ব্যাজ ও অফলাইন টোটাল), এবং যেকোনো এক্সপোর্ট/রিপোর্ট কুয়েরি।\n\nযদি ব্যবসা থেকে নিয়মিত অ্যাড-হক প্রশ্ন আসার আশা থাকে, SQLite-এর র’ কুয়েরি ক্ষমতা হারানো কঠিন। আর যদি আপনি চাইছেন অধিকাংশ ডেটা অ্যাকসেস সাধারণ অবজেক্টের মতো পড়ুক, Realm দ্রুত তৈরি মনে হতে পারে—যতক্ষণ তা আপনার কঠিন স্ক্রিনগুলো awkward করার দরকার না করে।\n\n## কনফ্লিক্ট রেজলিউশন ও সিঙ্ক: কোন সহায়তা পাবেন\n\nঅফলাইন-প্রথম ফিল্ড অ্যাপগুলো সাধারণত একই মৌলিক কাজগুলোকে সমর্থন করে নেটওয়ার্ক ছাড়াও: রেকর্ড তৈরি, রেকর্ড আপডেট, অবৈধ কিছু মুছে ফেলা। কঠিন অংশ লোকারেল সেভ নয়—কঠিন হচ্ছে যখন দুই ডিভাইস একই রেকর্ড পরিবর্তন করে এবং সেগুলো সিঙ্ক হওয়ার আগে।\n\nকনফ্লিক্ট সাধারণত সহজ পরিস্থিতিতে দেখা দেয়। একজন টেকনিশিয়ান বেসমেন্টে সিগন্যাল না থাকায় একটি ইন্সপেকশন আপডেট করে। পরে সুপারভাইজার একই ইন্সপেকশন ল্যাপটপ থেকে ঠিক করে। দু’জন যখন রিকনেক্ট করে, সার্ভার দুইটা ভিন্ন ভার্সন পায়।\n\nঅনেক দল এই পন্থাগুলোর মধ্যে পড়ে:\n\n- লাস্ট রাইট উইনস (দ্রুত, কিন্তু ভালো ডেটা নীরবে ওভাররাইট হতে পারে)\n- ফিল্ড অনুযায়ী মার্জ (যদি বিভিন্ন ফিল্ড বদলে থাকে তবে বেশি নিরাপদ, কিন্তু স্পষ্ট নিয়ম দরকার)\n- ম্যানুয়াল রিভিউ কিউ (ধীরতম, উচ্চ ঝুঁকির ক্ষেত্রে সেরা)\n\nSQLite আপনাকে নির্ভরযোগ্য লোকাল ডাটাবেস দেয়, কিন্তু এটি নিজে সিঙ্ক সরবরাহ করে না। সাধারণত বাকি কাজ আপনি নিজে বানান: পেন্ডিং অপারেশন ট্র্যাক করা, সেগুলো API-তে পাঠানো, নিরাপদভাবে পুনরায় চেষ্টা করা, এবং সার্ভারে কনফ্লিক্ট নিয়ম প্রয়োগ করা।\n\nRealm যদি এর সিঙ্ক ফিচার ব্যবহার করেন তবে প্লাম্বিং অনেকটা কমিয়ে দিতে পারে, কারণ এটি অবজেক্ট ও চেঞ্জ-ট্র্যাকিংকে ঘিরে ডিজাইন করা। কিন্তু “বিল্ট-ইন সিঙ্ক” তবুও আপনার ব্যবসায়িক নিয়মগুলো নির্ধারণ করে না—আপনিই সিদ্ধান্ত নেবেন কী কনফ্লিক্ট এবং কোন ডেটা জিতবে।\n\nপ্রথম দিন থেকেই একটি অডিট ট্রেল পরিকল্পনা করুন। ফিল্ড টিমগুলো প্রায়ই জানতে চায় “কে কী পরিবর্তন করলো, কখন, এবং কোন ডিভাইস থেকে।” যদিও আপনি লাস্ট রাইট উইনস বেছে নেন, মেটাডেটা সংরক্ষণ করুন যেমন user ID, device ID, timestamps, এবং সম্ভব হলে একটি কারণ। যদি আপনার ব্যাকএন্ড দ্রুত তৈরি হয়—উদাহরণস্বরূপ একটি নো-কোড প্ল্যাটফর্ম AppMaster—তবে এই নিয়মগুলো দ্রুত ইটারেট করা সহজ হয়।\n\n## ডিবাগ করা ও ইনস্পেকশন: মাঠের আগে সমস্যা ধরা\n\nঅফলাইন বাগগুলো কঠিন কারণ তারা সার্ভারের সাথে অ্যাপ কথা বলার সময় ঘটে না। আপনার ডিবাগিং অভিজ্ঞতা প্রায়ই এক প্রশ্নে নেমে আসে: ডিভাইসে কি আছে এবং সেটা সময়ের সাথে কীভাবে বদলেছে, সেটা কত সহজে দেখা যায়?\n\nSQLite ইনস্পেক্ট করা সহজ কারণ এটি একটি ফাইল। ডেভেলপমেন্ট বা QA-তে আপনি টেস্ট ডিভাইস থেকে ডাটাবেস টেনে আনতে পারেন, প্রচলিত SQLite টুল দিয়ে খুলে অ্যাড-হক কুয়েরি চালাতে পারেন এবং টেবিলগুলো CSV অথবা JSON-এ এক্সপোর্ট করতে পারেন। এটি আপনাকে নিশ্চিত করতে সাহায্য করে “কোন রোয় আছে” বনাম “UI কী দেখাচ্ছে”। তদুপরি, স্কিমা, জয়েন এবং যেকোন মাইগ্রেশন স্ক্যাফল্ডিং বুঝতে হবে।\n\nRealm আরও “অ্যাপ-জাতীয়” ইনস্পেকশন মনে হতে পারে। ডেটা অবজেক্ট হিসেবে স্টোর হয়, এবং Realm-এর টুলিং প্রায়ই ক্লাস, প্রোপার্টি, ও সম্পর্ক ব্রাউজ করার সহজ উপায় দেয়। অবজেক্ট গ্রাফ ইস্যু (মিসিং লিঙ্ক, অপ্রত্যাশিত নাল) দ্রুত দেখা যায়, কিন্তু অ্যাড-হক বিশ্লেষণে এটি কম নমনীয় হতে পারে যদি টিম SQL-ভিত্তিক ইনস্পেকশন অভ্যস্ত।\n\n### অফলাইন ইস্যু লগ করা ও পুনরাবৃত্তি করা\n\nবেশিরভাগ ফিল্ড ব্যর্থতা আসে নীরব লেখার ত্রুটি, আংশিক সিঙ্ক ব্যাচ, বা মাইগ্রেশন যা মাঝপথে শেষ হয়নি—যে কোনটাই হোক, কয়েকটি বেসিক বিষয়ে বিনিয়োগ করুন: প্রতিটি রেকর্ডের “শেষ পরিবর্তিত” টাইমস্ট্যাম্প, ডিভাইস-সাইড অপারেশন লগ, মাইগ্রেশন ও ব্যাকগ্রাউন্ড লেখার চারপাশে স্ট্রাকচার্ড লগ, QA বিল্ডে ভেরবোজ লগ সক্ষম করার উপায়, এবং একটি “ডাম্প ও শেয়ার” অ্যাকশন যা একটি রেড্যাক্ট করা স্ন্যাপশট এক্সপোর্ট করে।\n\nউদাহরণ: একজন টেকনিশিয়ান রিপোর্ট করে যে সম্পন্ন ইন্সপেকশন ব্যাটারি ড্রেনের পরে অদৃশ্য হয়ে গেছে। একটি শেয়ারকৃত স্ন্যাপশট আপনাকে নিশ্চিত করতে সাহায্য করবে যে রেকর্ডগুলো কখনো লেখা হয়নি, লেখা হয়েছিল কিন্তু কুয়েরি হয়নি, বা স্টার্টআপে রোলব্যাক হয়েছে।\n\n### একটি ব্যর্থ স্ন্যাপশট শেয়ার করা\n\nSQLite-র ক্ষেত্রে শেয়ার করা সাধারণত .db ফাইল (এবং কোনো WAL ফাইল) শেয়ার করার মতো সহজ। Realm-এ আপনি সাধারণত Realm ফাইল এবং তার সাইডকার ফাইলগুলো শেয়ার করবেন। উভয় ক্ষেত্রেই, ডিভাইস থেকে কিছু পাঠানোর আগে সংবেদনশীল ডেটা সরানোর একটি পুনরাবৃত্ত প্রক্রিয়া সংজ্ঞায়িত করুন।\n\n## বাস্তব জগতে নির্ভরযোগ্যতা: ব্যর্থতা, রিসেট, এবং আপগ্রেড\n\nফিল্ড অ্যাপগুলো নিস্তেজ কারণে ব্যর্থ হয়: সেভের মাঝখানে ব্যাটারি ডাই, OS ব্যাকগ্রাউন্ডে অ্যাপ কিল করা, বা ছবিসহ সপ্তাহের পরে স্টোরেজ ফুল হয়ে যাওয়া। লোকাল ডাটাবেস নির্বাচনের ফলে এই ব্যর্থতাগুলো কতবার কাজে হারায় তা প্রভাবিত হয়।\n\nক্র্যাশ যদি লেখার মাঝখানে ঘটে, সঠিকভাবে ব্যবহৃত হলে SQLite এবং Realm দুটোই নিরাপদ হতে পারে। SQLite নির্ভরযোগ্য হলে আপনি পরিবর্তনগুলো ট্রানজেকশনে রাখেন (WAL মোড স্থিতিশীলতা ও পারফরম্যান্সে সাহায্য করে)। Realm-এ লেখাগুলো ডিফল্টে ট্রানজেকশনাল, তাই সাধারণত আপনি অতিরিক্ত কাজ ছাড়াই “সব বা কিছুই নয়” সেভ পান। সাধারণ ঝুঁকি হল এমন অ্যাপ কোড যা একাধিক ধাপে লেখে কিন্তু সুনির্দিষ্ট কমিট পয়েন্ট নেই।\n\nকরাপশন বিরল, কিন্তু একটি রিকভারি প্ল্যান থাকা দরকার। SQLite-এ আপনি integrity checks চালাতে পারেন, পরিচিত-ভাল ব্যাকআপ থেকে রিস্টোর করতে পারেন, বা সার্ভার রিসিঙ্ক থেকে পুনর্নির্মাণ করতে পারেন। Realm-এ করাপশন হলে পুরো Realm ফাইল সন্দেহজনক হতে পারে, তাই প্রায়ই ব্যবহারিক রিকভারি পথ হলো “লোকাল মুছে দিয়ে পুনরায় সিঙ্ক” (যদি সার্ভার সৎ উৎস হয় ঠিক আছে, কিন্তু যদি ডিভাইসে অনন্য ডেটা থাকে তবে কষ্টকর)।\n\nস্টোরেজ বৃদ্ধিও একটি অবাক সমস্যা। SQLite ডিলিটের পরে ভ্যাকুয়াম না করলে বেলুন হয়ে যেতে পারে। Realm-ও বাড়তে পারে এবং কম্প্যাকশন পলিসি দরকার, সাথে পুরাতন অবজেক্টগুলি (যেমন সম্পন্ন কাজ) প্রুন করে রাখা উচিত যাতে ফাইল অনিরোধে বাড়তে না থাকে।\n\nআপগ্রেড ও রোলব্যাকও ফাঁদ। যদি একটি আপডেট স্কিমা বা স্টোরেজ ফরম্যাট বদলে দেয়, রোলব্যাক ব্যবহারকারীদের নতুন ফাইলেই আটকে দিতে পারে। আপগ্রেডগুলো একমুখী হিসাবে পরিকল্পনা করুন, নিরাপদ মাইগ্রেশন ও একটি “লোকাল ডেটা রিসেট” অপশন রাখুন যা অ্যাপকে ভাঙবে না।\n\nনির্ভরযোগ্যতার অভ্যাস যেগুলো লাভ দেয়:\n\n- “ডিস্ক ফুল” ও লেখার ব্যর্থতা পরিষ্কার বার্তা ও পুনরায় চেষ্টা পথ দিয়ে হ্যান্ডেল করুন।\n- বৃহৎ ফর্মে ইনপুট শেষ না করে চেকপয়েন্টে সেভ করুন।\n- পুনরুদ্ধার ও সাপোর্টের জন্য হালকা লোকাল অডিট লগ রাখুন।\n- ডাটাবেস অতিরিক্ত বড় হওয়ার আগে পুরাতন রেকর্ড প্রুন ও আর্কাইভ করুন।\n- নিম্ন-শেষ ডিভাইসে OS আপগ্রেড ও ব্যাকগ্রাউন্ড কিল পরীক্ষ করুন।\n\nউদাহরণ: একটি ইন্সপেকশন অ্যাপ যা চেকলিস্ট ও ছবিসহ ডেটা রাখে এক মাসে স্টোরেজ পূর্ণ করে ফেলতে পারে। যদি অ্যাপ আগে থেকেই কম স্পেস সনাক্ত করে, এটি ছবি নেওয়া স্থগিত করতে পারে, আপলোড হলে পুনরায় চালু করতে পারে, এবং চেকলিস্ট সেভগুলো নিরাপদ রাখতে পারে—যেটাই লোকাল ডাটাবেস আপনি ব্যবহার করুন না কেন।\n\n## ধাপে ধাপে: কীভাবে স্টোরেজ পদ্ধতি বেছে নেবেন ও সেটআপ করবেন\n\nস্টোরেজকে একটি লাইব্রেরি সিদ্ধান্ত হিসেবে নয়, প্রোডাক্টের অংশ হিসেবেই বিবেচনা করুন। সবচেয়ে ভাল অপশন হলো সেটাই যা সিগন্যাল পড়ে গেলে অ্যাপকে ব্যবহারে রাখে এবং সিগন্যাল ফিরে এলে প্রত্যাশিত আচরণ করে।\n\n### একটি সাধারণ সিদ্ধান্ত পথ\n\nপ্রথমে আপনার অফলাইন ইউজার ফ্লো গুলো লিখে ফেলুন। স্পষ্ট হোন: “আজকের কাজ খোলা, নোট যোগ করা, ছবি লাগানো, সম্পন্ন চিহ্নিত করা, সিগনেচার ক্যাপচার।” তালিকার প্রতিটি আইটেম নেটওয়ার্ক ছাড়াই প্রতিবার কাজ করবে।\n\nএরপর শর্ট সিকোয়েন্স অনুসরণ করুন: অফলাইন-ক্রিটিক্যাল স্ক্রিনগুলো ও প্রতিটি স্ক্রিনের জন্য কত ডেটা দরকার তা তালিকাভুক্ত করুন (আজকের কাজ বনাম পুরো ইতিহাস), একটি ন্যূনতম ডেটা মডেল ও যে সম্পর্কগুলো আপনি নকল করতে পারবেন না তা স্কেচ করুন (Job -> ChecklistItems -> Answers), প্রতিটি এন্টিটির জন্য কনফ্লিক্ট রুল নির্ধারণ করুন (সব ক্ষেত্রে এক রুল নয়), আপনি কীভাবে ত্রুটি পরীক্ষা করবেন তা সিদ্ধান্ত নিন (রিয়েল ডিভাইসে মাইগ্রেশন, সিঙ্ক রিটারাই, জোর করে লগআউট/রিইনস্টল আচরণ), এবং বাস্তবসম্মত ডেটা নিয়ে একটি ছোট প্রোটোটাইপ তৈরি করুন যা আপনি টাইম করতে পারবেন (লোড, সার্চ, সেভ, এক দিন অফলাইনে থেকে পরে সিঙ্ক)।\n\nএই প্রক্রিয়ায় সাধারণত সত্যিকার সীমাবদ্ধতা প্রকাশ পায়: আপনি কি নমনীয় অ্যাড-হক কুয়েরি ও সহজ ইনস্পেকশন চান, না কি অবজেক্ট-ভিত্তিক অ্যাক্সেস ও শক্ত মডেল এনফোর্সমেন্টকে মূল্য দেন?\n\n### প্রোটোটাইপে কী যাচাই করবেন\n\nএকটি বাস্তব সিনারিও ব্যবহার করুন, যেমন একজন টেকনিশিয়ান একদিনে ৩০টি ইন্সপেকশন অফলাইনে সম্পন্ন করে তারপর কভারেজে ফিরে আসে। 5,000 রেকর্ডসহ প্রথম লোড টাইম মাপুন, একটি স্কিমা পরিবর্তন আপগ্রেডের পরে টিকে আছে কি না যাচাই করুন, পুনরায় সংযোগের পরে কত কনফ্লিক্ট এসেছে ও প্রতিটি ব্যাখ্যা যোগ্য কিনা দেখুন, এবং একটি “খারাপ রেকর্ড” সাপোর্ট কল এ কতো দ্রুত আপনি ইনস্পেক্ট করতে পারবেন তা পরীক্ষা করুন।\n\nদ্রুত যাচাই করতে যদি চান, একটি নো-কোড প্রোটোটাইপ AppMaster আপনাকে ওয়ার্কফ্লো ও ডেটা মডেল দ্রুত লক করতে সাহায্য করতে পারে, এমনকি লোকাল ডাটাবেস চূড়ান্ত করার আগে।\n\n## সাধারণ ভুলযা গুলো অফলাইন-প্রথম অ্যাপকে ক্ষতিগ্রস্ত করে\n\nঅফলাইন-প্রথম ব্যর্থতার বেশিরভাগ কারণ ডাটাবেস ইঞ্জিন নয়। সমস্যা আসে নীরস অংশগুলো এড়িয়ে যাওয়ার ফলে: আপগ্রেড, কনফ্লিক্ট নিয়ম এবং পরিষ্কার ত্রুটি হ্যান্ডলিং না থাকা।\n\nএকটি ফাঁদ হলো কনফ্লিক্ট বিরল মনে করা। ফিল্ড কাজে সেগুলো স্বাভাবিক: দুই টেকনিশিয়ান একই অ্যাসেট এডিট করতে পারে, বা সুপারভাইজার একটি চেকলিস্ট পরিবর্তন করতে পারে যখন একটি ডিভাইস অফলাইনে। আপনি যদি একটি নিয়ম নির্ধারণ না করেন (লাস্ট রাইট উইনস, ফিল্ড অনুযায়ী মার্জ, বা উভয় ভার্সন রাখা), বাস্তবে আপনি অবশেষে সত্যিকার কাজ মুছে ফেলবেন।\n\nআরেকটি নীরব ব্যর্থতা হলো ডেটা মডেলকে “সম্পন্ন” ধরে নেওয়া ও আপগ্রেড অনুশীলন না করা। স্কিমা পরিবর্তন ছোট অ্যাপে ও ঘটে। যদি আপনি আপনার স্কিমা ভার্সনিং না করেন এবং পুরনো বিল্ড থেকে আপগ্রেড টেস্ট না করেন, ব্যবহারকারীরা আপডেটের পরে মাইগ্রেশন_fail অথবা ফাঁকা স্ক্রিন পেয়েও আটকে যেতে পারে।\n\nপারফরম্যান্স ইস্যুগুলোও দেরিতে দেখা দেয়। টিমগুলো কখনো সব ডাউনলোড করে রাখে “যখন দরকার হতে পারে” ধারণায়, তারপর অবাক হয় কেন সার্চ ধীর ও অ্যাপ মাঝারি-রেঞ্জ ফোনে খোলার সময় বেশি লাগে।\n\nমনোযোগ রাখার প্যাটার্নগুলো:\n\n- কোনো লিখিত কনফ্লিক্ট নীতি নেই, তাই এডিট নীরবে ওভাররাইট হয়।\n- মাইগ্রেশনগুলো ফ্রেশ ইনস্টলের ওপর কাজ করে কিন্তু বাস্তব আপগ্রেডে ব্যর্থ হয়।\n- অফলাইন ক্যাশিং সীমাহীন বৃদ্ধি পায়, ফলে কুয়েরি ধীর হয়ে যায়।\n- সিঙ্ক ব্যর্থতা স্পিনারের পেছনে লুকানো থাকে, ফলে ব্যবহারকারীরা ভাবে ডেটা পাঠানো হয়েছে।\n\n- গেসওয়ার্কের মাধ্যমে ডিবাগ করা, বদলে পুনরাবৃত্তিযোগ্য repro স্ক্রিপ্ট ও নমুনা ডেটা না রাখা।\n\nউদাহরণ: একটি টেকনিশিয়ান অফলাইনে একটি ইন্সপেকশন সম্পন্ন করে, Sync ট্যাপে করে কিন্তু কোনও কনফার্মেশন পায় না। আপলোডটি প্রকৃতপক্ষে auth টোকেন ইস্যুর কারণে ব্যর্থ হয়েছিল। যদি অ্যাপ ত্রুটিটি লুকিয়ে রাখে, তারা সাইট ছেড়ে যায় মনে করে কাজ শেষ—এবং আস্থা হারায়।\n\nআপনি যে স্টোরেজই বেছে নিন না কেন, একটি মৌলিক “ফিল্ড মোড” টেস্ট চালান: এয়ারপ্লেন মোড, কম ব্যাটারি, অ্যাপ আপডেট, এবং একই রেকর্ড দুই ডিভাইসে এডিট করা। যদি আপনি দ্রুত তৈরি করছেন এবং একটি নো-কোড প্ল্যাটফর্ম AppMaster ব্যবহার করেন, এই টেস্টগুলো প্রোটোটাইপ পর্যায়েই অন্তর্ভুক্ত করুন।\n\n## দ্রুত চেকলিস্ট সিদ্ধান্ত নেওয়ার আগে\n\nস্টোরেজ ইঞ্জিন বেছে নেওয়ার আগে নির্ধারণ করুন আপনার ফিল্ড অ্যাপের জন্য “ভাল” মানে কী, তারপর বাস্তব ডেটা ও বাস্তব ডিভাইসে তা পরীক্ষা করুন। টিমরা বৈশিষ্ট্যের ওপর তর্ক করে, তবে বেশিরভাগ ব্যর্থতা সাধারণ বিষয়গুলো থেকে আসে: আপগ্রেড, ধীর স্ক্রিন, অস্পষ্ট কনফ্লিক্ট নিয়ম, এবং লোকাল স্টেট ইনস্পেক্ট করার উপায় না থাকা।\n\nএটিকে একটি গো/নো-গো গেট হিসেবে ব্যবহার করুন:\n\n- আপগ্রেড প্রমাণ করুন: অন্তত দুই পুরনো বিল্ড নিন, আজকের বিল্ডে আপগ্রেড করুন, এবং নিশ্চিত করুন ডেটা এখনও খুলছে, এডিট হচ্ছে, এবং সিঙ্ক হচ্ছে।\n- বাস্তব ভলিউমে মূল স্ক্রিনগুলো দ্রুত রাখুন: বাস্তব ডেটা লোড করে ধীরতম স্ক্রিন সময় নিন একটি মিড-রেঞ্জ ফোনে।\n- প্রতিটি রেকর্ড টাইপের জন্য কনফ্লিক্ট পলিসি লিখুন: ইন্সপেকশন, সিগনেচার, ব্যবহৃত পার্টস, মন্তব্য।\n- লোকাল ডেটা ইনস্পেক্টেবল ও লগ দুটো সংগ্রহযোগ্য করুন: সাপোর্ট ও QA কীভাবে অফলাইনে স্টেট ক্যাপচার করবে তা সংজ্ঞায়িত করুন।\n\n- পুনরুদ্ধার পূর্বানুমানযোগ্য করুন: কখন লোকাল ক্যাশ rebuild করবেন, পুনরায় ডাউনলোড করবেন, বা আবার সাইন-ইন করাবেন—“অ্যাপ রিইনস্টল করুন”কে পরিকল্পনা বানাবেন না।\n\nআপনি যদি AppMaster-এ প্রোটোটাইপ করেন, একই শৃঙ্খলা প্রয়োগ করুন। আপগ্রেড টেস্ট করুন, কনফ্লিক্ট নির্ধারণ করুন, এবং এক দলকে হাজির করার আগে পুনরুদ্ধার অনুশীলন করুন যাদের ডাউনটাইম সহ্য করা কঠিন।\n\n## উদাহরণ দৃশ্য: দুর্বল সিগন্যাল সহ একজন টেকনিশিয়ানের ইন্সপেকশন অ্যাপ\n\nএকজন ফিল্ড টেকনিশিয়ান দিন শুরু করে ৫০টি ওয়ার্ক অর্ডার তাদের ফোনে ডাউনলোড করে। প্রতিটি জব-এ ঠিকানা, প্রয়োজনীয় চেকলিস্ট আইটেম, এবং কয়েকটি রেফারেন্স ছবি থাকে। এরপর সারা দিন সিগন্যাল মাঝে মধ্যে চলে যায়।\n\nপ্রতিটি দর্শনে টেকনিশিয়ান একই কয়েকটি রেকর্ড বারবার এডিট করে: কাজের স্ট্যাটাস (Arrived, In Progress, Done), ব্যবহৃত পার্টস, কাস্টমার সিগনেচার, এবং নতুন ছবি। কিছু এডিট ছোট কিন্তু ঘন (স্ট্যাটাস)। অন্যগুলো বড় (ছবি) এবং হারানো যাবে না।\n\n### সিঙ্ক মুহূর্ত: দুই জন একই জব স্পর্শ করেছে\n\n11:10 এ টেকনিশিয়ান Job #18-কে Done চিহ্ন করে এবং অফলাইনে একটি সিগনেচার যোগ করে। 11:40 এ অফিস থেকে একটি ডিসপ্যাচার Job #18 পুনরায় অ্যাসাইন করে কারণ এটি অফিসে এখনও খোলা দেখায়। টেকনিশিয়ান 12:05 এ কনেক্ট করলে অ্যাপ চেঞ্জগুলো আপলোড করে।\n\nভালো কনফ্লিক্ট ফ্লো এটি লুকায় না—এটি উত্থাপন করে। সুপারভাইজারকে একটি সরল বার্তা দেখানো উচিত: “Job #18-এর দুইটি ভার্সন আছে,” মূল ক্ষেত্রগুলো পাশে-দু’পাশে দেখিয়ে (স্ট্যাটাস, অ্যাসাইনড টেক, টাইমস্ট্যাম্প, সিগনেচার আছে/নেই) এবং স্পষ্ট অপশন দিতে: ফিল্ড আপডেট রাখুন, অফিস আপডেট রাখুন, বা ফিল্ড অনুযায়ী মার্জ করুন।\n\nএখানেই আপনার স্টোরেজ ও সিঙ্ক সিদ্ধান্তগুলো বাস্তবে আসে: আপনি কি পরিষ্কার পরিবর্তন ইতিহাস ট্র্যাক করতে পারবেন, এবং বেশ কয়েক ঘন্টা অফলাইনের পরে সেগুলো নিরাপদে পুনরায় চালাতে পারবেন?\n\nযদি একটি জব “অদৃশ্য” হয়ে যায়, ডিবাগিং মূলত প্রমাণ করা যে কী ঘটেছে। পর্যাপ্ত লগ রাখুন যাতে উত্তর পেতে পারেন: লোকাল রেকর্ড আইডি এবং সার্ভার আইডি ম্যাপিং (কখন তৈরি হয়েছে সহ), প্রতিটি লেখার টাইমস্ট্যাম্প/ইউজার/ডিভাইস, সিঙ্ক প্রচেষ্টা ও এর ত্রুটি বার্তাগুলো, কনফ্লিক্ট সিদ্ধান্ত ও বিজয়ী কে ছিল, এবং ছবির আপলোড স্ট্যাটাস আলাদা করে ট্র্যাক করা।\n\nএসব লগ থাকলে আপনি সমস্যা অনুমান না করে পুনরায় তৈরি করতে পারবেন।\n\n## পরবর্তী পদক্ষেপ: দ্রুত যাচাই করুন, তারপর পূর্ণ ফিল্ড সলিউশন বানান\n\nSQLite বনাম Realm বিতর্কে পক্ষ নেওয়ার আগে, আপনার অফলাইন ফ্লো-এর জন্য এক পৃষ্ঠার স্পেসিফ লিখুন: টেকনিশিয়ানের দেখা স্ক্রিনগুলো, কোন ডেটা অন-ডিভাইসে থাকবে, এবং কী নেটওয়ার্ক ছাড়া কাজ করবে (তৈরি করা, এডিট, ছবি, সিগনেচার, কিউ করা আপলোড)।\n\nতারপর পুরো সিস্টেমটি শীঘ্রই প্রোটোটাইপ করুন, শুধু ডাটাবেস নয়। ফিল্ড অ্যাপগুলো সংযোজনে ব্যর্থ হয়: একটি মোবাইল ফর্ম লোকালি সেভ হলে প্রশাসনিক দল যদি রেকর্ড পর্যালোচনা ও ঠিক করতে না পারে, বা ব্যাকএন্ড পরে আপডেটগুলো প্রত্যাখ্যান করে, তাহলে কাজ বেহাল।\n\nএকটি ব্যবহারিক যাচাই পরিকল্পনা:\n\n- একটি পাতলা এন্ড-টু-এন্ড স্লাইস তৈরি করুন: এক টা অফলাইন ফর্ম, এক টা তালিকা ভিউ, এক টা সিঙ্ক প্রচেষ্টা, এক টা অ্যাডমিন স্ক্রিন।\n- পরিবর্তন টেস্ট চালান: একটি ফিল্ড রেনেম করুন, এক ফিল্ডকে দুই ভাগ করুন, একটি টেস্ট বিল্ড পাঠান, এবং আপগ্রেড কেমন আচরণ করে দেখুন।\n- কনফ্লিক্ট সিমুলেট করুন: একই রেকর্ড দুই ডিভাইসে এডিট করুন, ভিন্ন অর্ডারে সিঙ্ক করুন, এবং কোনটা ভেঙে যায় নোট করুন।\n- ফিল্ড ডিবাগিং অনুশীলন করুন: আপনি কীভাবে লোকাল ডেটা, লগ, এবং ব্যর্থ সিঙ্ক পেইলোড ডিভাইসে ইনস্পেক্ট করবেন তা সিদ্ধান্ত নিন।\n\n- একটি রিসেট পলিসি লিখুন: কখন লোকাল ক্যাশ মুছে ফেলবেন, এবং ব্যবহারকারীরা কীভাবে কাজ হারাতে না থেকে পুনরুদ্ধার করবে তা নির্ধারণ করুন।\n\nযদি গতি জরুরি হয়, একটি নো-কোড প্রথম পাস আপনাকে দ্রুত ওয়ার্কফ্লো যাচাই করতে সাহায্য করতে পারে। AppMaster একটি অপশন, যেটি পুরো সলিউশন তৈরি করতে ব্যবহৃত হতে পারে (ব্যাকএন্ড সার্ভিস, ওয়েব অ্যাডমিন প্যানেল, এবং মোবাইল অ্যাপ)।\n\nঝুঁকির ভিত্তিতে পরবর্তী যাচাই পদক্ষেপ নিন। যদি ফর্ম সাপ্তাহিকভাবে বদলে যায়, প্রথমে মাইগ্রেশনগুলো পরীক্ষা করুন। যদি একাধিক মানুষ একই কাজ স্পর্শ করে, কনফ্লিক্টগুলো পরীক্ষা করুন। যদি “অফিসে ঠিক ছিল” ভয় থাকে, আপনার ফিল্ড ডিবাগিং ওয়ার্কফ্লো অগ্রাধিকার দিন।