Redux + (RxKotlin | RxSwift) == Awesome Native Mobile Apps — Introduction — Part 1
The title is exciting, is n’t? The purpose of this blog is not to explain these libraries, very good documentation for them are already available. This blog will explain why the native app developer needs these libraries and how the developer experience changes when the need for such libraries are understood.
When you finish this blog series, I promise, you will learn a new way of writing your mobile apps, where you have a lot of predictability, testability and better developer experience.
The concepts explained in this blog are platform neutral, both iOS and Android development community can read on.
Let’s understand the need
Mobile Apps are evolving fast, many of them perform complex work than when it was conceived. With changing needs, Is our existing app development architectures are flexible enough?
Current architectures (MVC, MVVM, MVP, cleanAndroid and so on) built on an assumption that changes are always minimal and incremental like adding one or more UI controls to the UI screen. But often, changes are non-incremental and sometimes disruptive, such as
- adding completely new information to an existing screen, for instance, showing possible add-ons on the order confirmation screen
- introducing a new screen in the existing flow, for instance, introducing the frequently bought items by the user before user pays the order
How do we react to such app needs?
We often rewrite the mobile app screens and yes, more or less we end up changing many classes across the whole app!
Why?
When we add new information to the existing screen or adding a new screen in a mobile app flow, we are altering the application state. Often altering app state sends rippling changes in the app code, generally we end up editing good number of classes.
What is Application State?
App State is the UI data models used by the app, UI views reflect the portion of them and user actions, data from APIs and data sources such as SQLite, content providers update them. You may not call them with the name App State, certainly, every app has something like “App State”.
How are we updating App State?
- No consistency: Often trivial modification of the state results in disruption of as we don’t have a consistent way to handle the UI state of the app. It is developer discretion to decide how to update the app state. Often the same sub-state gets updated by different code blocks.
- No single source of truth: The application UI state is stored in different objects, often they are defined according to the needs of the screens. The data gets duplicated across many objects.
As the app grows, so as the complication of handling the states. For example, in the above picture, if the age is updated, the every screen states that have the age has to be updated.
- Multiple communication paths: In the typical app code, the changes are communicated two way, one from the code blocks to the data models and from the data model to the components.
If you think the above picture looks messy, the cruel truth is most of our native app code looks exactly the same.
Now we understood the issues, let’s find out the solution explore — Is there any better way?
Redux
Redux is a popular state container for UI apps. Very popular in the javascript world, proves to solve most of the problems of the native app engineering, we have noted in this post.
It starts with the below principles
- Have single source of truth for App state
Let’s not have every screen have their own state, instead every screen should work with the same object, App State. The state can have substates.
Explain Sub states?
The composition of sub-states makes the App state, for example in an ordering app, sub-states could be the user, user profile, offer, cart, order, last orders etc.
2. State is read-only
- Not every function in the app can update the state, instead, have a consistent mechanism to update the states.
- The initiation of state update should be explicit, using an object that describes what happened. Redux calls the object as Action.
- Neither the views nor the network callbacks will ever write directly to the state.
- All changes are centralised and happen one by one in a strict order. No race conditions!
3. Pure function changes the state
State changes are made by the functions that take the previous state and an action and return the next state. These functions do not change the previous state, it creates and returns new state objects, instead of mutating the previous state.
Redux calls these functions as reducers.
What about unit testing such mechanism?
Absolutely necessary, in order to ensure unit testability, such mechanism should be a pure function, devoid of native app intricacies such as ‘context’ in Android, ‘viewcontrollers’ in iOS.
React to State Changes
Ok, states are updated, how the components are updated with app state changes?
Before understanding that, let’s understand components, Components could be the portion of native app page or even a complete app page. Fragments and Activities components in Android, viewcontroller, and Views are components in iOS.
In order to get the updates, the components subscribe to the state changes
When the app state getting updated, the subscribed components notified of the state changes. It is up to the components to react to such event, either by updating the UI or take some action or simply ignore the event.
Simple is n’t? Remember in a typical native app code, instead, we have the series of callbacks, knocking the door of callback hell.
In the next post…
Now we have understood and learned the concepts, we will look at more deep into the Redux and code examples in next post, where you will start appreciating how Redux changes the developer experience.
Links to the series
NEXT ➡ Redux + (RxKotlin | RxSwift) == Awesome Native Mobile Apps — Code Examples and More — Part 2
