JavaRush /Java Blog /Random-TL /MVP sa Android para sa mga maliliit

MVP sa Android para sa mga maliliit

Nai-publish sa grupo
Noong sinimulan ko ang aking paglalakbay bilang isang developer ng Android, ang mga salitang "Arkitektura ng Mobile Application" ay nagdulot sa akin ng matinding pagkalito, ang Google at mga artikulo sa Habré ay nagdulot sa akin sa mas malaking depresyon - tumitingin ako sa aklat at wala akong makita. Sa palagay ko kung binabasa mo ang artikulong ito, napag-aralan mo na ang larawang ito nang higit sa isang beses at sinubukan mong maunawaan kung ano ang nangyayari: MVP sa Android para sa maliliit na bata - 1Ang problema sa pag-unawa sa diskarte sa arkitektura sa pag-unlad ng mobile, sa palagay ko, ay nakasalalay sa abstractness ng arkitektura mismo. Ang bawat developer ay may sariling pananaw kung paano ipapatupad nang tama ito o ang pattern na iyon. Ang higit pa o hindi gaanong disenteng mga halimbawa ng pagpapatupad ng MVP ay natagpuan sa sektor ng Internet na nagsasalita ng Ingles, na hindi nakakagulat. Tingnan natin sandali kung ano ang ano at magpatuloy sa isang halimbawa. Modelo - antas ng data. Hindi ko gustong gamitin ang terminong "lohika ng negosyo", kaya sa aking mga aplikasyon ay tinatawag ko itong Repository at nakikipag-ugnayan ito sa database at sa network. Tingnan — antas ng pagpapakita. Ito ay Aktibidad , Fragment o Custom na View kung hindi mo mahilig sumayaw gamit ang tamburin at makipag-ugnayan sa ikot ng buhay. Hayaan mong ipaalala ko sa iyo na sa simula lahat ng Android application ay napapailalim sa MVC structure , kung saan ang Controller ay isang Activity o Fragment . Ang Presenter ay isang layer sa pagitan ng View at Model. Ang View ay nagpapadala ng mga kaganapang naganap dito, ang nagtatanghal ay nagpoproseso sa kanila, kung kinakailangan, ay nag-a-access sa Modelo at nagbabalik ng data sa View para sa pag-render. Kaugnay ng Android at isang partikular na halimbawa, i-highlight ko ang mahalagang bahagi - Kontrata. Ito ang interface na naglalarawan sa lahat ng mga pakikipag-ugnayan sa pagitan ng mga bahagi sa itaas. Upang ibuod ang teoretikal na bahagi:
  • Tingnan ang alam tungkol sa Presenter;
  • Alam ng nagtatanghal ang tungkol sa View at Modelo (Repository);
  • Mag-modelo sa sarili;
  • Ang kontrata ang namamahala sa mga pakikipag-ugnayan sa pagitan nila.
Sa totoo lang, ang halimbawa mismo, para sa pagiging simple ng eksperimento, sa pamamagitan ng pag-click sa isang pindutan, maglo-load kami ng isang hilera mula sa database at ipapakita ito sa isang TextView . Halimbawa, ang database ay naglalaman ng isang listahan ng mga pinakamahusay na restaurant sa lungsod. Magsimula tayo sa kontrata: Gumawa tayo ng interface MainContract:
public interface MainContract {
    interface View {
        void showText();
    }

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

    interface Repository {
        String loadMessage();
    }
}
Sa ngayon, itinatampok lang namin ang 3 bahagi ng aming aplikasyon sa hinaharap at kung ano ang kanilang gagawin. Susunod ay ilalarawan namin ang Repository:
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 "Сосисочная у Лёхи»;
    }
}
Malinaw ang lahat dito, naglo-load at nag-unload lang ng data. Susunod ay ang Presenter:
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()");
    }
}
Naaalala mo ba na isinulat ko ang tungkol sa pagsasayaw gamit ang tamburin at ang ikot ng buhay? Ang Presenter ay nabubuhay hangga't nabubuhay ang View nito, kapag bumubuo ng mga kumplikadong sitwasyon ng user, ipinapayo ko sa iyo na i-duplicate ang lahat ng View callback sa Presenter at tawagan ang mga ito sa naaangkop na mga sandali, na duplicate ang Activity/Fragment lifecycle, upang maunawaan sa oras kung ano ang kailangan. na gagawin sa data na kasalukuyang nakabitin sa "interlayer". At sa wakas, Tingnan:
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()");
    }
}
Ano ang nangyayari?
  • Ang aktibidad, na kilala rin bilang View, onCreate()ay lumilikha ng isang Presenter instance sa isang paraan at ipinapasa ang sarili nito sa constructor nito.
  • Kapag ang isang Presenter ay nilikha, ito ay tahasang tumatanggap ng isang View at lumilikha ng isang Repository na halimbawa (sa pamamagitan ng paraan, maaari itong gawing isang Singleton)
  • Kapag pinindot ang isang button, kumakatok ang View sa nagtatanghal at sasabihing: "Pinindot ang button."
  • Bumaling ang nagtatanghal sa Repository: "I-download ang crap na ito para sa akin."
  • Ang Repository ay naglo-load at naghahatid ng "bagay" sa Presenter.
  • Lumiko ang nagtatanghal sa View: "Narito ang data para sa iyo, iguhit ito"
Iyon lang, guys. PS Mahalagang malinaw na ilarawan ang mga responsibilidad sa pagitan ng mga bahagi. Halimbawa, sa isa sa aking mga proyekto sa pagsasanay, kapag nag-click sa isang pindutan, kinakailangan na baguhin ang data sa database. Ang modelo ay inilarawan ng isang klase ng POJO, ipinasa ko ang impormasyon tungkol sa lokasyon ng view, na responsable para sa impormasyon tungkol sa bagay sa screen, Hinanap ng Presenter ang bagay na ito sa listahan at ipinadala ito upang maisulat sa Repository. Mukhang lohikal ba ang lahat? Ngunit itinuro ng aking tagapayo ang mga sumusunod: ang Repository ay dapat LAMANG na gumawa ng pagsusulat at pagbabasa, hindi nito dapat hilahin ang mga kinakailangang impormasyon mula sa POJO at magpasya kung ano ang kailangan nitong isulat. Ang Nagtatanghal ay dapat magbigay sa kanya lamang ng impormasyon upang itala at wala nang iba pa. Walang mahigpit na balangkas para sa pagpapatupad ng arkitektura: eksperimento, subukan, hanapin kung ano ang maginhawa para sa iyo nang personal. At huwag kalimutang ipakita ang iyong mga senior na kasama sa pagsusuri ng code =) Available ang halimbawa sa GitHub: https://github.com/admitrevskiy/MVP_Example
Mga komento
TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION