Calendar的主入口是AllInOneActivity，所有视图其实都是需要这个AllInOneActivity的，视图之间的差别体现在各自的fragment中。AllInOneActivity相当于一个派发者。
AllInOneActivity中定义了actionbar的布局样式以及菜单项目，初始化了各种视图所需要的Fragment，定义了各种菜单以及按钮的响应事件处理方式（比如menu菜单），以及事件处理机制handleEvent。
日历的代码中处理各种视图的模块，包括月、周、日、日程各种fragment为入口，比如：
月视图以/month/MonthByWeekFragment.java为入口
周视图、日视图以/DayFragment.java为入口
日程以/agenda/AgendaFragment.java为入口
设置模块/CalendarSettingsActivity.java为入口
日程编辑和新建部分，/event/EditEventFragment.java为入口
单条日程信息的显示部分/EventInfoActivity.java为入口
Alerts日程消息通知部分/alert/AlertActivity.java为入口。
而日历代码中被反复调用的最频繁的是如下的几个文件：
Utils.java
工具函数，具体日期的数字显示值的获取就是通过它，各个账户颜色的取值也是通过它，公历的一些转换也是它。
CalendarController.java
日历在主体上只有一个AllInOneActivity.java，然后分别是各种Fragment。这就需要一个中介来统一处理他们的关系，AllInOneActivity和Fragment之间，以及不同的Fragment之间的通信（主要是事件），都是通过CalendarController这个类来完成的。
当在某个Fragment中想要发出一个事件的时候，该Fragment会用到自己实例化的CalendarController对象（mController），例如下面的样子：
mController.sendEvent(this, EventType.GO_TO, time, time, -1, ViewType.CURRENT);
/**
* Helper for sending non-calendar-event events
*
* @param sender object of the caller
* @param eventType one of {@link EventType}
* @param start start time
* @param end end time
* @param eventId event id
* @param viewType {@link ViewType}
*/
public void sendEvent(Object sender, long eventType, Time start, Time end, long eventId,
int viewType) {
sendEvent(sender, eventType, start, end, start, eventId, viewType, EXTRA_GOTO_TIME, null,
null);
}
这里的sendEvent函数有很多参数，但是他们最终都会调用 CalendarController中重载了的public void sendEvent(Object sender, final EventInfo event)，而之前的那些零散的参数都被封装在了这两个参数里。
sendEvent函数最终是要把EventInfo（事件信息）传递给事件处理对象（eventHandler），一个事件的处理对象可能还不止一个，因此需要遍历一次所有存在的事件处理对象，并调用这些对象的handleEvent(event)函数。
if (DEBUG) {
Log.d(TAG, "sendEvent: Dispatching to " + eventHandlers.size() + " handlers");
}
// Dispatch to event handler(s)
if (mFirstEventHandler != null) {
// Handle the 'first' one before handling the others
EventHandler handler = mFirstEventHandler.second;
if (handler != null && (handler.getSupportedEventTypes() & event.eventType) != 0
&& !mToBeRemovedEventHandlers.contains(mFirstEventHandler.first)) {
handler.handleEvent(event);
handled = true;
}
}
for (Iterator<Entry<Integer, EventHandler>> handlers =
eventHandlers.entrySet().iterator(); handlers.hasNext();) {
Entry<Integer, EventHandler> entry = handlers.next();
int key = entry.getKey();
if (mFirstEventHandler != null && key == mFirstEventHandler.first) {
// If this was the 'first' handler it was already handled
continue;
}
EventHandler eventHandler = entry.getValue();
if (eventHandler != null
&& (eventHandler.getSupportedEventTypes() & event.eventType) != 0) {
if (mToBeRemovedEventHandlers.contains(key)) {
continue;
}
eventHandler.handleEvent(event);
handled = true;
}
}
那么事件处理对象，基本上都是通过自己的CalendarController成员变量mController发送事件的类本身也是事件处理对象，也就是我们熟悉的AllInOneActivity、MonthByWeekFragment、AgendaFragment、DayFragment。
这些类都继承了EventHandler这个接口（也就是事件处理对象的原型），并实现了其中的void handleEvent(EventInfo event);方法。EventHandler这个接口是在CalendarController中定义的，如下：
public interface EventHandler {
long getSupportedEventTypes();
void handleEvent(EventInfo event);
/**
* This notifies the handler that the database has changed and it should
* update its view.
*/
void eventsChanged();
}
刚才提到了遍历事件处理对象，也给出了遍历的那段代码，可以看到其实实在遍历这个集合eventHandlers，eventHandlers中的成员是通过public void registerEventHandler(int key, EventHandler eventHandler)方法得到的。但是AllInOneActivity比较特殊，调用的是CalendarController的registerFirstEventHandler方法。
之所以要区分于其他，是因为整个日历的架构中要求优先调用AllInOneActivity的handleEvent。假如mFirstEventHandler不为空，则最先处理他，registerFirstEventHandler也在方法之类调用了registerEventHandler，这样AllInOneActivity就有优先和普通两种身份。
不管是registerFirstEventHandler还是registerEventHandler都有一个key参数，key是标识是不是同一个handler的键。
可以看到AllInOneActivity能处理的事件也只有三种，跳转、查看日程、更新日历title上的日期。对于其他的handler，能处理的可能更少。
我们来看看其他的handler支持哪些事件。可能还没有找出所有的handler。
MonthByWeekFragment
public long getSupportedEventTypes() {
return EventType.GO_TO | EventType.EVENTS_CHANGED;
}
DayFragment
public long getSupportedEventTypes() {
return EventType.GO_TO | EventType.EVENTS_CHANGED;
}
AgendaFragment
public long getSupportedEventTypes() {
return EventType.GO_TO | EventType.EVENTS_CHANGED | ((mUsedForSearch)?EventType.SEARCH:0);
}
这个类实现了一个重要的接口——CalendarController.EventHandler，它的父类是AbstractCalendarActivity。
先来看AbstractCalendarActivity，它是AllInOneActivity, EditEventActivity, SelectVisibleCalendarsActivity这三个类的父类。其内容很简单：
public abstract class AbstractCalendarActivity extends Activity {
protected AsyncQueryService mService;
public synchronized AsyncQueryService getAsyncQueryService() {
if (mService == null) {
mService = new AsyncQueryService(this);
}
return mService;
}
}
包含一个AsyncQueryService变量和对应的get方法，并且get方法还是加锁的，保证了AsyncQueryService对象的唯一性。
· 这是一个辅助类，是用来在后台Service中执行ContentResolver调用的。它将因为调用方(活动)被杀而导致调用丢失的可能性降至最低。
· 它被设计用来将AsyncQueryHandler在后台线程调用ContentResolver的方式简单的迁移到Calendar中。
· 这个类支持增删改查和批量操作，它也支持延迟处理和时限内取消操作。注意一个应用中只有一个队列来序列化所有调用。
上面说了，本质上AsyncQueryService是个Handler，但它又要在后台Service中执行操作，这个Service就是AsyncQueryServiceHelper，AsyncQueryServiceHelper是IntentService的子类。
所以，AsyncQueryService的基本操作模式是，外部调用其添删改查方法时，它把方法参数和自身的引用交给一个IntentService，由这个IntentService来实际执行添删改查操作。执行完后，IntentSerice会给Handler回送消息。而在AsyncQueryService的handlerMessage中，它会根据操作类别回调不同的方法，例如onDeleteComplete。
因此，在使用AsyncQueryService时，我们需要实现自己的子类，重写onDeleteComplete等方法，就可以实现自动在后台服务中做数据操作，操作结束后在主线程回调操作结果。
注意一点，上面的AbstractCalendarActivity中的AsyncQueryService对象是直接实例化的，没有重写任何回调方法。因为这个对象只在EditEventHelper中用到了：
public EditEventHelper(Context context) {
mService = ((AbstractCalendarActivity)context).getAsyncQueryService();
}
mService.startBatch(mService.getNextToken(), null, android.provider.CalendarContract.AUTHORITY,ops, Utils.UNDO_DELAY);
只需要编辑后台数据，无需回调显示到视图上。
