2

This is an example app to demo a problem with nested fragments and wallet

https://github.com/zumper/WalletTest

Here is the structure of the app in terms of nesting

MainActivity
    |
    +-> TopLevelFragment
                |
                +-> NestedFragment
                        |
                        +-> SupportWalletFragment

The SupportWalletFragment is configured with a request code of 3333 via

  public static final int WALLET_REQUEST_CODE = 3333;

  ...

  WalletFragmentInitParams.Builder startParamsBuilder =
          WalletFragmentInitParams.newBuilder()
                  .setMaskedWalletRequest(generateMaskedWalletRequest("10.99"))
                  .setMaskedWalletRequestCode(WALLET_REQUEST_CODE);

But when the payment method is selected from the wallet activity the result is delivered via MainActivity.onActivityResult() with a request code value of 66036 and then to TopLevelFragment.onActivityResult() with a request code value of 500.

That's it. NestedFragment.onActivityResult() is never called with the expected request code of 3333

This problem seems to be a known issue:

http://blog.shamanland.com/2014/01/nested-fragments-for-result.html

https://code.google.com/p/android/issues/detail?id=40537

I can work around the problem in our real code by intercepting the onActivityResult() and relaying the params via event bus or something.

The tricky part is the fact that I don't even get the correct requestCode passed in... This makes all my hacks very brittle.

We have a fragment heavy application and I am unable to reduce the hierarchy more than I already have.

Are there other options for addressing this?

Vaibhav Mule
  • 5,016
  • 4
  • 35
  • 52
danb
  • 10,239
  • 14
  • 60
  • 76

1 Answers1

2

I have talked to google about this.. the answer is that there is no answer. If you are using SupportWalletFragment in a nested fragment situation, activity result propagation will not work (you need to handle it yourself) and your requestCode will not be honored for the MaskedWalletRequest (it will be honored for the FullWalletRequest).

If you are using native Fragments instead of support library Fragments, the requestCode will be honored but you will still need to deal with your own propagation.

We need to continue to use the support library.. So in our case, I am dealing with propagation of activity results manually, and I have set my requestCode to 500 to match the code I seem to get from the masked wallet response result. I think this is the best that can be done given the circumstances. I will update here if I get additional clarity.

danb
  • 10,239
  • 14
  • 60
  • 76
  • Thank you for the response danb. I am having the same problem. The only thing I am afraid about your solution is that you assume the generated requestCode will always be 500. I am not sure if we can assume that, but if it is working for you (and for your users) it might be safe then. Please update this if you find something else. – Bitcoin Cash - ADA enthusiast Feb 23 '16 at 22:48
  • The latest version of the support library (23.2) supposedly fixes some of these sorts of problems, but I have not yet confirmed. – danb Feb 25 '16 at 01:17
  • I am having this issue...I am trying `play-services-wallet:9.4.0` the issue seems to exist still. Has anyone also tried this? – Arst Aug 15 '16 at 03:09