Skip to content
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

Open
wants to merge 21 commits into
base: master
Choose a base branch
from

Conversation

SeanBlahovici
Copy link

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.

@aplourde
Copy link

I came up with the same solution ! 👍

@fulldecent
Copy link

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.'
Copy link
Member

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?

@hpique
Copy link
Member

hpique commented Jan 3, 2016

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?

@DonaldLawton
Copy link

hpique, when do you expect to pull Sean's change into the main line?

@hpique
Copy link
Member

hpique commented Jan 16, 2016

@dlawton @seantb If I could merge the request from GitHub it'd been in already. I get "This branch has conflicts that must be resolved" though.

Can try to do this manually later this month as I'm abroad right now.

@DonaldLawton
Copy link

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

On Jan 16, 2016, at 10:11 AM, Hermes Pique [email protected] wrote:

@dlawton @seantb If I could merge the request from GitHub it'd been in already. I get "This branch has conflicts that must be resolved" though.

Can try to do this manually later this month as I'm abroad right now.


Reply to this email directly or view it on GitHub.

@SeanBlahovici
Copy link
Author

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.

milancermak pushed a commit to 8fit/RMStore that referenced this pull request Aug 18, 2016
As single commit, as the original is messy.
balthisar added a commit to balthisar/RMStore that referenced this pull request Dec 24, 2019
…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
everappz added a commit to everappz/RMStore that referenced this pull request Mar 24, 2024
…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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants