Member-only story
When NOT to Use LiveData
If you are familiar with Android development, I have no doubt you have heard about Architecture Components and maybe even implemented them into your projects. There is several articles out there talking about when and how to use them, but I feel there is not enough emphasis on when NOT to use them, especially keeping in mind that Google’s guide to app’s architecture promotes them as a quite universal tool that can be used on all layers of your architecture. So there is definitely a temptation of trying to make the most out of them :)
In this article I am going to talk about cases when I would NOT recommend using LiveData and the alternatives you can use. The idea for the article was inspired by a talk at the Android Dev Summit’18 that I found new-ish and interesting.
- You have backpressure in your app.
If you have an actual steam where backpressure can occur as a use case LiveData will not solve your problem. The reason for it is that LiveData doesn’t support it. The purpose of LiveData is to promote the latest value to UI when the observer is/goes active. You can use RX Flowable or Kotlin’s streams to properly handle this use case. The image below demonstrates the backpressure handles properly. In the case you are using LiveData the values 9,10,11 will be dropped in favor of delivering the latest value. Here is a link to Google’s issue tracker confirming LiveData can’t handle backpressure.
2. You need to use a lot of operators on data.
Even though LiveData provides such a tool as Transformations, there is only map and switchMap to your help out of the box. If you want something more advanced and probably chained, LiveData doesn’t provide this sort of data manipulations. So the best way to handle this sort of need would be to not to use LiveData as the producer but instead go for a RX type or Kotlin which has support for multiple higher order functions and extensions on the Collections and Sequence apis. Here are some examples of how much boilerplate you can avoid by just using higher order functions in Kotlin.
fruits
.filter { it.type == "apple" }
.firstOrNull { it.color ==…
