-
Notifications
You must be signed in to change notification settings - Fork 450
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix to ensure restoreTransactions completion callback is called #150
base: master
Are you sure you want to change the base?
Conversation
…s always called in the case of duplicate updatedTransaction callbacks
I came up with the same solution ! 👍 |
I have been using this version locally and confirm works. |
@@ -2,7 +2,7 @@ Pod::Spec.new do |s| | |||
s.name = 'RMStore' | |||
s.version = '0.7.1' | |||
s.license = 'Apache 2.0' | |||
s.summary = 'A lightweight iOS library for In-App Purchases that adds blocks and notifications to StoreKit, plus verification, persistence and downloads.' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I remember having to shorten the description for some reason.
In any case, would you mind taking this change out of the PR?
Thanks for fixing this @seantb. Sorry it took so long to review. Would you mind taking out the style/code formatting changes out of the PR? |
Add a Gitter chat badge to README.md
…atting and added new lines where necessary.
hpique, when do you expect to pull Sean's change into the main line? |
Some of my customers are reporting that although they attempt to restore purchases from my Mac app, the app doesn't actually recognize their prior purchases. Should this change address that issue? Sent from my iPhone
|
…s always called in the case of duplicate updatedTransaction callbacks
…atting and added new lines where necessary.
# Conflicts: # RMStore/RMStore.m
Sorry for the delay. I fixed the conflicts. Please lemme know if I need to do anything else to allow this pull request to be merged. |
As single commit, as the original is messy.
…icts, etc., I'm adding these manually, so the actual commits are not part of the git history, unfortunately. However this list indicates the original PR number and the author. - Add robotmedia#138 by @protikhonov. - Add robotmedia#150 by @seantb. - Add robotmedia#175 by @metasmile
…media#150 Inside RMStore, when the paymentQueue:updatedTransactions is called after a restore, a pendingRestoredTransactions counter was incremented/decremented as transactions were processed. However, in our case updateTransactions callback was called twice, so 2x the amount of transactions were added to the pendingRestoredTransactions counter. The problem was the counter was incremented twice but only decremented once for each transaction. WHen the code reached notifyRestoreTransactionFinishedIfApplicableAfterTransaction, the counter was checked but was not equal to zero, so the callback wasn't called, even though all the transactions were processed. The fix was to use a MutableSet to store transaction identifiers that were pending restore, which prevents duplicate transactions to be handled. The callback is now always called after transactions are restored.
Inside RMStore, when the paymentQueue:updatedTransactions is called after a restore, a pendingRestoredTransactions counter was incremented/decremented as transactions were processed. However, in our case updateTransactions callback was called twice, so 2x the amount of transactions were added to the pendingRestoredTransactions counter. The problem was the counter was incremented twice but only decremented once for each transaction. WHen the code reached notifyRestoreTransactionFinishedIfApplicableAfterTransaction, the counter was checked but was not equal to zero, so the callback wasn't called, even though all the transactions were processed.
The fix was to use a MutableSet to store transaction identifiers that were pending restore, which prevents duplicate transactions to be handled. The callback is now always called after transactions are restored.