Bringing Redux to Kotlin

Our today’s story isn’t typical. We’ll talk about a bit unusual architecture for the mobile world. Yet, we hope that you will find our insights useful and implement described here practices during next app development in Kotlin.

Short historical reference: in 2014 Facebook developed its Flux architecture. A year later, a new architecture, Redux, appeared on its basis and won great popularity among developers. It was designed to simplify the work with complex and branched systems of possible application states and create apps that are easy to test and have no problem with running in different environments.

Speaking of now, Redux has proved its suitability and that’s why we want to share with you our insights on this topic.

📚 Redux: Main Concepts of the Architecture

The Redux architecture is not the most complicated one. Actually, there is just a few basic concepts and features that you should be aware of before putting it into practice. It’s also important to figure out how all the elements are interconnected to fold a complete and deep understanding of the Redux architecture. And that’s what we’re going to do right now.

State

State is an object that holds a minimum required amount of information to construct a screen. In other words, current screen characteristics are recorded in a state and can be easily displayed to users.

For the better comprehension, let’s find some real-life situations that match this description. If we draw an analogy between a screen and a pie, then the possible pie “states” are: the pie is baked; the pie is sprinkled with powdered sugar; the pie is half-eaten; the pie is stale, and others. These are some static states that provide us with information which is true for anybody (if you and I look at the half-eaten pie, we both will see only the half of it but not the whole).

Yet, if we come back to coding and imagine some hypothetical ToDo app, its state may look like this:

However, in order to successfully apply Redux in practice, you should also get to know basic principles of its work. So let’s find out what Redux is all about.

🏆 3 Main Principles of Redux

Compliance with these principles is the key to successful use of the Redux architecture in mobile applications.

Principle # 1: Single source of truth

The main idea: the state of your app or screen is stored in an object tree within a single store.

A single state tree is a great advantage as it allows inspecting and debugging an app with no extra effort. Moreover, with the single source of truth the state from your server can be easily serialized and hydrated into the client one. This also opens up opportunities for implementing specific functionality - for example, Undo/Redo.

Principle # 2: State is read-only

The main idea: the state cannot be changed in any other way than by emitting the action.

The one and only way to change the system is through actions. Network callbacks, system events or views can’t directly influence the state - they can only initiate actions. These actions are centralized and processed one by one in a strict order, which makes it easier to log, store, serialize and replay them for different purposes.

Principle # 3: Changes are made with pure functions

The main idea: for specification of state tree transformation pure reducers are used.

The workflow of pure reducers is simple as that: they combine the previous state with an action and return a new updated state back to the user. Because reducers are just functions, you can easily manage them: pass additional data, control the order of their usage and so on.

🤔 Why Use Redux in Your App?

The Redux architecture allows solving many different development issues.

For example, an application state is usually spread out through the whole codebase. And that can be a great problem since over time we no longer understand what happens and why, how and when states are changed. Therefore, it’s difficult to add new features or reproduce bugs. However, Redux brings the state into a more streamlined form and makes it behavior more predictable.

Another issue is cascade updates that complicate the structure of apps and slow them down. Yet, do you remember the “single source of truth” principle? So this single store manages data flow to all other views. As a result, the hierarchy inside the app becomes more horizontal (we have one center that sends data to all other objects).

Predictable state mutations are the additional advantage of using Redux. Since all the updates are done one by one in a strict order, you always can foretell what state you’re going to receive in the end.

Then the app takes current ViewPager’s position and rounds it to find out the past and the next integers and their latitude and longitude. Right after that the average latitude and longitude are calculated (based on the current index) and the app provides a smooth transition from one location to another.

🎬 Presentation

Finally, we also have a presentation by our developer Alex for you. There you can find everything we were talking about today but in a visual form: