15

as I mentioned in the title, I'm curious about the general differences between the two. Can you help with this? I couldn't find the specific differences as there are complex examples on the internet.

  1. What are the differences in terms of performance?
  2. In which scenarios does it provide advantages?
  3. Using StateFlow with Kotlin Flow is advantageous. But what is the risk of not switching to StateFlow in a project using LiveData?
  4. Is Google deprecating LiveData? :)
Phil Dukhov
  • 67,741
  • 15
  • 184
  • 220
Arda Kazancı
  • 8,341
  • 4
  • 28
  • 50
  • 2
    1. Negligible. 2. StateFlow enforces there being an initial value (but you could subclass MutableLiveData to do the same thing), so the value is never null if the type is not nullable. 3. I don't understand the question. How can you use a Flow in a project that doesn't use Flow? 4. Don't understand what you're asking. – Tenfour04 Aug 03 '21 at 13:22
  • 4. Is Google deprecating LiveData? – Arda Kazancı Aug 03 '21 at 13:23
  • 1
    There is no public announcement that they plan to deprecate it. StateFlow cannot practically be used in Java, so I doubt it will be deprecated any time in the next few years. – Tenfour04 Aug 03 '21 at 13:26
  • 3. Using StateFlow with Kotlin Flow is advantageous. But what is the risk of not switching to StateFlow in a project using LiveData? – Arda Kazancı Aug 03 '21 at 13:27
  • 2
    Regarding 2, I also think Flows operators are a lot easier to use than LiveData's transformations. 3. I still don't understand what you're saying about using StateFlow with Flow. StateFlow is just a subtype of Flow. It's kind of like saying it's advantageous to use Comparable in a project that has Ints. There's no risk to not switching, unless you're afraid LiveData might get deprecated soon. – Tenfour04 Aug 03 '21 at 13:29
  • I am satisfied with your answers. Thank you. 3. Sorry for not explaining the question fully. – Arda Kazancı Aug 03 '21 at 13:32

1 Answers1

15

I just switched to StateFlow, so this is a great time for me to answer your question.

What are the differences in terms of performance?

Honestly, I don't know, but since it's pushed by Kotlin and Android, just trust them :).

In which scenarios does it provide advantages?

  1. For LiveData you are not forced to give an initial value, it may end up writing more code in init{}; But for StateFlow you are Forced to give an initial value (including null), it may save your code a bit.

  2. For LiveData even if you give an initial value, you still need to do Null Check when you access its value (see this), it's kind of annoying. But that's not gonna happen on StateFlow - it will be what it should be.

  3. For LiveData you cannot easily, or elegantly observe data changes JUST inside ViewModel, you are gona use observeForever() which is also mentioned in here. But for StateFlow it's easy, do it like following:

     class FirstViewModel() : ViewModel() {
     val uiScope = viewModelScope

     val name = MutableStateFlow("Sam")      //must have initial value
     //val name = MutableStateFlow<String?>(null)   //null is acceptable

     init {
         observeName()
     }

     private fun observeName() = uiScope.launch {    //must run in coroutine scope                                                       
         name.collect { name ->                      //for Fragment / Activity, use lifecycleScope.launch{}
             //do your stuff
         }
     }
 }

Using StateFlow with Kotlin Flow is advantageous. But what is the risk of not switching to StateFlow in a project using LiveData?

What is the risk of not switching to Kotlin in a project using Java? :)

Is Google deprecating LiveData?

I would say yes, and they would say no, no for "not yet to say it loudly" :).

Sam Chen
  • 7,597
  • 2
  • 40
  • 73
  • Amazing explanation! – Abed Dec 13 '21 at 22:11
  • But wouldn't the `//do your stuff` block involve updating the UI? How can this be done in viewmodel without either passing the view to the viewmodel (violating MVVM) or using another observable/callback (in which case, what's the point of having `StateFlow` at all?) – Matt Feb 19 '22 at 19:58
  • @Matt Observing `StateFlow/LiveData` doesn''t mean that work is UI-related, I may want to update an variable based on the changes of another `StateFlow/LiveData`, but I don't want that variable to be exposed to the `Fragment/Activity`. – Sam Chen Feb 21 '22 at 19:44
  • 2
    @SamChen That sounds like an unusual use case, and all of Google's examples in the documentation have `StateFlow` updating a UI directly. I don't see the purpose of `StateFlow`. It sounds like it's the same as `LiveData` except now you have to handle your coroutines in the Activity/Fragment (which google itself claims is bad practice). – Matt Feb 21 '22 at 21:35
  • @Matt This video may help: https://youtu.be/JnN6EFZ6DO8. – Sam Chen Feb 22 '22 at 01:40
  • 2
    @SamChen I finally got a chance to watch the video and still do not understand the benefit of `StateFlow`. The only real argument he gives for it is that now you can pass the fragment as a lifecycle owner rather than `viewLifecycleOwner`. I think this is yet another Android fad that has no benefit. – Matt Mar 05 '22 at 18:20