Reactive Programming with RxAndroid and Kotlin
Apps nowadays need to meet the requirement of being robust and responsive. RxAndroid and Kotlin tools are equipped to help this process. They will help us take our apps to the next level.
Reactive vs Imperative Programming
Following are some characteristics of Reactive Apps
Responsive: Makes the UI thread is responsive so that the UX is improved and users don't get frustrated using it.
Resilient: Components are decoupled. they can fail and recover without affecting the other components
Elastic: If the size of the input increases, the app handles it gracefully
Message-driven: Async message passing system allows the components to stay decoupled and independent. Makes the app Elastic by monitoring the data load it helps resilience and responsiveness.
Functional: operate on data streams. Kotlin supports this
Declarative: opposite of imperative. Relies on the abstraction.
Tools
RxJava in a Kotlin env, RxAndroid
Kotlin — support functional programming, lambdas, first-class support for Android, removes boilerplate code
Improving the code with reactive programming
Handling user input to improve the usability
Chaining network calls without calling the second call in onPostExecute of an AsyncTask
Data caching — fetch data at regular intervals and display from the app’s memory. reduces the number of network calls. Rx Android makes this tedious task easier
And much more…
Making the apps reactive
Design Patterns:
It is important to consider various patterns available and use them according to the requirement. The idea behind most design patterns is the separation of concerns and modularity.
MVC:
Model View Controller, traditionally most common but has its issues
Model: responsible for representing the state of an application. Will consist of DBs, network APIs.
View: XML layout
Controller: Responsible for user interaction and displaying of our views.
But here the XML layout and the Activity/Fragments are tightly coupled (View and Controller). All the code gets bloated in Activity/Fragments.
Model is the only thing that can be unit tested. Instrumentation tests for other components, which can be tricky.
Also with MVC we need to manually preserve the state with onSaveInstanceState() or onRestoreInstanceState().
MVP
View — XML, activity, interface (view and layout are naturally coupled)
Presenter — business logic, state of the app. Nice contract between what we show and the logic which tells what to show. But can get bloated.
Model and Presenter can be unit tested but instrumentation tests for View — mocking need to occur.
MVVM
Model: Keeps the state and data of the overall system
ViewModel: Provides state and data for the particular instance. Says the view what it should display
MVVM gives all benefits of MVP plus Easy state persistence, less boilerplate code due to no interfaces and easier testing due to better separation of concerns and its reactive. Therefore MVVM is preferred.
Android architecture components
LiveData: is an observable data holder class. life cycle aware — respects the lifecycle of other components. It will only send updates to observers that are active. It helps decouple business logic. Can keep them in the view model and update the view when the state changes and makes the app reactive
ViewModel: A class that prepares the data in a life cycle conscious way. Totally isolated from activity/fragments so it can be easily tested.
Room: This persistence library is an abstraction layer over the built-in SQLite database. Integrates with RxJava. Easy to set up
DataBinding: More declarative layouts for views. You can access a ViewModel inside an XML layout and the UI elements can react directly to the state of the ViewModel. Two way binding is even possible. This reduces boilerplate code. but can be confusing and tempting to have logic on XML which can be wrong and makes testing impossible.
