Communication modes between Android application modules

Android application development often requires multiple modules to communicate (call each other), if you do not pay attention to avoid coupling, future function expansion and adjustment will make the code very confusing, prone to errors, and maintenance difficulties. For example, fragment uses its public member method directly through (mainactivity) getactivity (), which is tightly coupled between fragment and mainactivity.

1 public class ...     3 public                void              

First of all, there are several common coupling types: 1 simple data parameter coupling. It is generally acceptable to use only basic data types to pass information between two modules. 2 Simple Object coupling. Refers to an object that creates another object. In general, this is no problem, but in some cases, such as unit tests need to configure network objects, this requires dependency injection to solve the problem. 3 semantic coupling. means that the module does not directly manipulate the other module in the same way as an interface. For example, as mentioned above, fragment converts an activity reference to its subclass to use. We should try to avoid semantic coupling. So how to avoid tight coupling? First, the first interface allows other classes to communicate with each other through the means of the interface.

public class fragmentpage{     private tabswitcher mtabswitcher;     ...      Public Fragmentpage (Tabswitcher switcher) {          mtabswitcher = switcher;     }      public void OnClick (View v) {          ...          Mtabswitcher (tabswitcher.recommend_tab);          ...     }}

In large-scale Android application development, we may need to notify the occurrence of multiple classes of an event, if implemented simply through an interface, will generate a large number of interfaces, and need to maintain the message recipient queue, increase the complexity of the program. So we need to be able to manage the subscription-release relationship scenario: Messagebus. This method of communication is based on the subscription-release design pattern, where publishers can post messages, and the classes or modules that subscribe to the message are notified, making the two completely separate. Android provides a way of broadcasting so that intent can be passed between different applications. However, when you pass complex data objects, you need to implement the serializable or parcelable interfaces. Currently more prevalent is the use of event-based Messagebus, which supports custom events. The related eventbus are Greenrobot eventbus and square Otto. Reference: http://vinsol.com/blog/2014/11/04/communication-patterns-for-application-components/

Communication modes between Android application modules