Video first
If it’s easy for you to watch videos, just go to Bilibili or YouTube.
The following is the script of the video content. If you’ve seen the video, skip the rest of the text and go to the bottom of the comment section.
Word version
During the Jetpack Q&A session at Google I/O this year (2021), the Android team was asked an interesting question: Is LiveData going to be obsolete?
The question is not a blind question
Hi, I’m Junkey the sling. Let’s talk about something lighter and less hardcore — LiveData.
LiveData is one of a number of architectural components that will be officially launched by Android in 2017 along with ViewModel and Lifecycle, among others, and a number of others that have been introduced over the years. These components were later given a common name: Jetpack; The components of Jetpack are becoming more and more accepted by Android developers. LiveData, the oldest member of Jetpack’s architecture components, has been gaining momentum as well, but — it’s starting to move down from here. As you can see at the beginning of the video, someone asked the Android team “Are you going to scrap LiveData?” This question is not a blind question.
How is that? It all started with RxJava.
From the RxJava
LiveData got a lot of attention when it first came out in 2017, in part because it reminded many people of RxJava. LiveData is a watter-centric component that automatically notifys and updates by having the interface subscribe to variables. RxJava’s core keywords are watter-centric and event-flow, so many people compared it to RxJava at the time: Some say it is better than RxJava, others say it is less powerful than RxJava, and others say that the two are not the same thing at all, and it is meaningless to compare them together.
As for my opinion… It’s said.
RxJava is in 2014, 2015 this time the fire, domestic later, about in 2016 began to explode fire. Working people around the world used RxJava for two things: network requests, and event bus. RxJava works with Retrofit to do web requests, complex operations and thread switching, and everyone knows what to do — now you can just use coroutines, which is easier than RxJava. And Event Bus, two popular open source libraries at that time: GreenRobot’s EventBus — the library of the same name — and Square’s Otto, after the popularity of RxJava, people found that, oh, RxJava can be customized a little bit to implement the function of event Bus? So since I’m using RxJava, why don’t I give it the Event bus as well? As a result, a model called RxBus became popular, and later someone opened source such a library.
It was against this backdrop that LiveData was released in 2017. Its function is to make variables subscriptable. Compared to regular subscriptions, LiveData has two features: First, its goal is very direct, directed to interface refresh, so its data updates only happen on the main thread; Second, it uses the functionality of another architectural component, Lifecycle, which allows it to notify updates only when the interface is in the foreground and not when it is in the background, avoiding wasted performance and avoiding bugs.
Why not use RxJava?
It’s convenient. It works. But here’s the question: Can’t you subscribe to variables with RxJava? Why build a new one? RxJava is dedicated to event subscription, right?
- Because… Do LiveData updates occur on the main thread? RxJava can do the same thing with an operator (
observeOn(AndroidSchedulers.MainThread))). - That…… Is it because Lifecycle is integrated and Lifecycle is supported? RxJava can also work, change to change to support, is it easier than writing a new library?
So can the functionality of LiveData be implemented with RxJava? It’s totally ok. There’s no problem. Why did Android do LiveData instead of recommending RxJava to do this? Or take a step back and use RxJava for the underlying implementation of LiveData? Why not? Because RxJava is too big, and it’s not an official Android thing, it’s someone else’s.
This is not to say that Google is being narrow-minded and can only promote my own stuff and not expand others, but Android, as a platform, certainly needs to consider the general level of developers. To be honest, RxJava is easy to use, but it is too complex and expensive to get started, so if Android wants to use RxJava to implement LiveData, or developers are recommended to use RxJava to implement LiveData functions themselves, Then it needs to think about how we developers can learn RxJava. How can we learn? You can only teach yourself! Write documentation, make videos, teach people how to use RxJava. That’s a big move, and it complicates things. In addition, RxJava is not part of the Android system, nor is it part of the Google system. If the Android team wants to promote and teach RxJava all over the web for a single LiveData feature, the logic is a little wrong. That’s not how it works. So RxJava is too big, and it’s a third party, and these two reasons combine to prevent RxJava from being used in Android’s LiveData. It’s not a question of competition or mind, it’s a question of “don’t make things complicated.” B: That’s my opinion, of course.
Changes from 2017 to 2021
But!!! That’s just the situation. When was it? In 2017. 2017 was a big year for Android, and several big things happened:
- Several architectural components have been officially released;
- Official announcements of support for Kotlin;
HenCoder release(false).
HenCoder, I just made that up. I’m talking about Kotlin, which was officially and publicly supported by Android in 2017, and which has gotten better and better over the years. Before 2017, most people subscribed to events using EventBus or Otto, and after RxJava became popular, the use of EventBus and Otto began to continue to decline; After 2017, people slowly transition to LiveData for simple scenarios, but still use RxJava for complex scenarios, because LiveData is not suitable for complex scenarios; And now we have Flow. The Flow of coroutines is very similar in scope to RxJava — in fact, I think it is — but Flow is an essential part of coroutines, and coroutines are an essential part of Kotlin, Kotlin is an essential part of Android development — oh, that’s not true, again — and Kotlin is the main development language and future trend for Android, so that when Flow comes out, there’s no LiveData. Forget LiveData, RxJava will be fine in the future. It’s going to take a while, and LiveData and RxJava — especially RxJava — are going to continue to hold up for a while, but the trend is going to be that way.
“LiveData will not be abandoned”… ?
To the question at the beginning of the video, Yigit answers that LiveData will not be discarded for two reasons:
- People who write Android in Java also need it — Flow is a coroutine thing, so if you’re in Java, you can’t really use Flow;
- While LiveData is simple to use and functional enough for simple scenarios, things like RxJava and Flow are less intuitive to learn than LiveData.
In short, LiveData will be retained for Java language users and those who do not want to learn RxJava or Flow. But if you look at his words in a developmental light… You know what I mean?
Then I go?
That…… For those who do not know LiveData, is it necessary to learn LiveData? And for projects that are already using LiveData, do you need to remove LiveData quickly?
If you don’t know LiveData, it’s important to learn it for today (2021), because the usage rate of LiveData is still high, so even if you don’t use it now, your future team will probably use it, but it’s easy enough to learn. On the other hand, if you’re using LiveData, you can actually consider removing it; It’s not a poison, it’s not a landmine, it’s just coroutine Flow can do it now, and Flow will be mainstream in the future, just like Kotlin is today; Using two things to do the same thing (event subscriptions) in a project is better than using only one, so you can consider removing LiveData, that’s the logic. Therefore, even if you are in a hurry, you should also hurry to learn Flow, rather than hurry to remove LiveData, it is not toxic, and later when you feel it brings you inconvenience, you will naturally remove it.
Ok, that’s it for today. If you like my content, don’t forget to like and subscribe. I’m the throwing line. I don’t compete with you. I just help you grow.
