服务器接口
服务器的接口配置是在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 - bean
Flowable是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的类型了
-
- 继承自HSActivity，并实现contract.view接口,根据提示实现接口方法
简单实战
以HS2.0的一个简单的列表为例，图例如下：
原型图
-
简单分析
- 首先控件是用RecyclerView
- 需要进行item布局
- 需要创建Adapter
- 前台所需的字段大致为四个：头像，标题，昵称，副标题
- 创建以上四个基础类
- 通过假数据测试自己的程序
- 创建后端bean，进行数据灌入
- 首先控件是用RecyclerView
-
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赋值
- 继承自
- 以往的Adapter创建大致分为以下几步
-
图片下载
Android中图片下载使用的是Glide框架，应该是类似于iOS的SDWebImage，原理暂时还不懂，应用杜小哥封装的方法- 封装方法中有有一个Drawable类型的参数，我开始以为直接通过
R框架去取，但是发现不行，后来才知道静态资源要通过上下文间接去获得 -
bindData(SimpleRecyclerViewHolder holder, int position, T item)方法中的能通过holder间接获取到context，然后调用context.getResources().getDrawable(R资源)
- 封装方法中有有一个Drawable类型的参数，我开始以为直接通过
获取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;
}
- 内部类中尽量不要做线程相关的操作，容易造成内训泄露
