Game Development Reference
In-Depth Information
}
} else {
[powerupButton setImage:[UIImage imageNamed:@"powerup_purchase"] forState:UIControlStateNormal];
}
}
In Listing 10-6, we see the task setGameParameters . This task is responsible for making the UI reflect
the state of the passed in GameParameters object called param . For the asteroidButton , we simply
indicate which image should be displayed depending on the value of the property includeAsteroids .
For saucerButton , we perform a similar test, but only if the product ID for the saucers is included in
the NSSet purchases . If the product ID is not present, we set the image on the button to display the
purchase version. We give the UIButton powerButton a similar treatment by setting the background
to be active, inactive, or purchase.
Making the Purchase
Now that we know how the button state is managed, let's look at how clicking one of the purchase
buttons triggers a purchase. Listing 10-7 shows the code that is run when a user presses the saucer
button.
Listing 10-7. ExtrasController.m (saucerButtonClicked:)
- (IBAction)saucerButtonClicked:(id)sender {
if ([gameParams.purchases containsObject:PURCHASE_INGAME_SAUCERS]){
[gameParams setIncludeSaucers:![gameParams includeSaucers]];
[self setGameParams:gameParams];
[gameParams writeToDefaults];
} else {
SKProduct* product = [idsToProducts objectForKey:PURCHASE_INGAME_SAUCERS];
SKPayment* payRequest = [SKPayment paymentWithProduct: product]; [[SKPaymentQueue defaultQueue]
addPayment:payRequest];
}
}
In Listing 10-7, we see the task saucerButtonClicked that is called when the user clicks the saucer
button. If we have already purchased the saucer feature, we know that the user is simply looking to
toggle if saucers are included. We respond to this by flipping the value of includeSaucers , updating
the UI by calling setGameParams , and writing the change to disk. If the user has not yet purchased the
saucer feature, we know he or she wants to make a purchase. To start this process, we retrieve our
SKProduct object from idsToProducts , and then we create an SKPayment object with that SKProduct .
Lastly, we add the SKPayment object to the default SKPaymentQueue . This triggers the dialog process,
as shown in Figure 10-7 . The code to manage the power-ups is almost identical to the code in
Listing 10-7, and it's not worth looking at. Next, let's look at how we respond to a successful
purchase.
 
Search WWH ::




Custom Search