Content of this article:
- The process of creating a ViewModel
- Why does the ViewModel store data
- Relationship between ViewModel and onSavedInstanceState()
UML class diagrams
The architecture is relatively clear. After all, it is the simplest one among the three musketry. The core of it is ViewModelProvider and ViewModelStore. The ViewModelProvider is used to provide the interface to obtain the ViewModel, and the ViewModelStore is used to store the ViewModel instance. The Factory interface is used to create a ViewModel. There are many ways to create a ViewModel. There are three native methods: NewInstanceFactory without parameters, KeyedFactory with its own key value, And AndroidViewModelFactory with the Application object.
The process of creating a ViewModel
Don’t think of the ViewModel as mysterious. It is an empty class whose only purpose is to hang your objects into the ViewModelStore Map. new ViewModelProvider(this, New ViewModelProvider. NewInstanceFactory ()). The get (TimerViewModel. Class) usually we use this way to obtain a ViewModel object directly, Why don’t you just pass in a ViewModel object?
ViewModelProvider.get()
There are two overloaded methods, one with no key and the other with key. The reason for exposing the key is for the KeyedFactory service, whereas without the key the canonicalName generates a default key. Why do they do that? Because you can create multiple instances of the same ViewModel with a key, you can create only one instance of a ViewModel. Let’s take an overloaded method with key as an example
- We get it from the ViewModelStore, and when we get it, we return the ViewModel object
- Determine what kind of Factory it is and call the corresponding create method to create the object
Why does the ViewModel store data
Here’s core lies in the Acitivity onRetainNonConfigurationInstance () can be accidental destruction of the Activity of data saved to memory, so who hold? The ActivityThread, of course, has the same life cycle as the process, and it is also used to create activities, so it is easier to restore references. So how does it recover? Restore by passing parameters to activity.attach ()
Relationship between ViewModel and onSavedInstanceState()
In fact, the official website has been explained very clearly
ViewModel | onSavedInstanceState | Persistent storage space | |
---|---|---|---|
Storage location | In memory | Serialized to disk | On disk or network |
Persists after configuration changes | is | is | is |
Continues after a system initiated process terminates | no | is | is |
The Activity continues after the user has finished closing /onFinish() | no | no | is |
Data limit | Complex objects are supported, but space is limited by available memory | Applies only to primitive types and simple small objects, such as strings | Limited only by disk space or cost/time to retrieve from network resources |
Read/write time | Fast (memory access only) | Slow (requires serialization/deserialization and disk access) | Slow (requires disk access or network transactions) |
User-initiated shutdowns include the following:
- Press the back button
- Swipe from the Overview (Recently Used Apps) screen to shut down the Activity
- Navigate up from the Activity
- Terminates the application from the Settings screen
- Completes some kind of “finish” operation (supported by activity.Finish ()), that is, the application calls the activity.Finish () operation
For more details, please refer to the status of the save interface on the official website
Considerations for using the ViewModel
- Do not allow your ViewModel to hold any non-Application Context, as this will cause memory leaks, such as member objects such as Views, Drawable, etc
- By default, you can’t add a constructor with arguments to a ViewModel. If you need to add a constructor, you can implement your own Factory, and then create a ViewModel with your own Factory