Will store.purchase() always timeout/return in all cases?
That is can I be confident that I can leave my modal dialog with a spinner in place waiting for a response back from this call?
(doesn’t really say anything about this in the docs at http://docs.coronalabs.com/daily/api/library/store/purchase.html#store.purchase )
actually I think the scenario I saw when it seems to lock up was one where my ADSL internet modem connection died during the purchase…make any sense…definitely got stuck and wasn’t returning…
CoronaLabs - Any comment on whether there will be a response if the initial purchase outgoing request occurs, but then you lose internet connectivity after this? Will the Corona IAP API ensure there is a timeout? Seems like there isn’t one from what I’m seeing.
Whilst it might be a bit of an edge case, if it occurs the user would have to reset the app to recover. Should I be manually trying to put in a timeout somehow around the request? I’m also in test mode too, but I assume the apple API/interface shouldn’t be any different. Anyway just wanting to get a level of comfort that I can wait for a response with a modal dialog with spinner, and can rely on the Corona callback coming back in any case…
@Rob - wondering if you’ve seen this and could respond? just looking for a warm and fuzzy, before releasing an update, that there will be a call back you receive in general (i.e. and that what I saw from probably some unlikely edge case)
Brent/Rob (bump) - just a quick reply confirming would be great (for piece of mind)
actually I think the scenario I saw when it seems to lock up was one where my ADSL internet modem connection died during the purchase…make any sense…definitely got stuck and wasn’t returning…
CoronaLabs - Any comment on whether there will be a response if the initial purchase outgoing request occurs, but then you lose internet connectivity after this? Will the Corona IAP API ensure there is a timeout? Seems like there isn’t one from what I’m seeing.
Whilst it might be a bit of an edge case, if it occurs the user would have to reset the app to recover. Should I be manually trying to put in a timeout somehow around the request? I’m also in test mode too, but I assume the apple API/interface shouldn’t be any different. Anyway just wanting to get a level of comfort that I can wait for a response with a modal dialog with spinner, and can rely on the Corona callback coming back in any case…
@Rob - wondering if you’ve seen this and could respond? just looking for a warm and fuzzy, before releasing an update, that there will be a call back you receive in general (i.e. and that what I saw from probably some unlikely edge case)
Brent/Rob (bump) - just a quick reply confirming would be great (for piece of mind)
Rob/Brent/(others) - I think I may have an issue here…could you help clarify my previous question above?
I’ve noted I have some users who are not able to “restore” previous purchases, and looking back at my code I’m thinking it may be due to the timeout I’ve implemented (not sure). The relevant code lines are here (below).
Question :
Q1) should I take out the “timer” concept below altogether? (but if yes, what happens if there’s a network during the call - i.e. could the app get “stuck” on the IAP dialog box I show then?)
Q2) if I leave the timeout check, what timeout value? e.g. 30 seconds? (is there a built in timeout in the Corona implementation of IAP perhaps that will trigger and return a result after X seconds anyway back to our code?)
local TIMEOUT = 6000 -- ms -- Commence if action == "purchase" then myIAP:purchase( {iap\_identifier\_string} ) elseif action == "restore" then myIAP:restore() else error("Action not recognized: " .. action) end -- Start Timer timeoutTimer = timer.performWithDelay(TIMEOUT, function(event) updateDialogForResponse("Unsuccessful", "Nothing to Restore") end ) I would think that store.purchase() should always return, though there could be some odd network circumstances like loosing networking though I would think the network.request would eventually time out.
The problem that people need the timer for has to do with store.restore() isn’t guaranteed to call your listener if there is nothing to restore. I personally think most people can work around this by having the app locked until they get a successful restore and then only unlock when they get a positive response. But…
Any way, 6 seconds is kinda short. I would think in the 15-30 range would be more appropriate.
As a side note, when you ask Brent and me to be the ones to respond, the community is less likely to respond to you and frankly in this case, the community has much more experience with In app purchases that we do and you would be better served by their responses.
thanks Rob
Rob/Brent/(others) - I think I may have an issue here…could you help clarify my previous question above?
I’ve noted I have some users who are not able to “restore” previous purchases, and looking back at my code I’m thinking it may be due to the timeout I’ve implemented (not sure). The relevant code lines are here (below).
Question :
Q1) should I take out the “timer” concept below altogether? (but if yes, what happens if there’s a network during the call - i.e. could the app get “stuck” on the IAP dialog box I show then?)
Q2) if I leave the timeout check, what timeout value? e.g. 30 seconds? (is there a built in timeout in the Corona implementation of IAP perhaps that will trigger and return a result after X seconds anyway back to our code?)
local TIMEOUT = 6000 -- ms -- Commence if action == "purchase" then myIAP:purchase( {iap\_identifier\_string} ) elseif action == "restore" then myIAP:restore() else error("Action not recognized: " .. action) end -- Start Timer timeoutTimer = timer.performWithDelay(TIMEOUT, function(event) updateDialogForResponse("Unsuccessful", "Nothing to Restore") end ) I would think that store.purchase() should always return, though there could be some odd network circumstances like loosing networking though I would think the network.request would eventually time out.
The problem that people need the timer for has to do with store.restore() isn’t guaranteed to call your listener if there is nothing to restore. I personally think most people can work around this by having the app locked until they get a successful restore and then only unlock when they get a positive response. But…
Any way, 6 seconds is kinda short. I would think in the 15-30 range would be more appropriate.
As a side note, when you ask Brent and me to be the ones to respond, the community is less likely to respond to you and frankly in this case, the community has much more experience with In app purchases that we do and you would be better served by their responses.
thanks Rob