Monetize your NativeScript apps with AdMob (part 2 - Android)

Or how to create a simple module when both iOS and Android come into play

This is the second part of the Monetize your NativeScript apps with AdMob blog. In part one I discussed how you can easily access and use the native API of a native framework in JavaScript, taking the AdMob library for iOS as an example. To do that, you only needed the existing AdMob documentation in combination with a few simple rules to translate the Objective-C API calls to JavaScript.

The popular mobile platforms, however, are two - iOS and Android. So, it would be fair if I cover Android as well. Moreover, further in this article as things get more interesting and we are close to having a cross-platform AdMob usage, I will show you what’s the recommended way of separating and isolating the native API calls in a NativeScript project. So, let’s begin.

Just like in the iOS case, we will focus on these two types of ads:

Banners - These ads appear at the bottom of your application without interruption

Interstitials - These ads appear from time to time occupying the whole screen estate

Following the documentations links above and with some help from the NativeScript documentation here is how to plug the AdMob SDKs in a NativeScript app.

Prerequisites

We made an important update in the latest version of NativeScript that allows calling Java methods of private classes. This will allow the usage of the Android AdMob API. Therefore, please check your version with:

The intriguing thing here is the usage of the AdListener which is an abstract class in Java. When an object of that type is attached to our banner, it allows us to handle various interesting events related to the banner - for example, when the banner is clicked and this puts the app in the background in favor of a browser with the landing page related to the ad.

Here is the result:

The complete iOS + Android source code of the Banner NativeScript app can be found at GitHub.

Using Interstitial ads

Again... interstitials… these ‘disrupting the UX’ ads… Let’s see how they are implemented.

First, we should create the interstitial on the loaded event of the page, or in other words, in the pageLoaded function:

As you can see, we are again taking benefit from an AdListener object attached to our interstitial. Actually, in the case of the interstitials, it’s not just our own scenario which may require the use of AdListener, but it’s the Google recommendation which makes it necessary. Because, we should prepare the next ad request the moment we close the previous interstitial, which happens on the onAdClosed function. And, here is the loadAndroidAd implementation:

Finally, we should display the interstitial. In our sample case we do that on a button click. In a real-world scenario, this would happen between two important events in your app, like two game levels. Make sure you do not annoy your end-users too much. :)

The complete iOS + Android source code of the Interstitial app can be found at GitHub.

But...wait a minute! All these platform checks… it’s madness! Can we do something about it? Yes, we can!

If you check the given GitHub repositories above you may not find the code there very pretty. We have just a few platform checks in our case, but in a real-world project with quite a rich native SDK, the platform checks may kind of uglify your code. If you are a fan of the clean code, just like me, then you can isolate the iOS and Android native API calls into a module.

If you check the tns-core-modules under the node_modules folder of the project, you will notice that a module mainly consists of modulename.ios.js, modulename.android.android.js, modulename-common.js and package.json . Well, as you may guess the modulename.ios.js contains the JavaScript calls to the native iOS API and the modulename.android.js contains the JavaScript calls to the native Android API. And on top of that we have modulename-common.js to expose unified API, so that you don’t bother with calls to the native APIs yourself.

NativeScript is smart enough to load only modulename.ios.js when run on an iOS device and modulename.android.js when run on an Android device.

The fact that the methods declarations in both files are the same allows us to simply call them in our main-page.js file and NativeScript will take the appropriate file (bannerview.ios.js or bannerview.android.js) depending on the platform the app is run at. Here is how simple main-page.js becomes:

varvmModule = require("./main-view-model");

varbannerModule = require("./bannerview");

functionpageLoaded(args) {

varpage = args.object;

page.bindingContext = vmModule.mainViewModel;

varplaceholder = page.getViewById("bannerView");

bannerModule.loadBanner(placeholder);

}

functioncreatingView(args) {

args.view = bannerModule.createBanner(args);

}

exports.pageLoaded = pageLoaded;

exports.creatingView = creatingView;

Note how that we are loading the bannerview module at the top.

You can get the complete source code of the bannerview module at GitHub.

Interstitial ads

Let’s do the same exercise for the interstitial ads. First, create two js files - interstitial.ios.js and interstitial.android.js.

iOS

In the interstitial.ios.js file we will expose two static method - one that creates the interstitial and one that shows it:

Finally, thanks to the code separation and abstraction, here is how simple the main-page.js looks now:

varvmModule = require("./main-view-model");

varplatformModule = require("platform");

varframeModule = require("ui/frame");

varinterstitialModule = require("./interstitial");

functionpageLoaded(args) {

varpage = args.object;

page.bindingContext = vmModule.mainViewModel;

interstitialModule.createInterstitial();

}

functionbuttonTapped(args) {

interstitialModule.showInterstitial(args);

}

exports.pageLoaded = pageLoaded;

exports.buttonTapped = buttonTapped;

Simple, huh? Get the complete source code of that modulized example from GitHub.

Now you know how to directly use the APIs of a native library by only referring to the documentation of that library and the NativeScript documentation. And, you also know how to extract the native API calls in a module thus keeping your code clean and tidy.

Enterprise

Stay connected with NativeScript

I agree to receive email communications from Progress Software or its Partners, containing information about Progress Software’s products. Consent may be withdrawn at any time.

We see that you have already chosen to receive marketing materials from us. If you wish to change this at any time you may do so by clicking here.

Thank you for your continued interest in Progress. Based on either your previous activity on our websites or our ongoing relationship, we will keep you updated on our products, solutions, services, company news and events. If you decide that you want to be removed from our mailing lists at any time, you can change your contact preferences by clicking here.