OK then. I’m a happy camper
I’ll adjust my IAP logic to reflect this.
Thanks,
Ingemar
OK then. I’m a happy camper
I’ll adjust my IAP logic to reflect this.
Thanks,
Ingemar
Do we have to call store.finishTransaction( trans ) for the “revoked” event ?
Hi ubj3d.android
According to the documentation "
You never _need _to call finishTransaction while using the Amazon IAP plugin
Thank you for the fast answer!
Can I leave the call to store.finishTransaction( trans ) (using same code for Apple) ? Can it hurt?
Also, I am a bit confused with receiving the revoked and restored event for the same item.
Would be great if revoked is only triggered if the item is really revoked.
Is the revoked event always triggered before restore ?
Yes, you can leave the call there. It is left in so that you don’t have to conditionally call it depending on the store you are using.
As for your other question: Please review the thread we are in as it is the best explanation I know of
I agree it is confusing, but this is how the native Amazon IAP SDK for Android works. If you get both revoked and restored, then ignore the revoked message. This means that the item was revoked and purchased again. This is a situation that will be very, very rare in practice(how often do you think someone will buy an IAP item, call Amazon to have it refunded, and then buy it again?)
You said
“There is a possible modification to the plugin that could be made: the
plugin could send ‘revoked’ events before ‘restore’ events.”
That is why I am asking if the revoked is triggered before restore.
Not sure if it is implemented or not.
Thank you very much for your help.
Regards,
Damir.
Hi ubj3d.android,
Sorry I did not pay close enough attention to your actual question!
Unfortunately this change has not been implemented
OK, so we have 2 scenarios:
first “restore” then “revoked”
first “revoked” then “restore”
Coding case 1)
* as soon as I receive “restore”, I can ignore “revoked”.
Coding case 2)
* after receiving “revoked” wait a bit (question is how long?) and if there is no “restore” event then make “revoke” action (e.g. lock again a level)
Is that logic OK ?
Yes I believe this will work, but it is a little tricky to advise you on how long to wait because of the asynchronous nature of the Amazon IAP SDK for Android
Coding case 1)
Coding case 2)
That’s how I’ve implemented my code. I’ve found during my testing that the callbacks always arrive one-after-another in very short succession. I’ve set a time-out of 10 seconds (which is waaay longer than necessary) but just to be on the safe side…
Do we have to call store.finishTransaction( trans ) for the “revoked” event ?
Hi ubj3d.android
According to the documentation "
You never _need _to call finishTransaction while using the Amazon IAP plugin
Thank you for the fast answer!
Can I leave the call to store.finishTransaction( trans ) (using same code for Apple) ? Can it hurt?
Also, I am a bit confused with receiving the revoked and restored event for the same item.
Would be great if revoked is only triggered if the item is really revoked.
Is the revoked event always triggered before restore ?
Yes, you can leave the call there. It is left in so that you don’t have to conditionally call it depending on the store you are using.
As for your other question: Please review the thread we are in as it is the best explanation I know of
I agree it is confusing, but this is how the native Amazon IAP SDK for Android works. If you get both revoked and restored, then ignore the revoked message. This means that the item was revoked and purchased again. This is a situation that will be very, very rare in practice(how often do you think someone will buy an IAP item, call Amazon to have it refunded, and then buy it again?)
You said
“There is a possible modification to the plugin that could be made: the
plugin could send ‘revoked’ events before ‘restore’ events.”
That is why I am asking if the revoked is triggered before restore.
Not sure if it is implemented or not.
Thank you very much for your help.
Regards,
Damir.
Hi ubj3d.android,
Sorry I did not pay close enough attention to your actual question!
Unfortunately this change has not been implemented
OK, so we have 2 scenarios:
first “restore” then “revoked”
first “revoked” then “restore”
Coding case 1)
* as soon as I receive “restore”, I can ignore “revoked”.
Coding case 2)
* after receiving “revoked” wait a bit (question is how long?) and if there is no “restore” event then make “revoke” action (e.g. lock again a level)
Is that logic OK ?
Yes I believe this will work, but it is a little tricky to advise you on how long to wait because of the asynchronous nature of the Amazon IAP SDK for Android
Coding case 1)
Coding case 2)
That’s how I’ve implemented my code. I’ve found during my testing that the callbacks always arrive one-after-another in very short succession. I’ve set a time-out of 10 seconds (which is waaay longer than necessary) but just to be on the safe side…