How Flux saved my life
I’ve working as an Android developer from 5 years now. And I used so many architecture and design patterns in a bunch of different production apps. MVC, MVP, MVVM, VIPER, MVI, CLEAN. They all start under the premise of making your life such easy that you're never gonna cry on the shower again … but it always ended the same way, a monolithic application where changing one thing could meade the whole app stop working. Made that bug fix a weeks long work. But one day I discovered something that changed my life. Flux.
What’s Flux (and Redux) about?
I’m not going into a detailed explanation of this patterns, there's a lot of information out there of people that knows more than me. This architecture patterns has one thing in common (most importants for me):
- Create a single source of truth
- Create a unidirectional information flow
The first one resolves a bunch of commons problems at mobile applications, and its that the information shown in one screen could no be the same as in another one. To resolve this typically we need to reload the information more often to ensure that its correct.
The second one helps us to keep us mind-safe when debugging. You remember that bug that was triggering some operation random times? And you don't know where it was called? Having a unidirectional information of flow helps you to understand how is your domain flow, making your app more resilient and easily to find what was causing that annoying bug.
And there's another important point: Reactivity
This is the glue for the first two points. Making your source of truth reactive made your app will always show the last information.
My Android’s flux approach
I’ve working in two (currently working in two more) production app using flux. We have more than 1 Million downloads and 800k active users each month. Our apps rating is 4.5 stars, and our crash free rate is above 99,99% (Firebase don't have more decimals). I know this numbers where difficult to achieve without such a great team and a solid architecture.
What are our architecture components:
- Stores: Contains an immutable state. The store subscribes to Actions. When an action arrives to the store it changes his state. When the state changes, it will be emitted to the view subscribed to it.
- Actions: Represent an use case. An action could be: LoginAction, RequestInfoAction.
- Dispatcher: Object that takes care of giving each store the actions dispatched.
TL;DR
Flux could change your life as it did with mine. Checkout my flux implementation called Fluxy.
This is my flux implementation created for an startup I’m co-founder, based on the one we use at my full time job. It contains a basic example. Don’t hesitate to contact my via medium or email.
