The Redux architecture is not very complicated but it has a steep learning curve especially for Java programmers. Redux focuses more on functional programming with some reactive elements as compared to run of the mill Java apps which are more object oriented. Redux is also different from architectures such as MVP, MVC or MVVM as
View is a significant part of these architectures and sometimes heavily tied. eg.
view.showLoading(), etc. Where as Redux does not know and does not care about
Let’s go over the components that make Redux. I’ll explain some details with an example of an app where users can search for a movie.
State in Redux describes your app’s state at any given time. State is an immutable object which holds the information about the ‘current state’ of the app. In Redux, state is immutable and can not be changed. To update the state, a copy or a new object must be created. Based on the requirements of your app, your state can have many
child state. Your state should be as small and flat as possible. If you have a deeply nested state, it can be very difficult to manage it. Let’s look at an example.
Here, we have a data class
AppState which represents the state of the whole app.
SearchState represents the state of the search (or search screen, but we are not going to focus on the view right now).
query is the search term entered by the user and
movies is the list of movies that search returned.
data class in Kotlin are very helpful as they are immutable and easy to copy so it makes sense to use it for our app’s state.
Action describes the change in the state. Usually, action has a name and some payload attached to it. But we can do without the name field. Here’s an example.
ClearSearch: This action describes that the query and search results should be cleared.
Search: This action describes that a search should be made based on the given query.
SearchResultLoaded: This action describes that search result should be loaded to the state.
So each of these actions will transform the state to a new one.
Reducers are an integral part of the Redux architecture. As the name suggests, a Reducer reduces (changes) the current state to a new state (based on the given action). In Redux, reducers are pure functions and they should not have any side effects. A pure function will give the same output for the same inputs no matter how many times you run it or when you run it. A pure function should not have something like
Random.getRandom() because we can’t predict the outcome in absolute values. Reducers should not have any side effects, eg. logging, making an api call, etc.
Let’s write a reducer for
AppState which modifies
SearchState and in turn
This reducer will change the state for
SearchResultLoaded actions only. For other actions, it will simply return the state as is.
Reducer are just there and you may be wondering how are these things related and tied together to make it work. That’s where
Store comes in. Store is at the heart of Redux. The store has following responsibilities.
- Store the state.
- Provide access to the state.
- Allow the state to be updated.
- Notify the listeners about the change.
Let’s see how the store is supposed to look.
This is a very crude definition of the Store and we will improve it later to make it less verbose and more closed.
Reducer is just some class that I have put here. We would replace it with higher order function later to make it cleaner. According to this implementation, the order of the reducers matters.
How does the store bind it all together?
- The store is created with a default state and a list of reducers.
- A component (usually the view) dispatches an action by calling
- The store iterates through all the reducers and asks them to reduce the current state to a new state based on the dispatched action.
- Once the state is reduced to a new state, it will notify all the listeners via
listener.onUpdate(state)if the state has actually updated.
Where does the view come in the picture?
The view subscribes to the store for state updates. Every time the state is updated, the store will notify the view and give it the new state. The view will render itself based on the new state. When user performs some action, eg. enter a search query, it will dispatch an action to the store.
To summarize, when an action is dispatched, the store asks the reducers to reduce the current state to a new state based on the given action. The store then notifies all the listeners (views in our case) of the state change. Here’s how the flow looks like!
Some code maybe?
Here’s some sample code that our movie search app will use on its search screen.
- Create a
StateChangeListenerwhich listens to state updates from the store. This is your
renderfunction which would update the UI based on the state. Subscribe it to the store.
Searchaction on click. The store will reduce the current state to the new state with the help of the reducers.
ClearSearchaction on click. The reducer will change the
SearchStatequery to empty string and movies to empty list. The store will notify the listeners of the new state. Our render function will update the UI.
I hope the explanation has made some sense and you have a bit of a picture of different concepts of Redux. Let’s go through the principles of Redux architecture.
Redux is described via these three fundamental principles.
1. Single source of truth.
The state of your whole application is stored in a single object (object tree) within a single store. It means that your app has only one store and one state object. Other states are stored in the app state object. A single state tree makes it easier to debug the application. The state of the application is single source of truth.
2. State is read-only.
The state is immutable and can only be changed via
dispatching an action to the store. State immutability is very important as we know exactly which action updated the state. It also ensures that the views or the network calls can not change the state directly. All the changes are centralized via the store and happen one by one in an order which also helps us in avoiding race conditions.
3. Changes are made with pure functions.
Reducers are pure functions that take the previous state and an action, and return the next state. Reducers are stateless in a sense that they do not care about the history. They will change State A to state B with given action X every time. There are no exceptions to this. This makes the reducers really easy to unit test.
These 3 principles are very important and are core elements of the Redux architecture. Now, that you have learnt about Redux, let’s see what are the reasons this could be beneficial in android application.
How does Redux help with developing an android application?
Redux allows us to solve a lot of different potential problems.
Single source of truth: Redux has one state for the whole app. So if something somewhere in the far corners of our app tries to change something, we will know about it since it has to dispatch an action to the store.
Immutability: Redux state is immutable so we are very sure that it’s not going to change randomly. We are confident about our state and UI.
Single threaded: Redux works on single thread only. All the actions must be dispatched on the same thread where the store was created. UI thread in case of android apps. The store notifies the listeners on the same thread. With this we avoid race conditions which are difficult to detect and fix.
Time travel debugging: Since the state is stored in the
Storeand can only be updated via dispatching an
Action, we can have something like time travel debugging. Basically, we can go through the logs and see the state 10 actions before. We could also write some component which would change the app state to any of the previous states and the UI would just work.
Separation of concerns: In MVP or MVVM, the
view,although passive, is still an integral part of the architecture. The presenter always calls method of the view / view interface. In Redux, the view is insignificant and is irrelevant for the Store and Reducers. This helps us in writing clean unit tests.
Pure functions: All the reducers are pure functions so it’s so much easier to expect what the function is going to return for a set of inputs. Writing unit tests for pure functions and covering all the cases is much easier.
Redux also creates some problems for us, but if we are disciplined in writing the code, we can avoid them.
Single source of truth: It’s a great pro but it can become a swirling abyss in no time. Since there is only one state tree, having complex multiple sub-states or child states can make our reducer logic go a bit haywire. Try to keep your state as flat and simple as possible.
UI state: The Redux generally does not care about the state, but we still have to add some UI state in our App state. This can also get complex very fast. So try to keep your UI state minimal.
Steep learning curve: Redux is based on functional paradigm and it takes some time to have that Ahaa! moment about Redux. Even though you don’t use Redux in your app, you should try to learn and write your own implementation. It’s really interesting.
There are more advantages and disadvantages of Redux architecture in an android app, but we will visit them in upcoming articles.
You must be wondering about
API calls or
Database calls which happen on IO thread and are technically not pure functions. Yes, Redux has taken care of it. These are
Side Effects and can be integrated with the Store via
Middleware. I’ll write more about
Middleware in the next article. We’ll also write our own implementation of Redux architecture.
Redux architecture series
- Introduction: Redux architecture for android apps
- Middleware: Introduction and implementation
- Write your own Redux implementation in Kotlin
- Add Middleware to your Redux implementation
- Build Battleship Game with Redux - Groundwork
- Implement the Battleship gameplay with Redux
Middleware in Redux architecture for android application
Are you having a hard time figuring out how middleware works in Redux architecture? This articles goes in-depth of Redux and explains what exactly a middleware is and how it is used in Redux. The article also helps you write your own middleware for Redux in Kotlin for your android apps.