服务器接口

服务器的接口配置是在ApiStores接口文件中,先看下样例

@GET("operation/show.json")
Flowable<HttpBase<HomeNovel>> getHomeMixNovelDatas(@Query("position") String position,
                                                   @Query("page") int page,
                                                   @Query("page_size") int size);
@GET("operation/getQuestionList.json")
Flowable<HttpBase<FeedBack>> getQuestionList(@QueryMap() Map<String, String> params);

• @配置get和post方法，分别为@GET和@POST
• beanFlowable是RxJava的一种写法，后边接一个泛型< HttpBase <bean的类型>>
• 函数名：加函数名字，这个可以自定义
• 参数：
  • 单个参数使用@Query("后端参数名")参数类型 前端参数名，多个参数的话用多个@Query包裹，并用逗号分隔
  • 多个参数只要传入@QueryMap() Map<String, String> params固定写法
  • @ FieldMap 暂不知道用法

创建基础类

• 新建contract类

  • 其作用试讲P层和View层分开
  • 创建普通实体类
  • 类内部顶一个继承自HSView的接口，接口名为View

• 新建前端bean

  • 根据界面模拟一下所需数据的字段和类型，封装为一个bean，前提是不知道后端返回的数据类型
  • 如果是java类需要添加getter 和 setter方法，以及构造方法，kotlin不需要

• 新建Presenter类

  • 继承自HSPresenter,泛型为刚才的contact点View
  • 根据提示实现构造方法,其中构造方法的参数类型为contact的View
  • 定义数据获取方法，名字随意,然后调用方法addSubscription,参数为
  • 调用后台接口的Flowable接口方法，通过apiStores调用刚才定义的方法名，然后传入相应的参数
  • 添加一个成功的闭包，闭包也有一个泛型，此泛型为先前准备的前端bean类型

• 新建Activity

  • 继承自HSActivity，并实现contract.view接口,根据提示实现接口方法
    • createLayoutId返回Activity的不就文件的id,故需要提前准备一个布局，布局不在赘述
    • createPresenter是返回一个presenter，其中参数为this,原因是在新建Activity的时候已经实现了contract.view接口了，所以可以认为Activity是contact的View的类型了

简单实战

以HS2.0的一个简单的列表为例，图例如下：

原型图

• 简单分析

  • 首先控件是用RecyclerView
    • 需要进行item布局
    • 需要创建Adapter
  • 前台所需的字段大致为四个：头像，标题，昵称，副标题
  • 创建以上四个基础类
  • 通过假数据测试自己的程序
  • 创建后端bean，进行数据灌入

• Adapter 的创建

  • 以往的Adapter创建大致分为以下几步
    • 前期准备：item的布局，对item赋值的模型类
    • 继承自RecyclerView.Adapter,有个泛型，泛型是Adapter一个内部类，一般命名为xxxAdapter.ViewHolder
    • 创建内部类，
      • 继承自RecyclerView.ViewHolder,
      • 创建与item的布局中相对应的控件类型的属性
      • 构造方法中参数为一个view(实际就是item的view)，并且将属性与item的空间关联起来
  • 创建一个数据源属性，List的元素类型为刚才提到的item赋值的模型类
  • Adapter的构造方法参数与数据源属性相同，然后将其给睡醒赋值
  • 实现接口方法
  • RecyclerView 设置manager和adapter
  • 在HS2.0中杜小哥对齐进行了封装，使用方法如下
    • 继承自SimpleRecyclerAdapter<T>T是一个实体类模型，能包含item的所有的属性的类型的一个模型,在此我们沿用上文说的前端bean
    • 构造方法，参数主要是一个上下文和一个数据源集合，方法实现只要调用super就行了
    • 实现接口方法：getItemLayoutId，返回item的布局
    • 实现接口方法：bindData(SimpleRecyclerViewHolder holder, int position, T item),holder可以简单的等同于ViewHolder，position可以简单理解为索引，item就是数据源中具体的某个对象，此方法主要是为item赋值

• 图片下载
  Android中图片下载使用的是Glide框架，应该是类似于iOS的 SDWebImage，原理暂时还不懂，应用杜小哥封装的方法

  • 封装方法中有有一个Drawable类型的参数，我开始以为直接通过R框架去取，但是发现不行，后来才知道静态资源要通过上下文间接去获得
  • bindData(SimpleRecyclerViewHolder holder, int position, T item)方法中的能通过holder间接获取到context，然后调用context.getResources().getDrawable(R资源)

• 获取url的字符串的时候，要调用一下trim()，去除一下空格

• 额外补偿一个知识点：在内部类情况下，内部类能默认拿到外部类的上下文，涉及到本例的话就是可以直接调用.getResources().getDrawable(R资源)

• 双模型设计
  此种设计是在应对在后端接口资源尚未准备好的的前提下，防止出现互相等待，故采取前台后台双模型

  • 前台模型：前台模型主要是看前台界面需要那些字段，那些类型，进行一下预估，然后在需要的地方写一些假数据进行测试，用以测试功能是否完好

  • 后台模型：这里不错过多的赘述，即根据后来返回的json,进行相应字段拆解，但是模型书写上有特定的规范，是有网络框架决定，这个后面章节会有总结

  • 两端模型的数据交接：本例中主要是在Presenter中，在我们获取到又网络床架处理好的数据以后，在创建一个新的前端模型实例，然后由后端模型的实例对前端的模型实例进行赋值，需要那些就赋值那些

  • 后端模型的一些规范
    先上一段json

    
    json实例
    

    我们想要得到的数据就是json节点下的rows的数据结合，以及count的，用于后续刷新使用，按照以前iOS的Swift（因为OC可以使用KVC）的编程习惯，需要对rows中的元素追个手撕，但在目前安卓的框架中可以不这样写，大致书写格式如下:

data class MineDragenBean(
        var count: String,
        var rows: ArrayList<DragenInfo>) 
{
    data class DragenInfo(
            @SerializedName("story_id")
            var story_id: String,
            var name: String,
            var content: String,
            var image: String,
            var user: User,
            var link: String)
}

此bean是用kotlin的语法，外层将rows和count摘出来，然后rows属性是一个 ArrayList其中泛型为例DragenInfo,其中DragenInfo也是一个bean,即我们要取值的具体的模型。为了看清书写的具体结构，我将代码特意写成了类似C语言习惯，将括号的内部的内容写出

• 整体流程串接
  前端

  • 分析设计图，预估前端模型，简单写一些假的数据
  • 创建contract类，虽然此时可能不知道具体的接口方法，但是由于后续的文件需要View接口，故先创建后续在使用
  • 创建Presenter，由于此时假定后端接口尚未准备后，所以在Presenter的处理网络返回数据的方法中，先造一些假数据
  • 创建 Activity
    • onCreate方法中对视图进行视图一些设置工作（也可以在wrapper中进行，本例中不涉及，放在后续文字中说明），以及调用Presenter的网络接口方法
    • 至于contract的接口方法，这个由具体的需求决定，一般来说就是数据的传递和设置

  前端的“后端”：假定后端接口准备后

  • 配置接口，在ApiStore中
  • 创建后端bean
  • 修改Presenter，进行数据的交接

一些注意

主要接受一些在本次总结中的一些不成系统的但是很用的Android的编程习惯或者约定俗成的东西

• 使用了ArrayList的属性要进行释放,下面的例子是在Activity的onDestroy方法中，这个要看具体的组件，如果其他控件中，记得再起销毁的生命周期中对其进行销毁

 @Override
    protected void onDestroy() {
        super.onDestroy();
        mDatas.clear();
        mDatas = null;
    }

• 内部类中尽量不要做线程相关的操作，容易造成内训泄露