Why RxFlux?
I realized that my previous post showing a real example of an app using RxFlux was quite extensive.
I decided to do a pre-introduction, where I will try to convince you why you should use it or at least read more about it.
So… why?
First of all RxFlux comes from the combination of RxJava and Flux pattern. If you don’t know the advantages of RxJava, just google it, you will find thousands of posts about it. On the other side, Flux is a known pattern in different platforms that recently popped up in the Android World.
There is no magical pattern or framework, but I really think that RxFlux could help you and here is why:
Architecture, RxFlux is based on a clear and straightforward architecture. That will keep your app organised while letting you work independently in each part.
Readability, there is a clear contract between View - Action - Store. Each part defines what it can do and what it provides. This contract makes it easy to know what are the actual methods and logic of your app while keeping the implementation and boilerplate code separate.
Testability, the clear separation and the defined contract of each part makes it easy to test independently. We can mock the input, test the logic and verify the output. The logic of the app, split between Store and Actions, can be “Unit tested”, the view will be covered by “Functional Tests” and Integration Test will verify the connection between each part.
Scalability, the structure of Flux allow us to couple and decouple modules since they work independently allowing the app to scale and being modified with minimal changes.
Those were the overall points, let’s focus now on specific problems and how RxFlux solve them.
Are you dealing constantly with super long activities or fragments, mixing up the logic and living on a callback hell?
RxFlux has a clear separation of concepts, will keep your activities and fragments in a diet, and since it uses RxJava and a bus pattern it will remove the callback hell from your life.
Have you ever found yourself handling errors everywhere, duplicating code and long if/else clauses everywhere?
RxFlux focus all the error handling in only one method that can be overridden in a base activity or in its children, this method will be called every time an error occur when trying to perform an action. This action will contain all needed information (type, error, action…) for handling the error.
What about analytics and marketing tools? They always make the code dirty, they change constantly and it’s always hard to integrate them in big projects.
The flow of RxFlux allows the Stores to register for Actions, why not to create a “AnalyticStore” that gets all the dispatched actions? That will allow us to concentrate all those tools in one point, where we will be able to get the needed information from the actions, or even create specific actions for them and push it to each tool.
If my arguments convinced you, spend some time reading more about it and try the example on the repository. Otherwise, please leave a comment, I would love to hear your opinions.
Next steps:
- Check the GitHub repository:
2. Follow the Wiki.
3. Read the next article RxFlux Android Architecture
Find me on: Twitter: @marxallski and Google+
