অ্যাপ আর্কিটেকচারের জন্য গাইড

এই নির্দেশিকাটি শক্তিশালী, উচ্চ-মানের অ্যাপ তৈরির জন্য সর্বোত্তম অনুশীলন এবং প্রস্তাবিত আর্কিটেকচারকে অন্তর্ভুক্ত করে।

মোবাইল অ্যাপ ব্যবহারকারীর অভিজ্ঞতা

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

একাধিক ফর্ম ফ্যাক্টর

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

সম্পদের সীমাবদ্ধতা

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

পরিবর্তনশীল লঞ্চ শর্ত

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

সাধারণ স্থাপত্য নীতি

আপনি যদি অ্যাপ্লিকেশন ডেটা এবং স্টেট সঞ্চয় করার জন্য অ্যাপের উপাদানগুলি ব্যবহার না করেন, তাহলে আপনি কীভাবে আপনার অ্যাপটি ডিজাইন করবেন?

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

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

উদ্বেগের বিচ্ছেদ

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

মনে রাখবেন যে আপনি Activity এবং Fragment এর বাস্তবায়নের মালিক নন; বরং, এগুলি শুধুমাত্র আঠালো ক্লাস যা Android OS এবং আপনার অ্যাপের মধ্যে চুক্তির প্রতিনিধিত্ব করে৷ ব্যবহারকারীর মিথস্ক্রিয়া বা কম মেমরির মতো সিস্টেমের অবস্থার কারণে OS যেকোন সময় সেগুলিকে ধ্বংস করতে পারে। একটি সন্তোষজনক ব্যবহারকারীর অভিজ্ঞতা এবং আরও পরিচালনাযোগ্য অ্যাপ রক্ষণাবেক্ষণের অভিজ্ঞতা প্রদান করতে, তাদের উপর আপনার নির্ভরতা কমিয়ে আনা সর্বোত্তম।

অভিযোজিত বিন্যাস

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

ডেটা মডেল থেকে ড্রাইভ UI

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

ক্রমাগত মডেল নিম্নলিখিত কারণগুলির জন্য আদর্শ:

• আপনার ব্যবহারকারীরা ডেটা হারাবেন না যদি Android OS সম্পদ খালি করার জন্য আপনার অ্যাপটি ধ্বংস করে দেয়।

• নেটওয়ার্ক কানেকশন ফ্ল্যাকি বা উপলব্ধ না থাকলে আপনার অ্যাপটি কাজ করতে থাকে।

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

সত্যের একক উৎস

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

এই প্যাটার্নটি একাধিক সুবিধা নিয়ে আসে:

• এটি একটি নির্দিষ্ট ধরণের ডেটাতে সমস্ত পরিবর্তনকে এক জায়গায় কেন্দ্রীভূত করে।
• এটি ডেটাকে সুরক্ষিত করে যাতে অন্য প্রকারগুলি এটির সাথে হস্তক্ষেপ করতে না পারে৷
• এটি ডেটাতে পরিবর্তনগুলিকে আরও সনাক্তযোগ্য করে তোলে। সুতরাং, বাগগুলি সনাক্ত করা সহজ।

একটি অফলাইন-প্রথম অ্যাপ্লিকেশনে, অ্যাপ্লিকেশন ডেটার জন্য সত্যের উৎস সাধারণত একটি ডাটাবেস। অন্য কিছু ক্ষেত্রে, সত্যের উৎস হতে পারে একটি ViewModel বা এমনকি UI।

একমুখী ডেটা প্রবাহ

সত্য নীতির একক উৎস প্রায়শই ইউনিডাইরেকশনাল ডেটা ফ্লো (UDF) প্যাটার্ন সহ আমাদের গাইডগুলিতে ব্যবহৃত হয়। UDF-এ, রাষ্ট্র শুধুমাত্র একটি দিকে প্রবাহিত হয়। যে ঘটনাগুলি ডেটা প্রবাহকে বিপরীত দিকে পরিবর্তন করে।

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

এই প্যাটার্নটি ডেটার সামঞ্জস্য বজায় রাখে, ত্রুটির প্রবণতা কম, ডিবাগ করা সহজ এবং SSOT প্যাটার্নের সমস্ত সুবিধা নিয়ে আসে।

প্রস্তাবিত অ্যাপ আর্কিটেকচার

প্রস্তাবিত সেরা অনুশীলনগুলি অনুসরণ করে কীভাবে আপনার অ্যাপ গঠন করতে হয় তা এই বিভাগটি দেখায়।

পূর্ববর্তী বিভাগে উল্লিখিত সাধারণ স্থাপত্য নীতিগুলি বিবেচনা করে, প্রতিটি অ্যাপ্লিকেশনের কমপক্ষে দুটি স্তর থাকা উচিত:

• UI স্তর যা স্ক্রিনে অ্যাপ্লিকেশন ডেটা প্রদর্শন করে।
• ডেটা স্তর যা আপনার অ্যাপের ব্যবসায়িক যুক্তি ধারণ করে এবং অ্যাপ্লিকেশন ডেটা প্রকাশ করে।

আপনি UI এবং ডেটা স্তরগুলির মধ্যে মিথস্ক্রিয়াগুলিকে সহজ করতে এবং পুনরায় ব্যবহার করতে ডোমেন স্তর নামে একটি অতিরিক্ত স্তর যুক্ত করতে পারেন।

আধুনিক অ্যাপ আর্কিটেকচার

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

• একটি অভিযোজিত এবং স্তরযুক্ত আর্কিটেকচার।
• অ্যাপের সব স্তরে ইউনিডাইরেশনাল ডেটা ফ্লো (UDF)।
• UI-এর জটিলতা পরিচালনা করতে স্টেট হোল্ডারদের সাথে একটি UI স্তর।
• Coroutines এবং প্রবাহ.
• নির্ভরতা ইনজেকশন সেরা অনুশীলন.

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

UI স্তর

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

UI স্তর দুটি জিনিস দ্বারা গঠিত:

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

এই স্তর সম্পর্কে আরও জানতে, UI স্তর পৃষ্ঠাটি দেখুন।

ডাটা লেয়ার

একটি অ্যাপের ডেটা লেয়ারে ব্যবসায়িক যুক্তি থাকে। ব্যবসায়িক যুক্তি হল যা আপনার অ্যাপকে মূল্য দেয়—এটি নিয়ম দিয়ে তৈরি যা নির্ধারণ করে যে আপনার অ্যাপ কীভাবে ডেটা তৈরি করে, সঞ্চয় করে এবং পরিবর্তন করে।

ডেটা স্তরটি সংগ্রহস্থল দিয়ে তৈরি যে প্রতিটিতে শূন্য থেকে অনেকগুলি ডেটা উত্স থাকতে পারে। আপনি আপনার অ্যাপে পরিচালনা করেন এমন প্রতিটি ভিন্ন ধরণের ডেটার জন্য আপনার একটি সংগ্রহস্থল শ্রেণী তৈরি করা উচিত। উদাহরণস্বরূপ, আপনি চলচ্চিত্র সম্পর্কিত ডেটার জন্য একটি MoviesRepository ক্লাস বা অর্থপ্রদান সম্পর্কিত ডেটার জন্য একটি PaymentsRepository ক্লাস তৈরি করতে পারেন।

সংগ্রহস্থল ক্লাস নিম্নলিখিত কাজের জন্য দায়ী:

• অ্যাপের বাকি অংশে ডেটা প্রকাশ করা হচ্ছে।
• তথ্য কেন্দ্রীকরণ পরিবর্তন.
• একাধিক ডেটা উত্সের মধ্যে দ্বন্দ্ব সমাধান করা।
• অ্যাপের বাকি অংশ থেকে ডেটার উৎস বিমূর্ত করা।
• ব্যবসায়িক যুক্তি ধারণ করে।

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

এই স্তর সম্পর্কে আরও জানতে, ডেটা স্তর পৃষ্ঠাটি দেখুন।

ডোমেন স্তর

ডোমেন স্তর হল একটি ঐচ্ছিক স্তর যা UI এবং ডেটা স্তরগুলির মধ্যে বসে।

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

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

এই স্তর সম্পর্কে আরও জানতে, ডোমেন স্তর পৃষ্ঠাটি দেখুন।

উপাদানগুলির মধ্যে নির্ভরতা পরিচালনা করুন

আপনার অ্যাপের ক্লাসগুলি সঠিকভাবে কাজ করার জন্য অন্যান্য ক্লাসের উপর নির্ভর করে। আপনি একটি নির্দিষ্ট শ্রেণীর নির্ভরতা সংগ্রহ করতে নিম্নলিখিত নকশা নিদর্শন ব্যবহার করতে পারেন:

• ডিপেনডেন্সি ইনজেকশন (DI) : ডিপেনডেন্সি ইনজেকশন শ্রেণীগুলিকে তাদের নির্মান না করেই তাদের নির্ভরতা নির্ধারণ করতে দেয়। রানটাইমে, অন্য শ্রেণী এই নির্ভরতা প্রদানের জন্য দায়ী।
• পরিষেবা লোকেটার : পরিষেবা লোকেটার প্যাটার্ন একটি রেজিস্ট্রি প্রদান করে যেখানে ক্লাসগুলি তাদের নির্মাণের পরিবর্তে তাদের নির্ভরতা পেতে পারে।

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

সাধারণ সর্বোত্তম অনুশীলন

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

যদিও নিম্নলিখিত সুপারিশগুলি বাধ্যতামূলক নয়, বেশিরভাগ ক্ষেত্রে সেগুলি অনুসরণ করা আপনার কোডবেসকে দীর্ঘমেয়াদে আরও শক্তিশালী, পরীক্ষাযোগ্য এবং রক্ষণাবেক্ষণযোগ্য করে তোলে:

অ্যাপের উপাদানগুলিতে ডেটা সংরক্ষণ করবেন না।

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

অ্যান্ড্রয়েড ক্লাসের উপর নির্ভরতা হ্রাস করুন।

আপনার অ্যাপের উপাদানগুলি শুধুমাত্র এমন ক্লাস হওয়া উচিত যা Android ফ্রেমওয়ার্ক SDK API যেমন Context বা Toast উপর নির্ভর করে। আপনার অ্যাপের অন্যান্য ক্লাসগুলিকে তাদের থেকে দূরে সরিয়ে রাখা পরীক্ষাযোগ্যতার সাথে সাহায্য করে এবং আপনার অ্যাপের মধ্যে সংযোগ কমায়।

আপনার অ্যাপের মডিউলগুলির মধ্যে দায়িত্বের স্পষ্ট সীমানা নির্ধারণ করুন।

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

প্রতিটি মডিউল থেকে যতটা সম্ভব কম প্রকাশ করুন।

উদাহরণস্বরূপ, একটি শর্টকাট তৈরি করতে প্রলুব্ধ হবেন না যা একটি মডিউল থেকে অভ্যন্তরীণ বাস্তবায়নের বিশদ প্রকাশ করে। আপনি স্বল্পমেয়াদে কিছুটা সময় লাভ করতে পারেন, তবে আপনার কোডবেস বিকশিত হওয়ার সাথে সাথে আপনি অনেকবার প্রযুক্তিগত ঋণ বহন করতে পারেন।

আপনার অ্যাপ্লিকেশানের অনন্য মূলে ফোকাস করুন যাতে এটি অন্যান্য অ্যাপ থেকে আলাদা হয়।

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

ক্যানোনিকাল লেআউট এবং অ্যাপ ডিজাইন প্যাটার্ন ব্যবহার করুন।

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

কীভাবে আপনার অ্যাপের প্রতিটি অংশকে বিচ্ছিন্নভাবে পরীক্ষাযোগ্য করা যায় তা বিবেচনা করুন।

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

ধরনগুলি তাদের সঙ্গতি নীতির জন্য দায়ী৷

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

যতটা সম্ভব প্রাসঙ্গিক এবং নতুন ডেটা বজায় রাখুন।

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

স্থাপত্যের সুবিধা

আপনার অ্যাপে একটি ভাল আর্কিটেকচার প্রয়োগ করা প্রকল্প এবং প্রকৌশল দলগুলির জন্য অনেক সুবিধা নিয়ে আসে:

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

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

নমুনা

নিম্নলিখিত Google নমুনাগুলি ভাল অ্যাপ আর্কিটেকচার প্রদর্শন করে৷ অনুশীলনে এই নির্দেশিকা দেখতে তাদের অন্বেষণ করুন:

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

আপনার জন্য প্রস্তাবিত

• দ্রষ্টব্য: জাভাস্ক্রিপ্ট বন্ধ থাকলে লিঙ্ক টেক্সট প্রদর্শিত হয়
• ডাটা লেয়ার
• UI স্তর
• UI ইভেন্ট

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