Differences
This shows you the differences between the selected revision and the current
version of the page.
| wmelite:iap_guide 2011/07/30 17:43 | wmelite:iap_guide 2013/05/15 19:34 current | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | ====== In app purchases guide ====== | + | ====== In app purchases guide (iOS only) ====== |
| Starting with iOS 3.0, the users can purchase "products" directly from applications. This technology is called "in app purchases". These products can be of three types: | Starting with iOS 3.0, the users can purchase "products" directly from applications. This technology is called "in app purchases". These products can be of three types: | ||
| Line 8: | Line 8: | ||
| WME Lite supports purchases of **non-consumable** products. | WME Lite supports purchases of **non-consumable** products. | ||
| + | |||
| Line 15: | Line 16: | ||
| A few important notes: | A few important notes: | ||
| - | + | ||
| * After you define products in iTunes Connect it takes some time before they are accessible to your app. | * After you define products in iTunes Connect it takes some time before they are accessible to your app. | ||
| * In app purchases must be tested on the actual device. They don't work in iOS simulator. | * In app purchases must be tested on the actual device. They don't work in iOS simulator. | ||
| Line 39: | Line 40: | ||
| } | } | ||
| </code> | </code> | ||
| + | |||
| Line 69: | Line 71: | ||
| on "ProductsValidated" | on "ProductsValidated" | ||
| { | { | ||
| - | // products are now validated, display purchase GUI | + | // products are now validated, display purchase GUI |
| } | } | ||
| Line 99: | Line 101: | ||
| } | } | ||
| </code> | </code> | ||
| + | |||
| Line 109: | Line 112: | ||
| </code> | </code> | ||
| - | Once again, this methos is asynchronous. You trigger the purchase and then you need to wait for a transaction event (see below). Again, you may want to display some waiting animation and a cancel button while the purchase is in progress. | + | Once again, this method is asynchronous. You trigger the purchase and then you need to wait for a transaction event (see below). Again, you may want to display some waiting animation and a cancel button while the purchase is in progress. |
| + | |||
| Line 125: | Line 130: | ||
| Since in iOS the application can be terminated at any moment (incoming call etc.), there may be pending transactions (App Store initiated the transaction but the application didn't have a chance to confirm it). App Store will re-send any pending transactions immediately after the application calls Store.EnableEvents(). For that reason you should call it immediately when the game starts, in game.script, and this script should be able to handle transactions. That way even if the game quits before confirming a transaction, the purchase will be finalized immediately after the user restars the game. | Since in iOS the application can be terminated at any moment (incoming call etc.), there may be pending transactions (App Store initiated the transaction but the application didn't have a chance to confirm it). App Store will re-send any pending transactions immediately after the application calls Store.EnableEvents(). For that reason you should call it immediately when the game starts, in game.script, and this script should be able to handle transactions. That way even if the game quits before confirming a transaction, the purchase will be finalized immediately after the user restars the game. | ||
| - | Whenever App Store sends a transaction form confirmation, a "TransactionsUpdated" event is triggered in the script that last called Store.EnableEvents(). The game can then access all pending transactions like this: | + | Whenever App Store sends a transaction for confirmation, a "TransactionsUpdated" event is triggered in the script that last called Store.EnableEvents(). The game can then access all pending transactions like this: |
| Line 140: | Line 145: | ||
| </code> | </code> | ||
| - | As you can see, teach transaction has a unique ID, an ID of the purchased product, and a state. Use the state to decide what to do about the transaction. The state can be one of the following strings: | + | As you can see, each transaction has a unique ID, an ID of the purchased product, and a state. Use the state to decide what to do about the transaction. The state can be one of the following strings: |
| * **purchased** - the transaction was successful and the product was purchased | * **purchased** - the transaction was successful and the product was purchased | ||
| Line 179: | Line 184: | ||
| } | } | ||
| </code> | </code> | ||
| + | |||
| Line 185: | Line 191: | ||
| Since the users can uninstall and reinstall games, or buy new devices, they must be able to restore previous purchases. Use the Store.RestoreTransactions() method to ask App Store to re-send all previously completed transactions. These transactions (if any) will be added to the list of transactions with the "restored" state (see above). | Since the users can uninstall and reinstall games, or buy new devices, they must be able to restore previous purchases. Use the Store.RestoreTransactions() method to ask App Store to re-send all previously completed transactions. These transactions (if any) will be added to the list of transactions with the "restored" state (see above). | ||
| - | Just like the other communication methods, this one is anynchronous. You request the restored transactions and then you wait for events. In this case, the script Store.RestoreTransactions() will receive either the "TransactionsRestoreFinished" event or the "TransactionsRestoreFailed" event. | + | Just like the other communication methods, this one is anynchronous. You request the restored transactions and then you wait for events. In this case, the script which called Store.RestoreTransactions() will receive either the "TransactionsRestoreFinished" event or the "TransactionsRestoreFailed" event. |
| Line 207: | Line 213: | ||
| } | } | ||
| </code> | </code> | ||
| + | |||
| ===== Unlocking functionality ===== | ===== Unlocking functionality ===== | ||
| - | Once the product is purchased, you should store this information somewhere locally (it would me impractical to connect to App Store all the time). WME Lite provides two convenience methods: Store.UnlockProduct() and Store.IsProductUnlocked(). Both accept a product ID as a parameter. | + | Once the product is purchased, you should store this information somewhere locally (it would be impractical to connect to App Store all the time). WME Lite provides two convenience methods: Store.UnlockProduct() and Store.IsProductUnlocked(). Both accept a product ID as a parameter. |
| When you are handling the "purchased" or "restored" transaction, you can call Store.UnlockProduct() to save the information about the purchase. In your game, just use the Store.IsProductUnlocked() to check if the user has purchased some functionality. If yes, let them continue playing, if not, display some purchase GUI and offer them to buy the functionality. | When you are handling the "purchased" or "restored" transaction, you can call Store.UnlockProduct() to save the information about the purchase. In your game, just use the Store.IsProductUnlocked() to check if the user has purchased some functionality. If yes, let them continue playing, if not, display some purchase GUI and offer them to buy the functionality. | ||
