How to make the most of Reactive for your project
At mobitouch, we always look for new ways to improve our work and deliver the best digital products to our clients. That’s why we invest so much time in searching for new technologies and innovations that bring significant benefits to developers, businesses, and app users.
One of the technologies I’ve been exploring is ReactiveX, a library for composing asynchronous and event-based apps by using observable sequences. Giants like Netflix, GitHub, and Microsoft are using it to improve their work.
ReactiveX claims to be more than an API. In fact, it has inspired the creation of several other APIs, frameworks, and even programming languages.
With ReactiveX, developers can easily create event or data streams, compose and transform them with query-like operators, and subscribe to any observable stream to perform side effects.
ReactiveX – our way
Until recently, Google hasn’t provided Android developers with patterns and general recommendations for creating quality code. That forced me to find and develop different tools for writing good quality code.
One of them is MVI.
Check out this repo to see what MVI is all about:
I created MVI to get a great event-based reactive architecture to make code cleaner, more readable, and easily scalable. MVI stands for Model View Intent (not Android Intents, but some events – let’s call it Event Manager and not mix it with titles). It’s a very similar pattern to MVP, but instead of having lots of methods you get just one public method which when used by View receives only one argument created specifically to identify an action.
Want to learn more about how to make the most of ReactiveX with these tools?
Read the three articles I published on Medium:
In Part 1, I introduce Reactive architecture with MVI pattern to enable project to use entire power of RxJava instead of wrapping network requests into it.
In Part 2, I show how to deal with MVVM provided by Google in a way that allows keeping all advantages of Reactive architecture with MVI introduced in the previous part. With that solution, ViewModel becomes an Observer instead of Activity/Fragment(View) but keeps the same way of sending events as View.
In Part 3, I look at the modular architecture that makes projects more easily scalable and builds much faster thanks to Gradle that doesn’t rebuild all modules that weren’t changed.