[META] Adopt RxJava to avoid reimplementing operators in LiveData

[mcomella]

edit: Morphed into meta bug

• [ ] parent of #1845 Identify preferred RxJava pattern to handle lifecycle
• [ ] parent of #1846 Identify how to adopt Rx, e.g. incrementally?
• [ ] (no issue: maybe can happen organically?) Identify how we should write and review new code (who reviews? Pair coding?)
• [ ] (file when we know incremental adoption is viable) Proof of concept: convert CursorViewModel, which already combines 3 existing streams, to Rx
• Non-blocking issues
  • [ ] parent of #1847 Compile a list of Rx learning materials, gotchas, debugging tips? for team
  • [ ] parent of #1848 Identify reasonable subset of Rx to use

Note: if possible, we'd prefer incremental adoption so this doesn't require much sprint planning. As dnarcese mentioned, this means we'll need to be careful when working on related code so we don't run into rebasing issues after systemic refactors.

---

Why/User Benefit/User Problem

Our architecture relies on the reactive programming model. We're using the LiveData API to execute this but LiveData falls short in some essential operators. In particular, we rely on combineLatest to allowing combining multiple pieces of data. We reimplemented this for two streams but now I'm in a situation where I need to combine 3 (#1628); it's only a matter of time before we need to combine 4. This code requires duplication to write (making it hard to make consistent bug fixes, tests) so it'd be preferable to use a library that handles this for us.

Some options: we can find a library that wraps LiveData to provide these operators or use RxJava or other ReactiveStreams APIs.

However, some of these are not decisions to be taken lightly: e.g. RxJava is notorious for its complexity and difficulty onboarding new users. Also, it'll take some thinking to identify the patterns we need to convert LiveData – which has lifecycle events to worry about – to Rx and vice versa.

What / Requirements

• Identify the specific problems we currently have with LiveData and may want to solve in the future
• Identify libraries, implementations that solve these problems (are there LiveData libraries? ReactiveStreams?)
• Identify trade-offs between solutions including writing the libs ourselves
  • Consider the lifecycle issues LiveData solves for us and how different libs may tie into that
• Decide how we want to move forward
• Implement or integrate
• Write ADR to document this decision for us and others

Acceptance Criteria (how do I know when I’m done?)

---

fwiw, some initial thinking on using Rx:

• We could use Rx in the model, expose LiveData as the public API of the VM. We'll have to clean up Rx observers subscribed in the VM though using ViewModel.onCleared()
• RxJava has a lot of obnoxious type issues with Kotlin: RxKotlin solves some issues but is confusingly named – Flowable... vs. Flowables... – and has type inconsistencies with RxJava.
• Rx -> LiveData conversion has a lot of types to learn: LiveData -> Publisher -> Flowable. We can abstract these away but that may make it harder for devs to figure out when there are problems.

[severinrudie]

Another possibility would be moving away from LiveData entirely. Uber has released a library that lets us replicate the subscription behavior of LiveData with Rx observables. A few things to note, if we use it though:

• We would need to set VMs to cache their most recently emitted values (this isn't the default behavior in Rx, but it's easy to set).
• AutoDispose, at least in the current version, uses AndroidX Lifecycles, while we are still using the old version.
• The syntax requires use of backticks, which is mildly irritating (as is an Rx operator).

  vm.state
  .`as`(lifecycleOwner.scope())
  .subscribe { }

[psymoon]

@Baron-Severin maybe we can add and extend to this https://github.com/mozilla-mobile/android-components/blob/master/components/support/ktx/src/main/java/mozilla/components/support/ktx/android/arch/lifecycle/Lifecycle.kt ?

[severinrudie]

I would be pretty wary about reimplementing this kind of thing. I know the team at Google that worked on LiveData had to call up some of the programmers who had originally worked on fragment transactions in order to get all of the edge cases correct. And a really popular OSS project for ~typing~ tying Rx to Android lifecycles (RxLifecycle) was eventually deprecated in favor of either doing it by hand or using Uber's solution, because it turns out it's just a hard problem to solve and they never quite got it right.

[mcomella]

As a team, we decided to adopt a more advanced FRP library than LiveData. We've lightly decided on Rx over other libraries because it's ubiquitous on Android (and thus well tested, well documented) and in use by other teams at Mozilla.

As such, this bug is being morphed into a meta bug.

[mcomella]

We're converting this gradually when we need to use Rx operators or need to combine a LiveData and Rx stream (in which case we convert the LiveData stream): I don't think we need to keep an issue open for this.