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

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

অ্যাপ রচনা

একটি সাধারণ অ্যান্ড্রয়েড অ্যাপ একাধিক অ্যাপ কম্পোনেন্ট , যেমন সার্ভিস , কন্টেন্ট প্রোভাইডার এবং ব্রডকাস্ট রিসিভার নিয়ে গঠিত। আপনি আপনার অ্যাপ ম্যানিফেস্টে এই কম্পোনেন্টগুলো ঘোষণা করেন।

একটি অ্যাপের ইউজার ইন্টারফেসও একটি কম্পোনেন্ট। ঐতিহাসিকভাবে, ইউআই একাধিক অ্যাক্টিভিটি ব্যবহার করে তৈরি করা হতো। তবে, আধুনিক অ্যাপগুলো সিঙ্গেল-অ্যাক্টিভিটি আর্কিটেকচার ব্যবহার করে। একটিমাত্র Activity স্ক্রিন বা জেটপ্যাক কম্পোজ ডেস্টিনেশনের জন্য কন্টেইনার হিসেবে কাজ করে।

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

Apps can run on multiple form factors, including not just phones, but also tablets, foldables , ChromeOS devices, and more. Don't assume that your app always stays fixed in a portrait or landscape orientation. Configuration changes, such as device rotation or folding and unfolding a foldable device, force your app to recompose its UI, which affects app state.

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

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

পরিবর্তনশীল উৎক্ষেপণ পরিস্থিতি

In a resource-constrained environment, the components of your app can be launched individually and out of order; what's more, the operating system or user can destroy them at any time. As a result, don't store any application data or state in your app components. Make your app components self-contained, independent of each other.

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

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

As Android apps grow in size, it's important to define an architecture that lets the app scale. A well-designed app architecture defines the boundaries between parts of the app and the responsibilities each part has.

উদ্বেগের পৃথকীকরণ

আপনার অ্যাপের আর্কিটেকচার কয়েকটি নির্দিষ্ট নীতি অনুসরণ করে ডিজাইন করুন।

The most important principle is separation of concerns : separating your app into methods, classes, files, packages, modules and layers that have clearly defined responsibilities and boundaries.

আপনার সমস্ত কোড একটি Activity তে লেখা একটি সাধারণ ভুল।

The primary role of an Activity is to host your app's UI. The Android OS controls their lifecycle, frequently destroying and recreating them in response to user actions like screen rotation or system events like low memory.

This ephemeral nature makes them unsuitable for holding application data or state. If you store data in an Activity , that data is lost when the component is recreated. To ensure data persistence and provide a stable user experience, don't entrust state to these UI components.

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

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

ডেটা মডেল থেকে UI চালনা করুন

Another important principle is to drive your UI from data models, preferably persistent models. Data models represent the data of an app. They're independent from the UI elements and other components in your app. This means that they are not tied to the UI and app component lifecycle but will still be destroyed when the OS removes the app's process from memory.

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

  • রিসোর্স খালি করার জন্য অ্যান্ড্রয়েড ওএস আপনার অ্যাপটি মুছে ফেললেও ব্যবহারকারীদের কোনো ডেটা নষ্ট হয় না।

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

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

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

When a new data type is defined in your app, assign a single source of truth (SSOT) to it. The SSOT is the owner of that data, and only the SSOT can modify or mutate it. To achieve this, the SSOT exposes the data using an immutable type; to modify the data, the SSOT exposes functions or receives events that other types can call.

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

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

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

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

The single source of truth principle is often used with the unidirectional data flow (UDF) pattern. In UDF, state flows in only one direction, typically from parent component to child component. The events that modify the data flow in the opposite direction.

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

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

UDF সম্পর্কে আরও তথ্যের জন্য, Jetpack Compose-এ একমুখী ডেটা প্রবাহ দেখুন।

সাধারণ স্থাপত্য নীতিগুলো বিবেচনা করে, প্রতিটি অ্যাপ্লিকেশন কমপক্ষে দুটি লেয়ার দিয়ে ডিজাইন করুন:

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

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

একটি সাধারণ অ্যাপ আর্কিটেকচারে, UI লেয়ার অ্যাপ্লিকেশন ডেটা পায় ডেটা লেয়ার থেকে অথবা ঐচ্ছিক ডোমেইন লেয়ার থেকে, যা UI লেয়ার এবং ডেটা লেয়ারের মাঝে অবস্থান করে।
চিত্র ১. একটি সাধারণ অ্যাপ স্থাপত্যের চিত্র।

আধুনিক অ্যাপ স্থাপত্য

একটি আধুনিক অ্যান্ড্রয়েড অ্যাপ আর্কিটেকচারে (অন্যান্য কৌশলের পাশাপাশি) নিম্নলিখিত কৌশলগুলো ব্যবহার করা হয়:

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

আরও তথ্যের জন্য, অ্যান্ড্রয়েড আর্কিটেকচারের সুপারিশসমূহ দেখুন।

UI স্তর

The role of the UI layer (or presentation layer ) is to display the application data on screen. Whenever the data changes, either due to user interaction (such as pressing a button) or external input (such as a network response), the UI updates to reflect the changes.

UI স্তরটি দুই ধরনের কাঠামো নিয়ে গঠিত:

  • UI এলিমেন্টগুলো স্ক্রিনে ডেটা রেন্ডার করে। অ্যাডাপ্টিভ লেআউট সমর্থন করার জন্য আপনি Jetpack Compose ফাংশন ব্যবহার করে এই এলিমেন্টগুলো তৈরি করেন।
  • State holders (such as ViewModel ) that hold data, expose it to the UI, and handle logic. State holders should live for the same duration as the UI element they are providing state for. For example, a ViewModel for a screen should be retained in memory until the screen is removed from the app's navigation back stack. For more information, see State Lifespans .
একটি সাধারণ আর্কিটেকচারে, UI লেয়ারের UI এলিমেন্টগুলো স্টেট হোল্ডারদের উপর নির্ভর করে, যারা আবার ডেটা লেয়ার অথবা ঐচ্ছিক ডোমেইন লেয়ারের ক্লাসগুলোর উপর নির্ভর করে।
চিত্র ২. অ্যাপ আর্কিটেকচারে UI লেয়ারের ভূমিকা।

অ্যাডাপ্টিভ UI-এর ক্ষেত্রে, ViewModel অবজেক্টের মতো স্টেট হোল্ডাররা এমন UI স্টেট প্রকাশ করে যা বিভিন্ন উইন্ডো সাইজ ক্লাসের সাথে খাপ খাইয়ে নেয়। এই UI স্টেটটি পাওয়ার জন্য আপনি currentWindowAdaptiveInfo() ব্যবহার করতে পারেন। এরপর NavigationSuiteScaffold মতো কম্পোনেন্টগুলো উপলব্ধ স্ক্রিন স্পেসের উপর ভিত্তি করে বিভিন্ন নেভিগেশন প্যাটার্নের (যেমন, NavigationBar , NavigationRail , বা NavigationDrawer ) মধ্যে স্বয়ংক্রিয়ভাবে পরিবর্তন করার জন্য এই তথ্য ব্যবহার করতে পারে।

আরও জানতে, UI লেয়ার এবং কম্পোজ UI আর্কিটেকচার দেখুন।

অ্যাডাপ্টিভ অ্যাপস এবং নেভিগেশন সম্পর্কে আরও তথ্যের জন্য, ' বিল্ড অ্যাডাপ্টিভ অ্যাপস' এবং 'বিল্ড অ্যাডাপ্টিভ নেভিগেশন' দেখুন।

ডেটা স্তর

একটি অ্যাপের ডেটা লেয়ারে বিজনেস লজিক থাকে। বিজনেস লজিকই আপনার অ্যাপকে মূল্যবান করে তোলে—এতে এমন কিছু নিয়ম থাকে যা নির্ধারণ করে আপনার অ্যাপ কীভাবে ডেটা তৈরি, সংরক্ষণ এবং পরিবর্তন করবে।

The data layer is made up of repositories, each of which can contain zero to many data sources. Create a repository class for each different type of data you handle in your app. For example, you might create a MoviesRepository class for data related to movies or a PaymentsRepository class for data related to payments.

একটি প্রচলিত আর্কিটেকচারে, ডেটা লেয়ারের রিপোজিটরিগুলো অ্যাপের বাকি অংশে ডেটা সরবরাহ করে এবং ডেটা সোর্সগুলোর উপর নির্ভর করে।
চিত্র ৩. অ্যাপ আর্কিটেকচারে ডেটা লেয়ারের ভূমিকা।

রিপোজিটরি ক্লাসগুলো নিম্নলিখিত বিষয়গুলোর জন্য দায়ী:

  • অ্যাপের বাকি অংশে ডেটা প্রকাশ করা
  • ডেটার পরিবর্তনগুলিকে কেন্দ্রীভূত করা
  • একাধিক ডেটা উৎসের মধ্যে দ্বন্দ্ব নিরসন করা
  • অ্যাপের বাকি অংশ থেকে ডেটার উৎসগুলোকে আলাদা করা
  • ব্যবসায়িক যুক্তি ধারণ করে

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

আরও জানতে, ডেটা লেয়ার পৃষ্ঠাটি দেখুন।

ডোমেইন স্তর

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

The domain layer is responsible for encapsulating complex business logic or simpler business logic that is reused by multiple view models. The domain layer is optional because not all apps have these requirements. Use it only when needed - for example, to handle complexity or favor reusability.

যখন এটি অন্তর্ভুক্ত করা হয়, তখন ঐচ্ছিক ডোমেইন লেয়ারটি UI লেয়ারকে নির্ভরতা প্রদান করে এবং ডেটা লেয়ারের উপর নির্ভর করে।
চিত্র ৪. অ্যাপ আর্কিটেকচারে ডোমেইন লেয়ারের ভূমিকা।

ডোমেইন লেয়ারের ক্লাসগুলোকে সাধারণত ইউজ কেস বা ইন্টারঅ্যাক্টর বলা হয়। প্রতিটি ইউজ কেস একটিমাত্র কার্যকারিতার জন্য দায়ী থাকে। উদাহরণস্বরূপ, আপনার অ্যাপে একটি GetTimeZoneUseCase ক্লাস থাকতে পারে, যদি একাধিক ভিউ মডেল স্ক্রিনে সঠিক বার্তা দেখানোর জন্য টাইম জোনের উপর নির্ভর করে।

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

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

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

  • ডিপেন্ডেন্সি ইনজেকশন (DI) : ডিপেন্ডেন্সি ইনজেকশন ক্লাসগুলোকে তাদের ডিপেন্ডেন্সিগুলো কনস্ট্রাক্ট না করেই সংজ্ঞায়িত করার সুযোগ দেয়। রানটাইমে, অন্য একটি ক্লাস এই ডিপেন্ডেন্সিগুলো সরবরাহ করার দায়িত্বে থাকে।
  • সার্ভিস লোকেটর : সার্ভিস লোকেটর প্যাটার্ন এমন একটি রেজিস্ট্রি প্রদান করে, যেখান থেকে ক্লাসগুলো তাদের ডিপেন্ডেন্সিগুলো তৈরি করার পরিবর্তে সংগ্রহ করতে পারে।

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

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

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

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

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

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

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

আপনার অ্যাপের কম্পোনেন্টগুলোকেই একমাত্র ক্লাস হিসেবে তৈরি করুন যেগুলো অ্যান্ড্রয়েড ফ্রেমওয়ার্ক SDK API, যেমন Context বা Toast উপর নির্ভর করে। অ্যাপের কম্পোনেন্টগুলো থেকে অন্যান্য ক্লাসকে অ্যাবস্ট্রাক্ট করলে তা টেস্টেবিলিটি বাড়াতে সাহায্য করে এবং অ্যাপের অভ্যন্তরীণ কাপলিং কমায়।

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

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

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

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

আপনার অ্যাপের অনন্য মূল বৈশিষ্ট্যের উপর মনোযোগ দিন, যাতে এটি অন্যান্য অ্যাপ থেকে স্বতন্ত্র হয়ে ওঠে।

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

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

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

কনফিগারেশন পরিবর্তনের পরেও UI অবস্থা অপরিবর্তিত রাখুন।

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

পুনরায় ব্যবহারযোগ্য এবং সংযোজনযোগ্য UI উপাদান ডিজাইন করুন।

অ্যাডাপ্টিভ ডিজাইন সমর্থন করার জন্য পুনঃব্যবহারযোগ্য ও সংযোজনযোগ্য UI কম্পোনেন্ট তৈরি করুন। এটি আপনাকে উল্লেখযোগ্য রিফ্যাক্টরিং ছাড়াই বিভিন্ন স্ক্রিনের আকার ও ভঙ্গির সাথে মানিয়ে নিতে কম্পোনেন্টগুলোকে একত্রিত ও পুনর্বিন্যাস করার সুযোগ দেয়।

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

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

টাইপগুলো তাদের কনকারেন্সি পলিসির জন্য দায়ী।

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

যথাসম্ভব প্রাসঙ্গিক ও নতুন তথ্য সংরক্ষণ করুন।

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

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

আপনার অ্যাপে একটি ভালো আর্কিটেকচার প্রয়োগ করা হলে তা প্রজেক্ট এবং ইঞ্জিনিয়ারিং টিমের জন্য অনেক সুবিধা বয়ে আনে:

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

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

নমুনা

নিম্নলিখিত নমুনাগুলো ভালো অ্যাপ আর্কিটেকচারের উদাহরণ: