Redux + (RxKotlin | RxSwift) == Awesome Native Mobile Apps — Reactive Programming— Part 4

These libraries can be a boon for native app developers. See how they change the developer experience in the fourth part of this series.

We have learned about store, state, Reducer in part 3, and started to explore the need for Reactive programming, let’s dive in…

Just to recollect we have updated the authenticationState when the GitHub Login API is called, as we need to show the progress bar.

Redux Cycle

We have achieved the above by using the traditional callbacks or listeners. Refer to the section — to recollect the code.

When the API returns success or failure or timeouts, we need to dismiss the progress bar.

Looking at the code, you may see callbacks and logic inside the callbacks. Welcome to the call back hell. Think about the unit testing this code, you need to spend a lot of energy there.

Is there any better way?

ReactiveX Programming

ReactiveX is a library for composing asynchronous and event-based programs by using observable sequences.

In our example, we are calling GitHub API the results will be emitted asynchronously. We will be using Observables to capture the asynchronous results.

Why we use Observables?

ReactiveX Observable model allows you to treat streams of asynchronous events with the same sort of simple, composable operations that you use for collections of data items like arrays.

We have transformed our old UserLogin Class to the below

You may appreciate that the above code frees you from tangled webs of callbacks, and thereby makes your code more readable and less prone to bugs. More importantly, it is unit testable.

To summarise the work of the above code, it

• Calls the github API
• Create a RxSingle instead of other types, as it will emit only one event, either login success or failure
• Once the result is available it converts to the LoginResultAction
• Formats the date
• Creates a Pair of LoginResultAction and mainStrore
• Expose the Pair as Observable

In case iOS, you will create the Observable as described below

Now, let’s look at Subscriber.

The subscriber or observer, based on the outcome of the Async action, it takes the next step.

• If the API call results in an error, when the API is down, it calls onError functions, which will dispatch a call to start LoginFailedAction
• If the API call succeeds, based on the login success outcome, it starts either LoginFailedAction or starting LoginCompletedAction and LoggedInDataSaveAction

Who will tie up the Observable and the Subscriber?

Middleware. It observer the GHLoginObserver in the main thread and subscribe on the background thread with the subscription created earlier.

I hope by this time you are able to appreciate the fact, the calls between the APIs are truly decoupled.

Think about a scenario, where we need to call a second API, based on the result of a first API, in a traditional call back or listener paradigm, you have to hard wire the APIs calls inside the callback code.

Now with help of Redux and Rx combination, once you have the result from first API, you can dispatch the Action that can trigger the call to second API.

Calling Multiple API — truly decoupling

Now we are able to take the advantage of the Redux, to dispatch the actions to communicate between the API.

What about unit testing?

In the next post…

We will discuss unit testing the reducers, middleware and observables.

Links to the series

• NEXT ➡ Redux + (RxKotlin | RxSwift) == Awesome Native Mobile Apps — Part 5 — Unit Testing
• Redux + (RxKotlin | RxSwift) == Awesome Native Mobile Apps — Reducer and More — Part 3 ⬅ PREVIOUS
• Redux + (RxKotlin | RxSwift) == Awesome Native Mobile Apps — Code Examples and More — Part 2
• Redux + (RxKotlin | RxSwift) == Awesome Native Mobile Apps — Introduction — Part 1