用了这个插件后，Flutter开发更简单了！

百花齐放

不知道您是否还记得，刚入手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 createState() {
    return new _SimplePage2State();
  }
}

class _SimplePage2State extends BaseState {

  List modelList = [];
  int page = 1;

  /// 当前页面的标题，不写该方便表示无 AppBar
  @override
  String AppBarTitle() {
    return '真数据示范';
  }

  /// AppBar 一个或多个右上角按钮，不写该方法表示无右上角按钮
//  @override
//  List 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 onRefresh() {
    print('，，，onRefresh');
    page = 1;
    return SimpleDao.getData10();
  }

  /// 加载更多
  @override
  Future onLoading() {
    print('，，，onLoading');
    page++;
    return SimpleDao.getData4();
  }

  /// 具体页面的数据处理
  /// 在该页面，通过 onRefresh 去触发数据获取，除了正常情况意外，都不需要在单独处理
  /// 数据正常时，父类方法返回的是 Object data ，但是具体页面具体接口我们是知道的
  /// 所以内部数据是list,还是Object 我们是知道的，所以，针对处理即可
  @override
  void useNetData(Object data) {
    if (page == 1) {
      modelList.clear();
    }
    List 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