android - Retrofit chaining observables -

i'm trying use retrofit rxjava. have problem chaining retrofit observables 1 or observables created me. example:

    observable<list<friend>> friendslistobservable = friendsservice.getfriends();     observable<void> updatereqestobservable = friendslistobservable.switchmap(friends -> {         log.d(tag, "hello");         return userapi.updatefriends(session.getuserid(), friends);     }).subscribe(); 

everything gets called until gets switchmap. hello never displayed, if return instance observable.just(null) instead of retrofit observable works fine. if user retrofit observable without chaining, works.

edit1: it's android app. seems map operator not called @ all. happens retrofit observables also. still think has threading. understand operator called when item emitted, calling onnext doesn't trigger map operator. below whole code:

public observable<list<facebookfriend>> getfriends() {     publishsubject<list<facebookfriend>> friendspublishsubject = publishsubject.create();      observable<list<facebookfriend>> returnobservable = friendspublishsubject.doonsubscribe(() -> {     log.d(tag, "onsubscribe called");     session session = session.getactivesession();      if (session != null && session.isopened()) {         new request(session, "/me/friends", null, httpmethod.get,                 new request.callback() {                     public void oncompleted(response response) {                         jsonobject graphresponse = response.getgraphobject()                                 .getinnerjsonobject();                         try {                             jsonarray friends = graphresponse.getjsonarray("data");                             gson gson = new gson();                             type listtype = new typetoken<arraylist<facebookfriend>>() {                             }.gettype();                             list<facebookfriend> friendslist = gson.fromjson(friends.tostring(), listtype);                              friendspublishsubject.onnext(friendslist);                             friendspublishsubject.oncompleted();                         } catch (jsonexception e) {                             e.printstacktrace();                             friendspublishsubject.onerror(e);                         }                     }                 }).executeasync();     } else {         invalidsessionexception exception = new invalidsessionexception("your facebook session expired");         friendspublishsubject.onerror(exception);     }     });      return returnobservable.subscribeon(androidschedulers.mainthread()).observeon(androidschedulers.mainthread()); }  public observable<void> updatefriendslist() {     observable<list<facebookfriend>> facebookfriendslistobservable = facebookservice.getfriends();      observable<void> updatereqestobservable = facebookfriendslistobservable.map(friends -> {     log.d(tag, "this never called"); }); 

}

one way around blocking @ actual calling point subscribe subject , block on subject @ end of whatever part of code requires requests have been executed.

for example:

final replaysubject<void> subject = replaysubject.create(); friendsservice.getfriends()     .switchmap(friends -> userapi.updatefriends(session.getuserid(), friends))     .subscribeon(schedulers.io())     .subscribe(subject);  // other things don't require done yet...  // wherever need wait request happen: subject.toblocking().singleordefault(null); 

since subject observable, return subject method, , block on later.

all being said, seem bit odd using update call side effect there. updatefriends retrofit service? if so, may want consider making update call synchronous service returns void instead of observable<void> call within onnext call. if still needs block, can use foreach this:

friendsservice.getfriends()     .foreach(friends -> { userapi.updatefriends(session.getuserid(), friends) }); 

foreach similar subscribe, except explicitly blocks. use original code, added empty onnext action wouldn't terribly clean.

if can provide more details app structure (is in main method? android app? etc.) give more pointers on avoiding blocking as possible.