Bringing Redux to Kotlin

As you could understand from our example, the state is a static object, yet, it can change. And to introduce these changes, we’ll have to dispatch an action.

Action

Actions are the objects that describe changes in the state. These payloads of data are the only source of information for the store (we’ll come to this a bit later) and a key element that allows producing a new state from the previous one.

Back to our pies. In this case, actions are the changes that transformed the previous state into the new one. For example, you had a baked pie (previous state), then you sprinkled it with powdered sugar (action) and got a pie with powdered sugar on the top (new state). Later, you took this pie (previous state), ate half of it (action) and then there is only half of your pie left (new state). That’s the simplified model of how actions and states are interrelated.

Having every change described as an action is very convenient for developers since it provides with a clear understanding of what’s going on in the app.

Using Kotlin, actions in a ToDo app can be written like this:

However, states and actions are just objects that require some function to interact with each other. And that’s when a reducer comes into play.

Reducer

Reducer is a function that ties two previous objects (a state and actions) together and returns a new updated state that includes these changes.

The point is that actions include information about some changes but not about their consequences. That’s, actually, the task for reducers.

So, if you have a whole cake (previous state) and then eat half of it (action), it’s the reducer who will tell you “well, now you have only half of the cake left” (new state).

How does it work in practice? Let’s take a look at the reducer in our hypothetical ToDo app written in Kotlin:

But ToDo apps like the one above are usually simple and don’t have too many objects (actions, for example). But what is to be done when we’re considering complicated apps where a lot of different actions take place? For this purpose, we advise splitting reducers so each of them manages only some specific slice of the state. That’s what we call reducer composition and consider as the fundamental pattern of creating mobile apps using Redux.

So, the reducer from the code above may be split into 2:

Finally, there is only one core concept left to review.

Store

This object fulfills several important tasks:

• stores the state;
• provides access to the states as well as allows to update them;
• notifies listeners about changes of the state.

Note that you can have only a single store. For splitting data handling logic, you should use reducer composition that we mentioned in the previous paragraph.

Now let’s come back to our ToDo app prototype and find out how we managed to write the store for it. Here is the implementation example in Kotlin:

So, these were our short review of the 4 main concepts related to the Redux architecture. They perfectly describe the main idea behind Redux and offer us a deeper understanding of app’s lifecycle. If in a simplified form lifecycle of a mobile app looks like this:

After we apply what we’ve just learned about Redux core concepts, our outline can be more detailed and specific:

📱 Advanced Example of Redux Implementation

Now we want to show you how the Stormotion team used Redux while developing Tangery. This is a mobile application that allows to plan and share your events with friends. Each event can be tied up to a list of locations, so Redux helped us to manage all the activities connected to the locations.

Screen # 1: Initial state

On this screen we can see the initial state or, in other words, an "empty" event without any connected locations. Yet, the state is one of the central elements in the whole Redux architecture as we defined it earlier.

In order to build any screen you have to design its state. So your workflow should be as follows:

1. Examine screen's interface.
2. Determine which elements are essential ones and therefore should be stored in the state.
3. Code! 🙂

For example, the state of this screen will store only 2 main characteristics - the event itself and its admin (so as to show him a specific event management button).

Screen # 2: Removing locations

The geolocation element plays a big role in the Tangery app. When a new event is created, users should be able to add and delete locations as well as see the list of already added ones. The removal process (you can see it in the image above) requires special attention. Technically, this process looks like this:

1. Users call the action "delete" by tapping the appropriate button.
2. This request goes to the reducer.
3. Reducer takes the previous list, finds there the right element, deletes it and gets a new list.

Eventually, View only knows the previous list and the new one, so after reloading it's going to blink and just show the latest version. Yet, Redux allows improving this process with a smooth animation that will definitely provide better UX.

For this purpose you should use DiffUtil. We just have to pass it our adapter, to which our RecyclerView is attached, and DiffUtil will notify View of all the changes. To implement this DIffUtil we have to answer 2 questions about our lists: whether these 2 elements are just versions of the same entity and whether they are different.

Screen # 3: Transition from the list to the particular location

Redux allows easily solve this task. All you have to do is change mode in the state, and it will extract all the necessary information without any additional commands.

Screen # 4: Transition between locations

While developing this screen we used Redux to provide users with even smoother experience. The more common way to implement this feature is to call Google Maps’ animation and move to another location when the ViewPager animation has ended.

Instead, we have developed this in such a way when the transition from one location to another is smoothly carried out while the user scrolls the bottom panel with the locations.

To implement this it’s necessary to know the current position. For example:

💡 Takeaways

To sum up, the Redux architecture isn’t typical for the mobile world but it has enough advantages to make your app development easier and smoother. With its help you’ll be able to work with branched and complex systems in a simplified way. Let’s briefly remember main advantages and disadvantages of Redux: