Just would like to ask guys, is it good to use `anti pattern architecture` with coroutines or `clean...

# android

[Johnjake Talledo]

Just would like to ask guys, is it good to use anti pattern architecture with coroutines or clean architecture? As my concern on using clean arch is that it will add another layer, classes, callbacks and observable/collector. Also I am using paging3 library adding another layer might not be a good idea.

[Johnjake Talledo]

Anti Pattern

[Johnjake Talledo]

Clean arch

[K Merle]

I don't understand the anti-pattern part? Also, coroutines are the go-to when going reactive on Android today and coroutines are not aware of architecture and vice versa.

[Christophe Smet]

How is this an Anti pattern?

[Johnjake Talledo]

@Christophe Smet if you follow clean arch you will need to separate the use of Data Layer (sources: Api or local) and Domain Layer (Use case), in anti pattern domain and data layer is one as shown in the first image.

[Johnjake Talledo]

@K Merle Do you usually add domain or use case that set on the top of your repository or data layer?

[K Merle]

Only if necessary. If the feature is too shallow, I do not like to add it, as it feels boilerplate.
So if there is a necessity for these layers I add it. Use cases can be very helpful as you have a specific place where your business logic is, but they also can be a boilerplate, as sometimes your repository can handle all and there is no need for use-cases.
So for example, I have a repository. If only 1 presentation layer is consuming that features domain layer (presumably it is the presentation layer of the same feature), it is correct to say that use-cases are unnecessary and injecting the repository directly into a presentation (our ViewModel) is fine. However, if some of the functions from the repository are gonna be used elsewhere, I like to make use cases and reuse these use-cases because it is unnecessary for feature Y to be injected with the repository and for feature Y to only consume one function from the repository.

[Johnjake Talledo]

@K Merle Thanks

[Christophe Smet]

Totally agree with @K Merle, it’s good that you think about it, but separating this more would count as overengineering imo.
Just keep a eye out if the viewmodel starts doing too much.
Then it’s time to split them.

[Johnjake Talledo]

@Christophe Smet thanks