10 Feb 2015
(三篇系列文章之第一篇)
尽管在Android的开发中包含了一些事件驱动的特点，但是距离一个纯事件驱动的框架还差很多。这是好是坏？要看情况，因为对于软件开发中的每一个问题来说这都很困难。
首先，我们要确立事件驱动开发的含义。它是一个编程规范，依据触发的事件、动作决定程序执行流程（例如用户交互，来自其他线程的交互等等）。依据这个规则，我们都可以想到点击监听或者Activity生命周期中在App中可以触发行为事件。为什么我说这不是纯事件驱动的系统？默认情况下，每一个事件都被限制在一个特殊的控制器内，超出将很难被执行（例如，点击事件只能被定义在一个View中）。
等等，你是在说一个新的编程规范。采纳新的系统或者方法论通常会需要一笔消费，这会带来哪些优势？我说这是肯定的，为了展示它的优势我将要展示一些传统Android开发中的局限性。
Activities可以和Fragments通信，Fragments也可以和其他的Fragments和Services发送消息。他们之间有较高的耦合度，修改的代价会很高昂。这会导致在不同层之间频繁的引用模板代码，需要回调的接口实现方法…你可能知道
origin post
08 Feb 2015
使用好namespace这把利器，你就会成为一个设计UI界面的高手 想象一个场景：你在Android Studio正在设计一个UI布局的某一个块，你的xml编辑器在你的面前，你还有一个美妙的布局方案。你在预览布局面板内看到的却是这个样子的： 哎呀！哥们，啥也不说了。 如果你在Android上开发过任何需要远程数据填充的布局，相信你经历过这种情况很多次了。 唯一能检测你的布局是否正确的方法，那就是运行到你的手机上。 如果这个时候你正在设计UI，当app运行时，意味着你还没有绑定任何数据到UI上，这需要你放置一些脏数据来显示。 所以你做了你从来都不应该做的事情：将一些脏数据硬编码到你的布局文件中去。 <TextView android:id="@+id/text_main" android:layout_width="match_parent" android:layout_height="wrap_content" android:textAppearance="@style/TextAppearance.Title" android:layout_margin="@dimen/main_margin" android:text="I am a title" /> 好吧，至少现在你在运行的时候可以看到什么了。结果如你所愿！“好，让我们继续添加一些数据放入代码中，我们后来还会回来把这些硬编码删掉。”－开发者说。 时间快速流逝到了下午六点。时间不早了，你的代码还仅仅能够运行，处在只是不会出现崩溃的边缘，你累的快要死，你的脑袋也变的混沌。这时你提交了代码和问题，在你没变成这样子之前： 第二天，来到办公司，打开github，你会看到： 奧！扯淡！ 哪个家伙忘记把硬编码的脏数据去掉了。 这个数据会愉快的渗漏到我们最终版的apk中，这同样也是不好的。 这会导致今天某个人带着难看的样子站立五分钟。 哎呀！这个人曾在我身边出现。 不要成为一个工具，去使用工具 怎么才能避免，你问？足够简单：使用namespace工具和他的属性 从现在开始它将成为你最好的朋友：...
