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
Related
I'm a beginner studying MVVM design patterns.
Looking at the code of Google CodeLab and other sample codes, a question arose.
As the title suggests, does LiveData necessarily exist in the Repository?
I've been using and observing LiveData in a ViewModel so far.
(There's no special reason, I just used it because I didn't know anything)
By the way, I looked at the code of Google CodeLab to study Room, and I saw that it uses LiveData (or Flow) in the Repository and reference this in LiveData of the ViewModel.
Sample code from other web sites was similar.
But I don't know why LiveData is in the Repository and uses the way it's referenced.
Since LiveData is used in the Repository in the code of official docs such as CodeLab, I am using it accordingly, but I do not know why.
In the MVVM pattern, does LiveData necessarily exist in the Repository? I'd appreciate it if you could explain why.
LiveData is simply an observable data holder. It is lifecycle aware so it is a good practice to use it for providing data to View from ViewModel. LiveData can now be replaced with Flow which have few benefits over LiveData.
From Repository to ViewModel, it is completely up to you whether you want a LiveData/Flow returned or simply return the model that you expect from DAO but still you will require a LiveData/Flow if you want to provide that model to View after receiving that model from Repository to ViewModel.
The MVVM pattern is more about designing software, and organising the architecture into separate layers. The View is the user-facing frontend, the Model is the backend where the data is handled.
The View Model sits between them, converting data from the Model into some form of UI state the View can display, and turning UI events like button presses into calls to the app's backend functions, in the Model.
LiveData and Flow (which are similar - one is Android and one is Kotlin) are ways of exposing data, which is ultimately what the Model does - producing data. Instead of just providing a single value on request, they're able to provide a stream of data.
And the View Model (which is the intermediary between the Model and View - they don't talk to each other) can take that LiveData or Flow, and either expose it directly to the View, or do some processing on it to produce data suitable for the View to display. That way you have a pipeline from the data producer (the Model) to the UI (the View). That's basically how MVVM works in general, this is just using the streaming/producer/reactive model to wire things up and make things like async operations simpler
This is worth a read, it explicitly mentions repositories as the data producer in this model:
https://developer.android.com/kotlin/flow
I have an architectural question. Currently my app is so simple that user logs in and gets a list of restaurants and he can logout. I use kotlin coroutines for async part, mvvm live data and koin DI.
Here is my login flow when user clicks on login. The regex validation is done in LoginViewModel -
LoginFragment -> LoginViewModel -> AccountUseCase -> AccountRepoImpl -> AccountLocalDataSource or AccountRemoteDataSource
And the response is given all the way back from DataSource to LoginFragment.
I consider the AccountUseCase and AccountRepoInterface as a part of the domain folder along with the AccountModel. The AccountRepoImpl is in repo folder and AccountLocalDataSource and AccountRemoteDataSource is in datasource folder.
My question is ideally the domain should not have any 3rd party dependencies. But my AccountUseCase emits livedata to the viewmodel class and as a result my domain is using android livedata dependency and also it is not doing much but just calling the repo for loginuser. Does it make sense then to have this usecase?
In terms of the LiveData dependency, I would suggest you to ignore it in this case. If you want to make it reactive, either you use library like LiveData or RxJava or have your own implementation. There's no much difference. Just that LiveData happen to be provided by a package that has the word android inside.
Regarding the use case, as you said your app is currently simple. The use case seems redundant for now as the logic is simple in this case but it will be helpful once the app gets more complex.
Some scenarios that I can think of:
when the login logic changes, you only have to update the AccountUseCase which follows the Single Responsibility Pattern (SRP).
when you want to use the AccountUseCase in other ViewModel instead of reusing the whole LoginViewModel.
this makes your code base more consistent, if all the logic are inside the domain layer. Instead of "hiding" some simple logic inside your ViewModel.
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.
I want to know what is the role of presenters in Android application development?
And where should I call the data APIs?
Should I send my data requests inside the presenter or inside the (fragment / activity)?
Also, what is the role of the fragment/activity in MVP?
If you have any resources in this matter, they will be appreciated.
It depends on your MVP variant.
But data requests go in your data classes, called from the Presenter. XXXDataManager for example. Where XXX is the model class you are fetching.
Fragment/Activity is usually regarded as dumb views in MVP.
Resource: https://medium.com/#cervonefrancesco/model-view-presenter-android-guidelines-94970b430ddf
I'm trying to use Uncle Bob's clean architecture in my android app. So, I followed this guy's great implementation based on RxAndroid, Dagger 2 for DI. I know that to get data from data stores (Cloud or local db or disk), the Interactors (Use Case classes in the Domain layer) will invoke Repositories in the DATA Layer.
In my case, I have to execute two parallel REST API calls (Foursquare API and Google places API), then, compare the received data from each call.
Do I have to put these Retrofit calls' implementation in the Data layer or inside the Interactors in the Domain layer ? If any external API call belongs to the data layer, what's exactly the role of interactors in Uncle Bob's approach ?
I'm new to this approach, any help is greatly appreciated!
i think you should call the API in data layer and then process the result in domain layer, of course if the result was independent from any framework.
and interactors was the one that orchestrate the flow of data to and from the entities. (http://fernandocejas.com/2014/09/03/architecting-android-the-clean-way/)