Question

I am working on implementing in-app purchases and I am really torn about using a timeout method. It seems like it would be fine to timeout while loading the products from the store; but my concern is with using a timeout during purchasing. As part of my timeout, I think I would need to stop all processing, and I am afraid that this might be dangerous, especially because payments are concerned. But without a timeout, I am afraid that the user could be left hanging indefinitely; or, with a timeout that does not stop processing, the user could retry the process not knowing that there is a process still hanging around. I would appreciate some words of best-practices coding wisdom from anyone who has successfully implemented this feature in iOS.

To add some notes: I am using MKStoreKit; when I wrote the above question I had made it into a non-singleton (so as part of the timeout I was nullifying the store, which I decided was a bad idea). Now the store is a singleton and always around once instantiated. I am showing activity indicators when the products are loading, and on purchase/restore; the notifications received from these actions stop the activity indicator.

Everything works fine for me so far, but I am wondering, from those who have implemented, if you often find that you don't receive a notification, or don't receive one for a very long time. Basically, I am trying to figure out if I need to implement timeout timers for my StoreKit processes even though I receive notifications.

Was it helpful?

Solution

Never implement timeout functionality in In-App purchase. It is a bad approach because, the In-App purchase is taking time due to your network connection (Wi-fi) strength/speed and network load.

I had the same issue that my In-App purchase was taking a long time to complete.

I added a UIActivityIndicator for displaying that a process is taking place.

Displaying a UIActivityIndicator seemed very boring so I used MBProgressHUD and added some useful messages on it.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top