Android MVP模式面向接口写法

首先我们需要知道mvp所代表的含义，m即model可以理解成用来获取数据和处理数据，v即view可以看成activity和fragment用来显示数据和处理交互,p即presenter可以理解成用来提供数据。

三者关系：m层用来获取数据然后将数据提供给p层,p层拿到数据后通过v层展示,其中m层和v层是不能直接进行交互的，通过p层这个桥梁进行交互。这其中p层会持有v层和m层的引用。（先读懂）

理解上面的说法下面我们直接上手代码:

为了减少接口文件我们可以把接口都声明在Contract内

public interface ContentContract {
    interface Model {
    }
    interface View {
    }
    interface Presenter {
    }
}
//这样我们不需要写三个接口文件

然后分别实现三个接口与之对应的m层，v层，p层

//model
public class ContentModel implements ContentContract.Model {
}
//view
public class MainActivty extends BaseQuickActivty implements ContentContract.View {
}
//presenter
public class ContentPresenter implements ContentContract.Presenter {
}

首先我们需要考虑的是在v层我们需要做一些什么处理,然后在定义我们的方法。假如我们需要获取首页的banner数据，这时候就可以在view中声明一个方法用来接收banner数据。

public interface ContentContract {
    interface Model {
    }
    interface View {
    void getBanner(String str);
    }
    interface Presenter {
    }
}
//这时候activity实现此方法
public class MainActivty extends BaseQuickActivty implements ContentContract.View {
    @Override
    public void getBanner(String  str) {
    }
}

当v层已经有了接收数据的方法时,那么数据从何而来了?我们在之前说过m层是用来获取数据的 所以我们可以在m层中定义一个请求网络的方法。

//
public class ContentModel implements ContentContract.Model {
      //获取banner
     public void sendHttpBannerData(OnListener<String> on){
          //这里需要考虑一个问题，就是每次获取请求后的数据,我们需要传递给p层,所以需要一个回调处理
          //我们可以对m层进一步封装下
          //代码示例  
          okgo.post().ex(new CallBack(){
             public void onSucces(String str){
                    on.onSuccess(str);
              }
              public void onFail(){
                     on.onFail();
              }
             });
   }
}
//封装后的modle层  ，先提取一个基类BaseModel
public interface BaseModel<T> {
    interface OnListener<T> {
        void onSuccess(T t);
        void onFail(int code, String msg);
    }
}
//modle实现
 interface Model<T> extends BaseModle<T> {
    }

现在数据获取的方式已经有了,那怎么传递给p层呢?我们在之前也说过p层会持有m层的引用,所以我们可以在p层中调用层方法。

public class ContentPresenter implements ContentContract.Presenter {
    private ContentModel mModel;
    private ContentContract.View mView;
    //当初始化的时候  同时持有v层和m层引用
    public ContentPresenter(ContentContract.View m) {
        mView=m;
        mModel = new ContentModel();
    }
    //定义一个send方法,在该方法中调用m层的请求数据方法
     public void send(){
           mModel.sendHttpBannerData(new BaseModel.OnListener<String>() {
               @Override
               public void onSuccess(String s) {
                    //这里就可以直接使用v层方法处理数据，在v层中我们已经实想该函数
                    mView.getBanner(s);
               }
               @Override
               public void onFail(int code, String msg) {
               }
           });
    }
}

最后一步就是初始化p

public class MainActivty extends BaseQuickActivty implements ContentContract.View {
@Override
    protected void onCreate(@Nullable Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        //初始化p
        ContentPresenter contentPresenter = new ContentPresenter(this);
        contentPresenter.send();//调用p层的send方法 开始请求数据
    }
    @Override
    public void getBanner(String  str) {
    }
}

这样我们就可以交互了,在接口中我们可以根据自己的需求增加方法,可以提供基类，这样没必要每次都重写方法,可以将一些通用的放在基类中。(可以先消化下，接下来我们做进一步的处理和避免内存泄漏问题)

我们分析下不足之处。

每一个presenter都需要每次重写相同代码,手动释放p等不足之处。所以我们先从presenter入手.

/**
 * 基类 presenter  绑定view
 *
 * @param <T>
 */
public abstract class BasePresenter<T> {
    //弱引用 
    private WeakReference<T> mWeakReference;
    private ReferenceQueue<T> mReferenceQueue = new ReferenceQueue<>();
    /**
     * 添加view进入队列
     *
     * @param t
     */
    public void attachView(T t) {
        mWeakReference = new WeakReference<T>(t);
    }
    public T getView() {
        return mWeakReference.get();
    }
    /**
     * 判断是否绑定过view
     *
     * @return true 绑定
     */
    public boolean isViewAttachecd() {
        return mWeakReference != null && mWeakReference.get() != null;
    }
    /**
     * 清除view，这样不用每次手动释放
     */
    public void deleteAttach() {
        if (mWeakReference != null) {
            mWeakReference.clear();
            mWeakReference = null;
        }
    }
}

接着我们改进activity或者fragment的基类base

**
 * activity 基类
 * v 代表 view
 * t presenter
 */
public abstract class BaseQuickActivity<V, T extends BasePresenter<V>> extends AppCompatActivity {
    protected T mPresenter;
    @Override
    protected void onCreate(@Nullable Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        mPresenter = createPresenter();
        //这里做一下非空判断 有可能某些模块不需要mvp模式
        if (mPresenter != null) {
            mPresenter.attachView((V) this);
        }
    }
    protected abstract T createPresenter();
    @Override
    protected void onDestroy() {
        super.onDestroy();
        if (mPresenter != null) {
            mPresenter.deleteAttach();
        }
    }
}
//fragment 一样的写法

这样我们基本上完善了mvp模式。mvp给我带来的好处很多，高度解耦，代码结构清晰(以前ac或者ft可以达到上千行代码,现在都交给了p和m),便于测试(不会)。但是同时也有缺点,第一感知就是类增多了。第二感知就是在交互时有些时候不方便。
上述结构体还是可以更加完善的，可以用eventbus或者rxjava用于沟通的桥梁和数据分发。