MVP combat mode (music APP-Android-Kotlin)

1. What is that?

MVP is a design pattern (frame), because of its excellent function decoupling Android widely used in engineering, it is divided into application Model-View-Presenter, their duties, referred MVP

  • Model (model) is responsible for handling and storage of the data, the data callback to Presenter
  • Presenter (moderator) is responsible for the request View layer (such as clicks, updated view of the data) is forwarded to the corresponding Model, after receiving a callback notification View layer update view
  • View (view) is only responsible for the display data
  • Contract (contract type) is only used to define and Model View interface, easy to manage and view

The basic flow of a simple update view
MVP combat mode (music APP-Android-Kotlin)

The order is in accordance with ①②③④⑤ to
1️⃣ in View, we send a request to update TextView Presenter
after receipt of the request 2️⃣Presenter get String request to send corresponding Model (middle there may be time-consuming operation, it may be necessary callback interfaces)
3️⃣ data and then successfully got through the callback interface to Presenter
callback to get the data and then trigger view of 4️⃣Presenter
5️⃣ finalization view view updates.
Throughout, View do only process the user's request (update TextView) and sent Presenter, and then provide a callback to update the view; Presenter only do forwarding itself does not deal with logic; model is responsible for providing information, including both processing data.

Some versions of MVP may choose to data processing into Presenter, and then only a model similar to the role of setter / getter of JavaBean, but I think this deal makes Presenter become very bloated, so I chose the logical processing into Model. It works both ways √

2. MVP common framework

2.1 Contract层
Contract并没有什么很通用个框架,因为每个视图和每一个model的工作各不相同,这里给出的是上图中的的范例

class DetailContract{
    interface DetailView{
        fun onChangeText(String)
    }

    interface DetailModel {
        fun getNowText(callBack: GetTextCallBack)
    }
    interface GetTextCallBack{
        fun onSuccess(str:String)
        fun onFail(info:String)
    }
}

2.2 Model层
Model也没有什么很通用的框架,这里给出的是上图中的范例

class SampleModel: DetailContract.DetailModel{
    override getNowText(callBack: GetTextCallBack){
        val str = ...
        //以上是获取String的操作
        if(str!=""){
            callBack.onSuccess(str)   
        }else{
            callBake.onFail("获取失败")
        }
    }
}

这里的具体Model类实现了Contract契约类中的接口,方便我们Presenter进行调用
2.3 View层
View在Android中一般包括两种,一种是Activity,一种是Fragment,这里只给出Activity的封装,Fragment类似,需要处理一些生命周期的问题。

Activity:

abstract class BaseActivity<V,T:BasePresenter<V>>:Activity(){

    val TAG:String = javaClass.simpleName

    protected lateinit var mPresenter: T

    lateinit var mContext: Context

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        mContext = this
        //初始化Presenter
        mPresenter = createPresenter()
        //将Presenter和View绑定
        mPresenter.attachView(this as V)
        //初始化布局
        initView(savedInstanceState)
    }

    /**
     * 应该由子类进行实现的初始化view的方法
     */
    abstract fun initView(savedInstanceState: Bundle?)

    /**
     * 创建对应的Presenter
     */
    abstract fun createPresenter():T

    //解除绑定
    override fun onDestroy() {
        super.onDestroy()
        mPresenter.detachView()
    }
}

BaseActivity是一个抽象类,所有加入MVP模式的Activity都应该继承这个抽象类。 泛型V代表的是视图(即自己),T则是对应的Presenter。View层持有对应Presenter的引用,用来发送消息。
2.4 Presenter层

abstract class BasePresenter<T> {
    //View接口类型的弱引用,防止所持有的view已经被销毁,但是该presenter仍然持有,导致内存的泄露
    protected lateinit var mViewRef:Reference<T>

    //绑定View引用
    fun attachView(view:T){
        mViewRef = SoftReference<T>(view)
    }

    //获取当前绑定的View引用
    protected fun getView(): T? {
        return mViewRef.get()
    }

    //是否已绑定View
    fun isViewAttached(): Boolean {
        return mViewRef != null&&mViewRef.get()!=null
    }

    //解除引用
    fun detachView(){
        if (mViewRef != null){
            mViewRef.clear()
        }
    }
}

BasePresenter是一个抽象类,所有加入MVP模式的Presenter都应该继承该抽象类。
Presenter持有View层的一个弱引用,同时包括4个和弱引用有关的方法,分别是绑定View的引用,获取当前View的引用,判定是否已绑定了View,解除View的引用。
在具体的Presenter中还拥有一个对应Model对象。也就是Presenter同时持有View和Model,这样才可以做到信息的转发功能

传入的是Contract中的View接口类型是因为可以使得Presenter只通过接口向view传输传输信息。而不是一个具体的类型。

以上就是一些常用的框架,下面我们用实战来继续加深理解:

3. 实战

The examples selected from the mid-part of the assessment Hongyan mobile development, content is a music App. Analyzing only play page (because I made two pages

Guess you like

Origin blog.51cto.com/14295695/2402179