Add manual transaction finish, getPendingPurchases

[lunarraid]

This is a breaking change that requires InAppUtils.purchaseFinish to be called to finalize a transaction, where before this was called automatically prior to the purchaseProduct callback being fired. The method getPendingPurchases to retrieve all unfinished transactions has also been added.

[Jacse]

Awesome work @lunarraid.

So one would typically call getPendingPurchases on app launch to finalize the delivery of any outstanding purchases, correct?

I think the readme should be updated to show this function and use-case.

[superandrew213]

What is the status on this?

[lunarraid]

I have been swamped with other projects and unable to look into this. If anyone else wants to take up the task of adding the requested documentation, feel free, since it may be a bit before I look at it.

[fluiddot]

Nice work @lunarraid! This feature is really a must for in app purchases, it would be awesome to have this PR merged. 🙏

[lunarraid]

@chirag04 I have updated the readme with an example for getPendingPurchases().

[Jacse]

Awesome, @lunarraid 👏

[unao]

Tried it but got this critical error:

Exception '*** -[__NSPlaceholderDictionary initWithObjects:forKeys:count:]: attempt to insert nil object from objects[3]' was thrown while invoking getPendingPurchases on target InAppUtils with params (
    231
)
callstack: (
    0   CoreFoundation                      0x00000001812e637c <redacted> + 148
    1   libobjc.A.dylib                     0x000000018052c528 objc_exception_throw + 56
    2   CoreFoundation                      0x000000018127ee9c _CFArgv + 0
    3   CoreFoundation                      0x00000001811b71d0 <redacted> + 352
    4   CoreFoundation                      0x00000001811b704c <redacted> + 64
    5   GetFinicky                          0x00000001013c7cd8 -[InAppUtils getPendingPurchases:] + 932
    6   CoreFoundation                      0x00000001812edcd0 <redacted> + 144
    7   CoreFoundation                      0x00000001811cc56c <redacted> + 292
    8   CoreFoundation                      0x00000001811d101c <redacted> + 60
    9   GetFinicky                          0x000000010120461c -[RCTModuleMethod invokeWithBridge:module:arguments:] + 2064
    10  GetFinicky                          0x0000000101297a50 _ZN8facebook5reactL11invokeInnerEP9RCTBridgeP13RCTModuleDatajRKN5folly7dynamicE + 664
    11  GetFinicky                          0x00000001012975e0 _ZZN8facebook5react15RCTNativeModule6invokeEjON5folly7dynamicEiENK3$_0clEv + 132
    12  GetFinicky                          0x0000000101297550 ___ZN8facebook5react15RCTNativeModule6invokeEjON5folly7dynamicEi_block_invoke + 28
    13  libdispatch.dylib                   0x0000000180c62a54 <redacted> + 24
    14  libdispatch.dylib                   0x0000000180c62a14 <redacted> + 16
    15  libdispatch.dylib                   0x0000000180c6f698 <redacted> + 1016
    16  CoreFoundation                      0x000000018128e544 <redacted> + 12
    17  CoreFoundation                      0x000000018128c120 <redacted> + 2012
    18  CoreFoundation                      0x00000001811abe58 CFRunLoopRunSpecific + 436
    19  GraphicsServices                    0x0000000183058f84 GSEventRunModal + 100
    20  UIKit                               0x000000018a90067c UIApplicationMain + 236
    21  GetFinicky                          0x0000000100fcbc10 main + 124
    22  libdyld.dylib                       0x0000000180cc856c <redacted> + 4

[unao]

Was trying to figure out it on my own, but I am not very familiar with debugging ObjC and in-app purchases sdk. The error basically kills the application.

@lunarraid any ideas what may cause it? did you see something similar on your end? may it be due to sandbox environment?

[lunarraid]

We're running this in production code right now without issue, so it is probably some permutation of environment-specific settings, target platform, etc. Has anyone else here run into this? I'm uncertain of how to reproduce this state.

[unao]

@lunarraid thank you for letting me know - good to know it is used in production, will update once/if figured out the real cause.

[yusufyildirim]

@lunarraid We are using almost same code in the production too, without issue.

[idris]

@chirag04 can this get merged? The library without this is really wrong, and causes problems because the transaction gets finished before the app confirms that processed it.

[yusufyildirim]

@idris You're totally right but forget the merge and just use forks which already merged this pr 😄 Mine is working that way but I made extra small changes

[idris]

I think this should be combined with #128 to create a proper API. My suggestion for the API is as follows:

• Purchase events should be sent to JS via EventEmitter
• JS is responsible for calling finishTransaction when it receives a purchase event (after processing/consuming the purchase)
• Keep JS promises (or callbacks) in place for purchaseProduct, but you don't need to call finishTransaction from there, because instead it will be called from the event handler.

One piece of functionality this allows, which the current PR does not, is if a purchase is initiated somewhere else in the app, for example from a native library.

I'm happy to help implement if we think this is the right direction.

[lunarraid]

@unao I finally ran into the issue you were mentioning. It happens if you have transactions in the queue that are retries of previous transactions and thus don't include certain pieces of data. I have updated my PR to address this edge case.