In MVVM Architechture M stands for Model which holds data. as per many references it looks same as POJO classes. Am i right ? if yes then whole android life cycle architecture is depend/composed of POJO classes, as with MVVM we can use databinding which also use POJO class or DATA class. In android room integration it also uses POJO to create table, in live model architecture most of the people uses POJO classes.
As far according to my knowledge, POJO is not suitable if your app has lot of Api integration as well as if the back end has no SQL which happens in my case, as Api is not consistence and data happens to be change rapidly and everyday new parameters are added.
Please provide me in short Advantages and disadvantages of using POJO class and a way to use POJO with non consistence API structure.
Currently i am using GSON for manually deserialization of data.
In summary, yes. Your model classes are simple pojos.
Your UI (your View) can get it's data from the ViewModel. The ViewModel provides this data with data from Models.
But you can still dynamically update the Model in the ViewModel. In the Guide to app architecture, you can find a diagram which shows a common pattern. Your ViewModel gets its Models from a Repository class.
The Repository class handles calls to the database or a web service or any other interface to provide up-to-date data to the ViewModel. The ViewModel doesn't care where the data comes from.
This has benefits in unit testing, since you only need to override the Repository interface if you want to provide mock data to your ViewModel.
Source: Google, https://developer.android.com/jetpack/docs/guide