*本篇文章已授权微信公众号 guolin_blog (郭霖)独家发布(在此特别感谢郭神的认可,具体发布 时间待定,希望大家也能多多关注我们的郭神)
通过这几天对这三者开发中的使用,今天准备做一个小的总结,帮助需要爬坑的"道友"!
1.## 首先先分别介绍一下这三个是什么东东 ##
1.MVP:MVP是基于MVC的改进,相信大家都是从MVC走过的,可能很多人还会在项目中使用MVC,我们传统的MVC 中xml布局充当就是视图层(View) ,业务层兼模型层的一些业务的处理需要在我们Activity 或Fragment中进行处理然后更新视图层,由于xml定义好的布局,一旦加载之后,只能通过动态更新,那么视图层和Model就建立了联系,因此二者的耦合度就提高了,那么一旦修改了其中的一个就有可能对另一产生影响,这很不利于我们后期的项目维护。同时所有的操作在我们的Controller中进行处理,我们的Controller就会显得十分的臃肿,可阅读性就降低了,对我们后期的项目维护成本提高了不少,很多时候你需要和团队一起开发一个项目,如果你的同事有一天在你请假或者想修改功能的时候发现一个Activity都有上前行甚至更多的时候,他开始慌了,他慌的时候如果还找到你的话,你可能也慌了。有了MVP之后,妈妈再也不用担心我会慌了!
## 我们的MVP模式来了 ##在MVP中model层依然不变,只不过之前充当Controller的Activity或者Fragment就变身为了View层,而业务逻辑的实现是在我们的Presenter中。简单介绍完了MVP,光说不练,一点效果都没有的,下面我们来进行MVP的三部曲:
本次案例是在进入程序的时候访问服务器的指定接口来获取当前服务器的apk的版本号,通过对比和当前应用程序的版本号,如果有新版本弹出一个土司提示用户更新,功能就这么简单,下面开始码代码:
1.视图层需要哪些更新UI的操作?可能大家会好奇我为什么会问这个,这里我留下一个悬念,待会给大家细讲。这个问题的答案是弹出一个土司提示用户更新。
2.怎么进行更新UI前的操作?
3.何时告知视图层进行UI更新?
结合上面的三个问题:我们根据需求设计代码:
1>定义一个MvpView的接口
public Interface MvpView {
//提示更新
void showMessage();
}
2>定义一个Model类
public class MvpModel{
/*从服务器获取的apk版本*/
private String newApkVersion;
//这里我就随便给出一个,正确与否我就不得而知 这里面需要注意的query是跟上请求的参数,通过GET方法来请求的 ,你可能这会问我,不是说不知道正不正确的吗,那还解释这么多?不好意思哈,我这里说明好是为了下面讲到Retrofit 做铺垫的
public static final String GET_NEW_VER_URL="http://192.168.1:8080/app/index/type?version=query";
public String getNewApkVersion() {
return newApkVersion;
}
public void setNewApkVersion(String newApkVersion) {
this.newApkVersion = newApkVersion;
}
3>定义一个基类BasePresenter(当然大家也可以不用这么做)
public abstract class BasePresenter {
/*这个基类的Presenter 主要的作用就是将当前Presenter持有的view 在合适的时候给清除掉*/
public T mView ;
public void attach(T mView){
this.mView=mView;
}
public void dettach(){
mView=null;
}
}
4>定义一个实际操作的MvpPresenter
public class MvpPresenter extends BasePresenter<MvpView> {
private MvpModel mMvpModel;
private Context mContext;
private RequestQueue mRequestQueue;
//这里重写当前的构造函数 因为我们需要获取程序的版本,因此需要一个上下文对象
public MvpPresenter (Context mContext) {
this.mContext = mContext;
//当前的Mvp模式的讲解我是采用Volley进行网络请求的所以 就封装了一个VolleyManager用于获取唯一的RequestQueue对象
mRequestQueue = VolleyManager.getInstance(mContext).getRequestQueue();
//对业务层初始化为后面获取的apk版本进行存放
mUpdateModel = new MvpModel();
}
//由于逻辑处理放到我们的Presenter中了,因此我们需要将在Activity的onResume 时候进行版本的检查
public void onResume(){
}
}
5>开始视图层的构建了不过在之前我们先创建一个BaseMvpActivity 用于统一化管理我们的MVP模式的Activity的构建
public abstract class BaseMvpActivity<V,T extends BasePresenter<V> > extends AppCompatActivity {
/*定义一个Presenter 用于解绑持有的View
*
* 在onCreate进行初始化Presenter的操作
* 在onResume中进行绑定
* 在onDestroy 中进行解绑
*
* */
public T presenter;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
presenter=initPresenter();
}
@Override
protected void onResume() {
super.onResume();
presenter.attach((V)this);
}
@Override
protected void onDestroy() {
super.onDestroy();
presenter.dettach();
}
/* 这里是适配为不同的View 装载不同Presenter*/
public abstract T initPresenter();
}
6>正式写我们的应用Activity了(当前activity的布局中仅有一个TextView)
public class MvpActivity extends BaseMvpActivity<MvpView,MvpPresenter> implements MvpView{
@Bind(R.id.tvShow)
TextView tvMsg;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_update);
ButterKnife.bind(this);
}
@Override
protected void onResume() {
super.onResume();
presenter.onResume();
}
@Override
public MvpPresenter initPresenter() {
return new MvpPresenter (getApplicationContext());
}
@Override
public void showMessage(){
tvMsg.setText("有新版本需更新!");
Toast.makeText(getApplicationContext(),"更新版本啦",Toast.LENGTH_LONG).show();
}
}
7>看到上面的MvpActivity 是不是觉得代码很清爽,那还不是把业务处理的逻辑丢给了 Presenter了,好了我们来具体看看MvpPresenter是怎么写
//在前面贴出的代码中添加
pulic void onResume(){
getVerFromServer();
}
private void getVerFromServer(){
JsonObjectRequest jsonRequest = new JsonObjectRequest(Request.Method.GET, MvpModel.GET_NEW_VERSION ,null, new Response.Listener() {
@Override
public void onResponse(JSONObject response) {
Log.e("请求版本返回结果为:",response.toString());
try {
mUpdateModel.setNewApkVersion(response.getJSONObject("data").getString("version"));
//如果从服务器获取的版本和当前的版本相同,就可提示用户了
if(mUpdateModel.getNewApkVersion.equals(getCurrentVer())){
//这里就是合适的更新UI时间,通过这里把更新的实际传递出去
mView.showMessage();
} catch (JSONException e) {
e.printStackTrace();
}
}
}, new Response.ErrorListener() {
@Override
public void onErrorResponse(VolleyError error) {
}
});
jsonRequest.setTag("getVer");
mRequestQueue.add(jsonRequest);
}
private String getCurrentVer(){
String verName="";
try {
verName=mContext.getPackageManager().getPackageInfo(context.getPackageName(),0).versionName;
} catch (PackageManager.NameNotFoundException e) {
e.printStackTrace();
}
Log.e("apkVer",verName);
return verName;
}
2.##Retrofit的简单使用介绍 ##
相信大家在开发过程中被这个字眼给冲击过不少次,具体Retrofit 是什么这里我就不详细介绍了,如果有不明白的读者可以看看我之前的一篇的文章对Retrofit有简单的介绍,但是这里我们只针对它的简单应用来讲解:
1>我们首先需要创建一个接口如RetrofitCall,因为Retrofit是通过注解的形式构建方法的 下面我们来 写一下:
public interface RetrofitCall{
// 我们把之前定义好的api接口 拿来 http://192.168.1:8080/app/index/type?version=query
//这里我先简单给大家介绍一下 Retrofit 请求网络的接口形式要满足RESTful 形式(有不了解的可自填坑) 不够构成一般是这样的[协议类型:][//主机地址加端口(或者域名)][具体目录][请求参数]
//所以这个接口的具体目录(path)为app/index/type 也就是下面这个GET注解中应该填入的
@GET("app/index/type")
Call<VersionBean> getVer(@Query(version) String ver);
//如果有读者不知道这个VersionBean怎么生成的可以查看我的博客有一篇讲Retrofit的 其实就是利用GSONFromat 来实现的
}
2>注册网络访问(这里的代码是在Presenter实现的)
Retrofit mRetrofit =new Retrofit.Builder()
//这里为主机加端口(或域名)
.baseUrl("http://192.168.1:8080/")
.clent(new OkHttpClient())
.addConverterFactory(GsonConverterFactory.create())
.build();
3>创建自定义接口实例并执行异步网络请求
RetrofitCall call=mRetrofit.create(RetrofitCall.class);
//这里需要把请求的参数填入
Call myCall=call.getVer("1");
//异步执行
maCall.enqueue(new Callback(){
@Override
public void onResposne(Callcall,retrofit2.Response response) {
if(response.body().getData().getVersion().equals(getCurrentVe r())){
mView.showMessage();
}
}
@Override
public void onFailure(Call call, Throwable t) {
Log.e("callerro+"------------>"+t);
}
});
3.## 通过RxJava对上面Retrofit 的改进 ##
RxJava 是一个异步操作的库,主要采用的观察者模式,在这里我只是简单的介绍,需要详细了解可以参考扔物线的这篇[给Android开发工程师的一篇关于RxJava的详解](http://www.jcodecraeer.com/a/anzhuokaifa/androidkaifa/2015/1012/3572.html?from=timeline&isappinstalled=0#toc_1)
在这里我就不作过多的篇幅来介绍了,我们来演示RxJava依靠Retrofit的改进上面的代码,我们在RetrofitCall中添加一个新的注解
@GET("app/index/type")
Observable getVerByRxJavaWithRetrofit(@Query("version") String ver) ;
接着在Presenter中填入如下的方法:
private void requestDataByRxJavaWithRetrofit(){
Retrofit mRxjavaRetrofit= new Retrofit.Builder()
.baseUrl("http://192.168.1:8080/")
//由于需要转为Observable 需要添加RxJavaCallAdapterFactory
.addCallAdapterFactory(RxJavaCallAdapterFactory.create())
.addConverterFactory(GsonConverterFactory.create())
.build();
RetrofitCall call= mRxjavaRetrofit.create(RetrofitCall.class);
call.getVerByRxJavaWithRetrofit(""1)
//指定时间消费在主线程
.observeOn(AndroidSchedulers.mainThread())
//事件产生在新线程
.subscribeOn(Schedulers.newThread())
//指定一个观察者
.subscribe(new Observer(){
@Override
public void onCompleted() {
mView.showMessage();
}
@Override
public void onError(Throwable e) {
}
/*这个时候是订阅者需要跟新UI的时间了通知它更新*/
@Override
public void onNext(LogoBean logoBean) {
/*这里先不做判断*/
}
} );
}
4## 总结 ##
上面对这三者的结合使用有了一个直观的介绍,其实MVP模式可以理解为 更新UI需要什么操作,什么时候开始更新UI,怎么更新UI;而我们的MVP模式就是把这三种状态巧妙地分开,因此会让思路显得很清晰,而RxJava 正式基于这种设计,被观察者通过被订阅的形式在自己有新动态的时候告知观察者我改变了,剩下的就交给观察者做自己应该做的事情了!这样的设计模式很符合我们需求,也很利于团队开发,换个模式你会觉得效率大大提高,让我们一起加入MVP+RxJava+Retrofit的队列之中吧!