Related articles

Module decoupling Framework RxFluxArchitecture1- Introduction to the framework

Module decoupling framework RxFluxArchitecture2- Basic function realization

Module decoupling framework RxFluxArchitecture3- Subscription management binding lifecycle

Module decoupling framework RxFluxArchitecture4- Dependency libraries and dependency injection

Module decoupling framework RXFluxArchitecture5-Application co-exists with multiple modules

Architecture is introduced

RxFluxArchitecture

The architecture is divided into three levels: View, ActionCreator and Store.

1, the View

UI interface. Call ActionCreator method according to user interaction and respond to notification sent by ActionCreator or Store to complete UI update.

2, ActionCreator

Complete user interaction operations (interface invocation, time-consuming operation, page jump notification, etc.) and notify Store or View.

  • Sends notification of the result of the encapsulation operationRxActionTo the Store;
  • Send UI response notificationsRxChangeTo View;
  • Send operation exception notificationRxErrorTo View;
  • Send operation retry notificationRxRetryTo View;
  • Send operation progress notificationRxLoadingTo View.

3, Store

Maintain the data needed in the View, receive the operation result notification RxAction, extract the encapsulated data for the View to use, process different business logic.

  • Send UI response notificationsRxChangeGo to View, do UI update;
  • throughLiveDataMake the View UI update.

Characteristics of framework

1. One-way data flow

Using Flux, the front-end architecture launched by FaceBook, data flows in a single direction without callback of operation method. The relationship between upper and lower levels is obvious and logic is clear.

2. Hierarchy decoupling

The core library core-EventBus (with Tag function) implements the function of data bus. In the architecture, the upper level does not hold the objects of the lower level. This level only needs to complete the operation and send the notification, without knowing who the next level will respond to the notification.

3. Bidirectional binding

  • Store can be accessed throughandroidx.lifecycle.LiveData<T>Implement MVVM architecture and notify View of UI updates.
  • Store inheritanceandroidx.lifecycle.ViewModelTo maintain data while the View switches between horizontal and vertical screens.

4. Subscription management binding lifecycle

  • Store implementationandroidx.lifecycle.LifecycleObserverAutomatically associate the View lifecycle.
  • View and Store automatically register and unsubscribe with View life cycle.

5. Implementation of dependency injection in modularization

Dagger.Android is used to realize the dependency injection in the core library core-arch. The business Module only needs to create the dependency injection object generation library of @Module annotation without knowing how to realize the dependency injection.

6. Application multiple modules coexist

Core libraries Core-Arch-Annotations and Core-Arch implement multiple business modules to coexist Application lifecycle method proxy classes via compile-time generated code and reflection annotations.

Unit testing

  • ActionCreator does not use Android SDK code in principle and can be unit tested using JUnit.
  • RESTMock, Robolectric, Daggermock, and other libraries are used to easily test project code.

The source code

Open source module decoupling framework RxFluxArchitecture, welcome to like Fork, welcome to comment on guidance.