If You Think THIS Is a Best Practice, You're WRONG in 99% of the Cases...

This video will show you new possibilities and why you have been wrong 99% of the time!

Get my super extensive Android testing course here:

💻 Let me be your mentor and become an industry-ready Android developer in 10 weeks:

⭐ Courses with real-life practices
⭐ Save countless hours of time
⭐ 100% money back guarantee for 30 days
⭐ Become a professional Android developer now:

Get my FREE PDF about 20 things you should never do in Jetpack Compose:

Join my Discord server:

[rudemption]

You will not misuse use-cases, if you're not using them😂

[sevarbg]

The mistake is the assumption that every mapping operation can be performed as a simple 1-to-1 conversion. Very often it's not the case. Sometimes you need to merge data from 3 objects to create one or a pair of two. Layer to layer mapping is not bad. The bad thing is the 1-to-1 generic mapper interface. It's too inflexible. Just use concrete mappers not implementing mapper interfaces.

[RajSharma-ltfw]

Thanks a lot for the explanation by showing an actual app and walking through step by step about the complexity. A lot of other content providers would just go through the Google documentation and explain the redundant topic. These videos helps to relate with the actual usecases developers face daily especially with large scale applications. Many a times new joiners would just get lost in the abstractions and navigating through so many classes. Please continue sharing such awesome content ❤

[brytonmassie]

2:52 This is why I *used to* despise Java when trying to understand someone else's Minecraft mod or plugin, more often than not they'd have functions sending variables to a slew of other classes to an unnecessary degree, it was like three dimensional spaghetti-code, the function was abstracted across multiple classes and was more passing variables than logic making it a nightmare to debug because it could've been done with potentially a few extra lines of code but kept said code inside 1 class and therefore keeping things simple.

[arielapp]

it is probably a good idea to have a usecase (especially in large projects)
but it's important to understand why you want them.
if you only use it to transfer data from repo to viewmodel, then it's not really useful,
but if you're using it to create a buffer between the viewmodel and the repo, and save data to local repo, then it's useful.
also, it's probably a better practice to use high order functions for the mapper, instead of an interface.

[BrayanBedritchuk]

Great video Philipp!

I agree with you that creating abstractions that will have no more than one implementation can be overwhelming when we try to navigate from one end to another.

As a counterpoint, the main advantage that I see in my projects in implementing structures this way is the possibility of isolating contracts from concrete implementations in different modules, resulting in a reduction in the project build time when the other modules in my application reference only the modules with these contracts and not the robust modules that contain all the concrete implementations. There's a very interesting talk at Droidcon called Android at Scale @Square that exemplifies this approach.

[mariospiritof]

Thank you! I think you missed an other abstraction benefit: it allows to keep the real implementation as an internal class. If you modularise an app, it could be very helpful:
Let's say you have a UseCase that needs a mapper. This mapper is used only by UseCases. You want to keep this mapper internal in the "domain" gradle module. If you expose your real UseCase implementation to your UI module, and if the mapper is given to the UseCase constructor via DI, you will need to expose your mapper too. If you use an abstraction in front of your UseCase, you can expose the abstraction only, and keep the UseCase implementation and the mapper as internal.
This way, you can avoid that the UI layer knows the data layer too.
WDYT ?

[jackeblan]

Use the use case when your function needs more than one repositories and these needs to return a result. In the video, It just delegate the calls to the repository which doesn't make sense. Also, Do not put all the UI logic to the use case... Let the UI do that. For business logic, let the data layer do it too. So your use case is like a bridge to many repositories.

[damirkrancpiler]

Exactly what I've been arguing in all the architecture talks, nice!

[GakisStylianos]

We all need to go through the process of doing too little such abstractions, then we do too much, and then we go back to doing just as much as we actually need to. This video is great in describing this. I am sure people who disagree will be able to come back to this in 2 years and find themselves agreeing instead. Great work on this one Philipp.

[SahilNagi]

Hello Philipp, I am a senior manager of JetBrains and I was in the role of developing Kotlin language, so will kotlin kmm surpass Flutter in next 2 years ?

[VivartPandey]

You can also inject implementations directly which will solve the ctrl+ click navigation problem and use abstraction as architecture style enforcers.

[sergeykharuk]

Probably you forgot to say that we should always have interfaces (abstractions) for repositories (if we write multimodule project) because for example AuthRepository (interface) is usually placed in DOMAIN layer and AuthRepositoryImpl is placed in DATA layer, which are in the sepatere modules.
So, having only AuthRepositoryImpl we can not follow clean architecrute (correct if I am wrong)

[gekylafas]

I used to think like that. Then the reality of actual production enterprise applications used by hundreds of thousands of users that were using ever changing backend services but had backend code tightly coupled with UI code hit me hard. There is a good reason for these abstractions and personally I would use them even for toy/hobby projects.

[nicoloagnoletti]

Hi Philipp, clear explanation as always, but I wish you would bring some examples here, as if you're using a complete Clean Architecture, every layer of any feature has strong directional dependency towards the center, towards the domain logic layer.
I understand this could seem like an unnecessary complication, but without it no one would be stopped when trying to inject a retrofit interface to a viewmodel or even worse a view.
I don't want to check your course to understand what you meant in the video, or if you're thinking of every scenario or most scenarios, we can all agree it shouldn't be necessary right?
Other than that, keep the good job as always!

[bhuvneshvarma]

Nice video! In your experience, abstracting use cases might not be the most effective for testing. Since they often encapsulate business logic, testing with real implementations can be more valuable. This means using mocks or fakes for the repository layer when testing view models in the presentation layer?
Here's why: Use cases typically depend on repositories. If we don't mock the use case itself, we'd need to mock the repository to avoid hitting the real server during tests.
My question is: Considering this approach, would you prefer mocking the repository directly in the presentation layer tests?

[RatneshNavlakhe]

Similar question I had when I started working on a big android project I wasn’t able to understand, now it’s crystal clear thanks philipp for such an informative video keep doing the great work you inspire lots of engineers ❤

[nnamdiwilliams]

This video makes sense. I would imagine on a project, everyone has their own philosophy on when to use Abstraction. I don' think there is a clear answer.

[NaorBK]

Its true that we should find the balance between absctraction and simplicity, But in your example, I tend to disagree, since we see a repository, useCase, well mappers im not sure but it does make sense after all. Even if the only thing you need right now in the use-case of login is the login-execution method to implement, since all the functions in the applications are working that way its not that complex for the developer.
If you are working with a massive application, with dozens of use cases, it making the developer to know exactly what to expect to find when he is looking for the implementation of some function in the UI layer..

[gorudonu]

what?! you're saying that clean architecture with use cases are boilerplate and not useful in 99% of projects? You're right ;)