Kiedy należy używać RxJava Observable i kiedy proste Callback na Androida?

Obserwowalne rzeczy są już zrobione w Retrofit, więc kod może być taki:

api.getUserPhoto(photoId)
    .observeOn(AndroidSchedulers.mainThread())
    .subscribe(new Action1<Photo>() {
         @Override
            public void call(Photo photo) {
                //save photo?
            }
     });

W przypadku getUserPhoto() korzyści dla RxJava nie są wielkie. Ale weźmy inny przykład, gdy dostaniesz wszystkie zdjęcia dla użytkownika, ale tylko wtedy, gdy obraz jest PNG, a nie masz dostępu do JSON, aby zrobić filtrowanie na serwerze.

api.getUserPhotos(userId)
.subscribeOn(Schedulers.io())
.observeOn(AndroidSchedulers.mainThread())
.flatMap(new Func1<List<Photo>, Observable<Photo>>() {
    @Override
    public Observable<Photo> call(List<Photo> photos) {
         return Observable.from(photos);
    }
})
.filter(new Func1<Photo, Boolean>() {
    @Override
    public Boolean call(Photo photo) {
         return photo.isPNG();
    }
})
.subscribe(
    new Action1<Photo>() {
    @Override
        public void call(Photo photo) {
            // on main thread; callback for each photo, add them to a list or something.
            list.add(photo)
        }
    }, 
    new Action1<Throwable>() {
    @Override
        public void call(Throwable throwable) {
            // on main thread; something went wrong
            System.out.println("Error! " + throwable);
        }
    }, 
    new Action0() {
        @Override
        public void call() {
            // on main thread; all photo's loaded, time to show the list or something.
        }
    });

Teraz JSON zwraca listę zdjęć. będziemy flatMap je do poszczególnych elementów. W ten sposób będziemy mogli użyć metody filtrowania, aby zignorować zdjęcia, które nie są PNG. Następnie SUBSKRYBUJEMY i otrzymujemy oddzwonienie do każde pojedyncze zdjęcie, errorHandler i wywołanie zwrotne po zakończeniu wszystkich wierszy.

TLDR Punkt tutaj jest; zwrotne tylko zwraca ci zwrotne za sukces i porażkę; RxJava Observable pozwala zrobić mapę, zmniejszyć, filtr i wiele innych rzeczy.

Z rxjava możesz zrobić więcej rzeczy z mniejszą ilością kodu.

Załóżmy, że chcesz zaimplementować natychmiastowe wyszukiwanie w aplikacji. W przypadku połączeń zwrotnych, które martwią Cię o anulowanie poprzedniej prośby i subskrypcję nowej, zajmij się zmianą orientacji samodzielnie... Myślę, że to dużo kodu i zbyt gadatliwy.

Z rxjava jest bardzo proste.

public class PhotoModel{
  BehaviorSubject<Observable<Photo>> subject = BehaviorSubject.create(...);

  public void setUserId(String id){
   subject.onNext(Api.getUserPhoto(photoId));
  }

  public Observable<Photo> subscribeToPhoto(){
    return Observable.switchOnNext(subject);
  }
}

Jeśli chcesz zaimplementować instant search, wystarczy posłuchać TextChangeListener i zadzwonić do photoModel.setUserId(EditText.getText());

W onCreate metoda fragmentu lub aktywności subskrybujesz obserwowalny, który zwraca fotomodelę.subscribeToPhoto (), zwraca Obserwowalną, która zawsze emituje elementy emitowane przez najnowszą Obserwowalną (request).

AndroidObservable.bindFragment(this, photoModel.subscribeToPhoto())
                 .subscribe(new Action1<Photo>(Photo photo){
      //Here you always receive the response of the latest query to the server.
                  });

Ponadto, jeśli na przykład PhotoModel jest Singletonem, nie musisz się martwić o zmiany orientacji, ponieważ BehaviorSubject emituje ostatnią odpowiedź serwera, niezależnie od tego, kiedy subskrybujesz.

Dzięki tym liniom kodu zaimplementowaliśmy natychmiastowe wyszukiwanie i obsługa zmian orientacji. Czy uważasz, że możesz to zaimplementować za pomocą wywołań zwrotnych z mniejszą ilością kodu? Wątpię.

Wygląda na to, że odkrywasz koło na nowo, to, co robisz, jest już zaimplementowane w modernizacji.

Na przykład możesz spojrzeć na Retrofit ' s RestAdapterTest.java, Gdzie definiują interfejs z typem return, a następnie używają go.

Przez próbki i wnioski w innych odpowiedziach, myślę, że nie ma dużej różnicy dla prostych zadań jedno-lub dwuetapowych. Jednak oddzwanianie jest proste i proste. RxJava jest bardziej skomplikowana i zbyt duża na proste zadanie. Jest trzecie rozwiązanie przez: AbacusUtil . Pozwolę sobie zaimplementować powyższe przypadki użycia ze wszystkimi trzema rozwiązaniami: Callback, RxJava, CompletableFuture (AbacusUtil) z Retrolambda :

Pobierz zdjęcie z sieci i zapisz/Wyświetl na urządzenie:

// By Callback
api.getUserPhoto(userId, new Callback<Photo>() {
    @Override
    public void onResponse(Call<Photo> call, Response<Photo> response) {
        save(response.body()); // or update view on UI thread.
    }

    @Override
    public void onFailure(Call<Photo> call, Throwable t) {
        // show error message on UI or do something else.
    }
});

// By RxJava
api.getUserPhoto2(userId) //
        .observeOn(AndroidSchedulers.mainThread())
        .subscribe(photo -> {
            save(photo); // or update view on UI thread.
        }, error -> {
            // show error message on UI or do something else.
        });

// By Thread pool executor and CompletableFuture.
TPExecutor.execute(() -> api.getUserPhoto(userId))
        .thenRunOnUI((photo, error) -> {
            if (error != null) {
                // show error message on UI or do something else.
            } else {
                save(photo); // or update view on UI thread.
            }
        });

Załaduj dane użytkownika i zdjęcie równolegle

// By Callback
// ignored because it's little complicated

// By RxJava
Observable.zip(api.getUserDetails2(userId), api.getUserPhoto2(userId), (details, photo) -> Pair.of(details, photo))
        .subscribe(p -> {
            // Do your task.
        });

// By Thread pool executor and CompletableFuture.
TPExecutor.execute(() -> api.getUserDetails(userId))
          .runOnUIAfterBoth(TPExecutor.execute(() -> api.getUserPhoto(userId)), p -> {
    // Do your task
});

Zazwyczaj kierujemy się następującą logiką:

1. jeśli jest to proste połączenie jednej odpowiedzi, to Callback lub przyszłość jest lepsza.
2. jeśli jest to wywołanie z wieloma odpowiedziami (stream), lub gdy istnieją złożone interakcje między różnymi wywołaniami (zobacz odpowiedź @Niels' ), wtedy Obiekty obserwacyjne są lepsze.