Building Windows 8 Apps with JavaScript: Working with In App Purchases
- Creating in-app Purchase Functionality
- Defining in-app Offers in the Store Submission Process
From the book
From the book
From the book
In the last few sections, we’ve talked about monetizing through ads, and moving your potential users to a sale by leveraging trial modes in your app. In this section, we’ll discuss the final piece of the app monetization puzzle, in-app purchases.
In-app purchases are a relatively new concept in the world of mobile and tablet apps, but they’ve proven wildly popular on other platforms, and Microsoft was wise to include them for Win8 style apps as well. Simply put, in-app purchases allow you, the developer, to sell app add-ons and features, or even physical products and services directly to users from within your app. For example, let's say I have a simple first-person shooter game. I can sell my game in a traditional fashion, or I can choose to offer the game for free, but sell character power-ups and weapons via in-app purchases. I could even choose to sell my game for a buck or two and offer in-app purchases. Similar to enabling trials in your app, in-app purchases allow users to try out what you have to offer, and “upgrade” their experience as they get hooked.
Creating in-app Purchase Functionality
In Win8, in-app purchases give you the benefit of being able to monetize products without directing the user to the store or external site, and users get the ease of being able to purchase products or add-ons quickly from within your app, and with the payment information already on file in their Windows account.
Let’s take a look at adding in-app purchase functionality to my Tom8to application. One feature that Tom8to offers is the ability to customize the alarm sound that plays at the end of a timer. Figure 13.24 shows the default list of alarms.
)
Figure 13.24 Alarm Sound settings for the Tom8to App
My initial list of alarms is good for getting started, but for users who like a little more variety, I can offer an in-app purchase that unlocks more sounds. The first step I need to take in defining an in-app purchase for local testing is to add information about the feature in the WindowsStoreProxy file, which we discussed at length in the trial-mode section:
<?xml version="1.0" encoding="utf-16" ?>
<CurrentApp>
<ListingInformation>
<App>
...
</App>
<Product ProductId="AlarmPack1" LicenseDuration="0">
<MarketData xml:lang="en-us">
<Name>Timer Alarm Add-on Pack</Name>
<Price>1.00</Price>
<CurrencySymbol>$</CurrencySymbol>
</MarketData>
</Product>
</ListingInformation>
<LicenseInformation>
<App>
...
</App>
<Product ProductId="AlarmPack1">
<IsActive>false</IsActive>
</Product>
</LicenseInformation>
</CurrentApp>
The two preceding sections in bold define your product, or in-app offering, and you’ll need to complete the information in both sections to test this functionality. First, you’ll define the product listing information, which includes the id, “AlarmPack1”, name and price information. The Id is used for store-tracking and management in your app, and is never shown to the user—they’ll see the name value—so be sure to use a terse, descriptive and unique id here. The LicenseDuration attribute can be used if you want to time-limit your in-app purchase. For example, for power-ups in a game that only last for a few days before being de-activated. Setting the value to zero indicates that the product is not time-limited.
Once I’ve added the test data, I can query the CurrentAppSimulator for information about the product.
var buyAlarmPack = document.querySelector('#buyAlarmPack');
var currentApp = Windows.ApplicationModel.Store.CurrentAppSimulator;
var licenseInfo = currentApp.licenseInformation;
if (!licenseInfo.productLicenses.lookup("AlarmPack1").isActive) {
// Code to wire-up the purchased product goes here
} else {
buyAlarmPack.disabled = true;
}
Using the same LicenseInformation object we worked with in the last section on trial-modes, I can call a lookup function on the productLicenses object to determine if the user owns an active license for my “AlarmPack1” offering. If they do, I’ll disable the “Alarm Pack” purchase button depicted in Figure 13.25. Otherwise, I’ll wire up the “Alarm Pack” button with product purchase functionality.
buyAlarmPack.addEventListener('click', function () {
currentApp.requestProductPurchaseAsync("AlarmPack1", true).done(
function (receipt) {
buyAlarmPack.disabled = true;
}, errorHandler);
});
function errorhandler() { ... }
When the user clicks on the button, I’ll call the requestProductPurchaseAsync method to contact the store and initiate the purchase UI for my app. At the time of writing, it’s not possible to locally simulate the in-app purchase experience from the user’s point-of-view[1]. Instead, the requestProductPurchaseAsync call will open a dialog window, as depicted in Figure 13.25.
)
Figure 13.25 The in-app purchase simulator dialog
With this dialog, I can simulate any of the possible outcomes of an in app purchase: success, user cancelation, general failure, etc. Once, I choose a code to return, my done handler will be called. Because my alarms are defined in a settings flyout that’s dismissed when the purchase is initiated, there’s not much I need to do immediately after purchase, other than to disable the purchase button. The real change occurs when the user re-opens the Settings Flyout after a purchase.
var alarms = [
{ name: "Arena Buzzer", value: "ArenaBuzzer" },
{ name: "Basic Alarm", value: "alarmRing", selected: "selected" },
{ name: "Boing", value: "boing" },
{ name: "Jazz Tune", value: "jazzTune" },
{ name: "Siren", value: "siren" }
]; //Existing alarms
var alarmPack = [
{ name: "Shouty Dubstep", value: "dubstep" },
{ name: "Wailing Baby", value: "wailingBaby" },
{ name: "Sinofsy", value: "steveSi" },
{ name: "R. Lee Ermey Yelling", value: "drillSergeant" }
];
function renderAlarmData() {
var alarmSound = document.querySelector('#alarmSound');
if (licenseInfo.productLicenses.lookup("AlarmPack1").isActive) {
alarms = alarms.concat(alarmPack);
}
addOptions(alarmSound, alarms);
}
function addOptions(selectList, data) {
var optionControl;
var optionTemplate = document.querySelector('#optionsTemplate');
if (optionsTemplate) {
optionControl = optionTemplate.winControl;
data.forEach(function (item) {
optionControl.render(item, selectList);
});
}
}
renderAlarmData();
First, I’ll define the sounds that make up my alarm pack, using the same format as the original alarms array. Then, in my renderAlarmData function, I’ll look up the information about my “AlarmPack1” offer to determine if the user now owns a license. If they do, I’ll add the alarms from the alarm pack to the original array and pass the new array off to the addOptions function, which applies each item in the array to a template that produces an <option> tag and adds the tag to a select element. The user will now see an extended list of alarm sounds, as in Figure 13.26.
)
Figure 13.26 Adding additional alarms via an in-app purchase
[1] To get an idea of what the in-app purchase experience will look like to your users, check out “The in-app purchase experience for a customer” in the Windows Dev Center (http://tinysells.com/225 - http://msdn.microsoft.com/en-us/library/windows/apps/hh924350.aspx)