CODEWITHSUNDEEP
androidkotlinrx-javarepository-pattern
Lenin
Lenin

Reputation: 2111

Editing data in repository pattern using RxJava

I'm refactoring the implementation of my repositories using RxJava so i want to know some ways to edit, for example, a user. My getUser(email: String), with email as id, is returning an observable and in the repository implementation i either get the data from database or server, all good by now.

What i want to achieve is editing a user. For that i would have and update(user: User) function, and the naive way to use it would be

userRepository.getUser(email)
   .subscribeOn(Schedulers.io())
   .subscribe { user ->
      user.name = "antoher name"
      userRepository.update(user)
         .subscribeOn(Schedulers.io())
         .subscribe {
             //handle response
         }
    }

Is there a way to avoid this type of call of an observer inside an observer? It is not very readable for me and i guess there's a better way but i'm not getting it.

NOTE: I'm using clean architecture, so i think an update for every field, making me get user in data module is not correct as i would have subscribe to an observer in data, and that difficult the dispose when activity destroys

For me is not the same question as When do you use map vs flatMap in RxJava? because, despite of flatMap being the thing that answer the question, it is not the same question, so anyone who has the same problem/question but don't know that flatmap is the answer, will never reach to use flatmap.

Upvotes: 0

Views: 499

Answers (1)

CoderSpinoza
CoderSpinoza

Reputation: 2165

One strength of using RxJava is that you can chain as many async operations (method that would return Observable or Single, repository methods in your case) as you want without falling into callback hells. You see in your code that there are nested subscribe blocks. What if you had to chain more async network operations? You fall into callback hells and the code will become harder to follow and maintain.

Removing nested callbacks and making code more functional, compositional, and readable is one thing RxJava is really good at. In the intro part of ReactiveX website , they mention about this in the intro part of ReactiveX website (http://reactivex.io/intro.html).

Callbacks solve the problem of premature blocking on Future.get() by not allowing anything to block. They are naturally efficient because they execute when the response is ready.

But as with Futures, while callbacks are easy to use with a single level of asynchronous execution, with nested composition they become unwieldy.

Flatmap operator is to the rescue here. You can look into the definition of flatMap operator in the link below.

http://reactivex.io/documentation/operators/flatmap.html

Below is the code I would use in your case.

userRepository.getUser(email)
   .subscribeOn(Schedulers.io())
   .map { user -> user.name = "another name"; return user; }
   .flatMap { user -> userRepository.update(user) }
   .doOnSuccess { /* handle response here */ } // doOnNext if you are using observable
   .subscribe({ /* or handle response here */ }, { /* must handle error here */})

Flatmap operator flattens Single of update response which will be returned by your repository's update method and pass just the response downstream. Above code is not only easier to read but also makes your code reusable because update logic is now part of the chain.

Distinguishing between map and flatMap is really important in exploiting the full benefit of RxJava so it will be really beneficial to get used to it!

Upvotes: 2

Related Questions