I am using LiveData
in AndroidViewModel
class where i need to wait for the response, but there are some cases where i need to check some value from local shared preference
, which won't block any thread.
For these scenarios i am not using LiveData
. This is what i am doing in my activity class
.
homeViewModel.sendTokenToServer().observe(this, isFCMSendToServer -> {
Toast.makeText(this, "FCM Token Observer called", Toast.LENGTH_SHORT).show();
});
//Without Live Data
if(homeViewModel.isUpgradeAvailable()){
displayAlertMessage();
}
I want to know if the above approach is fine, or we have to use LiveData
or some other observers for each method in ViewModel
No, It is not mandatory to use LiveData always inside ViewModel, it is just an observable pattern to inform the caller about updates in data.
Why should you initialize and store LiveData in your ViewModel instead of a UI Controller? Both the ViewModel and LiveData are lifecycle aware. To ensure that the LiveData isn't destroyed when the UI Controller is destroyed. To hide or separate implementation details making your app more flexible.
The ViewModel stores the app related data that isn't destroyed when activity or fragment is destroyed and recreated by the Android framework.
LiveData notifies Observer objects when underlying data changes. You can consolidate your code to update the UI in these Observer objects. That way, you don't need to update the UI every time the app data changes because the observer does it for you. No memory leaks.
The LiveData class, on the other hand, allows for an emitter-observer pattern: elements of the view can subscribe to data in the ViewModel and be notified whenever that data changes. Let’s take a closer look at each of these 2 classes.
This part is clear and does not result in too many discussions, however the ViewModel has to load, subscribe or trigger the load of its data at some point. The question remains as to when this should be done.
Possibility to provide parameters. ViewModel very often needs to accept parameters to load its data. This is widely used concept and is promoted even in Google Blueprints example, but has significant problems. The method needs to be called from somewhere and this typically ends up in some lifecycle method of Activity or Fragment.
The main benefit of the ViewModel is that it is created the first time and if the Activity, Fragment or any other LifecycleOwner is destroyed or recreated by the system, the next time it starts it will receive the same ViewModel created before. It works like a Loader (AsyncTaskLoader and CursorLoader)
AFAIK ViewModel
and LiveData
are not tightly connected. Therefore you are not obliged to use any observers. For example in this sample app, the ViewModel
is used to preserve some numbers through orientation change. Therefore ViewModel
serves as a container (something like a headless fragment) where you can store data to be retained through orientation change.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With