当前位置: 首页 > 面试题库 >

RXJava2:正确的模式以链接改造请求

陶胤
2023-03-14
问题内容

一般而言,我对RXJava相对较新(真的只是开始将其与RXJava2一起使用),而且我能找到的大多数文档都倾向于RXJava1。我现在通常可以在两者之间进行翻译,但是整个Reactive的内容是如此之大,以至于它是一个压倒性的API,具有很好的文档(当您可以找到它时)。我正在尝试简化我的代码,这是我想用婴儿的脚步做到的。我要解决的第一个问题是我在当前项目中做的很多工作:

您有一个请求,如果成功,将用于发出第二个请求。

如果任何一个失败,则您需要能够确定哪个失败了。(主要是显示自定义UI警报)。

这是我现在通常的做法:

.subscribeOn/observeOn为简单起见,省略了)

Single<FirstResponse> first = retrofitService.getSomething();

first
   .subscribeWith(
     new DisposableSingleObserver<FirstResponse>() {
         @Override
         public void onSuccess(final FirstResponse firstResponse) {

               // If FirstResponse is OK…
                Single<SecondResponse> second = 
                 retrofitService
                    .getSecondResponse(firstResponse.id) //value from 1st
                    .subscribeWith(
                      new DisposableSingleObserver<SecondResponse>() {

                           @Override
                           public void onSuccess(final SecondResponse secondResponse) {
                              // we're done with both!
                           }

                           @Override
                            public void onError(final Throwable error) {
                            //2nd request Failed, 
                            }                        
                     });

         }

         @Override
         public void onError(final Throwable error) {
              //firstRequest Failed, 
         }
      });

在RXJava2中是否有更好的方法来解决此问题?

我已经尝试过flatMap和变体,甚至一个Single.zip或类似的,但我不确定要解决这个问题最简单,最常见的模式是什么。

如果您想知道FirstRequest是否会在SecondRequest中获取实际Token的需求。没有令牌,无法再次发出请求。


问题答案:

我建议使用平面地图(如果可以的话,也可以使用retrolambda)。另外,Single<FirstResponse> first如果您不对返回值进行任何操作,则无需保留返回值(例如)。

retrofitService.getSomething()
    .flatMap(firstResponse -> retrofitService.getSecondResponse(firstResponse.id)
    .subscribeWith(new DisposableSingleObserver<SecondResponse>() {
         @Override
         public void onSuccess(final SecondResponse secondResponse) {
            // we're done with both!
         }

         @Override
          public void onError(final Throwable error) {
             // a request request Failed, 
          }                        
   });

这文章让我觉得通过我如何总体结构RxJava风格。如果可能的话,您希望您的链条是高级操作的列表,以便可以将其理解为一系列操作/转换。

编辑 没有lambdas,您可以只Func1为您的flatMap使用。做同样的事情只是增加了很多样板代码。

retrofitService.getSomething()
    .flatMap(new Func1<FirstResponse, Observable<SecondResponse> {
        public void Observable<SecondResponse> call(FirstResponse firstResponse) {
            return retrofitService.getSecondResponse(firstResponse.id)
        }
    })
    .subscribeWith(new DisposableSingleObserver<SecondResponse>() {
         @Override
         public void onSuccess(final SecondResponse secondResponse) {
            // we're done with both!
         }

         @Override
          public void onError(final Throwable error) {
             // a request request Failed, 
          }                        
   });


 类似资料:
  • 我正在尝试从使用普通改型迁移到使用RxJava扩展进行改型,以便在后台线程上进行API调用链。 例如,我有一个名为ModelGroup的对象,它有一个ModelPerson对象列表。我的目标是做到以下几点。 将ModelGroup发送到服务器并接收一个响应,它是一个整数,表示新插入的ID,我们称之为newGroupId 对于ModelGroup中的每个ModelPerson,设置Person。gr

  • 所以基本上我想做的是,打第一个网络电话。如果调用的RESTful web服务返回1,则进行第二次网络调用。如果web服务返回0,则不要进行第二次网络调用。 这是我的密码 显然,上面的代码是错误的,因为它应该总是返回可观察的。那么,如果第一次网络调用返回0,我的代码应该如何编写?

  • 16.4 纯与不纯的职责链模式 职责链模式可分为纯的职责链模式和不纯的职责链模式两种:          (1) 纯的职责链模式 一个纯的职责链模式要求一个具体处理者对象只能在两个行为中选择一个:要么承担全部责任,要么将责任推给下家,不允许出现某一个具体处理者对象在承担了一部分或全部责任后又将责任向下传递的情况。而且在纯的职责链模式中,要求一个请求必须被某一个处理者对象所接收,不能出现某个请求未被

  • 16.3 完整解决方案 为了让采购单的审批流程更加灵活,并实现采购单的链式传递和处理,Sunny公司开发人员使用职责链模式来实现采购单的分级审批,其基本结构如图16-3所示:        在图16-3中,抽象类Approver充当抽象处理者(抽象传递者),Director、VicePresident、President和Congress充当具体处理者(具体传递者),PurchaseRequest

  • 16.2 职责链模式概述 很多情况下,在一个软件系统中可以处理某个请求的对象不止一个,例如SCM系统中的采购单审批,主任、副董事长、董事长和董事会都可以处理采购单,他们可以构成一条处理采购单的链式结构,采购单沿着这条链进行传递,这条链就称为职责链。职责链可以是一条直线、一个环或者一个树形结构,最常见的职责链是直线型,即沿着一条单向的链来传递请求。链上的每一个对象都是请求处理者,职责链模式可以将请求

  • “一对二”,“过”,“过”……这声音熟悉吗?你会想到什么?对!纸牌。在类似“斗地主”这样的纸牌游戏中,某人出牌给他的下家,下家看看手中的牌,如果要不起上家的牌则将出牌请求再转发给他的下家,其下家再进行判断。一个循环下来,如果其他人都要不起该牌,则最初的出牌者可以打出新的牌。在这个过程中,牌作为一个请求沿着一条链在传递,每一位纸牌的玩家都可以处理该请求。在设计模式中,我们也有一种专门用于处理这种请求