Lessons learned implementing Redux on Android

When a lot of people think of the Redux architecture they think of the web. This isn’t really surprising because it originated and gained a lot of popularity there. At its core, it’s a simple application architecture that describes a system of organizing and manipulating state. This means that it can be applied to any kind of application development including mobile.

For those who are unfamiliar, the Redux architecture centers around a strict unidirectional data flow. All data within the application flow in one direction through components. At a high level, Redux aims to ensure deterministic view renders as well as deterministic state transformation and reproduction. Determinism here refers to the ability to know that at any given point in time, your application state is always valid and can be transformed into another predictable and valid state. Your UI components then update based on the given state.

The Redux architecture centers around three main components:

Store

This is simply a state container that holds on to your app state. It holds an immutable reference representing the entire state of your application and can only be updated by dispatching an Action to it.

Actions

Actions contain information to be sent to the store. They represent how we want our state to be changed. For example, consider the following action:

java
1data class AddTodoAction(val text: String)
Copy

It would be dispatched to a given store to update the application state:

java
1store.dispatch(AddTodoAction("Write blog post"))
Copy

Reducers

Since neither Actions nor the Store update state themselves, we need a component dedicated to doing this. That’s where Reducers come in. They simply take an Action and State and emit a new State.

java
1fun reduce(oldState: AppState, action: Action) : AppState {
2    return when (action) {
3        is AddToDoAction -> {
4            oldState.copy(todo = ...)
5        }
6        else -> oldState
7    }
8}
Copy

Now that we understand the components, let’s see how they fit together. The Redux flow is very simple. Your app renders the content of your app state on your view layer. User interactions dispatch actions which are forwarded to Reducers which operate on—and emit—a new app State.

I recently went about implementing the Redux architecture on a fairly large project, so I wanted to give a perspective on some lessons that I’ve learned along the way.

Do not have multiple stores in your app

Having more than one store in your app may seem like a great idea at first especially if your goal is a separation of concerns. However, each store together with its data flow can be thought of a closed loop system, making it difficult to synchronize state between them. Attempting to do this often requires you to attempt to dispatch state changes in response to other state changes which can result in an infinite loop.

java
1mainStore.dispatch(FetchGridItemsAction())
2...
3
4override fun onNewState(newState: MainState) {
5    // FIXME: You should never dispatch an event in response to a state change.
6    // This can potentially create an infinite loop.
7    homeStore.dispatch(UpdateHomeGridAction(newState.gridState));
8    ...
9}
Copy

Having multiple stores in this manner makes your architecture very rigid and difficult to change in the long term. This is especially problematic in an environment where requirements can change at any moment.

A better approach to take is to maintain a single global app state that contains multiple sub-states.

java
1data class AppState(val LoginState,
2                    val HomeScreenState,
3                    val GridState )
Copy

Keep your app state as flat as possible

The deeply nested state results in a lot of boilerplate code and is difficult to update since everything is immutable and requires you to create a new app state for every state update. While it may seem intuitive to have your state data models match the hierarchy of your UI, it makes updating deeply nested portions of your state very difficult. For example, considering the following data model classes:

java
1data class State(val sections: List<Section>)
2
3open class Section(val articles: List<Article>)
4class Home(articles: List<Article>) : Section(articles)
5class Discover(articles: List<Article>) : Section(articles)
6
7class Article
Copy

Instantiating and updating the state object would look something like this:

java
1val state = State(sections = listOf(
2                  Home(listOf(article1, article2)),
3                  Discover(listOf(article1, article2))))
Copy

Updating deeply nested properties such as articles here ends up being very tedious even using Kotlin’s excellent copy mechanism:

java
1val newHome = Home(listOf(newArticle, state.sections[0].articles[1]))
2state.copy(sections = listOf(newHome, state.sections[1]))
Copy

The solution here is to avoid nesting as much as possible. This is especially true with a state object that contains collections.

Your app state does not need to match the hierarchy of your UI.

java
1val state = State(sections = listOf(
2                 Home(refs=listOf(0, 1),
3                 Discover(refs=listOf(0, 1))),
4                 articles = listOf(article1, article2))
Copy

You can have a healthy mix of action creators and middlewares

Action creators are basically factory classes for actions. They allow you encapsulate things that you may want to do before dispatching actions such as making network requests or accessing shared preferences etc… and return an action as a result of completing the task:

java
1class TodoActionCreator {
2    fun createAddTodoAction(content: String): Action {
3        ... // do stuff
4        return AddTodoAction(transformedContent)
5    }
6}
Copy

Middlewares, on the other hand, are a lot like Reducers except they do not create new app state. Instead, they perform tasks and choose to forward along actions to the Reducers, discard them, or dispatch new actions altogether. A great use of middleware is for things like logging actions as they are processed during the flow:

java
1class LoggerMiddleware {
2    fun interact(store: Store, action Action) {
3        logDebug { action.toString() }
4    }
5}
Copy

Middlewares work best in situations where you want to do something globally across the entire application. Things like logging, Analytics and persistence make great candidates for middleware. However, actions that tend to be specific to the use case such as API calls should generally be delegated to action creators.

Reducers should be pure functions

The Redux architecture encourages a functional approach where you compose pure functions. Pure functions are basic functions that are deterministic in nature. Meaning that the output of a given function would always yield the same result if called with the same inputs. This is because pure functions have no internal state and leave no side effects.

Reducers should embody this philosophy. They should always take a state and an action and return a new state.

java
1class Reducer {
2    fun reduce(state: State, action: Action) : State {
3        ...
4    }
5}
Copy

Any additional information that is required by the reducer to reduce the state correctly should be passed in the action and the reducer should respect state immutability and always return a new state.

If you require a side-effect in response to an action, consider using a Middleware instead.

Unit tests save lives and hair

Unit tests are where the Redux architecture truly shines in my opinion. Since reducers are pure functions with no internal state, they are deterministic in nature. They will always return the same output state for a given input state and action. This makes them dead simple to test.

Additionally, given that state and actions are light-weight data objects, you don’t require any mocks for tests. Simply construct instances of your state and actions. Testing a reducer looks like this:

java
1val reducer = MyReducer()
2val state = MyState(...)
3val action = MyAction(...)
4
5val newState = reducer.reduce(state, action)
6
7assert(newState …)
Copy

If there are instances where you require data that are typically acquired from various places such as an external API or datastore. You can keep your reducer tests simple by making a “dumb” constructor for your action as well as a smart constructor/factory that supplies the data you need.

java
1class MyAction(val data1: String, val data2: String) {
2
3  companion object {
4    fun create(apiResponse: Response, datastore: Datastore): MyAction {
5      val data1 = apiResponse…
6      val data2 = datastore…
7      return MyAction(data1, data2)
8    }
9  }
10
11}
Copy

And as a result, your reducer remains crazy easy to test.

java
1val action = MyAction(data1 = "data1", data2 = "data2)
2val newState = reducer.reduce(state, action)
Copy

And you can test the factory separately where you may want to use mocks.

java
1val response = mock<Response>()
2val datastore = mock<Datastore>()
3...
4val action = MyAction.create(response, datastore)
5
6assert(action.data1 …)
Copy

Just use Kotlin

The Redux architecture certainly has a lot of ceremony around structuring components. While these contribute to keeping things clear and consistent as the project grows, your choice of language may determine the extent to which you are able to manage the boilerplate.

Features such as data classes, when statements, multiple top-level classes, and higher-order functions make a huge difference in code clarity. For example when trying to match actions in reducers one may choose to use instanceof checks;

java
1if (action instanceof AddTodoAction) {
2    return reduceAddTodoAction(oldState, action);
3} else if (action instanceof RemoveTodoAction) {
4    return reduceRemoveTodoAction(oldState, action);
5} else if (...) {
6    ...
7}
8return oldState;
Copy

This can get very unwieldy very quickly. Another option would be to use string constants as actions along with string matching in a switch but that isn’t a whole lot better. What does present a decent solution is the Kotlin when statement.

java
1return when (action) {
2    is AddTodoAction -> reduceAddTodoAction(oldState, action)
3    is RemoveTodoAction -> reduceRemoveTodoAction(oldState, action)
4    else -> oldState
5}
Copy

Conclusion

While Redux may have its origins on the web, it has a lot of really good ideas behind the architecture that we can learn from and bring to Android. While our platform, languages, and tools may be different, we share a lot of the same fundamental problems such as striving for complete separation of concerns between our views and business logic.

Redux is by no means a perfect silver bullet but at the end of the day; no architecture really is. It’s still relatively new but shows a lot of promise and we’re excited to see it mature on Android. If you are interested in playing around with Redux, I recommend taking a look at Evan Tatarka’s Redux library or ReKotlin which is a port of ReSwift.

---

Nish Tahir is a Senior Software Engineer at WillowTree Inc. where spends most of his time building digital products for the world’s leading companies. You can find more of his writings on the WillowTree blog.