不知道您是否还记得，刚入手Flutter时候的惊艳。
后来你是否为Json格式而苦恼，你是否已经习惯了各种括号...
随着熟悉，不习惯的总是无限放大着，像极了爱情。
导读
- 移动开发知识体系总章（Java基础、Android、Flutter）
- 用了这个插件后，Flutter开发更简单了！
那，请耐心阅读完本篇文章，让您的Flutter开发之旅回归本质: 极速构建漂亮的原生应用。
在上一个项目开发的时候，产出了 flutter_allroundrefresh 插件 （集下拉刷新、上拉加载、初始转圈、错误页面、异常重试、登录失效 的一条龙功能的插件），开发的时候，只需要复制固定的代码（内部封装了刷新等逻辑及数据粗颗粒处理的逻辑）到每个页面，然后根据页面接入对应的接口（dao类，获取数据用），再然后处理数据正常时的显示、数据异常时的显示、登录失效的处理回调等情况，让开发分工于接口接入\测试，UI绘制，逻辑处理，极大的提高了团队的开发效率。
经过一段时间沉淀后，发现这个小插件还是很难用起来，为什么呢，因为耦合度高的问题。
具体表现是接口结果集格式的高耦合，考虑到现在用flutter作为生产环境的公司（可能估计大概也许瞎猜的）还是相对较少
不过最近看群里有小伙伴的公司都上线好几个Flutter的APP了，可喜可贺。
估计每个公司的接口格式都不一定相同（或略有不同），甚至大部分DEMO使用了是网络上的公共API，这样的API结果集格式就算是花样百出，无法统一了，就无法在插件内部封装的高耦合数据解析方案！
所以，处理数据的逻辑必须是要暴露给开发者，或者说可定制的。
那么如何降低这个耦合，又保留flutter_allroundrefresh 上的一条龙的功能呢？于是，我苦思冥想，顿悟了九九八十二天后便有了这篇文章中的新插件。
flutter_futrue：低耦合，更简洁，可定制接口解析方案，内部处理复杂的逻辑（额外转圈、下拉刷新、加载更多、无数据处理、网络错误处理、登录失效处理等），让开发者的重心放到UI的构建上！（即极速构建漂亮的原生应用）ps，别问我为什么我多用了一天，因为年满十八岁的我好不容易修炼出来的金丹，居然被医院拿走了，开心过头了）
简单的效果图：
| 截图1：模式无内容、无网络 | 截图2：模拟返回页面时的情况 |
|---|---|
 flutter_futrue_1.gif
|
 flutter_futrue_2.gif
|
flutter_futrue使用建造者模式的概念（把一个复杂的对象的构建与它的表示分离） ，即把公共的复杂的逻辑、功能、构建过程进行封装，使用一些方法（页面）进行具体表现（及可重载定制化）。
1.这里需要先提一下MVC架构模式。
笔者在架构之初，复习了一遍MVC、MVP、MVVM架构模式以及flutter上流行的状态管理BLoC、Redux，最后根据Flutter自身的特点，研究出了Flutter + MVC +Refresh的方案。
MVC架构模式在Flutter上继续保持着其优点：
耦合性低
重用性高
可维护性高
在Flutter上同样有MVC明显的缺点：
没有明确的定义
视图与控制器间的过于紧密的连接
MVC分别是Model（模型）、View（视图）、Controller（控制器）三个模块。
优点确实很明显，低耦合、重用、好维护、定制。
而缺点确实是划分不够明确：
Model（模型层）则是对数据的储存和处理，再传递给视图层相应或者展示。
在这里主要指Dao类，但这里仅仅是做数据的获取，不进行数据的处理。
View（视图层）最主要完成前端的数据展示。
在这里主要指当前page页面，或者说页面对应的buildBody（下的ListView、GridView）及其他buildXXX方法。
Controller（控制层）是对数据的接收和触发事件的接收和传递。
在这里主要指BaseState极其子类，Controller会对数据进行初步处理，用于处理数据的非正常情况的逻辑。
具体的数据整理则交给了buildBodyNoData 该方法在 View层进行处理。
2.使用
2.1.添加依赖
dependencies:
flutter_futrue: latest_version
2.2.引入
import 'package:flutter_futrue/flutter_futrue.dart';
2.3.使用（完整的一个页面代码，注意 关键点：BaseState）
import 'dart:async';
import 'package:flutter/material.dart';
import 'package:flutter_futrue/flutter_futrue.dart';
import 'package:flutter_futrue_example/dao/simple_dao.dart';
import 'package:flutter_futrue_example/dao/bean/simple_bean.dart';
class SimplePage2 extends StatefulWidget {
@override
State<StatefulWidget> createState() {
return new _SimplePage2State();
}
}
class _SimplePage2State extends BaseState<SimplePage2> {
List<SimpleDataBean> modelList = [];
int page = 1;
/// 当前页面的标题，不写该方便表示无 AppBar
@override
String AppBarTitle() {
return '真数据示范';
}
/// AppBar 一个或多个右上角按钮，不写该方法表示无右上角按钮
// @override
// List<Widget> buildAppBarActions() {}
/// 正文内容，即 body:buildBody()
@override
buildBody() {
return ListView.builder(
itemBuilder: (c, i) =>
Card(child: Center(child: Text(modelList[i].name))),
itemExtent: 100.0,
itemCount: modelList.length,
);
}
/// 刷新方法
@override
Future<dynamic> onRefresh() {
print('，，，onRefresh');
page = 1;
return SimpleDao.getData10();
}
/// 加载更多
@override
Future<dynamic> onLoading() {
print('，，，onLoading');
page++;
return SimpleDao.getData4();
}
/// 具体页面的数据处理
/// 在该页面，通过 onRefresh 去触发数据获取，除了正常情况意外，都不需要在单独处理
/// 数据正常时，父类方法返回的是 Object data ，但是具体页面具体接口我们是知道的
/// 所以内部数据是list,还是Object 我们是知道的，所以，针对处理即可
@override
void useNetData(Object data) {
if (page == 1) {
modelList.clear();
}
List<dynamic> temp = data;
temp.forEach((v) {
modelList.add(new SimpleDataBean.fromJson(v));
});
setState(() {});
}
}
单从这个页面的代码来看，其实更像Android原生中的MVP模式。
通常情况下，或者说项目或者DEMO使用的是标准接口（或者说和我司接口格式一致），那么使用flutter_futrue架构，只需要每个页面继承 BaseState 后专心写UI即可了。
那么我前面提到：处理数据的逻辑必须是要暴露给开发者，或者说可定制的。
也就是说项目或者DEMO中的接口和笔者不一样，或者说嫌弃笔者审美下的转圈、空数据页面、无网络页面、甚至是刷新头，那该怎么办？。
可扩展BaseState:熟悉JAVA的朋友都知道Java的三大特性，这里BaseState充分利用了这个特性，使自身具备封装、继承和多态的特性。也就是说BaseState是一个具备额外转圈、下拉刷新、加载更多、无数据处理、网络错误处理、登录失效处理等功能的父类，如此，就好办了，继承BaseState利用多态特性，重构具体方法达到自己想要的效果（额外转圈、无数据处理、网络错误处理等）。
当然了，通过群里的了解，也有很多朋友不清楚Java、Android、Ios或者基础相对薄弱点，那么可以具体查看example中的实例及文档。
最后
笔者确实18岁，额，零几十个月吧，捂脸，也没有修炼出过金丹，再次捂脸。
我的FlutterQQ群：10788108
Flutter专栏QQ群：497219582
