-
Notifications
You must be signed in to change notification settings - Fork 922
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Returning LiveData from domain layer #14
Comments
LiveData is part of the framework so i would not use it in the domain layer. |
AFAIK livedata can work even in unit tests? |
@St4B I don't think is a good aproach lose Room features of update LiveData just because its part of framework. |
hmmm ... I was affected by the old project (with rxJava) which had different models per layers and mappers. Now that we use the same model in every layer it does not seem wrong to me. Basically I started to like it! : p |
@Zhuinden yes. You have to add dependencies of livedata to unit test |
Totally agree here with the above comments.
In my opinion, it clearly belong to the UI layer, being a key part of MVVM. |
If you use RxJava in your project, the solution might be to return the Observable from the domain layer and use the reactive streams to convert it to the LiveData in the UI layer. |
Is this available already in the source code? This would be a big help since I want to take advantage of Room -> LIve Data interaction by using this clean arch repository. |
No, this sample app is not using RxJava. |
I agree that the domain layer must not have a dependency on the platform-specific frameworks/libraries, but based on YAGNI principle we're just adding an extra level of abstraction without gain. |
I am kind a new to the Clean Approach, but there was always something that made my crazy in the begging when I tried to understand it. Everywhere, like in here, everybody are saying - just plain Java! No Android, not this, no that, but every time RxJava is the solution of everything. But RxJava is not pure Java!! I swear, I have never seen an article saying - "Here we are using RxJava, and we are breaking the principle, but there are more pros than cons, so it is OK!". So saying this I don't see why RxJava is ok, but LiveData not. |
@mitevyav Well, RxJava is not something that is Android specific, it can be used everywhere (web, mobile, desktop, etc..), on the other side, IMO, you don't need to strictly follow clean "rules", just pick what suits your use-case the best and as long as your app is testable and maintainable you are good. |
After adding the core-testing dependency
it throws an error that has do with with Powermockito.
This error gets thrown after you call the following function in the setUp function
|
So i commented out these dependencies // testImplementation “org.mockito:mockito-all:$mockitoVersion” and now i just have these depenedencies testImplementation “junit:junit:$junitVersion” and there is no longer a conflict. |
Why don't you go for Flow instead of LiveData. as Flow is a pure data driven item. |
Objectively, if you don't want to use LiveData, then you shouldn't use Room. Room is also Android-specific. Honestly, we should just all use Flutter, you can port that to any platform now. 😂 |
Definitely, at the moment there is only one solution for this problem and it's using Coroutine Flow instead of LiveData. That's it! |
RxJava / Reaktive are technically both valid options |
I suppose that it's not necessary to bring huge framework in your project just for gaining data from Room :) |
In that case, just use LiveData 😉 |
The question is "how to avoid liveData in domain layer?", so.. |
What do you think about returning LiveData instances directly from domain Layer?
I'm asking it because the one of the best features of Room framework is the hability to observe changes in DB directly.
So the LiveData instances should be returned directly from domain (usecase and repositories)?
The text was updated successfully, but these errors were encountered: