There are two common postures for LiveData

Use wrapper classes to pass events

We may encounter problems with “sticky” events when working with LiveData, which can be solved by wrapping classes. Use LiveData in SnackBar, Navigation and other events

This is what happens when you use it

class ListViewModel : ViewModel {
    private val _navigateToDetails = MutableLiveData<Event<String>>()

    val navigateToDetails : LiveData<Event<String>>
        get() = _navigateToDetails
   fun userClicksOnButton(itemId: String) {  _navigateToDetails.value = Event(itemId) // Trigger the event by setting a new Event as a new value  } }  myViewModel.navigateToDetails.observe(this, Observer { it.getContentIfNotHandled()? .let {// Only proceed if the event has never been handled  startActivity(DetailsActivity...)  } }) Copy the code

But it’s tedious to write, and we can do it in a more elegant way

// Provide a type alias for LiveData
      
       >, using EventLiveData
       
      
typealias EventMutableLiveData<T> = MutableLiveData<Event<T>>

typealias EventLiveData<T> = LiveData<Event<T>>
Copy the code

Using the typealias keyword, we can provide a typealias that can be used as follows

MutableLiveData
      
       >(Event(false))
      
val eventContent = EventMutableLiveData<Boolean>(Event(false))
Copy the code

Now that you don’t have to add a layer of generics to the declaration, it’s still cumbersome to use

We can use kotlin’s extension functions more elegantly

Event extension function
use

The demo encapsulates two forms of LiveData, one is LiveData

and the other is EventLiveData

. When the screen rotates, the former will call back the result again, while the latter will not execute onChanged because the event has been processed. We can observe this phenomenon through Toast


Java version for reference


Encapsulates data with network state

Most of the time, we need to encapsulate a layer of network state when obtaining network data, such as loading, success, failure


We ran into the same problem as above, with multi-layer generics being cumbersome to use

We can still handle this problem elegantly using the TypeAlias + extension function

typealias
Extension function
use

The demo screenshot

demo

Demo

The demo is here. If you feel this idea is helpful, click on a little star ~ 😉

I also uploaded it to the JitPack, introducing the pose as follows:


  1. Add to build. Gradle in the project root directory

    allprojects {
  repositories {
    / /...
    maven { url 'https://jitpack.io' }
  }
} Copy the code

  1. Add the dependent

    dependencies {
  implementation 'com.github.Flywith24:WrapperLiveData:$version'
}
Copy the code

The articles

This series mainly introduces some “SAO operation”, it may not be suitable for production environment, but some of the more novel ideas

  • AndroidStudio Nexus3.x builds Maven private server with problems and solutions
  • What? There are over 200 lines of Gradle code in this project! You may need the Kotlin+buildSrc Plugin
  • Gradle relies on lookup too much? This plugin may help you
  • Android componentization does not use Router how to implement activity jump between components
  • New image loading library? Image loading library — Coil based on Kotlin coroutine

  • Use Navigation + Dynamic Feature Module to achieve modularity

  • How do you configure dependencies like this in addition to buildSrc? Use opportunely includeBuild

The rest of my series is here

About me

I am Flywith24, and my blog content has been classified here. You can click Watch in the upper right corner to get updates of my articles in time, oh 😉

  • The Denver nuggets

  • Jane’s book

  • Github