Send a canceled() confirm result in FawryActivity#onDestroy

[amk-stripe]

Summary

Send a canceled() confirm result in FawryActivity#onDestroy

Motivation

Properly handle the case where a user presses "back" to exit the FawryActivity

We could also handle this by trying to detect if ExternalPaymentMethodProxyActivity has been restarted, but any solution there seems pretty fragile and likely to have unintended impacts on a merchant's EPM implementation.

Screen recordings

Before:
You need to press back twice to get back into PS, and FlowController just totally freezes

epm.hangs.on.back.button.mp4

After:
You press back from the FawryActivity and wait ~.5 second for state to be restored

press.back.on.fawry.activity.mp4

Testing

• Added tests
• Modified tests
• Manually verified

[github-actions]

Diffuse output:

OLD: identity-example-release-base.apk (signature: V1, V2)
NEW: identity-example-release-pr.apk (signature: V1, V2)

          │          compressed          │         uncompressed         
          ├───────────┬───────────┬──────┼───────────┬───────────┬──────
 APK      │ old       │ new       │ diff │ old       │ new       │ diff 
──────────┼───────────┼───────────┼──────┼───────────┼───────────┼──────
      dex │     2 MiB │     2 MiB │  0 B │   4.3 MiB │   4.3 MiB │  0 B 
     arsc │     1 MiB │     1 MiB │  0 B │     1 MiB │     1 MiB │  0 B 
 manifest │   2.3 KiB │   2.3 KiB │  0 B │   8.1 KiB │   8.1 KiB │  0 B 
      res │ 301.5 KiB │ 301.5 KiB │  0 B │   455 KiB │   455 KiB │  0 B 
   native │   7.3 MiB │   7.3 MiB │  0 B │  18.4 MiB │  18.4 MiB │  0 B 
    asset │   1.5 MiB │   1.5 MiB │  0 B │   1.5 MiB │   1.5 MiB │  0 B 
    other │    87 KiB │    87 KiB │ -5 B │ 161.5 KiB │ 161.5 KiB │  0 B 
──────────┼───────────┼───────────┼──────┼───────────┼───────────┼──────
    total │  12.2 MiB │  12.2 MiB │ -5 B │  25.8 MiB │  25.8 MiB │  0 B 

 DEX     │ old   │ new   │ diff      
─────────┼───────┼───────┼───────────
   files │     1 │     1 │ 0         
 strings │ 21686 │ 21686 │ 0 (+0 -0) 
   types │  6869 │  6869 │ 0 (+0 -0) 
 classes │  5634 │  5634 │ 0 (+0 -0) 
 methods │ 31447 │ 31447 │ 0 (+0 -0) 
  fields │ 18315 │ 18315 │ 0 (+0 -0) 

 ARSC    │ old  │ new  │ diff 
─────────┼──────┼──────┼──────
 configs │  164 │  164 │  0   
 entries │ 3404 │ 3404 │  0

APK

   compressed    │   uncompressed   │                                           
──────────┬──────┼───────────┬──────┤                                           
 size     │ diff │ size      │ diff │ path                                      
──────────┼──────┼───────────┼──────┼───────────────────────────────────────────
 29.1 KiB │ -4 B │    64 KiB │  0 B │ ∆ META-INF/CERT.SF                        
    269 B │ -2 B │     120 B │  0 B │ ∆ META-INF/version-control-info.textproto 
  1.2 KiB │ +2 B │   1.2 KiB │  0 B │ ∆ META-INF/CERT.RSA                       
 25.9 KiB │ -1 B │  63.9 KiB │  0 B │ ∆ META-INF/MANIFEST.MF                    
──────────┼──────┼───────────┼──────┼───────────────────────────────────────────
 56.4 KiB │ -5 B │ 129.2 KiB │  0 B │ (total)

[jaynewstrom-stripe]

Should we assume it's cancelled if our external proxy activity sees onResume after launching the merchants EPM activity?

[amk-stripe]

I think that probably doesn't work if the merchant doesn't launch an activity in their external payment method implementation. Because then onResume() could also be called if a user were to exit the app and come back to it, right?

I thought about doing this and have a PR that does it, but I think it's fairly fragile/likely to not work well for all integrations. Definitely happy to discuss it though, this feels like an interesting problem

[jaynewstrom-stripe]

Makes sense. I agree. Thanks for considering!