iOS নেটিভ ডেভেলপমেন্ট ওভারভিউ
এই পাঠে যা শিখবেন
- Swift ভাষা এবং iOS-এর নেটিভ ডেভেলপমেন্ট স্ট্যাকে এটি কোথায় বসে
- UIKit বনাম SwiftUI — ইমপারেটিভ বনাম ডিক্লারেটিভ, এবং বাস্তব প্রজেক্টে দুটোই কেন এখনো গুরুত্বপূর্ণ
- ইমপারেটিভ ও ডিক্লারেটিভ UI আপডেটের পার্থক্য একটি সত্যিকারের, কার্যকর Python উদাহরণে
- কেন ডিক্লারেটিভ পদ্ধতি অপ্রয়োজনীয় UI-আপডেট এড়িয়ে যেতে পারে — এবং এটি কেন গুরুত্বপূর্ণ
১ · Swift ও iOS-এর নেটিভ স্ট্যাক
SwiftSwiftApple-এর তৈরি, স্ট্যাটিক্যালি-টাইপড, নিরাপত্তা-সচেতন প্রোগ্রামিং ভাষা — iOS, macOS, watchOS ও tvOS অ্যাপ লেখার অফিসিয়াল ভাষা, প্রকৃত ARM নেটিভ মেশিন কোডে কম্পাইল হয়। হলো Apple-এর প্ল্যাটফর্মগুলোর জন্য অফিসিয়াল ভাষা। এটি স্ট্যাটিক্যালি টাইপড এবং নিরাপত্তা-সচেতন ডিজাইন করা — যেমন optional টাইপ দিয়ে null-সংক্রান্ত ভুল কম্পাইল-টাইমেই ধরা পড়ে। একটি iOS অ্যাপ Xcode দিয়ে লেখা হয় এবং সরাসরি ARM নেটিভ মেশিন কোডে কম্পাইল হয় — কোনো ইন্টারপ্রিটার বা ব্রাউজার স্তর ছাড়াই।
iOS SDK-তে UI তৈরির জন্য দুটি অফিসিয়াল ফ্রেমওয়ার্ক আছে — পুরনো UIKit এবং নতুন SwiftUI। দুটোই Apple সক্রিয়ভাবে সমর্থন করে, এবং বাস্তবে অনেক প্রোডাকশন অ্যাপ দুটোই একসাথে ব্যবহার করে (interop layer দিয়ে) — একটি সম্পূর্ণ নতুন অ্যাপ শুরু করলে SwiftUI-তে শুরু করা সাধারণ, কিন্তু একটি বিদ্যমান বড় UIKit কোডবেস রাতারাতি বদলানো হয় না।
২ · UIKit বনাম SwiftUI
ভিউ-কন্ট্রোলার-ভিত্তিক; ডেভেলপার প্রতিটি UI পরিবর্তনের জন্য সরাসরি, ধাপে ধাপে কমান্ড দেন (যেমন একটি লেবেলের টেক্সট বদলানো)। ২০০৮ থেকে সক্রিয়, পরিণত ও বিশাল লাইব্রেরি বেস, জটিল কাস্টম ইন্টারঅ্যাকশনে এখনো অনেক ক্ষেত্রে বেশি নিয়ন্ত্রণ দেয়।
UI-কে বর্তমান স্টেটের একটি ফাংশন হিসেবে বর্ণনা করা হয়; ফ্রেমওয়ার্ক নিজেই পুরনো ও নতুন বর্ণনার মধ্যে পার্থক্য বের করে UI আপডেট করে। ২০১৯ থেকে সক্রিয়, কম বয়লারপ্লেট, iOS/macOS/watchOS জুড়ে কোড শেয়ার করা সহজ, তবে কিছু অত্যন্ত জটিল কাস্টম UI-তে এখনো তুলনামূলক নতুন।
৩ · ইমপারেটিভ বনাম ডিক্লারেটিভ — একটি সত্যিকারের উদাহরণ
ধরা যাক একটি স্ক্রিনে একটি লোডিং লেবেল আছে, যার টেক্সট ও ভিজিবিলিটি একটি is_loading বুলিয়ানের
উপর নির্ভর করে বদলাতে হয়। নিচে দুটি পদ্ধতিতেই এটি বাস্তবায়ন করা হলো — একটি ইমপারেটিভ স্টাইলে (UIKit-এর
চেতনায়), আরেকটি ডিক্লারেটিভ স্টাইলে (SwiftUI-এর চেতনায়) — এবং প্রতিটি পদ্ধতি প্রকৃতপক্ষে কতগুলো UI-অপারেশন
সম্পাদন করে তা গুনে দেখানো হলো।
# ইমপারেটিভ বনাম ডিক্লারেটিভ UI আপডেট -- একটি জেনেরিক উদাহরণ
# (এটি কোনো নির্দিষ্ট iOS ফ্রেমওয়ার্কের প্রকৃত সিনট্যাক্স নয় -- শুধু ধারণাটি ব্যাখ্যা করার জন্য)
# ---- ইমপারেটিভ স্টাইল (UIKit-এর চেতনায়) ----
# প্রতিটি স্টেট পরিবর্তনে ডেভেলপারকে সরাসরি, ধাপে ধাপে UI অবজেক্ট মিউটেট করতে হয়
class ImperativeLabel:
def __init__(self):
self.text = ""
self.is_hidden = True
self.mutation_log = []
def set_loading(self, is_loading):
if is_loading:
self.text = "লোড হচ্ছে..."
self.is_hidden = False
else:
self.text = ""
self.is_hidden = True
self.mutation_log.append(f"text = {self.text!r}")
self.mutation_log.append(f"is_hidden = {self.is_hidden}")
imp_label = ImperativeLabel()
imp_label.set_loading(True)
imp_label.set_loading(True) # একই স্টেট আবার সেট করা হলো -- তবু প্রতিটি মিউটেশন আবার চলে
imp_label.set_loading(False)
print(f"ইমপারেটিভ: মোট মিউটেশন কল = {len(imp_label.mutation_log)}")
for m in imp_label.mutation_log:
print(f" {m}")
# ---- ডিক্লারেটিভ স্টাইল (SwiftUI-এর চেতনায়) ----
# UI-কে বর্তমান স্টেটের একটি ফাংশন হিসেবে বর্ণনা করা হয়;
# প্রতিবার শুধু পুরনো ও নতুন বর্ণনার প্রকৃত পার্থক্যটুকুই "প্রয়োগ" (apply) করা হয়
def render(is_loading):
if is_loading:
return {"text": "লোড হচ্ছে...", "is_hidden": False}
return {"text": "", "is_hidden": True}
def diff_and_apply(old, new, applied_log):
changes = 0
for key in new:
if old is None or old[key] != new[key]:
applied_log.append(f"{key} = {new[key]!r}")
changes += 1
return changes
decl_state_sequence = [True, True, False]
prev = None
applied_log = []
for is_loading in decl_state_sequence:
new = render(is_loading)
diff_and_apply(prev, new, applied_log)
prev = new
print(f"\nডিক্লারেটিভ: মোট প্রকৃত প্রয়োগ (applied changes) = {len(applied_log)}")
for a in applied_log:
print(f" {a}")
[True, True, False] সিকোয়েন্স প্রসেস করে, কিন্তু ইমপারেটিভ সংস্করণ প্রতিটি কলে
নিঃশর্তভাবে মিউটেট করে (মোট ৬টি মিউটেশন — ৩টি কল × ২টি প্রপার্টি), যেখানে ডিক্লারেটিভ সংস্করণ দ্বিতীয় কলে
(আবার True) কোনো প্রকৃত পরিবর্তন খুঁজে না পেয়ে কিছুই প্রয়োগ করে না (মোট ৪টি প্রয়োগ)। এটিই
SwiftUI-এর মতো ডিক্লারেটিভ ফ্রেমওয়ার্কের মূল সুবিধার সারমর্ম — অপ্রয়োজনীয় কাজ এড়িয়ে যাওয়া।
UIKit ইমপারেটিভ — "কীভাবে" UI বদলাতে হবে তা ধাপে ধাপে বলে দিতে হয়। SwiftUI ডিক্লারেটিভ — "কী" দেখাতে হবে তা স্টেটের একটি ফাংশন হিসেবে বর্ণনা করলেই ফ্রেমওয়ার্ক নিজে পার্থক্য বের করে প্রয়োগ করে। এই একই ডিক্লারেটিভ ধারণা Full-Stack Web Frameworks কোর্সে শেখানো React-এর virtual DOM diffing-এর সাথেও মিলে যায় — একই সমস্যার দুটি ভিন্ন প্ল্যাটফর্মে সমাধান।
ভাবনার প্রশ্ন
প্রতিটি প্রশ্ন নিজে কিছুক্ষণ ভাবুন — তারপর "→ উত্তর" চাপুন।
প্র ০১ SwiftUI নতুন ও আধুনিক হওয়া সত্ত্বেও Apple কেন UIKit সম্পূর্ণ বাদ দেয়নি?
বাস্তবে বিশাল, প্রোডাকশনে চলা UIKit কোডবেস আছে যেগুলো রাতারাতি রিরাইট করা অবাস্তব। এছাড়া কিছু অত্যন্ত জটিল
কাস্টম ইন্টারঅ্যাকশন এখনো UIKit-এ বেশি নিয়ন্ত্রণসহ সহজে বাস্তবায়ন করা যায়। Apple একটি ইন্টারঅপ লেয়ার
(UIViewRepresentable-জাতীয় ধারণা) দিয়ে দুটোকে একসাথে ব্যবহারের সুযোগ রাখে, যাতে দলগুলো
ধীরে ধীরে মাইগ্রেট করতে পারে।
প্র ০২
কোড সেলে set_loading(True) পরপর দুইবার কল করার তাৎপর্য কী?
এটি ইচ্ছাকৃতভাবে দেখানো হয়েছে যে ইমপারেটিভ পদ্ধতি প্রতিবার কল হলেই মিউটেশন চালায় — এমনকি স্টেট আগের মতোই থাকলেও, অপ্রয়োজনীয় কাজ হয়। ডিক্লারেটিভ পদ্ধতি প্রতিবার পুরো UI বর্ণনা নতুন করে গণনা করলেও, শুধু প্রকৃত পার্থক্যটুকুই প্রয়োগ করে — তাই দ্বিতীয় কলে কিছুই প্রয়োগ হয় না।
প্র ০৩ ডিক্লারেটিভ পদ্ধতির এই "diff" ধাপটি একটি ব্যাটারি-চালিত মোবাইল ডিভাইসে কেন বিশেষভাবে গুরুত্বপূর্ণ?
প্রতিটি অপ্রয়োজনীয় UI-আপডেট বাড়তি CPU/GPU কাজ মানে, যা ব্যাটারি খরচ করে এবং ফ্রেম বাজেট চাপে ফেলতে পারে (M11-এ পারফরম্যান্স ও ফ্রেম বাজেট বিস্তারিত শেখানো হবে)। যেহেতু ওয়েবের মতো মোবাইল ডিভাইসেও রিসোর্স সীমিত, শুধু প্রকৃত পরিবর্তনটুকু প্রয়োগ করা একটি বাস্তব পারফরম্যান্স সুবিধা, নিছক তাত্ত্বিক পরিচ্ছন্নতা নয়।
অনুশীলন
-
চিন্তা করুন: আপনার ব্যবহৃত কোনো iOS অ্যাপের কথা মনে করুন যেখানে একটি স্ক্রিন পুরনো-স্টাইল
(UIKit-এর মতো) এবং আরেকটি স্ক্রিন নতুন-স্টাইল (SwiftUI-এর মতো) মনে হয়েছে। কেন মনে হয় দুটো ভিন্ন প্রযুক্তিতে
লেখা হতে পারে?
সাধারণত অ্যানিমেশনের মসৃণতা, ট্রানজিশনের ধরন, বা কোনো স্ক্রিনের "নতুন ফিচার" মনে হওয়া (যা প্রায়ই নতুন কোডে যুক্ত হয়) — এসব ইঙ্গিত দিতে পারে যে অ্যাপটি ধাপে ধাপে SwiftUI-তে মাইগ্রেট হচ্ছে, একই সাথে পুরনো UIKit স্ক্রিনগুলো এখনো বহাল আছে।
-
পরীক্ষা করুন: কোড সেলে
decl_state_sequence-কে[True, False, False]-এ বদলান, চালান, এবং প্রতিটি ধাপে কয়টি প্রকৃত প্রয়োগ (applied change) ঘটে তা লক্ষ করুন — মোট সংখ্যাটি এখনো ৪ থাকে কি না যাচাই করুন।হ্যাঁ, মোট এখনো ৪-ই থাকে — কিন্তু বণ্টন বদলে যায়। প্রথম ধাপে (
True) ২টি প্রয়োগ ঘটে (আগের স্টেটNoneবলে), দ্বিতীয় ধাপে (False) ২টি প্রয়োগ ঘটে (স্টেট বদলেছে), আর তৃতীয় ধাপে (আবারFalse) ০টি প্রয়োগ ঘটে (স্টেট অপরিবর্তিত)। এটি দেখায় যে "কোন ধাপে কতটুকু কাজ বাঁচানো যায়" নির্ভর করে সিকোয়েন্সের উপর — কিন্তু নীতিটি (শুধু প্রকৃত পার্থক্য প্রয়োগ করা) সবসময় একই থাকে।
আরও পড়ুন · ABCL TECH-এ আপনার পরবর্তী পদক্ষেপ
- পরের পাঠ: Android নেটিভ ডেভেলপমেন্ট ওভারভিউ পাঠ ১৬ Kotlin, XML+Activities বনাম Jetpack Compose — Android-এর নিজস্ব ইমপারেটিভ/ডিক্লারেটিভ গল্প।
- কোর্সের সম্পূর্ণ সিলেবাস দেখুন ৫৭টি পাঠ নেটিভ বনাম ক্রস-প্ল্যাটফর্ম, UI কম্পোনেন্ট, নেভিগেশন, স্টেট ম্যানেজমেন্ট, লোকাল স্টোরেজ, ডিভাইস ফিচার ও ডিপ্লয়মেন্ট — বাকি পাঠগুলো এই কোর্সেই আছে।
- সব Courses দেখুন ABCL TECH C, C++, Python, Java, JavaScript, DSA, DBMS, Discrete Mathematics, System Design, Cybersecurity, Cloud Computing & DevOps, Computer Networks, Operating Systems, Computer Architecture, Programming Languages & Compiler Design, Software Engineering & Git, Theory of Computation, Engineering Economics, Full-Stack Web Frameworks ও Mobile App Development — সব এক জায়গায়।