Convert from LiveData To StateFlow

Tram Ho

You must have worked with LiveData in Android, right, in this article I will not talk about LiveData or Flow in depth (I will talk more about this in the next section), here I just talk about the benefits. StateFlow and why we should move from using LiveData to StateFlow

I. Why shouldn’t LiveData be used?

Sometimes we can use the wrong in a few places so there are two major problems here:

  • Can be used anywhere eg in the repository floor

  • It makes no distinction between setValue () and postValue () functions.

 

The first one: can greatly affect the performance of the application (I will go into detail on this later and how to fix it when using Flow)

second problem: this can have a major effect when uploading data to the UI

 

II. What is StateFlow?

 

As far as Kotlin announced:

StateFlow is a state owner’s observable thread that emits new and current status updates to its receivers. The current state value can also be read through its value property . To update the state and send it to the thread, assign a new value to the value property of the MutableStateFlow class.

Bottom line : We roughly roughly understand that StateFlow is something that can help us recognize data like LiveData can know what state the data is in and check it. Data like LiveData will be accessed through the value property. Previously we had the MutableLiveData class to implement LiveData , now we have MutableStateFlow implementing StateFlow , it seems there is a slight imitation here (poke a little to be the same for everyone to use.)

Seeing for a while, it looks like the scary LiveData, but with a little difference here, pay close attention:

 

According to the code above, it is a child of SharedFlow that this guy is an extension of the guy Flow of Coroutines , so it may have a light combination with Coroutines to let you get around kkk. (If I have free time, I will write a StateFlow article that incorporates Coroutines )

  • – It seems that you also know a little about StateFlow here, I will talk through the transition from LiveData to StateFlow.

III. LiveData to StateFlow

 

We have a build with LiveData like this :

  • PostsFragment : display list of posts
  • PostViewModel : interaction between fragment and repository

PostFragment.kt:

PostsViewModel.kt:

 

 

(1) because when we setValue for LiveData we must run on MainThread, now we have to change the scope of Coroutines.

According to the code above, it is a child of SharedFlow that this guy is an extension of the guy Flow of Coroutines, so it may have a light combination with Coroutines to let you get around kkk. (If I have free time, I will write a StateFlow article that incorporates Coroutines)

– It seems that you also know a little about StateFlow here, I will talk through the transition from LiveData to StateFlow.

Switch to StateFlow

 

Together with me, convert to StateFlow:

B1 . ” Everlasting Prologue ” adds coroutine library to gradle :

app.gradle:

B2: Fix a little bit of code in View “* PostsFragment.kt *”:

PostsFragment.kt:

(1) : Here we will use the launching of coroutine to wrap the StateFlow ‘s activity scope and make sure it will work when the view is in the RESUMED state.

(2) : We will observe StateFlow by collecting the flow within the main thread

 

PostsViewModel.kt

 

(1) We will have to initialize an initial state when initializing a StateFlow

(2) Since we have initialized at 1 this place will no longer be needed

(3) Here instead of returning 1 LiveData , the return time is 1 StateFlow

(4) The simplest thing here is even more: in the coroutines scope we can update the new state anywhere so it will be easier and less error to code.

(5) Previously, LiveData, this section had to change to Main Thread to update, but StateFlow did not need to do so much simpler.

(6) Contrary to LiveData StateFlow value can not be null, so we have to check null support.

Is that done quickly, we just need to:

  • gives it a scope of active croutines and is tied to the life cycle of the view
  • To handle the returned data instead of obsever , use collect of the flow
  • A little change of the return data type at ViewModel is finished

 

IV. Summary :

I personally find it very useful and clean code than LiveData, but while using it, be careful with its scope because it can cause careless errors that may crash the app .

Using StateFlow I have seen benefits like this :

  • no need to pay any attention to it are posted on the thread status should be safe for the thread
  • It is inside coroutines so it is easy to combine coroutines , especially can be used for multiplatform coroutines.
  • no need to check null as ** LiveData **
  • If you are using coroutines or flow in the project, this conversion is easy and combines quite well with coroutines.

There are a few issues to note when using StateFlow:

  • StateFlow is quite good but I think it should only be used in updating data state for the purpose of designing it as “representing states”.
  • StateFlow only sends the most recently submitted value that will be recrawled, if the new data matches the old one will not be emitted (it checks via the Any . Equals () function
  • When using StateFlow , it is important to consider when and in which thread you are collecting a thread. There is a simple example: if you are using with launch () instead of using launchWhenResumed () it means you can update the data again when the view is destroyed, so I recommend accompanying viewLifecycleScope to be able to control it better.

Thank you for reading, for a stronger Andoird community, I hope you can give me a review as well as additional supplements for me to improve the following article!

More information can be found from the following source:https://medium.com/swlh/migrating-from-livedata-to-stateflow-4f28d6889a04

Share the news now

Source : Viblo