This is more of a question about designing applications, rather than fixing a specific issue.
So most Android tutorials I see use ViewModel as a layer between the data source and the views. Hence my first impression was that a ViewModel is supposed to handle data fetching and updating, but then I read about 'Use cases' which most Android samples don't even mention and I don't understand how all these parts fit together. What's the relationship between a ViewModel and a use case?
1) Clean Architecture this is approach how to design your application. This is not about specific realization like in case of ViewModel.
2) If you looked at the official Android documentation you will not find any mentions of Clean Architecture. Google not forcing this approach.
3) ViewModel this is part of MVVM design pattern. So if we looking info Clean Architecture MMVM can be part of Presentation layer (same as MVP commonly used in this layer). But you still need UseCase to make interactions between Data layer and Presentation layer.
Related
Is it really necessary to use UseCases in my android Clean Architecture?
In the Android Jetpack documentation they are not mentioning it.
They are accessing the repository directly from the ViewModels.
Isn't that a better option? Isn't the UseCase code not just making it unnecessarily more difficult to adjust the code?
If you want to strictly follow Uncle Bob's clean architecture then you should use UseCases.
They are accessing the repository directly from the ViewModels. Isn't that a better option?
It depends, greatly, the clean architecture makes testing super easy, also makes you think more architecturally before you implement things and makes you not to make compromises a.k.a. adjusting code, and it follows SOLID principles which are just great.
On the other hand, it's much harder to setup project and sometimes it feels like you are overengineering it
But after setting it up you will see improvement in maintainability and also scalability.
I think that it's great to know what clean architecture is and take what suits your needs.
This is great resource if you want to learn more about clean architecture https://caster.io/courses/android-clean-architecture and how it fits android.
Well I think it's really not necessary to use UseCases, especially if you are not familiar with them. UseCases are just an architectural pattern for creating a more scalable project and to reuse code.
I am personally using UseCases where I see that it makes sense. For example in our project we have the View, ViewModel and Repository. Two common cases to use a UseCase would be if
1) Two ViewModel has a common logic of processing data from the Repository. That could go into a UseCase (But not necessarily, you can create a smaller VM for just that)
2) You want to include a plus layer between the Repository and ViewModel, because you need that layer to handle some extra logic, that is out of the purpose of the Repository and/or ViewModel. For example neither the Repository nor the ViewModel should solve scheduling problems. (A problem like, if you have cache get the data on the MainThread, if not switch to a background thread.)
So in conclusion, nothing related to architecture is necessary. You shouldn't force something on your project, architectural patterns are there only to make your application easier to modify, scale, work with.
I've started using Architecture Components in my application and I'm still learning how to use it.
In my app I have an Activity showing different Fragments sequentially. In some of them I need to communicate with a background service in order to receive data from external BLE sensors. Since I need to interact with the service in more than one Fragment, I'm wondering if ViewModel is the right place where to make the binding. I've looked around but I didn't found an answer.
Are there any problems binding a service inside a ViewModel?
It is not advisable to use Android framework classes inside ViewModels.
Here is the link on Google Developers blog post with the detailed explanation: ViewModels and LiveData: Patterns + AntiPatterns
Ideally, ViewModels shouldn’t know anything about Android. This
improves testability, leak safety and modularity. A general rule of
thumb is to make sure there are no android.* imports in your
ViewModels (with exceptions like android.arch.*). The same applies to
presenters.
Don’t let ViewModels (and Presenters) know about Android framework
classes
I am looking into MVP architecture Implementation in android.
I found too many ways(mention end of the question) to implement it in the android studio, but Still, I am confused.
Can someone help me to find the right answer of below questions.
What would be directory structure of Application in MVP?
Activity should be a Presenter or View?
Way-1
Way-2
What would be directory structure of Application in MVP?
There is no predefined structure for that. What makes your code readable or what structure you are following, you can use same for MVP also.
Activity should be a Presenter or View?
View is the UI layer which displays the data and notifies the Presenter about user actions. So Activity will always be a view.
If you are looking for a good example of MVP implementation, there is one GitHub Repo for MVP developed by Android itself. Which you should look into.
Where
todo‑mvp
Demonstrates a basic Model‑View‑Presenter (MVP) architecture and provides a foundation on which the other samples are built. This sample also acts as a reference point for comparing and contrasting the other samples in this project.
todo‑mvp‑clean
Uses concepts from Clean Architecture.
todo‑mvp‑dagger
Uses Dagger 2 to add support for dependency injection.
todo‑mvp‑rxjava
Uses RxJava 2 to implement concurrency, and abstract the data layer.
todo‑mvvm‑databinding
Based on the todo-databinding sample, this version incorporates the Model‑View‑ViewModel pattern.
todo‑mvvm‑live
Uses ViewModels and LiveData from Architecture Components and the Data Binding library with an MVVM architecture.
Though there are lot of implementations for an MVP architecture, all of them share a basic idea (or they should at least), which is separating business logic from your views (activities, fragments, dialogs). Why is that? Well, for two reasons mainly:
separation of concerns
Testability: your business logic is able to be tested if there is no android components involved.
About your questions:
What would be directory structure of Application in MVP?
There is no rule about that except that your MVP components should be identified. Here you have an article where I started with a package structure but then I found other more convenient.
Activity should be a Presenter or View?
Your activity (or fragment or whatever components in charge of showing view components) should be the one that implements your view.
My advice is that you should check multiples examples and see their advantages and disadvantages of each one, and try to define your own architecture from those which you will feel more comfortable with.
You can use either Activity or Fragment for View layer. This is because showing UI elements in android needs Context.
For the Presenter layer, you must make sure not to pass the Context to the Presenter via constructor or setter. If you needed Context in your Presenter for tasks other than showing the UI, such as writing to SharedPreferences, you can get it from your View (which is either Activity or Fragment). In this way, if the View gets destroyed or becomes null, there would no standalone null Context in the Presenter to cause leak issues.
If you want to know more about the MVP structure, I have written a very handy MVP library for android and explained its use in a sample app here.
MVP android sample example application
MVP Android Example used to explain how to use this pattern in our Android apps.
In Android Architecture Components docs on the Handling Lifecycle page in Best practices paragraph, written:
Use Data Binding to maintain a clean interface between your views and the UI controller.
Can someone provide me with link to example on how to use this libraries together?
You can take a look into this Google Sample, which applies Architecture Components and the Data Binding Library together.
From the link:
https://developer.android.com/topic/libraries/architecture/viewmodel.html
I understood that ViewModel(Android Architectural components) is aware of Life cycle of Component.
Can we use these two ViewModels together ?
Firstly, you need to realize MVVM is the name of an architecture. It's used to extract the logic from the View and put it into the ViewModel. One of the great benefits of doing this is making this logic more easily testable.
The ViewModel class from the Architecture Components has the same name but is in itself not the same. It's just a handy tool to keep data from being deleted when the state of your View changes (e.g.: when the screen is rotated).
As for your last question, the two can of course be used together, but the two are definetely not the same.
For more information on implementing MVVM there are some great answers here on StackOverflow already (e.g.: Android MVVM Design Pattern Examples).
Yes, you can use more than one ViewModel in android application.
I have created 2 boilerplate projects for newbies references to MVVM architecture
MVVM with Retrofit- LiveData - ViewModel pattern
MVVM with Room database - LiveData-ViewModel pattern