Google introduced Jetpack, a family of opinionated libraries to make Android development easier a few years ago. One of the core classes in Jetpack is LiveData
- an observable, lifecycle aware data holder. The typical use case is having a ViewModel
that exposes LiveData
as a property, and observing it from your lifecycle owner, a Fragment
or an Activity
.
A typical usage would look like this:
data class MyState(val value: String)
class MyViewModel : ViewModel {
private val _state = MutableLiveData<MyState>()
val state: LiveData<MyState>
get() = _state
}
class MyFragment : Fragment {
val viewModel by viewModels<MyViewModel>()
override fun onViewCreated() {
viewModel.state.observe(this, Observer(::handleState))
}
private fun handleState(state: MySate): Unit = TODO()
}
There are multiple benefits of using LiveData
:
- Your observer is notified when the data changes
- The observer is only notified of changes when it’s active
- Observers are notified when they become active again, like entering into foreground etc
Check the LiveData docs for all benefits.
LiveData and Events
In situations like showing a Snackbar
/dialog or navigating to a different Activity/Fragment
the ViewModel
also needs to notify the LifecycleOwner
. A plain old LiveData
doesn’t work well here because it caches the last item. As a workaround, in the official Android architecture samples there is a SingleLiveEvent
implementation of LiveData
.
Data Layer
But what about the rest of the app? You can use LiveData
in your data layer, in fact Room, the persistence library from Jetpack, support LiveData
as the return type natively. However while using LiveData
across all the layer in the app is possible, it is less than ideal. The operations are always executed on the Main Thread and it comes with limited number of transformation functions compared to RxJava
or Flow
.
To fix this problem LiveData
comes with adapters for both RxJava
and Flow
from KotlinX Coroutines. This means developers can use RxJava
or Flow
in their data layer and convert to LiveData
in the ViewModel
benefiting from the lifecycle awareness.
State and RxJava
I was working on a sample app last week using the Marvel API, you can check the full code on Github. It uses a fully reactive architecture powered by RxJava. My initial approach was to use LiveData
for the ViewModel
-> Fragment
communication. However I also wanted to benefit from the RxJava
excellent testing support, so I decided to try and do what LiveData
does using RxJava
.
For observing state, RxJava offer BehaviorSubject
, a Subject
that caches the last value it observer and emits it to each subscribed Observer
. That takes care of the caching of the last value and observing changes. For observing on the Main Thread there is RxAndroid
. What about the lifecycle part. To take care of that I created a utility class, built atop LifecycleOwner
to help me dispose of the subscription at the right lifecycle callback.
class LifecycleDisposable(
private val disposable: Disposable
) : DefaultLifecycleObserver {
override fun onDestroy(owner: LifecycleOwner) {
disposable.dispose()
super.onDestroy(owner)
}
}
the code using this:
class RxViewModel : ViewModel() {
private val _state = BehaviorSubject.create<MyState>()
val state: Observable<MyState>
get() = _state
}
class RxFragment : Fragment() {
val viewModel by viewModels<MyViewModel>()
fun onViewCreated() {
viewModel.state
.subscribe(::handleState)
.autoDispose() // extension function, check the Github link
}
private fun handleState(state: MySate) = TODO()
}
Unlike LiveData
, this starts observing in onViewCreated
and unsubscribes in onDestroyView
. The code would be similar to subscribe in onStart
and stop observing in onStop
, however in my experience (and I could be wrong) updating view state while the view is not active never caused me problems.
Events and RxJava
Events are a bit different than state. The main requirement is to be delivered exactly once (they are consumable). Another important requirement is to be delivered ONLY when the view is active (between onStart
and onStop
). My first attempt was using UnicastSubject
:
A Subject that queues up events until a single Observer subscribes to it, replays those events to it until the Observer catches up and then switches to relaying events live to this single Observer until this UnicastSubject terminates or the Observer unsubscribes.
however that didn’t work out well. The queuing of events when there was no observers was working great. Upon subscription all events would be delivered. When there was a subscriber events were getting delivered. The problem was when the subscriber unsubscribes and a new subscriber tries to subscribe (onStart
and onStop
can be triggered multiple times). That led me to UnicastWorkSubject from RxJavaExtensions
:
A Subject variant that buffers items and allows one Observer to consume it at a time, but unlike UnicastSubject, once the previous Observer disposes, a new Observer can subscribe and resume consuming the items.
which was exactly what I needed. For the lifecycle part, again I turned to LifecycleObserver
and created:
class EffectsObserver<E>(
private val effects: Observable<E>,
private val executeEffect: (E) -> Unit
) : DefaultLifecycleObserver {
private var disposable: Disposable? = null
override fun onStart(owner: LifecycleOwner) {
super.onStart(owner)
disposable = effects.flatMap {
Observable.fromCallable { executeEffect(it) }
}.subscribe()
}
override fun onStop(owner: LifecycleOwner) {
disposable!!.dispose()
super.onStop(owner)
}
}
the usage looks like:
override fun onCreate(savedInstanceState: Bundle?) {
super.onCreate(savedInstanceState)
lifecycle.addObserver(EffectsObserver(viewModel.effects) { effect ->
when (effect) {
is NavigateToDetails -> TODO("Navigate")
}
})
}
this will make sure events such as navigation and showing a Snackbar
are queued when the app is in the background and happen only when the app is in foreground. It helps avoid the dreaded java.lang.IllegalStateException: Can not perform this action after onSaveInstanceState.
Note: when using this with a Fragment
it is important to register it in onCreate
(called exactly once) and not in onViewCreated
(may be called multiple times with fragments on the backstack).
Conclusion
You can emulate the way LiveData
works for ViewModel
-> LifecycleOwner
communication with RxJava
. However there are a few edge cases that you need to consider to do it right, like delivering events only when the LifecycleOwner
is active.
If you have a different idea to achieve this leave a comment below. Happy coding!
Top comments (1)
Wow, this is an interesting approach!