Learning to use livedata and ViewModel will make it easier for you to write business

Preface ：

This article is updated from time to time , If you have any questions, please put them in the comment area ~

Last updated ：2022-06-21

Introduce

stay 2017 year , At that time , The observer pattern effectively simplifies development , But things like RxJava A class of libraries is a little too complicated , The cost of learning is too high , So ,LiveData There is , One for Android Of , With autonomous life cycle awareness , Observable data storage classes . At the same time ViewModel This component , coordination LiveData, More convenient implementation MVVM In the pattern Model And View The separation of . So let this article take you to learn LiveData And ViewModel Let 's use .

LiveData and ViewModel The relationship between ：

Case code of this article ：

https://github.com/taxze6/Jetpack_learn/tree/main/Jetpack_basic_learn/livedata_viewmodel

LiveData

Reference material ：

Official documents ：

https://developer.android.google.cn/topic/libraries/architecture/livedata

LiveData postValue Detailed explanation ：

https://www.cnblogs.com/button123/p/14871526.html

LiveData

It's a kind of

Observable data storage class

( Responsive programming , similar Vue). Unlike conventional observable classes ,LiveData 

Life cycle awareness

.LiveData The most important thing is that it understands the life cycle of the observer , Such as

Activity

and

Fragment.

therefore , When LiveData When sending changes ,UI Will receive notice , then UI You can redraw yourself with new data . let me put it another way ,LiveData It's easy to synchronize what happens on the screen with the data （ The core of responsive programming ）

Use  LiveData  It has the following advantages ：

• UI Match data status

• LiveData  Follow the observer pattern . When the underlying data changes ,LiveData  Will inform
  Observer
  object . You can integrate the code in these  
  Observer
  Object to update the interface . thus , You don't need to update the interface every time the application data changes , Because the observer will complete the update for you .

• Improve code stability

• Code stability increases throughout the application lifecycle ：

• There is no crash when the activity stops . If the application component is inactive , Then these changes are not affected . therefore , You don't have to worry about the lifecycle of application components when updating data . For activities in the background stack , It will not accept any LiveData event

• Memory leaks are reduced , The observer will be bound to Lifecycle object , And self cleaning after its associated life cycle has been destroyed

• Don't worry about unsubscribing from any observer

• If due to configuration changes （ If the equipment rotates ） And recreated  Activity  or  Fragment, It will immediately receive the latest available data .

• No longer need to manually handle the lifecycle

• Interface components just look at relevant data , Does not stop or resume observation .LiveData  All of these operations will be managed automatically , Because it can sense the change of related life cycle state when observing .

• Data is always up to date

• If the life cycle becomes inactive , It receives the latest data when it becomes active again . for example , Used to be backstage  Activity  It will receive the latest data immediately after returning to the foreground .

• Shared resources

• Like the singleton mode , We can also expand our LiveData Object to wrap system services , So that they can be shared in our application . once LiveData Object to connect to system services , Any observer who needs resources can easily watch LiveData object .

In the following cases , Do not use LiveData：

• You need to use a lot of operators on Information , Even though LiveData Provides tools such as transformations , But only Map and switchMap Can help you

• You don't have any contact with information UI Interaction

• You have a one-time asynchronous operation

• You do not have to save cached information to UI in

How to use LiveData

Generally speaking, we will be in  ViewModel  Created in  Livedata  object , Guarantee app When the configuration changes , Data will not be lost , And then again  Activity/Fragment  Of  onCreate  Register in  Livedata  monitor （ Because in  onStart  and  onResume  There may be redundant calls for listening in ）

Basic usage process ：

1. Create an instance LiveData To store some type of data . Usually when you create ViewModel Complete in class

class MainViewModel : ViewModel() {
 var mycount: MutableLiveData<Int> = MutableLiveData()
}


2. stay Activity perhaps Fragment Get to the ViewModel, adopt ViewModel Get the corresponding LiveData

class MainActivity : AppCompatActivity() {
 lateinit var viewModel: MainViewModel
 override fun onCreate(savedInstanceState: Bundle?) {
 ...
 /** Remember that you can never create directly ViewModel example
  Be sure to pass ViewModelProvider(ViewModelStoreOwner) Constructor to get .
  Because every time you rotate the screen, you will recall onCreate() Method , If you create a new instance every time, you cannot save the data .
  After using the above method ,onCreate Method is called again ,
  It will return an and MainActivity Associated with a preexisting ViewModel, That's why you save data .*/
 viewModel = ViewModelProvider([email protected],ViewModelProvider.
 NewInstanceFactory()).get(MainViewModel::class.java)
 }
}


3. to LiveData Add observer monitor , Used to monitor LiveData Data changes in , stay Observer Of onChanged Listen for callback data in

/**
 *  subscribe  ViewModel,mycount It's a LiveData type   You can observe
 * */ 
viewModel.mycount.observe([email protected]) {
 countTv.text = viewModel.mycount.value.toString()
}
// LiveData onchange Will automatically sense the lifecycle   No manual operation required
// viewModel.mycount.observe(this, object : Observer<Int> {
// override fun onChanged(t: Int?) {
//
// }
// })


Advanced usage ：

Transformations.map

Now there's a scene ： We request through the Internet , Got a User Class data （LiveData）, however , We just want to User.name Exposed to external observers , So we can get through Transformations.map To transform LiveData Data type of , So as to realize the above scenario . This function is often used to encapsulate data .

// Entity class
data class User(var name: String)
...
//Transformations.map Receive two parameters , The first parameter is for the transformation LiveData The original object , The second parameter is the conversion function .
private val userLiveData: MutableLiveData<User> = MutableLiveData()
 val userNames: LiveData<String> = Transformations
 .map(userLiveData) { user ->
 user.name
}


Transformations.switchMap

switchMap It's based on the incoming LiveData Value , And then judge the value , Then switch or build a new one LiveData. For example, some of our data needs to rely on other data for query , You can use switchMap.

for example , There is a student , He's got grades in two courses , But in UI In the component , We can only display the results of one course at a time , In this need to judge which course results to show , We can use switchMap.

data class Student
 (var englishScore: Double, var mathScore: Double, val scoreTAG: Boolean)
​
.....
class SwitchMapViewModel:ViewModel {
 var studentLiveData = MutableLiveData<Student>()
 val transformationsLiveData = Transformations.switchMap(studentLiveData) {
 if (it.scoreTAG) {
 MutableLiveData(it.englishScore)
 } else {
 MutableLiveData(it.mathScore)
 }
 }
}
​
// When using ：
var student = Student()
person.englishScore = 88.2
person.mathScore = 91.3
// Decide which grade to show
person.condition = true
switchMapViewModel.conditionLiveData.postValue(person)


MediatorLiveData

MediatorLiveData Inherited from MutableLiveData, stay MutableLiveData On the basis of , Add merging multiple LiveData The function of data source . It's really just through addSource() This method monitors multiple LiveData.

for example ： Now there is a local dbLiveData, There is also a network request LiveData, We need to combine the above two results and show them to users , The first is that we are Activity Register the two respectively in LiveData The observer , Update when data changes UI, But we actually use MediatorLiveData This operation can be simplified .

class MediatorLiveDataViewModel : ViewModel() {
 var liveDataA = MutableLiveData<String>()
 var liveDataB = MutableLiveData<String>()
​
 var mediatorLiveData = MediatorLiveData<String>()
 
 init {
 mediatorLiveData.addSource(liveDataA) {
 Log.d(&quot;This is livedataA&quot;, it)
 mediatorLiveData.postValue(it)
 }
​
 mediatorLiveData.addSource(liveDataB) {
 Log.d(&quot;This is livedataB&quot;, it)
 mediatorLiveData.postValue(it)
 }
 }
}


explain ：

If it is the first time to contact LiveData A friend of may find out , Although we have been talking about LiveData, But when it is used MutableLiveData, What is the relationship between the two , Since they are useless LiveData, Then change the title to MutableLiveData Well, actually ,LiveData And MutableLiveData They are identical in concept . The only differences are ：

“ Reference herein :

LiveData And MutableLiveData The difference between

Paragraphs in the article ”

• MutableLiveData The parent class is LiveData

• LiveData In the entity class, you can notify the data update of a specified field

• MutableLiveData It is only notified after the entire entity class or data type changes . Details will not be to a field .

Principle Exploration ：

about LiveData Let's stop here , Want to explore LiveData The principle friend may from the following several angles ：

• LiveData How it works

• LiveData Of observe Method source code analysis

• LifecycleBoundObserver Source code analysis

• activeStateChanged Source code analysis （ For sticky events ）

• postValue and setValue

• considerNotify Determine whether to send data analysis

• Analysis of viscous events

I believe you can analyze it from the above perspectives LiveData There will be no small gains

ViewModel

Official documents ：

https://developer.android.google.cn/topic/libraries/architecture/viewmodel

Official profile

ViewModel Class is designed to store and manage interface related data in a lifecycle focused manner .ViewModel Class allows data to persist after configuration changes such as screen rotation .

Life cycle

ViewModel The life cycle of will be better than the one that created it Activity、Fragment The life cycle of the is long . therefore ViewModel The data in will always survive Activity/Fragment in .

Basic usage process ：

1. Construct data object

Customize ViewModel class , Inherit ViewModel, Then in the custom ViewModel Class to add the required data objects

class MainViewModel : ViewModel() {
 ...
}


2. get data

There are two common ViewModel How it was created , The first is in activity or fragment Kind of directly based on  ViewModelProvider  obtain . The second is through ViewModelFactory  establish

// The first one is  ViewModelProvider Direct access to
ViewModelProvider([email protected]).get(MainViewModel::class.java)
​
// The second kind   adopt  ViewModelFactory  establish
class TestViewModelFactory(private val param: Int) : ViewModelProvider.Factory {
 override fun <T : ViewModel> create(modelClass: Class<T>): T {
 return TestViewModel(param) as T
 }
}
​
ViewModelProvider([email protected],TestViewModelFactory(0)).get(TestViewModel::class.java)
​


Use ViewModel It's that simple

ViewModel Common use scenarios

• Use ViewModel, After switching between horizontal and vertical screens ,Activity The reconstruction , Data can still be saved

• The same Activity Next ,Fragment Data sharing between

• And LiveData Cooperate to realize code decoupling

ViewModel and onSaveInstanceState The difference between

I'm sure you all know onSaveInstanceState, It is also used to save UI State of , You can use it to save what you want to save , stay Activity Before being killed , It's usually in onStop perhaps onPause Trigger before . although ViewModel Designed to apply in addition to onSaveInstanceState Another option for , But there are some obvious differences . Due to resource constraints ,ViewModel Cannot continue to exist after the process is shut down , but onSaveInstance Includes performing this task .ViewModel

Is a great choice for storing data , and onSaveInstanceState bundles Not a suitable option for this purpose .

ViewModel For storing as much as possible UI data . therefore , During configuration changes

There is no need to reload or rebuild

This data .

On the other hand , If the process is shut down by the framework ,onSaveInstanceState Replies should be stored UI The minimum amount of data required for a state . for example , All users' data can be stored in ViewModel in , Only the user's database ID Stored in onSaveInstanceState in .

android onSaveInstanceState Detailed summary of call timing

onSaveInstanceState Usage and source code analysis

ViewModel and Context

ViewModel Should not include a right to Activity,Fragment or context References to , Besides ,ViewModel Should not include a reference to UI controller （ Such as View） References to , Because this will create a pair of Context Indirect reference to . When you spin Activity When the screen is destroyed , You have a ViewModel Contains information about destroyed Activity References to , This is a memory leak . therefore , If you need to use context , You must use the application context  

（AndroidViewModel）

 .

LiveData and ViewModel We have already introduced the basic usage of , Now let's use a few examples to better use them

Case a ： Counter  —  Two Activity Share a ViewModel

Don't talk much , First on the renderings ：

Although this case is relatively simple , But I believe it can help you get familiar with LiveData and ViewModel

To realize the effect picture, you need to write from the following steps （ Just the core code , Please check the warehouse for the specific code ）：

First step ： establish ViewModel

import androidx.lifecycle.LiveData
import androidx.lifecycle.MutableLiveData
import androidx.lifecycle.ViewModel
​
class MainViewModel : ViewModel() {
 private var _mycount: MutableLiveData<Int> = MutableLiveData()
 // Expose only immutable LiveData Externally
 val mycount: LiveData<Int> get() = _mycount
 init {
 // initialization
 _mycount.value = 0
 }
 /**
 * mycount.value If it is empty, it will be assigned as 0, If it is not empty, add one
 * */
 fun add() {
 _mycount.value = _mycount.value?.plus(1)
 }
 /**
 * mycount.value If it is empty, it will be assigned as 0, If it is not empty, subtract one , Can be negative
 * */
 fun reduce() {
 _mycount.value = _mycount.value?.minus(1)
 }
 /**
 *  Random parameter
 * */
 fun random() {
 val random = (0..100).random()
 _mycount.value = random
 }
 /**
 *  Clear data
 * */
 fun clear() {
 _mycount.value = 0
 }
}


The second step ： Mark ViewModel Scope of action

because , We are two Activity Share a ViewModel, So we need to mark ViewModel Scope of action

import androidx.lifecycle.*
​
/**
 *  Used to mark viewmodel Scope of action
 */
@Retention(AnnotationRetention.RUNTIME)
@Target(AnnotationTarget.FIELD)
annotation
class VMScope(val scopeName: String) {}
​
private val vMStores = HashMap<String, VMStore>()
​
fun LifecycleOwner.injectViewModel() {
 // Create a store according to the scope
 this::class.java.declaredFields.forEach { field ->
 field.getAnnotation(VMScope::class.java)?.also { scope ->
 val element = scope.scopeName
 var store: VMStore
 if (vMStores.keys.contains(element)) {
 store = vMStores[element]!!
 } else {
 store = VMStore()
 vMStores[element] = store
 }
 val clazz = field.type as Class<ViewModel>
 val vm = ViewModelProvider(store, ViewModelProvider.NewInstanceFactory()).get(clazz)
 field.set(this, vm)
 }
 }
}
​
class VMStore : ViewModelStoreOwner {
 private var vmStore: ViewModelStore? = null
 override fun getViewModelStore(): ViewModelStore {
 if (vmStore == null)
 vmStore = ViewModelStore()
 return vmStore!!
 }
​
}


The third step ： stay Activity Use in ( Are part of the code )

class MainActivity : AppCompatActivity() {
 @VMScope("count") // Set scope
 lateinit var viewModel: MainViewModel
​
 override fun onCreate(savedInstanceState: Bundle?) {
 super.onCreate(savedInstanceState)
 setContentView(R.layout.activity_main)
 injectViewModel()
 initEvent()
 }
​
 private fun initEvent() {
 val cardReduce: CardView = findViewById(R.id.card_reduce)
 .....
 cardReduce.setOnClickListener {
 // Call custom ViewModel The method in
 viewModel.reduce()
 }
 
 .....
 
 /**
 *  subscribe  ViewModel,mycount It's a LiveData type   You can observe
 * */
 viewModel.mycount.observe([email protected]) {
 countTv.text = viewModel.mycount.value.toString()
 }
}
 
In the second Activity The same is true of ...


In this way, you can realize the effect picture

Case 2 ： The same Activity Of the two Fragment Share a ViewModel

Don't talk much , First on the renderings

This effect is very simple , In the same Activity Next , There are two Fragment, these two items. Fragment Share a ViewModel

This case is mainly to show you ViewModel stay Fragment The use of

First step ： Still create ViewModel

class BlankViewModel : ViewModel() {
 private val numberLiveData = MutableLiveData<Int>()
​
 private var i = 0
 fun getLiveData(): LiveData<Int> {
 return numberLiveData
 }
​
 fun addOne(){
 i++
 numberLiveData.value = i
 }
}


A very simple one ViewModel

The second step ： stay Fragment Use in

// Left Fragment
class LeftFragment : Fragment() {
 
 private val viewModel:BlankViewModel by activityViewModels()
 override fun onCreateView(
 inflater: LayoutInflater, container: ViewGroup?,
 savedInstanceState: Bundle?
 ): View? {
 return inflater.inflate(R.layout.fragment_left, container, false)
 }
​
 override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
 super.onViewCreated(view, savedInstanceState)
 // Yes +1 Button monitoring
 left_button.setOnClickListener {
 viewModel.addOne()
 }
 activity?.let {it ->
 viewModel.getLiveData().observe(it){
 left_text.text = it.toString()
 }
 }
 }
}
​
// Right Fragment
class RightFragment : Fragment() {
 private val viewModel: BlankViewModel by activityViewModels()
 
 override fun onCreateView(
 inflater: LayoutInflater, container: ViewGroup?,
 savedInstanceState: Bundle?
 ): View? {
 return inflater.inflate(R.layout.fragment_right, container, false)
 }
​
 override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
 super.onViewCreated(view, savedInstanceState)
 right_button.setOnClickListener {
 viewModel.addOne()
 }
 activity?.let { it ->
 viewModel.getLiveData().observe(it) {
 right_text.text = it.toString()
 }
 }
 }
}


such , This simple case is realized .

Epilogue

Finally put LiveData and ViewModel Explained the general use of , But this alone is not enough , You also need to be familiar with it in more and more practice , To learn more about ....

About me

Hello, I am a Taxze, If you think the article is valuable to you , welcome  ️, You are welcome to pay attention to my

Blog

.

If you think the article is not good enough , Please also go through

Focus on

Urge me to write better articles —— In case I improve one day ？

Foundation Series ：

2022 ·  Let me show you Jetpack Architecture components go from beginner to proficient  — Lifecycle

Learn how to use LiveData and ViewModel, I believe it will make you relaxed when writing business  ( this paper )

The following parts are still codewords , Hurry to order a collection

2022 ·  Let me show you Jetpack Architecture components go from beginner to proficient  — DataBinding

2022 ·  Let me show you Jetpack Architecture components go from beginner to proficient  — Navigation

2022 ·  Let me show you Jetpack Architecture components go from beginner to proficient  — Room

2022 ·  Let me show you Jetpack Architecture components go from beginner to proficient  — Paging3

2022 ·  Let me show you Jetpack Architecture components go from beginner to proficient  — WorkManager

2022 ·  Let me show you Jetpack Architecture components go from beginner to proficient  — ViewPager2

2022 ·  Let me show you Jetpack Architecture components go from beginner to proficient  —  Login to the registration page （MVVM）

Advanced Series :

coroutines  + Retrofit Network request status encapsulation

Room  Cache encapsulation

.....