为了重用Fragment的UI组件，创建的每个Fragment都应该是自包含的、有它自己的布局和行为的模块化组件。一旦你定义了这些可重用的Fragment，你就可以把它们跟一个Activity关联，并把它们跟应用程序的逻辑相连来实现全部的组合式UI。
现实中我们经常想要一个Fragment跟另一个Fragment进行通信，例如，要基于一个用户事件来改变内容。所有的Fragment间的通信都是通过跟关联的Activity来完成的。另个Fragment不应该直接通信。也就是说Fragment间不直接通信，通过Activity转一下，按java常规，转一下多是使用Interface实现的。
以前不理解什么叫回调，天天听人家说加一个回调方法啥的，心里想我草，什么叫回调方法啊？然后自己就在网上找啊找啊找，找了很多也不是很明白，现在知道了，所谓回调：就是A类中调用B类中的某个方法C，然后B类中反过来调用A类中的方法D，D这个方法就叫回调方法，这样子说你是不是有点晕晕的，其实我刚开始也是这样不理解，看了人家说比较经典的回调方式：
Class A实现接口CallBack callback——背景1
class A中包含一个class B的引用b ——背景2
class B有一个参数为callback的方法f(CallBack callback) ——背景3
A的对象a调用B的方法 f(CallBack callback) ——A类调用B类的某个方法 C
然后b就可以在f(CallBack callback)方法中调用A的方法 ——B类调用A类的某个方法D
最近大家面试说经常被问到EventBus，github上果断down了一份，地址：https://github.com/greenrobot/EventBus ，的确是个不错的框架，主要用于事件的发布和订阅。
EventBus定义：是一个发布 / 订阅的事件总线。
这么说应该包含4个成分：发布者，订阅者，事件，总线。
那么这四者的关系是什么呢？
很明显：订阅者订阅事件到总线，发送者发布事件。
对于MVP（Model View Presenter），大多数人都能说出一二：“MVC的演化版本”，“让Model和View完全解耦”等等。本篇博文仅是为了做下记录，提出一些自己的看法，和帮助大家如何针对一个Activity页面去编写针对MVP风格的代码。
对于MVP，我的内心有一个问题：
为何这个模式出来后，就能被广大的Android的程序员接受呢？
问了些程序员，他们对于MVP的普遍的认识是：“代码很清晰，不过增加了很多类”。我在第一次看到MVP的时候，看了一个demo，看完以后觉得非常nice（但是回过头来，自己想个例子写，就头疼写不出来，当然这在后文会说）。nice的原因还是因为，这个模式的确让代码的清晰度有了很大的提升。
