Event-driven programming for Android

Andoird 中事件驅動編程

https://medium.com/google-developer-experts/event-driven-programming-for-android-part-i-f5ea4a3c4eab

(This is the first article in a three-part series) (本文是系列文章中的一部分)

Although Android includes some event-driven features in its development, it is far away from being a pure event-driven architecture. Is this something good or bad? As in every issue with software development the answer is not easy: it depends.

雖然 Android 已經包含了若干事件驅動特性，但其離純正的事件驅動架構還有一定的距離。這到底是好事還是壞事呢？和多數軟件開發問題的答案一樣：看情況。

First, let’s establish a definition for event-driven development. This is a programming paradigm where the flow of execution is determined by events triggered by actions (such user interaction, messaging from other threads, etc). In this sense, Android is partially event-driven: we all can think of the onClick listeners or the Activity lifecycle, which are events able to trigger actions in an application. Why I said it is not a pure event-driven system? By default, each event is bound to a particular controller, and it is difficult to operate besides it (for example, the onClick events are defined for a view, having a limited scope).

我們先來為 “事件驅動開發” 做個定義：事件驅動開發指的事一種編程模式，在此模式下所有的程序流程都決定于事件 (event)，而事件又是由行為 (action) 來觸發（如用戶交互，來自其他線程的消息等等）。從這方面來看，Android 是部分驅動開發的：我們都能想到 onClick 監聽函數或 Activity 的生命周期函數，這些都是由應用里的行為來驅動的事件，那么為什么我們還是說 Android 不是純粹的事件驅動系統呢？因為，默認情況下，所有的事件都是綁定在各自的控件器里，你很難從外部去操作觸發它（例如：onClick 事件是在 view 中定義的，有指定的上下文范圍）。

Wait, you are talking about a new programming paradigm. Adopting frameworks or methodologies has always a cost, could this bring any advantage? I say yes, and to show it I want to present some limitations with traditional Android development.

等等等等，你是在說一個新的編程模式？移植框架是有代價的，這個新模式能帶來什么好處嗎？ 我的答案是：可以，為了證明其好處，我要先說下現有的編程模式的幾個局限性。

In many scenarios it will be easy to end up with a structure as the following diagram is showing:

在多數情況下，我們很容易設計出這樣一個代碼框架：

Activities can communicate with Fragments, Fragments can send messages to another Fragments and Services. There is a tight coupling of components, and applying changes can be expensive(*). This leads frequently to boilerplate code, interfaces that implement functions that need to callback and propagate through different layers… you probably know where I want to go. As the amount of code increases, the maintainability and good software engineering practices are decreasing.

Activiy 可以與 Fragment 通信，Fragment 可以發消息給其它 Fragment 或 Services。這是一種緊耦合的組件關系，在其中做修改是比較昂貴的 (作者后文標注：I deliberately like to use the word “expensive” when referring to “lot of time”. Thinking in economical terms is frequently more effective.)。這種設計會導致大量的同一格式的代碼，所實現的接口需要在不同的層次里進行回調和傳遞 (you probably know where I want to go)... 隨著代碼的增加，整個工程的可維護性及良好的工程實踐都會降低。

How does event-driven programming apply here? Let’s represent another system proposal:

那么，在事件驅動編程模式下會怎么處理這種情況呢？請看以下的系統結構圖：

Conceptually, the represented system have an event bus. There are different entities subscribed to the Event Bus, and posting events or listening to events?—?being respectively a producer or a consumer. Any subscriber can perform an action without knowing the logic. Think about it. Think about particular possibilities: a Fragment could render again and update its screen without knowing the logic behind any operation, just knowing that an event took place. Think about the possibilities of decoupling code and having a clean, compartmentalized architecture.

上圖中增加了一個概念：事件總線 (event bus)。不同的實例會訂閱 (發送或監聽) 事件總線，這里稱之為生產者 (producer) 和消費者 (consumer)。如此，可以想到，Fragment 可以在不知道背后任何邏輯和操作的情況下進行渲染，更新屏幕展示，代碼充分解耦，而架構也是非常清晰，系統模塊劃分非常明確。

Is this paradigm supported in Android? Well, partially. As mentioned, the SDK offers natively a reduced set of event handling techniques, but we we want to go further. There are some names I want to mention here:

上圖展示的結構 Android 支持嗎？嗯... 部分支持。上文已提到，Android SDK 提供了一些事件處理功能，但我們希望有更完整的實現。這里想提一提以下開源庫：

EventBus, from greenrobot. This library has been optimized for Android, and has some advanced features like delivery threads and subscriber priorities. Otto, from Square. Originally a fork from Guava, it has evolved and being refined to the Android platform. Having tried both I prefer EventBus over Otto. Greenrobot claims that EventBus is significantly better at performing than its pair, and provides an extra amount of features.

EventBus，來自 greenrobot。這個庫已為 Android 做優化，具有一些高級功能，如：分必線程，訂閱者優先級等。 Otto，來自 Square。源于 Guava ，為 Android 平臺做了重新的封裝改進。

嘗試過兩個后，我個人比較喜歡 EventBus。Greenrobot 宣稱 EventBus 明顯高效于其它競爭對手，并且額外提供了相當多的特性。

The next article will explore how to implement basic functions in EventBus

下一篇會展示如何使用 EventBus。