MVP — یہ کیا ہے، iOS اور Android میں Model-View-Presenter پیٹرن

MVP کیا ہے: Model-View-Presenter پیٹرن کا جوہر

MVP (Model-View-Presenter) — ایک آرکیٹیکچرل پیٹرن ہے جو مارٹن فاؤلر نے 2000 کی دہائی کے اوائل میں صارف انٹرفیس کی قابلِ آزمائش کو بہتر بنانے کے لیے MVC کے ارتقاء کے طور پر تجویز کیا تھا۔ Model ڈیٹا اور کاروباری منطق کا انتظام کرتا ہے، View رینڈرنگ اور صارف کے ان پٹ پروسیسنگ کے لیے ذمہ دار ہے، Presenter مرکزی جزو ہے جو View سے واقعات وصول کرتا ہے، Model سے ڈیٹا حاصل کرتا ہے اور ڈسپلے کے لیے حالت بناتا ہے۔

MVP اور MVC کے درمیان بنیادی فرق — Presenter کے پاس View کا براہ راست حوالہ نہیں ہوتا۔ اس کے بجائے، Presenter ViewContract انٹرفیس کے ذریعے View کے ساتھ تعامل کرتا ہے۔ View اس انٹرفیس کو نافذ کرتا ہے اور خود کو Presenter کو بھیجتا ہے۔ یہ UIKit (iOS) یا Android Framework پر انحصار کو توڑ دیتا ہے — Presenter کو ViewContract کے موک نفاذ کے ساتھ علیحدہ طور پر جانچا جا سکتا ہے۔ MVC میں UIViewController کنٹرولر براہ راست UILabel کو اپ ڈیٹ کرتا ہے، MVP میں Presenter view.showName(name) کو کال کرتا ہے، اور View فیصلہ کرتی ہے کہ کیسے دکھانا ہے۔

واحد ذمہ داری کا اصول MVP میں MVC سے زیادہ سختی سے پیروی کی جاتی ہے: View صرف رینڈرنگ کے لیے، Model ڈیٹا کے لیے، Presenter منطق اور ہم آہنگی کے لیے ذمہ دار ہے۔ حقیقی پروجیکٹس میں Presenter اسکرین کے 40–60% کوڈ پر مشتمل ہوتا ہے، View — 20–30%، Model — 20–30%. یہ تقسیم Android ایمولیٹر یا iOS سمیلیٹر شروع کیے بغیر کلیدی کاروباری منطق کو جانچنے کی اجازت دیتی ہے۔

Android میں MVP: Presenter، ViewContract اور Activity

Android میں MVP Activity یا Fragment کو View کے طور پر استعمال کرتا ہے، جو ViewContract کو نافذ کرتا ہے — ڈیٹا ڈسپلے کے طریقوں والا انٹرفیس۔ Presenter Activity میں بنایا جاتا ہے، View کو اپنے ساتھ منسلک کرتا ہے اور ڈیٹا لوڈنگ کا انتظام کرتا ہے۔ جب اسکرین گھومتی ہے، Activity دوبارہ بنائی جاتی ہے — Presenter کو retain Fragment یا بیرونی اسٹوریج کے ذریعے محفوظ کیا جا سکتا ہے، جو خالص MVC کی حالت کھونے کے مسئلے کو حل کرتا ہے۔

// ViewContract — Presenter کو View سے جوڑنے کا انٹرفیس
interface UserView {
    fun showLoading()
    fun hideLoading()
    fun showUser(user: User)
    fun showError(message: String)
}

// Presenter — قابلِ آزمائش منطق کی پرت
class UserPresenter(
    private val repository: UserRepository
) {
    private var view: UserView? = null

    fun attachView(view: UserView) {
        this.view = view
    }

    fun detachView() {
        view = null
    }

    fun loadUser(userId: Int) {
        view?.showLoading()
        repository.getUser(userId) { result ->
            view?.hideLoading()
            result.onSuccess { user ->
                view?.showUser(user)
            }.onFailure { e ->
                view?.showError(e.message ?: "Unknown error")
            }
        }
    }
}

// View (Activity) انٹرفیس کو نافذ کرتا ہے
class UserActivity : AppCompatActivity(), UserView {
    private val presenter = UserPresenter(UserRepository())

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        presenter.attachView(this)
        presenter.loadUser(42)
    }

    override fun onDestroy() {
        presenter.detachView()
        super.onDestroy()
    }

    override fun showUser(user: User) { /* UI اپڈیٹ کریں */ }
    override fun showLoading() { /* ProgressBar دکھائیں */ }
    override fun hideLoading() { /* ProgressBar چھپائیں */ }
    override fun showError(message: String) { /* Snackbar دکھائیں */ }
}

لائف سائیکل کا انتظام — Android پر MVP کا ایک اہم مسئلہ۔ اسکرین گھومنے پر Activity ختم ہو جاتی ہے، اور presenter.attachView() کو onCreate() میں دوبارہ بلایا جاتا ہے۔ اگر ڈیٹا لوڈنگ غیر متزامن ہے (RxJava، coroutines)، تو مکمل ہونے تک View منسلک نہیں رہ سکتی۔ حل — detachView() میں سبسکرپشنز منسوخ کریں یا Support Library سے Loader استعمال کریں (Jetpack کے بغیر پروجیکٹس کے لیے)۔ IT Sectr میں ہم نے تجارتی پروجیکٹس میں سالوں تک MVP + RxJava کا امتزاج استعمال کیا — پیٹرن مستحکم ہے لیکن سبسکرپشن مینجمنٹ میں نظم و ضبط کی ضرورت ہے۔

Retain Fragment — اسکرین گھومنے پر Presenter کو محفوظ رکھنے کا ایک طریقہ کار۔ UI کے بغیر Fragment (setRetainInstance(true)) Activity سے زیادہ زندہ رہتا ہے اور Presenter کا حوالہ رکھتا ہے۔ جب Activity دوبارہ بنائی جاتی ہے، Fragment اسی Presenter کو نئی Activity کو بھیجتا ہے۔ Retain Fragment AndroidX سے متروک ہیں، لیکن ان کا pre-Jetpack ہم معنی (Fragment.setRetainInstance) لیگیسی پروجیکٹس میں اب بھی کام کرتا ہے۔ جدید ڈویلپمنٹ میں Google retain Fragment کے بجائے ViewModel تجویز کرتا ہے۔

iOS میں MVP: Presenter اور View Protocol

iOS میں MVP ایک View پروٹوکول کے ذریعے بنایا جاتا ہے۔ UIViewController پروٹوکول کو نافذ کرتا ہے، Presenter UIKit کو درآمد نہیں کرتا اور خالص طور پر قابلِ آزمائش ہے۔ Apple MVC کے برعکس، جہاں UIViewController خود منطق اور براہ راست IBOutlet کنکشن رکھتا ہے، Presenter حالت کا انتظام کرتا ہے اور پروٹوکول طریقوں کے ذریعے View کو حکم دیتا ہے۔ View فیصلے نہیں کرتی — یہ Presenter کے احکامات پر عمل کرتی ہے: showUser، showLoading، navigateToProfile۔

import Foundation

// View Protocol — Presenter کے لیے تجرید
protocol UserViewProtocol: AnyObject {
    func showLoading()
    func hideLoading()
    func display(user: User)
    func displayError(message: String)
}

// Presenter — خالص منطق، UIKit کے بغیر
final class UserPresenter {
    private weak var view: UserViewProtocol?
    private let service: UserServiceProtocol

    init(service: UserServiceProtocol) {
        self.service = service
    }

    func attach(view: UserViewProtocol) {
        self.view = view
    }

    func detach() {
        view = nil
    }

    func loadUser(id: Int) {
        view?.showLoading()
        service.fetchUser(id: id) { [weak self] result in
            guard let self else { return }
            self.view?.hideLoading()
            switch result {
            case .success(let user):
                self.view?.display(user: user)
            case .failure(let error):
                self.view?.displayError(message: error.localizedDescription)
            }
        }
    }
}

// View (UIViewController) پروٹوکول کو نافذ کرتا ہے
final class UserViewController: UIViewController, UserViewProtocol {
    private let presenter = UserPresenter(service: UserService())

    override func viewDidLoad() {
        super.viewDidLoad()
        presenter.attach(view: self)
        presenter.loadUser(id: 42)
    }

    func display(user: User) {
        nameLabel.text = user.name
    }
    // ... پروٹوکول کے باقی طریقے
}

Weak reference — iOS MVP میں View پر کمزور حوالہ لازمی ہے۔ UIViewController ختم ہو سکتا ہے (نیویگیشن اسٹیک سے pop)، اور Presenter میں اس کا کلوزر retain cycle پیدا کرے گا۔ کمزور حوالہ (weak var) اس بات کی ضمانت دیتا ہے کہ View اسکرین چھوڑنے پر جاری ہو جاتی ہے، Presenter میں غیر متزامن کارروائیوں سے قطع نظر۔ Android میں اسی طرح کا مسئلہ detachView() سے حل ہوتا ہے — onDestroy() میں کال کرنے سے View کا حوالہ ختم ہو جاتا ہے۔

Passive View vs Supervising Controller — مارٹن فاؤلر کے MVP کی دو اقسام۔ Passive View: View میں کوئی منطق نہیں، Presenter مکمل طور پر حالت کا انتظام کرتا ہے۔ Supervising Controller: View خود سادہ ڈیٹا بائنڈنگ (مثلاً data binding) کرتی ہے، Presenter صرف پیچیدہ منظرناموں میں مداخلت کرتا ہے۔ موبائل ڈویلپمنٹ میں Passive View زیادہ استعمال ہوتا ہے — یہ زیادہ سے زیادہ قابلِ آزمائش اور اسکرین کی حالت کی پیش گوئی فراہم کرتا ہے۔

MVP اور MVC میں فرق اور جانچ کے فوائد

بنیادی فرق MVP اور MVC کے درمیان View کے ساتھ بات چیت کا طریقہ ہے۔ MVC میں Controller کا View (UIViewController.IBOutlets، Activity.findViewById) پر براہ راست حوالہ ہوتا ہے۔ MVP میں Presenter ViewContract انٹرفیس کے ذریعے View کے ساتھ تعامل کرتا ہے۔ یہ فرق بنیادی طور پر قابلِ آزمائش کو بدل دیتا ہے: ViewContract کو نافذ کرنے والی موک آبجیکٹ ایپ، ایمولیٹر یا UI فریم ورک شروع کیے بغیر Presenter کی منطق کو جانچنے کی اجازت دیتی ہے۔

Presenter کے یونٹ ٹیسٹ کی مثال Kotlin میں: ایک موک UserView بنایا جاتا ہے، Presenter کو بھیجا جاتا ہے، loadUser کال کیا جاتا ہے، جانچ کی جاتی ہے کہ showUser درست ڈیٹا کے ساتھ کال ہوا۔ ٹیسٹ ملی سیکنڈز میں انجام پاتا ہے، کسی ایمولیٹر کی ضرورت نہیں۔ iOS پر اسی طرح — OCMock یا پروٹوکول سٹب UserViewProtocol طریقوں کی کالز کی تصدیق کرتا ہے۔ IT Sectr کے MVP والے پروجیکٹس میں کاروباری منطق کا یونٹ ٹیسٹ کوریج 85–90% تک پہنچ گیا، جو اسی طرح کے MVC پروجیکٹس سے 2–3 گنا زیادہ ہے۔

MVP کب MVC سے بہتر ہے — استحکام کی سخت ضروریات والے پروجیکٹس میں: بینکنگ ایپس، طبی نظام، ادائیگی کے ٹرمینلز۔ ان شعبوں میں غلطی کی لاگت زیادہ ہے، اور یونٹ ٹیسٹ اہم ہیں۔ پوسٹ-MVP پروجیکٹس میں (جب پروڈکٹ پہلے سے مارکیٹ میں ہے لیکن کوڈ بیس لیگیسی ہے)، MVP مکمل آرکیٹیکچرل دوبارہ تحریر کے بغیر Massive View Controller سے قابلِ آزمائش پرت میں منطق کو بتدریج نکالنے کی اجازت دیتا ہے۔

MVP کی حدود اور MVVM کی طرف منتقلی

MVP کے اہم نقصانات — انٹرفیس کی تعداد میں اضافہ اور دستی سبسکرپشن مینجمنٹ۔ ہر اسکرین کو کم از کم ایک ViewContract + Presenter درکار ہے، 50 اسکرینوں کے لیے — 50 انٹرفیس اور 50 Presenter کلاسز۔ MVVM میں، ViewModel Presenter کی جگہ لیتا ہے اور رد عمل کے طریقہ کار (LiveData، StateFlow, ObservableObject) استعمال کرتا ہے، جو دستی attach/detach اور ViewContract انٹرفیس کی ضرورت کو ختم کرتا ہے۔

RxJava اور MVP — Android 2015–2019 میں ایک مشہور امتزاج۔ Presenter Repository سے Observable کو سبسکرائب کرتا ہے، ViewContract کے ذریعے نتیجہ دکھاتا ہے۔ مسئلہ: disposable کو detachView() میں واضح طور پر منسوخ کرنا ضروری ہے، ورنہ سبسکرپشن لیک منسلکہ View کو اپ ڈیٹ کرتے وقت کریش کا سبب بنے گا۔ RxLifecycle اور AutoDispose لائبریریوں نے جزوی طور پر ان سبسکرپشن کو خودکار کیا لیکن انحصار شامل کیا۔ IT Sectr میں ہم نے 2020 میں MVP+RxJava سے MVVM+Flow پر سوئچ کیا — ViewContract کے خاتمے کی وجہ سے کوڈ 25–30% چھوٹا ہو گیا۔

MVP سے MVVM میں منتقلی — ایک مرحلہ وار عمل۔ 1) Presenter میں ViewContract کو LiveData/StateFlow سے بدلیں۔ 2) attach/detach طریقے ہٹائیں — سبسکرپشن observe() کے ذریعے ہوتی ہے۔ 3) Presenter کا نام ViewModel رکھیں۔ 4) ViewModelFactory کے لیے DI (Hilt/Koin) ضم کریں۔ ایک اسکرین کی منتقلی میں 2–4 گھنٹے لگتے ہیں، پورے کوڈ بیس کی — 50–100 اسکرینوں والے پروجیکٹ کے لیے 2–4 ہفتے۔ منتقلی کے بعد، ViewContract انٹرفیس ہٹا دیے جاتے ہیں، کوڈ سکڑ جاتا ہے، ٹیسٹ باقی رہتے ہیں۔

جدید ڈویلپمنٹ میں MVP — پیٹرن زندہ ہے لیکن MVVM اور MVI سے پیچھے ہے۔ Google باضابطہ طور پر نئے پروجیکٹس کے لیے Jetpack کے ساتھ MVVM تجویز کرتا ہے۔ Apple — SwiftUI کے ساتھ MVVM۔ تاہم، لیگیسی کوڈ کے ساتھ کام کرنے کے لیے MVP کا علم لازمی ہے: Google Play پر سینکڑوں Android ایپس اب بھی MVP پر چلتی ہیں، بشمول بڑے بینکوں، خوردہ فروشوں اور ٹرانسپورٹ کمپنیوں کی ایپس۔ MVP کو سمجھنا MVI اور Clean Architecture میں مہارت حاصل کرنے کی بنیاد ہے، کیونکہ Presenter رابرٹ مارٹن کی اصطلاحات میں Use Case کا براہ راست پیشرو ہے۔