Android Event-driven programming-based on Eventbus (i)

Android Event-driven programming-based on Eventbus (i)

--Welcome Reprint, please specify the source http://blog.csdn.net/asce1885, without my consent do not use for commercial purposes, thank you--

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

This article Gitbooks link: Http://asce1885.gitbooks.io/android-rd-senior-advanced/content/androidshi_jian_qu_dong_bian_cheng _ff08_yi_ff09.html

While Android development has some event-driven features, it is far from purely an event-driven architecture. Is that a good thing or a bad thing? As with everything in software development, it's not easy to answer: it depends on the situation.

Let's start with the next definition for event-driven programming. Event-driven programming is a programming paradigm in which the execution of a program is determined by events (event) triggered by actions (actions such as user interaction, messages sent by other threads, and so on). In this sense, Android is part of the event-driven: We all know that the onclick listener or activity lifecycle is an action-triggered event in the app. Why do I say it's not purely an event-driven system? By default, each event is tied to a specific controller, so it is difficult to use the event elsewhere (for example, the onclick event is defined as a view service, so it has a limited scope of use).

Wait a minute, you're talking about a whole new paradigm of programming that uses this new framework or approach to bring costs, so what's the benefit? The answer is yes, in order to illustrate it, I'll start by talking about some of the limitations of traditional Android development.

In many cases our engineering code will easily evolve into the structure shown:

Activities can communicate with fragments, fragments can send messages to other fragments and services. The coupling between the components is severe and the time to modify the code is costly. This often leads to the generation of boilerplate code, such as the need to propagate interfaces between different layers that implement callback functions, and you should know what I mean. As the amount of code increases, maintainability and good software engineering practice decreases.

So how does event-driven programming work? Let's take a look at another system architecture design:

Conceptually, the system above has an event bus, with different entities subscribing to the event bus, either sending events or listening to events-either as producers or as consumers. Any subscriber can perform an action without knowing the business logic. Imagine a specific possibility: a fragment can re-perform rendering and update the screen display without knowing the business logic behind any operation, just receive an event. Imagine decoupling the code and getting the possibility of a neat, well-partitioned architecture.

Does Android support this programming paradigm? Well, partially supported. As mentioned above, the Android SDK itself provides a simplified event-handling technique, but we want more support. Here are some names I would like to mention:

• Eventbus, from Greenrobot. This library is optimized for Android and has some advanced features such as thread delivery and subscriber prioritization.

• Otto, from Square. Originally from the Guava fork, behind the development, has been perfected on the Android platform.

Two libraries have been tried, I prefer eventbus. Greenrobot claims that Eventbus is better at performance than Otto and offers a lot of extra features.

The next article will explain how to implement basic functionality in Eventbus.

--Welcome Reprint, please specify the source http://blog.csdn.net/asce1885, without my consent do not use for commercial purposes, thank you--

Android Event-driven programming-based on Eventbus (i)