পাঠ ১৬ · ৫৭-এর মধ্যে · মডিউল ৪
Home / Courses / Mobile App Development / Android ওভারভিউ

Android নেটিভ ডেভেলপমেন্ট ওভারভিউ

Android native development overview
৯ মিনিট পড়া মধ্যবর্তী · Intermediate Python কোডসহ সম্পূর্ণ বাংলায়

এই পাঠে যা শিখবেন

  • Kotlin ভাষা এবং Android-এর নেটিভ ডেভেলপমেন্ট স্ট্যাকে এটি কোথায় বসে
  • XML-লেআউট + Activities বনাম Jetpack Compose — ইমপারেটিভ বনাম ডিক্লারেটিভ পদ্ধতির Android-সংস্করণ
  • একটি সত্যিকারের Python উদাহরণে ইমপারেটিভ UI-আপডেট বনাম ডিক্লারেটিভ "রিকম্পোজিশন"
  • কেন এই ধারণাটি iOS-এর UIKit/SwiftUI গল্পের (L15) সমান্তরাল, শুধু ভিন্ন প্ল্যাটফর্মে

১ · Kotlin ও Android-এর নেটিভ স্ট্যাক

KotlinKotlinJetBrains-এর তৈরি, স্ট্যাটিক্যালি-টাইপড ভাষা — ২০১৯ থেকে Google-এর "Kotlin-first" ঘোষণার পর Android ডেভেলপমেন্টের অফিসিয়াল পছন্দের ভাষা, JVM/Android Runtime-এ চলে এবং বিদ্যমান Java কোডের সাথে সরাসরি ইন্টারঅপারেবল। এখন Android-এর জন্য Google-এর সুপারিশকৃত ভাষা — যদিও পুরনো Java কোডবেসও এখনো ব্যাপকভাবে ব্যবহৃত হয়। Kotlin null-নিরাপত্তা (null safety) এবং সংক্ষিপ্ত সিনট্যাক্সের উপর জোর দেয়, এবং Java-র সাথে একই প্রজেক্টে মিশিয়ে ব্যবহার করা যায়।

Android SDK-তে UI তৈরির দুটি প্রধান পদ্ধতি আছে — পুরনো XML লেআউট + Activities/Fragments এবং নতুন Jetpack Compose। iOS-এর UIKit/SwiftUI জোড়ার মতোই, দুটোই Google সক্রিয়ভাবে সমর্থন করে, এবং একই অ্যাপে দুটোই একসাথে থাকতে পারে (ComposeView-জাতীয় ইন্টারঅপ লেয়ার দিয়ে)।

২ · XML+Activities বনাম Jetpack Compose

XML + Activities — ইমপারেটিভ
UI একটি আলাদা XML ফাইলে ঘোষণা করা হয়; Activity/Fragment ক্লাসে findViewById বা ViewBinding দিয়ে ভিউ রেফারেন্স নিয়ে সরাসরি মিউটেট করা হয়। পুরনো, পরিণত, বহু বিদ্যমান বড় কোডবেসে এখনো প্রধান পদ্ধতি।
Jetpack Compose — ডিক্লারেটিভ
Kotlin ফাংশন ("composable") দিয়ে UI-কে স্টেটের একটি ফাংশন হিসেবে বর্ণনা করা হয়; স্টেট বদলালে ফ্রেমওয়ার্ক নিজে "রিকম্পোজ" করে শুধু প্রয়োজনীয় অংশটুকু আপডেট করে। ২০২১-এ স্টেবল হয়েছে, Android UI-এর আধুনিক অফিসিয়াল দিক।
এখানে কোনো প্রকৃত XML/Kotlin/Compose সিনট্যাক্স ব্যবহার করা হয়নি — নিচের কোড সেল ইমপারেটিভ বনাম ডিক্লারেটিভ ধারণাটি একটি জেনেরিক Python উদাহরণে দেখায়, ঠিক যেমন L15-এ iOS-এর ক্ষেত্রে দেখানো হয়েছিল।

৩ · ইমপারেটিভ আপডেট বনাম ডিক্লারেটিভ রিকম্পোজিশন

ধরা যাক একটি স্ক্রিনে একটি কাউন্টার লেবেল আছে। নিচে একই কাউন্ট-সিকোয়েন্স দুই পদ্ধতিতে UI-তে প্রতিফলিত করা হলো — একটি ইমপারেটিভ স্টাইলে (XML+Activity-র চেতনায়), আরেকটি ডিক্লারেটিভ স্টাইলে (Jetpack Compose-এর চেতনায়) — এবং প্রতিটি পদ্ধতি প্রকৃতপক্ষে কতগুলো UI-অপারেশন সম্পাদন করে তা গুনে দেখানো হলো।

Python
# ইমপারেটিভ আপডেট বনাম ডিক্লারেটিভ রিকম্পোজিশন -- একটি কাউন্টার স্ক্রিনের উদাহরণ
# (এটি কোনো নির্দিষ্ট Android ফ্রেমওয়ার্কের প্রকৃত সিনট্যাক্স নয়)

# ---- ইমপারেটিভ স্টাইল (XML + Activity, findViewById-এর চেতনায়) ----
class ImperativeCounterView:
    def __init__(self):
        self.label_text = "০"
        self.update_calls = []

    def set_count(self, count):
        self.label_text = str(count)
        self.update_calls.append(f"label.setText({count!r})")

imp_view = ImperativeCounterView()
for count in [1, 2, 2, 3]:
    imp_view.set_count(count)

print(f"ইমপারেটিভ: মোট UI-আপডেট কল = {len(imp_view.update_calls)}")
for c in imp_view.update_calls:
    print(f"  {c}")

# ---- ডিক্লারেটিভ স্টাইল (Jetpack Compose-এর চেতনায়) ----
def render_counter(count):
    return {"label_text": str(count)}

def recompose(old, new, applied_log):
    changed = 0
    for key in new:
        if old is None or old[key] != new[key]:
            applied_log.append(f"{key} -> {new[key]!r}")
            changed += 1
    return changed

sequence = [1, 2, 2, 3]
prev = None
applied_log = []
for count in sequence:
    new = render_counter(count)
    recompose(prev, new, applied_log)
    prev = new

print(f"\nডিক্লারেটিভ: মোট প্রকৃত রিকম্পোজিশন = {len(applied_log)}")
for a in applied_log:
    print(f"  {a}")

    
সিকোয়েন্স [1, 2, 2, 3]-এ কাউন্ট 2 পরপর দুইবার সেট করা হয়েছে। ইমপারেটিভ সংস্করণ মোট ৪টি setText কল করে (প্রতিটি কাউন্টের জন্য একটি, তৃতীয়টি অপ্রয়োজনীয় পুনরাবৃত্তি হলেও)। ডিক্লারেটিভ সংস্করণ শুধু ৩টি প্রকৃত রিকম্পোজিশন করে — কারণ 2 -> 2 ধাপে লেবেল টেক্সট আগের মতোই থাকায় কোনো প্রকৃত পরিবর্তন নেই।
মূল কথা · Key takeaway

XML+Activities ইমপারেটিভ — প্রতিটি UI পরিবর্তন সরাসরি, শর্তহীনভাবে কোড দিয়ে ঘটাতে হয়। Jetpack Compose ডিক্লারেটিভ — UI-কে স্টেটের ফাংশন হিসেবে বর্ণনা করলেই ফ্রেমওয়ার্ক নিজে রিকম্পোজ করে শুধু প্রকৃত পরিবর্তনটুকু প্রয়োগ করে। এটি ঠিক সেই একই ইমপারেটিভ/ডিক্লারেটিভ বিভাজন যা L15-এ iOS-এর UIKit/SwiftUI-তে দেখা গিয়েছিল — দুটি ভিন্ন প্ল্যাটফর্ম, একই স্থাপত্যিক প্যাটার্নের দিকে একত্রিত হচ্ছে।

ভাবনার প্রশ্ন

প্রতিটি প্রশ্ন নিজে কিছুক্ষণ ভাবুন — তারপর "→ উত্তর" চাপুন।

প্র ০১ Jetpack Compose আনার পরও এখনো অনেক Android অ্যাপ XML+Activity কেন ব্যবহার করে?

বিশাল বিদ্যমান কোডবেস রাতারাতি রিরাইট করা অবাস্তব; দলগুলো ধাপে ধাপে মাইগ্রেট করে, প্রায়ই ComposeView-এর মতো ইন্টারঅপ টুল দিয়ে দুটো পদ্ধতি একই অ্যাপে পাশাপাশি চালিয়ে। এটি iOS-এর UIKit/SwiftUI ইন্টারঅপের সাথে একই যুক্তি (L15 দেখুন)।

প্র ০২ কোড সেলে কাউন্ট 2 পরপর দুইবার সেট করার তাৎপর্য কী?

এটি দেখায় যে ডিক্লারেটিভ রিকম্পোজিশন বুদ্ধিমত্তার সাথে একটি "কোনো-পরিবর্তন-নেই" (no-op) আপডেট এড়িয়ে যায়, যেখানে ইমপারেটিভ পদ্ধতি প্রতিটি কলে নির্বিচারে UI-অপারেশন চালায় — এমনকি স্টেট আগের মতোই থাকলেও।

প্র ০৩ Compose-এর "রিকম্পোজিশন" ধারণাটি SwiftUI-এর re-render ধারণার সাথে কীভাবে মেলে?

দুটোই ডিক্লারেটিভ — ফ্রেমওয়ার্ক পুরনো ও নতুন UI-বর্ণনার মধ্যে পার্থক্য বের করে শুধু প্রকৃত পরিবর্তনটুকু স্ক্রিনে প্রয়োগ করে। iOS ও Android সম্পূর্ণ ভিন্ন কোম্পানি, ভিন্ন ভাষা (Swift বনাম Kotlin) ব্যবহার করলেও, UI-জটিলতা সমাধানের জন্য দুটোই স্বাধীনভাবে একই স্থাপত্যিক দিকনির্দেশনায় এসে পৌঁছেছে।

অনুশীলন

  1. চিন্তা করুন: আপনার ব্যবহৃত কোনো Android অ্যাপে কি কোনো স্ক্রিনের "লুক অ্যান্ড ফিল" অন্য স্ক্রিনের চেয়ে সামান্য আলাদা মনে হয়েছে? এটি কি XML+Activity ও Jetpack Compose-এর মিশ্রণের ইঙ্গিত হতে পারে?

    হতে পারে — অ্যানিমেশনের মসৃণতা, স্পেসিং/টাইপোগ্রাফির সামান্য পার্থক্য, বা নতুন ফিচারের "আধুনিক" অনুভূতি প্রায়ই ইঙ্গিত দেয় যে সেই অংশটি নতুন করে Compose-এ লেখা হয়েছে, যখন বাকি অ্যাপ এখনো পুরনো XML+Activity কোডে চলছে।

  2. পরীক্ষা করুন: কোড সেলে sequence-কে [5, 5, 5, 5]-এ বদলান, চালান, এবং ইমপারেটিভ ও ডিক্লারেটিভ সংস্করণের মোট গণনা কী হয় তা আগে থেকে অনুমান করে তারপর যাচাই করুন।

    ইমপারেটিভ সংস্করণ এখনো ৪টি setText কল করবে (প্রতিটি লুপ ধাপে একটি করে, মান একই থাকলেও)। ডিক্লারেটিভ সংস্করণ শুধু ১টি প্রকৃত রিকম্পোজিশন করবে — প্রথম ধাপে (আগের স্টেট None বলে), বাকি তিন ধাপে মান অপরিবর্তিত থাকায় কিছুই প্রয়োগ হবে না।

আরও পড়ুন · ABCL TECH-এ আপনার পরবর্তী পদক্ষেপ

আগের পাঠ
iOS নেটিভ ডেভেলপমেন্ট ওভারভিউ