چھوٹے بچوں کے لیے اینڈرائیڈ میں ایم وی پی

جب میں نے ایک اینڈرائیڈ ڈویلپر کے طور پر اپنے سفر کا آغاز کیا تو "موبائل ایپلیکیشن آرکیٹیکچر" کے الفاظ نے مجھے گہری تشویش میں مبتلا کر دیا، گوگل اور Habré کے مضامین نے مجھے اور بھی زیادہ ڈپریشن میں ڈال دیا - میں کتاب کو دیکھتا ہوں اور کچھ بھی نظر نہیں آتا۔ میرا خیال ہے کہ اگر آپ یہ مضمون پڑھ رہے ہیں، تو آپ نے پہلے ہی اس تصویر کا ایک سے زیادہ بار مطالعہ کیا ہے اور یہ سمجھنے کی کوشش کی ہے کہ کیا ہو رہا ہے: موبائل کی ترقی میں تعمیراتی نقطہ نظر کو سمجھنے کا مسئلہ، میری رائے میں، فن تعمیر کی ہی تجرید میں مضمر ہے۔ ہر ڈویلپر کا اپنا وژن ہوتا ہے کہ اس یا اس پیٹرن کو صحیح طریقے سے کیسے نافذ کیا جائے۔ ایم وی پی کے نفاذ کی کم و بیش مہذب مثالیں انٹرنیٹ کے انگریزی بولنے والے شعبے میں پائی گئیں، جو کہ حیرت کی بات نہیں ہے۔ آئیے مختصراً دیکھتے ہیں کہ کیا ہے اور ایک مثال کی طرف بڑھتے ہیں۔ ماڈل - ڈیٹا کی سطح۔ میں "بزنس لاجک" کی اصطلاح استعمال کرنا پسند نہیں کرتا، اس لیے میں اپنی ایپلی کیشنز میں اسے Repository کہتا ہوں اور یہ ڈیٹا بیس اور نیٹ ورک کے ساتھ بات چیت کرتا ہے۔ دیکھیں - ڈسپلے کی سطح۔ اگر آپ کو دف کے ساتھ ناچنا اور زندگی کے چکر کے ساتھ تعامل کرنا پسند نہیں ہے تو یہ ایکٹیویٹی ، فریگمنٹ یا کسٹم ویو ہوگا ۔ میں آپ کو یاد دلاتا ہوں کہ ابتدائی طور پر تمام اینڈرائیڈ ایپلی کیشنز MVC ڈھانچے کے ماتحت ہیں ، جہاں کنٹرولر ایک سرگرمی یا ٹکڑا ہے ۔ پیش کنندہ منظر اور ماڈل کے درمیان ایک پرت ہے۔ ویو ان واقعات کو منتقل کرتا ہے جو اس میں پیش آتے ہیں، پیش کنندہ ان پر کارروائی کرتا ہے، اگر ضروری ہو تو، ماڈل تک رسائی حاصل کرتا ہے اور رینڈرنگ کے لیے ویو میں ڈیٹا واپس کرتا ہے۔ اینڈرائیڈ اور ایک مخصوص مثال کے سلسلے میں، میں اہم حصہ پر روشنی ڈالوں گا - معاہدہ۔ یہ وہ انٹرفیس ہے جو مندرجہ بالا اجزاء کے درمیان تمام تعاملات کو بیان کرتا ہے۔ نظریاتی حصے کا خلاصہ کرنے کے لیے:

• View Presenter کے بارے میں جانتا ہے۔
• پیش کنندہ دیکھیں اور ماڈل (ذخیرہ) کے بارے میں جانتا ہے؛
• خود ہی ماڈل؛
• معاہدہ ان کے درمیان تعاملات کو کنٹرول کرتا ہے۔

دراصل، مثال کے طور پر، تجربے کی سادگی کے لیے، ایک بٹن پر کلک کرنے سے، ہم ڈیٹا بیس سے ایک قطار لوڈ کریں گے اور اسے ٹیکسٹ ویو میں ڈسپلے کریں گے ۔ مثال کے طور پر، ڈیٹا بیس میں شہر کے بہترین ریستوراں کی فہرست موجود ہے۔ آئیے معاہدے کے ساتھ شروع کریں: آئیے ایک انٹرفیس بنائیں MainContract:

public interface MainContract {
    interface View {
        void showText();
    }

    interface Presenter {
        void onButtonWasClicked();
        void onDestroy();
    }

    interface Repository {
        String loadMessage();
    }
}

ابھی کے لیے، ہم صرف اپنی مستقبل کی ایپلی کیشن کے 3 اجزاء اور وہ کیا کریں گے پر روشنی ڈال رہے ہیں۔ اگلا ہم ریپوزٹری کی وضاحت کریں گے:

public class MainRepository implements MainContract.Repository {

    private static final String TAG = "MainRepository";
    @Override
    public String loadMessage() {
        Log.d(TAG, "loadMessage()");
        /** Здесь обращаемся к БД or сети.
         * Я специально ничего не пишу, чтобы не загромождать пример
         * DBHelper'ами и прочими не относяшимеся к теме an objectми.
         * Поэтому я буду возвращать строку Сосисочная =)
         */
        return "Сосисочная у Лёхи»;
    }
}

اس کے ساتھ سب کچھ واضح ہے، صرف ڈیٹا لوڈ کرنا اور ان لوڈ کرنا۔ اگلا پیش کنندہ ہے:

public class MainPresenter implements MainContract.Presenter {
    private static final String TAG = "MainPresenter";

    //Компоненты MVP applications
    private MainContract.View mView;
    private MainContract.Repository mRepository;

    //Сообщение
    private String message;


    //Обрати внимание на аргументы конструктора - мы передаем экземпляр View, а Repository просто создаём конструктором.
    public MainPresenter(MainContract.View mView) {
        this.mView = mView;
        this.mRepository = new MainRepository();
        Log.d(TAG, "Constructor");
    }

    //View сообщает, что кнопка была нажата
    @Override
    public void onButtonWasClicked() {
        message = mRepository.loadMessage();
        mView.showText(message);
        Log.d(TAG, "onButtonWasClicked()");
    }

    @Override
    public void onDestroy() {
        /**
         * Если бы мы работали например с RxJava, в этом классе стоило бы отписываться от подписок
         * Кроме того, при работе с другими методами асинхронного андроида,здесь мы боремся с утечкой контекста
         */

        Log.d(TAG, "onDestroy()");
    }
}

کیا آپ کو یاد ہے کہ میں نے دف کے ساتھ رقص اور زندگی کے چکر کے بارے میں لکھا تھا؟ پیش کنندہ اس وقت تک زندہ رہتا ہے جب تک اس کا ویو زندہ رہتا ہے، جب صارف کے پیچیدہ منظرنامے تیار کرتے ہیں، میں آپ کو مشورہ دیتا ہوں کہ پیش کنندہ میں موجود تمام ویو کال بیکس کو ڈپلیکیٹ کریں اور انہیں مناسب لمحات پر کال کریں، ایکٹیویٹی/فراگمنٹ لائف سائیکل کو ڈپلیکیٹ کرتے ہوئے، وقت پر سمجھنے کے لیے اس ڈیٹا کے ساتھ کرنے کی ضرورت ہے جو فی الحال "انٹرلیئر" میں لٹکا ہوا ہے۔ اور آخر میں، دیکھیں:

public class MainActivity extends AppCompatActivity implements MainContract.View {

    private static final String TAG = "MainActivity";

    private MainContract.Presenter mPresenter;

    private Button mButton;

    private TextView myTv;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);

        //Создаём Presenter и в аргументе передаём ему this - эта Activity расширяет интерфейс MainContract.View
        mPresenter = new MainPresenter(this);

        myTv = (TextView) findViewById(R.id.text_view);
        mButton = (Button) findViewById(R.id.button);

        mButton.setOnClickListener(new View.OnClickListener() {
            @Override
            public void onClick(View v) {
                mPresenter.onButtonWasClicked();
            }
        });
        Log.d(TAG, "onCreate()");
    }

    @Override
    public void showText(String message) {
        myTv.setText(message);
        Log.d(TAG, "showMessage()");
    }

    //Вызываем у Presenter метод onDestroy, чтобы избежать утечек контекста и прочих неприятностей.
    @Override
    public void onDestroy() {
        super.onDestroy();
        mPresenter.onDestroy();
        Log.d(TAG, "onDestroy()");
    }
}

کیا ہو رہا ہے؟

• سرگرمی، جسے ویو کے نام سے بھی جانا جاتا ہے، onCreate()ایک طریقہ کار میں ایک پیش کنندہ مثال تخلیق کرتا ہے اور خود کو اس کے کنسٹرکٹر تک پہنچاتا ہے۔
• جب ایک پیش کنندہ بنایا جاتا ہے، تو یہ واضح طور پر ایک ویو حاصل کرتا ہے اور ایک ریپوزٹری مثال بناتا ہے (ویسے، اسے سنگلٹن بنایا جا سکتا ہے)
• جب ایک بٹن دبایا جاتا ہے، تو منظر پیش کنندہ پر دستک دیتا ہے اور کہتا ہے: "بٹن دبایا گیا تھا۔"
• پیش کنندہ ریپوزٹری کا رخ کرتا ہے: "میرے لئے یہ گھٹیا ڈاؤن لوڈ کریں۔"
• ریپوزٹری لوڈ کرتی ہے اور پیش کنندہ کو "سامان" فراہم کرتی ہے۔
• پیش کنندہ منظر کی طرف مڑتا ہے: "یہ رہا آپ کے لیے ڈیٹا، اسے کھینچیں"

بس، لوگو۔ PS اجزاء کے درمیان ذمہ داریوں کو واضح طور پر بیان کرنا ضروری ہے۔ مثال کے طور پر، میرے ایک تربیتی پروجیکٹ میں، بٹن پر کلک کرتے وقت، ڈیٹا بیس میں ڈیٹا کو تبدیل کرنا ضروری تھا۔ ماڈل کو ایک POJO کلاس کے ذریعہ بیان کیا گیا تھا، میں نے منظر کے مقام کے بارے میں معلومات پاس کیں، جو اسکرین پر موجود آبجیکٹ کے بارے میں معلومات کے لیے ذمہ دار ہے، پیش کنندہ نے فہرست میں اس آبجیکٹ کو تلاش کیا اور اسے ریپوزٹری کو لکھنے کے لیے بھیج دیا۔ کیا سب کچھ منطقی لگتا ہے؟ لیکن میرے سرپرست نے مندرجہ ذیل باتوں کی نشاندہی کی: ذخیرہ کو صرف لکھنا اور پڑھنا چاہیے، اسے POJO سے ضروری معلومات نہیں نکالنی چاہیے اور یہ فیصلہ نہیں کرنا چاہیے کہ اسے کیا لکھنے کی ضرورت ہے۔ پیش کنندہ کو اسے صرف ریکارڈ کرنے کے لیے معلومات دینا چاہیے اور اس سے زیادہ کچھ نہیں۔ فن تعمیر کو لاگو کرنے کے لیے کوئی سخت فریم ورک نہیں ہے: تجربہ کریں، کوشش کریں، ذاتی طور پر آپ کے لیے کیا آسان ہے تلاش کریں۔ اور اپنے سینئر ساتھیوں کو کوڈ ریویو پر دکھانا نہ بھولیں =) مثال GitHub پر دستیاب ہے: https://github.com/admitrevskiy/MVP_Example