I want to know that is viewModel necessary to use. Is there any alternative of ViewModel.
can I use only xml files for UI.
Model View ViewModel (MVVM) is a software architectural pattern so no its not necessary you can just throw everything in your activity/fragment if you wanted and it would work the same but typically you don't want to do that. There are a bunch of different patterns that you can use.
For your second question yes you can only use xml files to create your layout
Both are possible to make application. But I recommend for you to use Android Architecture Components including ViewModel by google.
The simple answer is No, it's not necessary you can make complete Application Architecture by using fragments but in this way you might face many problems.
Android Architecture Components
you can use the only XML for UI
Related
Suppose in a project I have 10 XML file. Within 3 of them don't require data binding feature i.e., we just need the reference of views, thus don't need to wrap all the three XMLs into <layout>...</layout> tag.
So is it a good idea to use both view binding and data binding, or just the data binding as it's superior of view binding?
P.S: Wrapping up into <layout>...</layout> is not a big deal, but I am asking for best practices we should follow.
The answer to your question is yes, you can use data-binding and view-binding together, but it's not recommended because it significantly impacts your build time. There is nothing view-binding can do that data-binding cannot.
You can check this link that compares these two approaches and explains the differences, but normally view-binding can be a better choice due to a lower build time and better effectiveness.
Yes both can be used in a project for the UI where the data is linked to the data of the viewModels used it is preferred to use DataBinding and normally you should use ViewBinding as it is less resource intensive and efficient, lastly you can use both of them synonymously in project.
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.
I have been using the SingleLiveData class which can be found here. My questions are:
Is SingleLiveData is actually part of the Android Architecture Components?
Is it a good idea to use it?
Is SingleLiveEvent actually part of the Android Architecture Components Library?
No, and it won't be: https://issuetracker.google.com/issues/122413110.
Basically, the official answer is "Yes, regular livedata wasn't enough, so we introduced it in our examples but it's too hacky to be in the library".
Looking at Live data and its Parent/Children inheritance there is no such thing as SingleLiveData. Reading link provided by #Raghu, I find statement:
The SingleLiveEvent class was created for a sample as a solution that worked for that particular scenario. It is a LiveData that will only send an update once.
So to answer your questions:
Is SingleLiveData is actually part of the Android Architecture Components?
No, it is not!
Is it a good idea to use it?
This depends on many factors. Since I haven't used it I will give general idea. Using classes that you find in demo app or other way might not be guaranteed to be updated or bug-fixed. So if you understand the class so well that you can fix any bug you might find, and if it fits your need, then use it.
But generally I would avoid that if I can find something that is well maintained and does the same job.
Since from skimming the article I get impression he is trying to make some sort of observer pattern, I will suggest you check out rxjava
I'm using ObservableField for single UI events but it requires some hacking to use with Fragments to subscribe/unsubscribe automatically.
using MVVM or MVP should i name packages like model, viewmodel, view and put proper classes and interfaces there or is it just a logical structure that should not be visible in classes structure?
If you want to go by the book, the current "correct" way to implement MVVM in Android is the Android Architecture Components set of libraries.
Read more about it here, and try this code lab. These will also show you how to name and place your classes.
But in general, you should go with what matches your app best. For smaller apps I would recommend going with M V P folders, while for bigger, more long-term ones tend to work better with folder-per-feature structure.
Google in it's sample Android Architecture project uses Model(Data) V(views) VM(view-models) file structure
Google sample sunflower app to show architecture components
Probably that's the best approach
Additionnaly you may find this resource interesting https://overflow.buffer.com/2016/09/26/android-rethinking-package-structure/
An implementation is visible here https://github.com/SamYStudiO/beaver
I also would like to indicate watching this TUTORIAL.
This guy goes well on teaching about the Architecture MVVM and also uses the ROOM Persistence Library.
It is worth giving a look at it.
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