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/
Related
I don't understand few things about repository in mvvm, also have seen multiple blogs and code templates. Every one of them doesn't match with other. So
Why there is needs to have multiple Repositories classes? Why single repository shouldn't handle all the data IN OUT for the app?
Why Repository shouldn't be a SINGLETON class in project?
What a repository('s method) should provide to viewmodel Result(Sealed class) or actual response from a api like list(or error)?
SharedPrefrences should be handled by Repository as well or not? if no why
I believe Repository should be that part of your code which should process all the data from multiple source whether be database or network or sharedprefs. So what do you think?
Purpose of repository is not only to manage requests/response but also provide a layer to keep responsibilities separated. If you have 2 modules (let's say Login and Registration), it is much better to keep repositories separated to keep things clean and simple rather than having a single repo with spaghetti code.
This point is opinionated. IMO you can have singleton repositories because they are stateless i.e they do not hold any kind of data which may cause conflict between multiple ViewModels/Modules.
Depends on you but it is much better to return Result. With Result you can handle Success Failure and Error Messages easily and return different Error Messages directly from repository rather than deciding in ViewModel what message to show. Messages can be either from server or internal exception messages.
SharedPreferences is a datasource. Yes you can manage preferences using repository pattern.
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
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/)
I am working on an android app with some networking aspects. There are places in the app that, when a button is pressed, a call is made to a server with a response full of data coming back. My question is regarding creating a robust flow where i have my network calls separated in their own class and all i do is instantiate a networking object such as new MyNetworkHelper(accessClientServer) and give it the name of a client server. This object would then instantiate the appropriate object (ClientServer or StudentServer or TeacherSever etc) to do with accessing that server and doing any database saving and returning a response to the MyNetworkHelper object which would return to the button that was pressed.
Is this the best way to do this kind of task?
What you propose is not unreasonable but could be more standardized using standard patterns such as your helper being a Singleton (and your additional servers as well if they are intended to be used in such a fashion). I would recommend you pick up a beginner book in Design Patterns and Architecture.
Here is one design/ best practices question..
I'm new to android development, and basically new to web/mobile solutions.
So, my question is - what are best practices when organizing structure of android application that get data from the remote server?
Should request to server go into one class that does communication with server (get and post requests), or should I look at my requests as data source, meaning that every data class manages it for itself?
or should I have more levels of abstraction - one level for acquiring data, other for model that uses some interfaces without knowing from what source data come from?
I'm curious how experienced android developers approach to these design issues...
Virgil Dobjanschi presentation is a good resource as pointed earlier, which basically tells you to run your requests from a background service so the activity does not get destroyed and to store your data in the database as early as possible.
For more technical details, the way I am doing it is to divide the app into three components:
1- Library to encapsulate the handling of the HTTP request and response (with ApacheHTTP), which can handle simple request/response and advanced features that might involve cookies (can be necessary for login) and modifying the HTTP header.
2- Marshal/Unmarsha layer, where I parse the server data (e.g. XML or JSON) and convert it to objects (i.e. models) that the rest of my app will deal with.
3- Persistence layer.
As per Dobjanschi's presentation, I usually make data requests run in a service not in a thread worker inside the activity.
Use one of the 3 models presented at this Google I/O talk. It provides you suggestions that will help you out on the whole process of definition of your app architecture. It'll also prevent you from making common mistakes beginners use to make:
http://www.youtube.com/watch?v=xHXn3Kg2IQE
This post will also help you out:
Need sample Android REST Client project which implements Virgil Dobjanschi REST implementation pattern