但是有一个重要的概念需要记住：Stores并不是仓库。它们的职责不是从一个外部源（API或者数据库）获取数据，而是跟踪actions提供的数据。
　　那么，Flux application是如何获得数据的呢？
　　网络请求与异步调用
　　在第一幅Flux示意图中我有意跳过了一部分：网络调用。接下来的示意图完善第一幅图并添加了更多细节：


　　异步网络调用是被一个Actions Creator触发的。一个Network 适配器完成相应API的异步调用并且返回结果给Actions Creator。
　　终Actions Creator分发带有返回数据的相应类型的Action。
　　把所有网络工作和异步工作独立于Stores之外有两个主要的优点：
　　你的Stores是完全同步的：这让Store中的逻辑更容易跟踪。Bug也更容易跟踪。同时，因为所有的状态变化都是同步的，那么Store的测试变会的非常简单：启动actions然后等待期望的结果。
　　所有的action都是从一个Action Creator触发的：在一处单一的点创建与发起所有用户操作可以大大简化寻找错误的过程。忘掉在多个类中寻找某个操作的源头吧 ，所有的事情都是在这里发生的。同时，因为异步调用发生在这之前，所有来自于ActionCreator的东西都是同步的。这大大提高了代码的可跟踪与可测试性。
　　演示代码：To－Do应用
　　在这个例子中，你将看到一个使用Flux架构的典型的To-Do应用。
　　我让项目尽量简单，只演示这个架构如何能够产生组织良好的app。
　　对于实现的一些评价：
　　Dispatcher的实现是通过Otto Bus。但是几乎任何bus都是可以的。Flux架构本身在事件上有一定限制，我在这里没有采用。原本Flux的定义中，前一个事件没有完成之前开始分发下一个事件是不允许的，会抛出一个异常。为了让项目简单，我没有采用。
　　有一个ActionsCreator类帮助创建Action，并把它们post给Dispatcher。这在Flux中时相当普遍的模式，可以让事情变的有序。
　　Actions类型只是String常量。也许这不是好的实现，但是它快速并且有助于事情的简单化。
　　同样的还有Actions数据：它们只是以String类型为key，Object为值的HashMap。这会导致Stores中转换成实际数据的时候发生丑陋的类型转换。而且显然这也不是类型安全的，但这也是为了让我们的例子更好理解。
　　总结
　　在安卓应用中其实不存在佳架构的说法。不过存在适合你当前app的佳架构。这个架构可以让你和团队其他成员协作起来更轻松，按时完成项目，尽可能的保持高质量与较少的bug。
　　我相信Flux对于以上提到的特点都有很好的支持。
　　源码
　　https://github.com/lgvalle/android-flux-todo-app