Develop Reference

ANDROID MVP Interactor vs MVVM Repository

I understand MVVM has View - Viemodel -> Repository flow in which repository is in charge of taking care of api calls, database calls...
On the other hand in MVP we have View - Presenter - Interactor.
From my opinion Interactor in MVP is very similar to repository in MVVM. They both do network and database calls with service and they send the results to Viewmodel/Presenter.
I would like to know a little bit more about this Interactor - Repository correlation.
Is it true that if we have Interactor in MVP architecture, we don't need Repository class since the network layer is already separated in Interactor class?
Also can we say that Interactor in MVP is almost the same thing as repository in MVVM?
What are their differencies?

The Interactor represents a logical use case. The interactor is more like bridging the gap between the View layer (by communicating with the presenter) on one hand, and the implementation environment, or repositories, on the other. The interactor is used to have a clear picture of the use cases you want to develop in your application.
Repositories, as you mentioned provides us with clean API to access the data layer and pass on the data to the domain layer(interactor/use cases).
Is it true that if we have Interactor in MVP architecture, we don't need Repository class since the network layer is already separated in Interactor class?
Answer-- No Because we want to avoid objects that deals with both presentation logic and dataflow logic. We also want the dataflow logic to be reusable across different ViewModels. Thus its better not to call the repository directly from the ViewModel/Presenter and have an additional interactor/usecase to handle that.
For reference - https://proandroiddev.com/why-you-need-use-cases-interactors-142e8a6fe576

Model in MVVM is simply is simply a pojo class?

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

Does an app built with Architecture Components make it "MVVM" and if yes, which parts of the app relate to which layer of MVVM?

I couldn't find any source that answers this question directly:
Are Android Architecture Components made to follow an MVVM architecture (if implemented properly)? And if yes, which part of the app (Activity/Fragment, ViewModel, repository, database, web service) relates to "Model" "View" and "ViewModel"?
The ViewModel class obviously belongs to the ViewModel layer, but what about the rest?

Your Activity or Fragment is your VIEW,particular activity/fragment viewmodel represents VIEWMODEL which contains all the business logic of your UI and Model/Repository represents MODEL which contains all the data related logics. You can manipulate data in model and can use Database,web services and Shared Preferences in the Model.

Using LiveData and ViewModel without using Room

For android MVVM architecture, in all the examples that I have seen, people either use Room to store/retrieve data or they get data directly from API calls through the Repository class.
I'm neither doing an API call nor using I have Room database to store data. But I need my ViewModel to get the data from the repository and pass it to my Actvity.
Can your Repository class inherit from Application class so that you can save static variables/companion objects if you don't intend to use Room for saving data locally ?
What is a good way to handle this case?

In general, in Software Engineering a Repository is used to abstract the Data Layer (Database, Web Service) from the rest of the application (usually directly Business Tier), a good example would be this schema of a booking website:
It receives the updates via the Publish/Subscribe asynchronous connection and sends them to the other components. So the components are independent of each other.
So Repository is just a simple mediator class that is used to make the application more modular, so that you can swap out pieces easier, and make sure that the rest of the app doesn't bother with DB connections or HTTP calls and so on. So technically, you can inherit from Application (or anything else) and use it to save static variables and so on.
But as explained here:
The application object is not guaranteed to stay in memory forever, it will get killed. Contrary to popular belief, the app won’t be restarted from scratch. Android will create a new Application object and start the activity where the user was before to give the illusion that the application was never killed in the first place.
So it's entirely up to you, you can use the repository style as you wish, it's not at all tied to Room or anything else.

Android MVP with RxAndroid + Retrofit

Recently I started reading a lot about MVP and I want to get into practicing my projects with it.
However I am not able to correctly understand where should Rx + Retrofit code go? I think it should be in Model Layer via Interactors but still can someone share some light on this?
Also what happens with the RX callback? the onNext(), onCompleted() and onFailure() passes data back to Presenter or do we implement listeners and then pass it on to Presenter?
I also want to persist data (Realm/StorIO) when I get it in onNext(), So again pass it to another DataLayer or where should it Go?
Also should we decouple Rx callbacks further?
I am following this post
https://davidguerrerodiaz.wordpress.com/2015/10/13/a-brief-introduction-to-a-cleaner-android-architecture-the-mvp-pattern/
and this seperate github repo from antonioleiva.com
https://github.com/antoniolg/androidmvp

As you pointed the RxJava functionality defines a use case of your model layer so it would be placed in an interactor of this layer. You can create a different interactor for each use case. Let's say you are pulling a list of users from your server, this would be a use case and an interactor that will have the RxJava/Retrofit Observable.
Then you will have a Presenter with an Observer in it which is interested in this users list, so it will be subscribed to that Observable.
And finally when this Observer in has all the data from the Observable (onCompleted), it will transform this data (if needed it) and pass to the View which will be just in charge of display it.

There is awesome post explaining mvp.
Rx is just additional tool for it.
http://hannesdorfmann.com/android/mosby-playbook/
there is deep explanation and source code with example.