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.