Reactive Architecture — Deep Dive

Welcome back. This is a continuation of my previous article on reactive architecture; where this time we will talk specifically about the building blocks of code. In other words, this post is a deep dive…an in the weeds, on the front lines, kind of post. I strongly urge you read the last post, read all blog links, and watch all videos. Then, and only then, will this post have a strong impact on you.

Four main components

I like to think of reactive architecture details as four major components and I’ll explain them in four analogies.

  1. Main Flow Pipe
  2. Interacting With The Asynchronous Sea
  3. Old Man Listener

Event Meat Grinder

Starting from the top left of the diagram, the event meat grinder takes all those UI interactions from the user and grinds them into a single event output. A great library for subscribing to UI interactions is RxBindings. This library from Jake Wharton wraps standard android listeners with Rx bindings. This way we can subscribe to a button click, scroll, long press, etc. From that subscription we then have all the UI data needed to create a well formatted UiEvent and send it to the main pipe.

UiEvent Creation in ViewController

Main Pipe

This is the most important aspect and probably the most complicated. The main pipe sits as a stream off a publish relay (Rx subject enhanced with no shortcomings) where we transform UiEvents into Actions, publish to the Interactor, and then scan results for UiModel updates.

Courtesy of: Mihaly Nagy
Main Flow Pipe in ViewModel

Interacting with the asynchronous sea

There are a sea of entities the Interactor will need to engage with in order to fulfill the requirements of the action. These actions and their results should be encapsulated inside the Interactor tied to the ViewModel. Using the same transformer techniques as before, you can transform data sets from asynchronous calls into results that the ViewModel can manipulate and manage. This is where a strong understanding of the operators will come in handy. Here you can manipulate the stream without breaking it.

NowPlayingInteractor

Old Man Listener

Like an old man with a megaphone in his ear, the end of the main pipe you subscribe to the UiModel on the main UI thread. The subscription happens in the ViewController. Here you’ll take the UiModel and process its results for updating the UI. All pretty straight forward.

Old Man Listener — NowPlayingActivity

Unit Testing

Unit Test UiEvents and UiModels
Unit Test Actions and Results
Main Pipe Unit Test Example

Saving State

Even though the android view model is a step in the right direction we still need to remember the memory constraints in Android. Once an activity is removed by the operating system, we need to save our screen state. The best way to do this is to directly save the UiModel inside the onSaveInstanceState. Store the UiModel in the bundle and reuse in cases where the ViewModel was created for the very first time. Here at this time we could “restore” our state.

Save State

All is well with the world…until!

As a user, I want to be able to filter my results

Filter + Scrolling Example = No Problem

Thinking in images

Before trying to hash out a new requirement in code, it pays to sit down and lay it out.

Use the marbles. Think in images.

Example Wrap Up

All of the discussions presented were accomplished by slowly cranking the dial of complexity. First, I started out with a basic example that included only the four main components. Second, I addressed application restore. Finally I went full steam ahead with a complicated multi event example. Each of them can be found as branches in my github repo.

  1. Restore
  2. Scrolling + Filtering

Final Thoughts

Reactive Architecture Be Like…
RxSwift Example