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.
Related
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
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 am currently integrating architecture components into my app according to the official documentation and the sample apps provided by google (sunflower and todo-app). I realized that none of these use interfaces for ViewModels (the sunflower app does not even use interfaces for repositories).
My question is: is it reasonable to just omit the interfaces for ViewModels (including advantages and disadvantages)?
Is it reasonable to just omit the interfaces for ViewModels?
The below is quite general and applicable not just for ViewModels.
Advantages:
less code
Disadvantages:
won't be able to use most of the well-known design patterns;
won't be able to properly unit test classes (no mocking);
won't be able to properly use dependency injection frameworks;
code refactoring when using another concrete implementation.
The answer depends on the complexity of your ViewModel. If you are never going to create more than one implementation of an interface (including mocking), then there is no need to create the interface, so you can reduce the code and the overall maintenance burden.
That said the important things to consider are:
Can you unit test your view model, even without the interface (answer should be yes, otherwise you have some other problems IMO)
Can you still use a dependency injection framework (the answer is yes at least for some DI frameworks like Prism)
Are you only ever going to create one implementation of your ViewModel?
I believe that the mark of a well-designed ViewModel, should have a relatively simple implementation, and be easy to unit-test without having to resort to mocking.
I know that both Exposed and Anko can operate SQLite easily, could you tell me which one is more better when I develope an Android App?
Use the framework you are most comfortable with. I tried Exposed once and it was ok for what I've used it. jooq might also be a valid alternative instead.
Reading the documentation of both, Room and Anko, I would stick to either one of those.
Regarding which of those, I just found an issue asking the very same question (even though just as a second or third question):
https://github.com/Kotlin/anko/issues/484
Some other resources I found regarding Room and Anko:
Stress-free SQLite with Anko: the comment regarding Anko vs Room is also insightful:
Anko SQLite provides a nice API to manage your data persistence layer but you still have do the heavy lifting by yourself. While Room is more like a framework. Generates databases from annotated classes for you, provides observable queries and has a really nice testing support. Also works well with Android Architecture Components.
Ah... and don't get me wrong. Exposed is ok too, I am still using it ;-) But if you are familiar with both, you may also have your preferred choice already. If you don't know any, you can try both and choose the one where you grasp the documentation more quickly or you feel more comfortable sooner.
I've been reading about architecture to android projects. And I found some stuff, but I guess I misunderstood some concepts or not even understood at all.
One of my questions is about handling api objects, if I have a local database, Should I use the same object from api to store in local database?
I'm also looking for explanation about why use MVVM or MVP, actually they looks like different stuff, I have figured out that MVP is a pattern more concerned about handling UI responsibilities, MVVM I think is oriented to handle communication between UI and database. So I misunderstood the concepts or it make sense?
The last but not least important topic is about dependency injection, I have read about the concept and this question came to my mind, why should I use any framework as dagger to handle this, if I can handle this pattern by myself, once it's not thaaat complicated?
Should I use the same object from api to store in local database?
It can really depend on how good your API object is. You should rather base your local database object on what it really mean in a logical way and if your endpoint is well done it could be the same. The important part in your architecture is to isolate your logic parts from your I/O parts (UI, database, API) so if you want to redesign your UI, change the Webservice you use it will not be too painful.
So I misunderstood the concepts or it make sense?
I am not that familiar with MVVM so I can not really answer that question. But for me the important is not to follow "by the book" one pattern or another but rather to adapt your architecture from what you like from each. I currently try do to so with the Clean Architecture. You can take a look at all the concepts Uncle Bob speak about in this article about making code cleaner and more maintainable.
why should I use any framework as dagger to handle this, if I can handle this pattern by myself, once it's not thaaat complicated?
You don't have to use dagger if you're not familiar with it. But if your project start to grow and you start to be a team of 2, 3, 5... working on it, a framework as dagger can help you keeping a common standard about how you make your dependency injection and then making the code more coherent. Dagger also provide some tools as scopes that can save you some time if you're familiar with it.