mvvm

Google official website MVVM example.

The MVP is introduced

Let’s talk briefly about how it differs from MVP. It is well known that MVP simplifies the V layer by moving some business logic to the Presenter layer and network requests to the Model layer. This makes the code less maintainable and more legible to read, but it has the fatal disadvantage of not being aware of the Activity lifecycle. Of course, it’s not that difficult to implement this functionality, as long as we write a lot of methods and manage them ourselves, but it’s infuriating because it directly increases our maintenance costs. Why don’t we have a cup of coffee sometime?

Introduce MVVM

MVVM’s appearance solves this problem. Let’s look at what MVVM is like. The Model layer does network requests, the VM layer does interaction with the V layer, and the V layer does UI presentation. There’s no difference, but there’s an interface called LifecycleObserver that Google provides. Once you implement it and register in the V layer, everything will be solved, your VM will be aware of the Activity lifecycle, and we can have a cup of coffee!

Let’s take a look at the simple implementation of LifecycleObserver

class MainActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?). {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)
        lifecycle.addObserver(MyObserver())
    }

    override fun onResume(a) {
        super.onResume()
        Log.e("---------MainActivity: "."onResume")}override fun onPause(a) {
        super.onPause()
        Log.e("---------MainActivity: "."onPause")}}class MyObserver : LifecycleObserver {
    @OnLifecycleEvent(Lifecycle.Event.ON_RESUME)
    fun connectListener(a) {
        Log.e("---------MyObserver "."ON_RESUME")}@OnLifecycleEvent(Lifecycle.Event.ON_PAUSE)
    fun disconnectListener(a) {
        Log.e("---------MyObserver "."ON_PAUSE")}}Copy the code

MainActivity#onResume->MyObserver#ON_RESUME->MyObserver#ON_PAUSE->MainActivity#onPause As long as you write lifecycle. AddObserver (MyObserver()) in your Activity, it will listen to your lifecycle. We won’t cover how that works in this section.

The analysis of principle is here

The 2019-12-27 15:31:33. 334, 27080-27080 / com. Air. Making E / -- -- -- -- -- -- -- -- -- MainActivity: OnResume 2019-12-27 15:31:33.335 27080-27080/com.air.github E/---------MyObserver: ON_RESUME 2019-12-27 15:32:03.969 27080-27080/com.air.github E/---------MyObserver: ON_PAUSE 2019-12-27 15:32:03.971 27080-27080/com.air.github E/---------MainActivity: onPauseCopy the code

jetpack

Jetpack official example of Jetpack architecture at Google official address

Jetpack is divided into basics, architecture, behavior and interface. Here we are going to highlight which libraries are used in our design architecture. In fact, we have introduced one at the very beginning, which is Lifecycle. Although we haven’t read its source code or analyzed its principle, we believe that its principle is much simpler.

Enter the next main characterLiveData

fun postValue() {
    val mutableLiveData = MutableLiveData<String>()
    mutableLiveData.observe(this, Observer {
        Log.e("---------hexl: ", it)}) / / Handler for its internal implementation mechanism of thread {mutableLiveData. PostValue ("LiveData basically uses -postValue")}}Copy the code

The first step is to create MutableLiveData. Its generics say we want to look at the type of the data. In this case, we’ll simply write it as a String. Observe observe observe observe observe observe observe The LifecycleOwner parameter is the same as the LifecycleOwner parameter. Why not report an error? In androidx, Google has already implemented the LifecycleOwner interface for us. Step 3: Create a child thread that calls postValue to emit an event.

The analysis of principle is here

Enter the next main characterViewModel

fun basic() {
    val myViewModel2 = ViewModelProvider(this).get(MyViewModel2::class.java)
    myViewModel2.mutableLiveData
        .observe(this, Observer {
            println("----------hexl: $it")
        })
    myViewModel2.getName()

}
class MyViewModel2 :ViewModel() {
    val mutableLiveData = MutableLiveData<String>()

    fun getName(){
        mutableLiveData.postValue("HEXL")}}Copy the code

ViewModelProvider(this).get(MyViewModel2::class.java). It creates an instance of the extends object that we can create ourselves with new. So why do we build it this way? In fact, it does caching for us underneath, preventing us from recreating the object when the Activity screen rotates.

The analysis of principle is here