RxSwift | Better Event Handling

How to start with RxSwift | Baby Steps Guide

“Reactive Programming = Async Programming + Functional Programming”

Reactive extensions when used correctly, it can make lot of things easier and reduce the code length. Additionally, the reactive extensions can be easily mixed with the OOPs.
The essence of reactive programming is composition of observer pattern & iterator pattern. Think about Rx as a game of football with more than one ball, we can say balls are free floating (asynchronous) and can be acquired by different players and pass to next one. Scalability, modularity, de-coupled & asynchronous code is the beauty of Rx. To achieve such characteristics, Rx is offered as library with which you get handful set of APIs to grab control over async calls.
With great power, comes great responsibility. Misuse of Rx can be a disaster. How? Memory management is important in Rx, we deal with objects & their ownership.

Why the heck Rx is used?

No need to use call-backs:

For a developer like me, call-backs/closures/blocks really give me creeps. Why you ask? It’s hard to trace flow across files, write a separate call-back function for each state or manage params to differentiate, then register them and finally find the place from where to call them when an event occurs. Phew...!! lots of stuff for a single change in value.
In Rx, you can simply put an observer on a value on which few things like UI or something else depends and relax. Rx will give you all you need at a single place.

Threading and asynchronous operations made easy:

By default, Rx is single threaded. Scheduler property of observable will make sure your event handling is running on desired thread/queue. This offloads the computation and gives access to required threads/queues.

Same API for every operation:

e.g. computations, database accesses, animations, networking or user input handling. This suit of API’s makes sure that when we want to implement same thing across the domain of choice, it becomes very handy because of its cross-platform support.

Declarative, readable code:

Rx code very much tells what it wants to accomplish which then gives a clear picture of states where the control can be stated to execute. classical problems like call-back hell and polling. After using Rx in my application, it became very much smooth, real-time, fast & results are updated in real-time.
Where Rx fits well?

Responsive-UI/Interactive/Event based/Parallel execution of tasks:

The apps with such requirements can be from any industry just that many inputs and many outputs should come into picture. To give a precise use case, in real time multiple stock price updating on one screen can be the good example, here multiple independent API’s are being called and everyone has liberty to update UI with results.

If you need to receive, filter and/or combine streams of events:

This is what Rx says about taking control over free floating balls. All you need is a closure/block for a state say error/success/completion and you will be precise about what should happen at that point of time. For such cases you might need to reject some events, repeat some events, group & trigger event on multiple conditions, sometimes you want to batch process things in a state, etc such scenarios are easily covered in Rx they call this feature of Rx as transformations.

What's on RxSwift’s roadmap?

In Rx we need to write code that reacts to the changes. Following classes and their responsibilities are provided by Rx community to better control your events:

Observable - Make a collection/object noticeable
Subjects – Observable where one can observe changes and emit events when needed.
Filtering Operators - Here we can give condition to remove unwanted elements from observable.
Transforming Operators - Modify entire sequence of observable elements.
Combining Operators - Mix different observable sequences to get a new sequence.
Time Based Operators - Control the time parameter of elements in sequence.
Schedulers - Run your subscription on desired thread/queue.
Marble Diagrams - Pictorial way to represent event handling in Rx.
Dispose Bag - Memory management of subscriptions created with Rx.

Let's talk about Pattern Rx uses its: Iterator + Observable

Rx is a combo of two patterns, iterator and observable. Iterator pattern to iterate over collection of events and observable to notify observer when appropriate state is reached.

To understand why Rx adopted this pattern we must take a step back and understand usually CURD operations on resources are needed in conjunction with events around states of the resources.

Who is using Rx?

Where to go from here?

Read this amazing (10 mins) post by Sebastian Boldt this post will make sure you learn some RxSwift code: Learn & Master ⚔️ the Basics of RxSwift

COFPROG