Tag Archive for: android

Removing platform specific code with webpack in your NativeScript application

The NativeScript framework automatically includes source files that are suffixed with the given platform name. This way the clutter and size of your built application is decreased and you do not distribute dead platform specific code that isn’t needed. But often there are case where is it much more simple to write your platform specific code in a single file and just surround it with if statements for the platform, rather then separating it into separate platform specific files. So what happens then? Let’s take an example – bellow you will see the natvigatingTo event handler for a page which has some platform specific code:

import { EventData } from "data/observable";
import { isIOS, isAndroid } from "platform";
import * as frame from "ui/frame";
import { Page } from "ui/page";
import { HelloWorldModel } from "./main-view-model";

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

    if (isIOS) {
        frame.topmost().ios.controller.view.window.backgroundColor = UIColor.colorWithRedGreenBlueAlpha(242 / 255, 242 / 255, 242 / 255, 1);
        UITableViewCell.appearance().selectionStyle = UITableViewCellSelectionStyle.None;
        UITableView.appearance().tableFooterView = UIView.alloc().initWithFrame(CGRectZero); // Hide empty cells

    console.log(`We are running on ${isAndroid ? "ANDROID" : "IOS"}`);

    page.bindingContext = new HelloWorldModel();

If we run that though webpack with uglify (and you should always do that for the version of an app that you publish to the stores) we will get this (note that I reformatted code with new lines for readability):

function i(e) {
    var t = e.object;
    o.isIOS && (
        a.topmost().ios.controller.view.window.backgroundColor = UIColor.colorWithRedGreenBlueAlpha(242 / 255, 242 / 255, 242 / 255, 1),
        UITableViewCell.appearance().selectionStyle = 0,
        UITableView.appearance().tableFooterView = UIView.alloc().initWithFrame(CGRectZero)
        console.log("We are running on " + (o.isAndroid ? "ANDROID" : "IOS")),
        t.bindingContext = new r.HelloWorldModel

As you see, although changed a bit, all the platform specific code is there. And no matter if you bundle for iOS or Android the code will be the same. Since you cannot change the platform during runtime some parts of that code are dead and will never execute. So how can we remove those? This can easily be achieved by helping webpack “understand” which parts of the code are dead so it can remove them when it optimizes the bundle.

First thing that we will do is instead of using the isAndroid / isIOS flags from the platform module, we will use flags that we will define in the global object (you will see why later on). In the app’s entry point before starting it we will extend the global object with the flags and their values:

import { isIOS, isAndroid } from "platform";
Object.assign(global, { isIOS, isAndroid });

Now in order to make TypeScript happy and so that we can directly use ‘global.isIOS’ and ‘global.isAndroid’ lets add an ‘app.d.ts’ in our app with the following content:

// Augment the NodeJS global type with our own extensions
declare namespace NodeJS {
    interface Global {
        // Add custom properties here.
        isIOS: boolean;
        isAndroid: boolean;

This extends the definition of the global object that is provided with NativeScript’s core modules and we won’t have to cast global to any in order to make our code compile.

Now if we refactor our platform specific code to use the global object instead, the code will look like this:

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

    if (global.isIOS) {
        frame.topmost().ios.controller.view.window.backgroundColor = UIColor.colorWithRedGreenBlueAlpha(242 / 255, 242 / 255, 242 / 255, 1);
        UITableViewCell.appearance().selectionStyle = UITableViewCellSelectionStyle.None;
        UITableView.appearance().tableFooterView = UIView.alloc().initWithFrame(CGRectZero); // Hide empty cells

    console.log(`We are running on ${global.isAndroid ? "ANDROID" : "IOS"}`);

    page.bindingContext = new HelloWorldModel();

If we run webpack with uglify now we wont see much of a difference. This is because webpack still does not know which code is dead. So lets help him understand that by changing the webpack.config.js and adding to the webpack.DefinePlugin the same global.isIOS and global.isAndroid flags. This is possible because during bundle time webpack already knows for which platform it is creating the bundle:

// Define useful constants like TNS_WEBPACK
new webpack.DefinePlugin({
    "global.TNS_WEBPACK": "true",
    "global.isAndroid": `${platform === "android"}`,
    "global.isIOS": `${platform === "ios"}`,
    "process": undefined,

When the bundle is created webpack will replace the occurrence of those two flags with the respective value as defined in the config file. By doing this it will render parts of the code dead and the UglifyJS plugin can safely remove them from the final bundle.

One last thing to do – since we will not actually need the flags in the global object when the code is bundled, we can safely change the code in the app entry point:

if (!global.TNS_WEBPACK) {
    Object.assign(global, { isIOS, isAndroid });

This will ensure that both bundled and non-bundled builds are working as expected and we will not be polluting the global object unnecessary.

Now if we bundle and uglify the code, for iOS we will get (again code reformatted for readability):

function r(e) {
    var t = e.object;
        o.topmost().ios.controller.view.window.backgroundColor = UIColor.colorWithRedGreenBlueAlpha(242 / 255, 242 / 255, 242 / 255, 1),
        UITableViewCell.appearance().selectionStyle = 0,
        UITableView.appearance().tableFooterView = UIView.alloc().initWithFrame(CGRectZero),
        console.log("We are running on IOS"),
        t.bindingContext = new a.HelloWorldModel

And for Android we will get:

function a(t) {
    var e = t.object;
    console.log("We are running on ANDROID");
    e.bindingContext = new o.HelloWorldModel

As you will notice the code for both platforms is greatly optimized now. First the conditional expression we had in the last console.log is changed so there is no unnecessary comparison. Furthermore for Android all the iOS specific code has been removed and replaced with a dummy 0.

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 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";


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">
        <ActionBar title="In-App Purchase Sample" class="action-bar">
                <ActionItem ios.position="right" text="Restore" tap="onRestoreTap"/>

        <ListView items="{{ items }}" itemTap="onProductTap">
                <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"/>
        <ActivityIndicator busy="{{ loading }}" />

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;

        .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;


export function onRestoreTap() {

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!