Android-cleanarchitecture: Chain use cases.

[amatkivskiy]

Hi guys,
Thanks for your project, it is great).
I was wondering whether I can execute one use case with the results of the previous without callback hell?

[caseykulm]

Escaping callback hell is one of the great benefits of rxjava/reactive programming.

Although it sounds like in this case rather than combining 2 UseCases in the presentation layer, you want one new UseCase that encompasses everything you need for this different use case.

[amatkivskiy]

Escaping callback hell is one of the great benefits of rxjava/reactive programming.

That why I like ractive and Android-CleanArchitecture pattern.

Although it sounds like in this case rather than combining 2 UseCases in the presentation layer

For example: when I receive results from one use case I need to pass them to the another use case. That approach leads to such code:

 firstUseCase.execute(new DefaultSubscriber<String>() {
        @Override
        public void onNext(String s) {
          secondUseCase.execute(new DefaultSubscriber<String>() {
            @Override
            public void onNext(String s2) {
              // Grab the results.
            }         
          });
        }
      });

Do you suggest to create separate use case that encapsulates previous use cases?

[alexandru-calinoiu]

I also think that using composition here is better, if you create a new use case you will have the ability to reuse it at a later time.

[amatkivskiy]

@alexandru-calinoiu yes, that sounds a nice solution.

Additionally I faced a situation when base use case returns all entities, but in one of the presenters where I want to use that use case I want to perform for example filtering or sorting.
My question is: what is the right way to implement this filtering(encapsulate this filtering in the use case, perform it after I'll receive results from use case)?

[alexandru-calinoiu]

I see 2 options in this case:

• if your source has the ability to do the sorting and filtering on the server side you should add that in the repo (for example an restfull api that has the ability to call page, sort and filter stuff)
• you can filter the data on the presenter side, if you find yourself manipulating the same data all over again maybe you can extract the common logic in a new use case.

[android10]

Use RxJava! You have many operators to compose observables:
https://github.com/ReactiveX/RxJava/wiki/Alphabetical-List-of-Observable-Operators

[amatkivskiy]

@android10 yep, but UseCase class doesn't provide access to the Observable directly.

[ghost]

@amatkivskiy it all depends from case to case but I see filtering of certain content as a domain or even data layer concern. Filtering is a data manipulation and If the filtering is only going to be perform in a really specific scenario, you could :

• Pass the filter selected to the domain layer as an init param to the use case and, as @android10 stated, use operators to perform the filtering of the data before passing it along the presentation layer.

Other consideration would be if this filtering has to be done in a global scale for the entire application scope. Then I would filter all content in the data layer (in the repositories), in order to make sure we are always manipulating the already filtered collection of items.

[amatkivskiy]

@jatago in my case I have a situation when one use case client wants all content as is, but another client want it to be sorted or filtered.

[jemshit]

@android10 as the guy said, UseCase#execute() does not return Observable, do you mean calling UseCase#buildUseCaseObservable() directly from outside?