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
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 difficulties knowing how to structure the classes in an MVP Android project that uses retrofit2 for calls to the API. I need to make a login and a registration. The requests for both of these are different but the response is the same. How can I create&structure the model classes in the best way?
As the matter of fact in MVP design pattern, there is a View(mostly a fragment), a presenter (has a duty to do logical things) and we have no an actual model there!
instead, there is a data part of your application that contains your database and internet connection that we can call it model.
I searched all the internet but I found the best example in below link:
https://github.com/googlesamples/android-architecture/tree/todo-mvp/
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'm building an app using MVP and I'm using a repository pattern.
I have a local data source, which is a DB where I store certain information.
I have a remote data source, in which using Retrofit, I make an API request. This request has a #Query, and that is a String that is stored in the SharedPreferences.
I thought of adding the SharedPreferences to the Repository, as a data source, but since the remote data source should make use of these SharedPreferences -which would be a different data source than the remote- I don't see this architecture so clear anymore.
Thanks a lot for the help in advance.
I think many people over complicate the idea of repositories. The Repository pattern is really just a specific type of the Facade pattern. It is just an abstraction layer which sits between the true data sources (Models) and the consumers.
Let's say we have a system that deals with weather data. In this case I see nothing wrong with having three Modal classes:
WeatherHttp
WeatherDb
WeatherPrefs
These can all be members of your repository class injected through the constructor. All three of these are hidden from the consumers (UI) behind a single repository class:
WeatherRepository
which might have a single public method:
public void getWeatherForecasts(Callback<List<Forecast> forecastCallback);
or Rx:
public Observable<List<Forecast>> getWeatherForecasts();
Behind the scenes of that method you might well make an http call to fetch the latest data, a database call to save the majority of the details and a shared prefs edit to save the timestamp of the last time the data was fetched. The idea is you are free to change the implementation at any time and the consumers don't care.
The single most important thing about implementing a repository is you must not leak the implementation details. No network classes, database DAOs or SharedPreference keys should be exposed by the public API of the repository.
Related to this question on JPA and Android, but looking for design guidance.
I have some data which will be persisted with Objectify on AppEngine. These objects also need to be interacted with on an Android App (and later, an iPhone App). Let's say they are playing cards:
#Entity
public class Card {
#Id Long id;
String suit;
String value;
}
Should I use the exact same class in my Android App as I do in AppEngine, or should I restrict these objects only to the layer closest to the DataStore, and re-encapsulate the data for transmission and use on the mobile - or use a superclass or Interface perhaps?
I suggest that you take the later approach since that will help you build a rich Domain model that is a set of pure classes and not interconnected with any other framework.
One can also refer to these classes as Data Transfer Objects or Value Objects. The nomenclature could be different but the principle is the same i.e. you want data to be passed between different layers of your applications.
Taking this approach of separation will help you a rich Domain model over time and it can be independent of underlying layers and the frameworks that they may use.
Objects persisted thru Objectify have relationships that you may not want to drag with to the client.
Design of API interface (contract) sooner or later will require objects that are different than entity objects. I created two packages, one for Objectify entity and another for api with POJOs and endpoints