Posts

Implementing In-App purchases in your NativeScript application (Part 3)

After I showed you how to create a simple NativeScript application that implements in-app workflow using the nativescript-purchase plugin and how to set up and sandbox test the workflow on iOS. Now it is time to do same thing on Android.

Preliminary Notes

Before we start you must understand that if you want to test the full workflow you will either need a physical Android device, or your emulator must have the full-blown Google Play services installed (with the Play Store and other stuff). So you cannot test this on the stock Android emulator that comes with Android SDK. This is because the in-app purchase services extensively use the play store to communicate with Google’s services.

Also I’m assuming that your Google account (the one with which you publish your app) is set up as a merchant account, which is needed if you want to use in-app purchases. If it is not you can take a look at this help article on how to set it up.

Set up test accounts

The first step we will take is to add which Google accounts will be able to sandbox test the purchases in our app. In order to do so you must go to the Google Play Console->Settings->Developer account->Account details. Scroll down to the License Testing section and in the field add as a comma-separated value the Google Accounts that will be treated as sandbox test users.

NB: Those accounts are considered sandbox purchase testers for ALL applications that are published through your Google Play developer account.

Create and set up the application in Google Play console

Next we should add our application to the Google Play developer console. I will not go in details on how you create it as there is nothing special compared to creating a normal application. Just make sure you fill in all the needed details (like screenshots, feature graphic, icons, etc.) as unlike iOS for Android we will actually need to publish our app. You will also need to upload your binary. Since my demo app does not do anything, I will be uploading it to the Alpha release with a closed Alpha testing so it is not public on the store.
Once you have created the application, before we publish it we need to add our in-app products. So lets head over to the In-app products section in the Google Play console and add our first product

Remember that for now the nativescript-purchase plugin does not support subscriptions so make sure you select the Managed Product option and also make sure you type the exact same product id we have set up in the initialization of the purchase plugin: org.nativescript.purchasesample.product1. Next is to set up the product details and pricing (I’m using the same description as for iOS):

Once you save this product remember to make it active via the drop down next to the save! 🙂
We repeat the above procedure for the second product org.nativescript.purchasesample.product2. Although this is our consumable product for Android there is no set up difference between the two like it was for iOS. The consuming is done in our NativeScript code. After you add the second product, your in-app product listing should look similar to this:

Now we are ready to publish our application! Note that it can take up to several hours for the application and in-app products to be published to Google Play, so we must wait for this to happen, before we can test it.

Sandbox testing purchases

Once the application is in Published status we can start our testing. Note that if you used a closed Alpha testing option you need to go to the Releases menu and open the Opt-in URL with the accounts which you assigned as testers.

NB: You cannot sandbox test purchases by deploying your app via tns run android or by any other means. You NEED to install the application from the Google Play store.

Now lets head over to the Play Store and find our app. Make sure you are signed in on the device with the same tester account you have added as a license test user at the start. In my experience it is sometimes very difficult to find the app in the store via search as it takes some additional time after publishing for Google to correctly update their index. So it might be best to just open the play store listing for the app directly by opening the following Url in the device’s browser: https://play.google.com/store/apps/details?id=<PACKAGE ID>

So lets install and open it. If everything is done correctly you should see a similar to the iOS listing of the products we have added:

If you tap on a product you will be presented with the popup to confirm your purchase. Take note of the bold line below the price that indicates that this is a sandbox purchase and that your credit card will not be charged.

Once you confirm the purchase you will get a notification that the it was successfully!

NB: You cannot use the same developer Google account that published the app for testing. You must set up and use another Google account for sandbox purchases.

Wrapping it up

As you can see testing on Android is a little bit harder than on iOS, especially if you want to debug something. This is due to the fact that you need to upload your APK to the Play Store, wait for the update to be published and then download it to the device. This makes it really difficult to iron out any bugs or trace problems. That’s why my personal recommendation is to first implement and thoroughly test your workflow and logic on iOS. Once you are sure it is working flawlessly then move to test it on Android.

Implementing In-App purchases in your NativeScript application (Part 2)

In the previous part I’ve shown you how to create a small NativeScript application and add a simple purchase workflow using the nativescript-purchase plugin. Now it is time to wire things for iOS. In this part I will guide through adding the necessary settings on the Apple Developer portal and iTunes Connect, create some sandbox users and test your workflow.

Creating an App ID

The first thing we need to do is register a new App ID in the Apple Developer portal. We do this in the “Certificates, IDs & Profiles” menu, then “App IDs” and click on the “plus” button on the top right. For the App ID, you can select whatever description you want. For the App ID Suffix you must select Explicit App ID and type exactly the name as it is present in the package.json file nativescript section the id attribute. In my case this is org.nativescript.purchasesample. And we need to use Explicit App ID, because wildcard App IDs do not support in-app purcahses.
App ID Setup

Configuring iTunes Connect

Once we have the App ID set up we need to head over to iTunes Connect and add our application there. Note that even if you intend to do Sandbox testing only, you still need to register your app in iTunes Connect. You do not need to upload the app binary or wait for Apple’s approval, it just needs to be registered.
On the New App screen we select iOS and fill in the rest of the details. For Bundle ID make sure you select the bundle that we have just created.
iTunes Connect App Add

NB: It can take up to couple of minutes for iTunes Connect to pick up your new App ID. So if you do not see it in the drop down, don’t worry, just wait 5-10 minutes and it should appear.

Once we have our App created we need to go the App settings screen Features -> In-App Purchases. This is where we will add our products.
iTunes Connect In-App Purchases

Since we are going to do Sandbox testing, you can safely ignore the Information about production products. When we press the plus button to add our first product we are presented with the following wizard that asks us what type of product we will add.
iTunes Connect Add Product

As of writing of this post the nativescript-purchase plugin supports only in-app purchases. So we will be working with the first 2 options. We will create one consumable and one non-consumable products.
We will start by adding a consumable product first. On the New In-App Purchase screen we go and enter the details for our product. When we created the application in the previous part of the tutorial we have said that our consumable product will be product2. So let’s fill in the details for that product:
iTunes Connect In-App Purchase Setup
Reference Name – You can use anything for this. This is not shown to the end user and is only for internal use.
Product Id – This one is very important. You must use the same ID that we used in the init() method of the nativescript-purchase plugin. In our case (and in case you followed the naming from the first part) we should input here org.nativescript.purchasesample.product2.
Pricing – You should select here the pricing tier for this product. You can chose from various ones and select the one that best suits your needs.
Localization (Display Name and Description) – This is what the user will see when you list your products. You can add localized text for both by pressing the plus sign next to the Localization header.

Once we save Product 2 info, we have to go through the above procedure and add Product 1 as well. Note that Product 1 will be a non-consumable product, so make sure you select the second option in the add product popup.

Now let’s return to our NativeScript project and run the app onto the simulator. If we did everything correctly we should see a nice list of products that we just added to iTunes Connect:
Purchase List Simulator

NB: You might NOT be able to see the registered products (consumable, non-consumable, etc.) if you do not have any contracts in effect regarding paid applications. To solve the problem, you can activate the contract for paid applications in App Store Connect > Contracts, Tax and Banking section.

Testing with Sandbox purchases

Now that we have the list ready it is time to do some sandbox purchases and test our purchase workflow. Before we start you must note the following: you cannot make sandbox (or real) purchases in the simulator! So in order to test we must deploy to a real device and in order to do this we first need to set up a provisioning profile. So lets get back to the Apple Developer portal and create a Development provisioning profile for the App ID we created at the start:
Provision Profile Creation Screen

Once you generated the provision profile and download it locally it is time to assign it to our app. In order to do so first do a tns build ios in the terminal in order NativeScript to generate fully the platform specific files. Then in Finder navigate to the platforms/ios folder located under you project’s root folder and open the .xcodeproj file. This should bring up XCode. There click on your project in the left pane and then uncheck the “Automatically manage signing” box and then in the “Signing (Debug)” section import your downloaded provision profile.
XCode Provisioning Setup

Do not close XCode yet as we still need to add the in-app purchase entitlement to the project. Go to the Capabilities section and turn on the In-App Purchase capability. Wait till all actions are complete and then you can close XCode.
XCode In-App Purchase Entitlement

Now we are ready to deploy the app to our real device. Attach your device and then use tns deploy ios to deploy to it. Once the app is deployed, open it and if everything is done correctly you should see the same list of products as in the simulator.
NB: You need to repeat the two XCode steps above every time you do tns platform clean ios on when you upgrade the NativeScript runtime to a new version. This is because those actions recreate the whole platforms/ios folder and its files.

The only thing left is to set up some sandbox users to test our purchases. Apple has a really nice step-by-step guide on how to add your sandbox users to your iTunes Connect account, so I will not go in much details here. The most important thing to remember is that you cannot use your actual Apple ID as a sandbox user. You must set up a new one.
Once you have added your sandbox users go to the App Store app on your device, scroll down to the bottom of the Featured page and tap on your Apple ID and select Sign Out. Do not try to sign in with the sandbox user to the App Store app as you will get an error. Instead go to the sample app we are developing and tap on a product. You will get a prompt asking you to sign in:
Device In-App Purcahse Prompt
Tap on the Use Existing Apple ID option and enter your sandbox user credentials:
Device Sandbox User Sign In
You will get a prompt to confirm your sandbox purchase:
Device Sandbox In-App Purchase Confirm
Once you press Buy and wait for the purchase to complete you will get a prompt of the successful purchase:
Device Sandbox In-App Purchase Success
Congratulations you have just made your first sandbox purchase!

If you want to explore all the properties you can get from the nativescript-purchase plugin for the Product and Transaction you can add some console.logs to the purchase workflow methods we have added in the previous part of the tutorial. Attach your device to your Mac and then use tns run ios so you can see the logs in your terminal.

Coming up next

In the final part of this three part tutorial I will guide you through configuring things for Android on Google Play and making some sandbox purchases on Android.

Implementing In-App purchases in your NativeScript application (Part 1)

Many mobile applications nowadays leverage the in-app purchase capabilities of both Android and iOS which gives users ability to buy digital goods. But since there are some tricks to get the native part going I’ve decided to write a 3-part in depth tutorial that will guide you through the full process of setting up in-app purchases in your NativeScript app. So let’s get going!

Creating the sample application

As of the writing of this article the most recent NatvieScript version is 2.5.1. Make sure you have installed and configured it correctly. For this tutorial we will be using vanilla TypeScript app so let’s run the following and create it:

tns create purchase-sample --tsc

Adding the nativescript-purchase plugin

After we created our sample app it is time to add the nativescript-purchase plugin. The plugin will do the heavy lifting of consuming in-app purchases in our application:

tns plugin add nativescript-purchase

Configuring available purchases for the application

Now it is time to start wiring things in our application. First stop is to specify what purchases will be available to our users. This is done in the app.ts file of the application (the main entry point of the NativeScript app). You can do this by adding the following block just above the app.start(...) line:

import * as purchase from "nativescript-purchase";

purchase.init([
    "org.nativescript.purchasesample.product1",
    "org.nativescript.purchasesample.product2"
]);

With this we are telling that products with ids org.nativescript.purchasesample.product1 and org.nativescript.purchasesample.product2 should be available to the users. Note that it is not necessary to prefix your products’ ids with the application id but this makes it really clear what product with which application is associated. If you do not like those long ids you can use just product1 and product2. Just note what ids you use here as we will need them in the next parts of the tutorial when we set up everything in iTunes Connect and Google Play Store.

Designing the UI

Now let’s move on to creating a simple UI that will show a list of products and give users ability to buy new products or restore their previous purchases (in case they changed their device):

<Page xmlns="http://schemas.nativescript.org/tns.xsd" navigatingTo="navigatingTo" class="page">
    <Page.actionBar>
        <ActionBar title="In-App Purchase Sample" class="action-bar">
            <ActionBar.items>
                <ActionItem ios.position="right" text="Restore" tap="onRestoreTap"/>
            </ActionBar.items>
        </ActionBar>
    </Page.actionBar>

    <GridLayout>
        <ListView items="{{ items }}" itemTap="onProductTap">
            <ListView.itemTemplate>
                <GridLayout rows="auto, auto" columns="*, auto" padding="5">
                    <Label row="0" col="0" class="h2" text="{{ localizedTitle }}"/>
                    <Label row="1" col="0" text="{{ localizedDescription }}" textWrap="true" color="#999999"/>
                    <Label text="{{ priceFormatted }}" row="0" rowSpan="2" col="1" class="h1" style="margin-left: 5"/>
                </GridLayout>
            </ListView.itemTemplate>
        </ListView>
        <ActivityIndicator busy="{{ loading }}" />
    </GridLayout>
</Page>

The UI is quite simple: we have an action bar with a button to restore previous purchases. Then bellow we have a list view that will display the available purchases and when tapped we will trigger our purchase workflow.Finally we have an activity indicator to show the user when we are doing some backend operations.

Purchase workflow code

With the setup and the UI ready it is time to go in the main-page.ts file and write the actual purchase workflow code that we will use to show the available products to the user and allow the user to buy and restore their purchases.
We will start by adding some required imports at the top for things that we will need:

import * as applicationSettings from "application-settings";
import * as purchase from "nativescript-purchase";
import { Transaction, TransactionState } from "nativescript-purchase/transaction";
import { Product } from "nativescript-purchase/product";
import { ItemEventData } from "ui/list-view";

let viewModel: Observable;

The next step will be to add the code that will load our products and put them in the model for the page.:

export function navigatingTo(args: EventData) {
    let page = <Page>args.object;

    viewModel = new Observable({
        items: [],
        loading: true
    });

    page.bindingContext = viewModel;

    purchase.getProducts()
        .then((res) => {
            viewModel.set("items", res);
            viewModel.set("loading", false);
        })
        .catch((e) => console.log(e));
}

NB: For simplicity we are be using a local model for the page that is defined in the same TS file. In a real life scenario you should always separate your models from the code behind of the view!

We set some default values in the model and bind it to the page. Next we call the getProducts() method of the nativescript-purchase plugin that will load our product details from iTunes Connect/Google Play Store – like price, title, etc. You can check all the available product properties here. The method will return an array with the products, which we set in the model and stop the loading animation.

There is one more thing that we should do in the navigatingTo event handler – to subscribe to the exposed transactionUpdated event of the nativescript-purchase plugin where we will handle the transactions made by our users. You can add this at the end of the navigatingTo event handler:

purchase.on(purchase.transactionUpdatedEvent, (transaction: Transaction) => {
    if (transaction.transactionState === TransactionState.Restored) {
        applicationSettings.setBoolean(transaction.productIdentifier, true); /* 1 */
    }
    if (transaction.transactionState === TransactionState.Purchased) {
        if (transaction.productIdentifier.indexOf(".product2") >= 0) { /* 2 */
            purchase.consumePurchase(transaction.transactionReceipt) /* 3 */
                .then((responseCode) => {
                    if (responseCode === 0) {
                        // Provision your user with their digital goods bought. 
                    }
                })
                .catch((e) => console.log(e));
        }
        else {
            applicationSettings.setBoolean(transaction.productIdentifier, true); /* 4 */
        }
    }    
});    

A nice way to store locally what products are purchased is to use NativeScript’s application-settings module. This way you can add a key in the application settings for any product bought by the user and then you can enable/disable specific parts of your application depending on what the user has purchased. So in lines /* 1 */, after a purchase is restored, and on /* 4 */, when the user has purchased a product, we set the product id in the application settings. The special case for product2 on line /* 2 */ is because we will be setting up product2 as a consumable purchase. There are differences of how consumable purchases work on iOS and on Android. For iOS consumable purchases are automatically consumed after a successful purchase, so the user can make another one right away. For Android you are responsible for consuming a purchase and flag it for repurchase. That’s why on line /* 3 */ we call the consumePurchase() method. If the consume is successful and the return code is 0 you should provision your users with the digital goods corresponding to the product bought. Note that for iOS this method always returns response code 0.
In case you have many consumable purchases you can add some suffix to the product id (for example .consumable) so you can easily distinguish for what products you should call the consumePurchase() method.
In this event handler you also have access to various other properties of the transaction which you can use (for example for extended verification of the transaction on your backend server with Apple/Google). You can check the full list of available properties here.

Finally we should add our handlers for the restore button tap and the tap on the product that should trigger a purchase:

export function onProductTap(data: ItemEventData) {
    let product = viewModel.get("items")[data.index] as Product;

    purchase.buyProduct(product);
}

export function onRestoreTap() {
    purchase.restorePurchases();
}

NB: For the buyProduct() method it is really important that you pass the product instance as returned by the getProducts() method. If you just create a new product and populate its properties the method will fail on iOS!

Up next

If you go ahead and run the code now, you should get a nice empty list 🙂 This is because we need to configure the products on iTunes Connect and Google Play Store.
In the next part of this tutorial I will guide through the setup on iTunes Connect and then we will run our sample application on iOS and make some sandbox purchases! So stay tuned!