In-app purchases, how to know when store.restore is finished

I have an iOS app with a large number of non-consumable items.  Is there any way to know if the store.restore is finished?.  I could have the app wait for a fixed amount of time, but I don’t want the user restoring 2 iaps to wait for the same time as the user with 50 iaps (this is the way its set up now).  I know I could call store.restore when initializing, but this does not work with my app. Each iap item has 10 customizable pictures and I don’t want the user pictures to go anywhere; therefore if they restore they loose those pictures.

Any help is greatly appreciated.

You need to watch for that in the listener you pass to store.init()

https://docs.coronalabs.com/daily/guide/monetization/IAP/index.html#restoring-purchased-items

I may be wrong on this, but I don’t think you ever do get told that ‘this is the final restore callback’.  In fact, if there are no IAP’s to restore, you don’t even get told that - you just have to initiate your own timeout if you don’t receive a callback from store.restore().

Correct.  You only get call backs for items that were purchased.  Simply process them as if they were new.  Unlock what needs unlocked.  They are not used for consumables like coins and gems.  IAP requests should be treated like the Asynchronous events that they are.  Don’t wait for them to complete.  Go about your app’s business.  If you get an event, process it as part of the handler and let your app continue on it’s merry way.  If a level gets unlocked, set the flag that says it is, when you get to that part of your code where you need to know, check the flag in an if statement.

Rob

When I saw the first reply, I thought that the store.loadProducts listener would get which items had been purchased via event.product. I now know that this is not true.  I use the settings that are being restored to run the program so I guess my only option is to wait for a few seconds.

Thank you for all the replies.

People worry too much about this.  It’s only needed if people delete the app and then later re-install it.   It’s not going to happen that often.  If you’re app is able to process these in the background then the user will get their restores as they happen.  You don’t need to wait on the process to complete.  If you’re concerned, when the user hits the restore button, popup an alert saying “Restoring will happen in the background, it may take a few seconds to complete” to give them some expectations.

Rob

You need to watch for that in the listener you pass to store.init()

https://docs.coronalabs.com/daily/guide/monetization/IAP/index.html#restoring-purchased-items

I may be wrong on this, but I don’t think you ever do get told that ‘this is the final restore callback’.  In fact, if there are no IAP’s to restore, you don’t even get told that - you just have to initiate your own timeout if you don’t receive a callback from store.restore().

Correct.  You only get call backs for items that were purchased.  Simply process them as if they were new.  Unlock what needs unlocked.  They are not used for consumables like coins and gems.  IAP requests should be treated like the Asynchronous events that they are.  Don’t wait for them to complete.  Go about your app’s business.  If you get an event, process it as part of the handler and let your app continue on it’s merry way.  If a level gets unlocked, set the flag that says it is, when you get to that part of your code where you need to know, check the flag in an if statement.

Rob

When I saw the first reply, I thought that the store.loadProducts listener would get which items had been purchased via event.product. I now know that this is not true.  I use the settings that are being restored to run the program so I guess my only option is to wait for a few seconds.

Thank you for all the replies.

People worry too much about this.  It’s only needed if people delete the app and then later re-install it.   It’s not going to happen that often.  If you’re app is able to process these in the background then the user will get their restores as they happen.  You don’t need to wait on the process to complete.  If you’re concerned, when the user hits the restore button, popup an alert saying “Restoring will happen in the background, it may take a few seconds to complete” to give them some expectations.

Rob