Group Group Group Group Group Group Group Group Group

Clean Architecture Tutorial for Android: Getting Started | raywenderlich.com

Hi!

Yes, it is ok to pass more different repositories to a single use case.

Thanks for the article. It might take a couple of more reads and then a practice myself. My one bit of feedback would be is that I’d have preferred it to have been done in MVP. I feel the article strayed off into MVVM territory too much in the latter half, which I know a little about, but this was quite complex MVVM, so the article stopped being about Clean and about MVVM instead.

It is a good tutorial for clean arch but i would highly recommend having the extra work to properly implement it with koin otherwise this is only partly complete.

Can i see your JSON Response to compare it with mine?

@ikust Can you please help with this when you get a chance? Thank you - much appreciated! :]

Hi,

sorry for such a late response.

Which JSON Response are you referring to? There are no network request made from the example project so I’m not sure.

Hey @ikust

Can we inject usecase inside another usecase?
Where does filtering, sorting belong in the layer?
If two usecases are almost doing the same thing but dealing with different domain models, different data source, should they be in one usecase?

@ikust

I am using Firebase Firestore which supports Observable get requests. Could you suggest how to implement it in clean?
Currently, my repository implementation class has LiveData (from AndroidX) & QuerySnapshot(from Firebase) as the function return type. Which mean framework related imports would enter into domain layer.
Could you explain how this can be done properly.

Hi @sagarsuri ,

Can we inject usecase inside another usecase?

the important thing is that Use Case doesn’t depend on anything from framework or presentation layers.
So, if you have a case where injecting another use case makes sense that’s fine.

Where does filtering, sorting belong in the layer?

I think a good guideline is to place business rules and logic in the domain layer. If there is logic that is only specific to a certain Use Case and is not a part of business rules (for example sorting or filtering of data to display them a certain way in some Use Case) I think it can go in the Use Case layer.

If two usecases are almost doing the same thing but dealing with different domain models, different data source, should they be in one usecase?

I think it depends on the Use Cases. Ideally, a single Use Case should represent, a Use Case in the app.
I’ll try to explain my point of view on the example app from the tutorial:
Adding a bookmark in the example app is one Use Case.
Adding a Document to your library is another Use Case. But I wouldn’t try to fit those two use cases into one just because they both do the same operation on different domain models (add them to collection).

Hey @ikust

I see all the Usecase classes are concrete classes. As per design principles, we should program for interfaces right? What is your opinion on this?

Hi @sagarsuri,

I think it’s ok to have Use Cases as concrete classes and it isn’t against SOLID principles. At the moment I can’t think of a situation where you would profit from having separate interfaces and implementations of Use Cases.

I’ve read so many articles and watched so many videos about knowing what is clean architecture and how to implement clean architecture and layers usage. But i couldn’t get the concept. After reading your articles i’ve understood whole concept and i decided to give you a comment. Thanks for your greatly explained article…

1 Like