Skip to end of metadata
Go to start of metadata

Android Custom Adaptors

Custom adaptors allow our SDK to call out to another SDK installed on the same device, usually for mediation. This document describes the code you must write to create your own custom adaptors.

Note that the interfaces described here are exactly what we used to implement our own mediation adaptors.

On This Page

Banners

In order to show mediated banner ads, you must implement the MediatedBannerAdView interface, whci consists of two methods: requestAd and destroy.

You are also responsible for implementing the callbacks that translate the mediated SDK’s events into events that are understood by our mobile SDK. For details, see the example implementation below:

 

Xandr's mobile SDK calls the requestAd method when the third-party SDK should begin requesting an ad. requestAd returns a view that holds the ad from the third-party SDK; it takes the following parameters:

  • mBC: A MediatedBannerAdViewController through which the adaptor must send events to our SDK.

  • activity: Activity context through which the adaptor can instantiate its view object.

  • parameter: An optional opaque string passed from the server, this can be used to define SDK-specific parameters such as additional targeting information. The encoding of the contents of this string are entirely up to the implementation of the third-party SDK adaptor.

  • uid: The network ID for this ad call. This ID is opaque to our mobile SDK; the ID’s contents and their encoding are up to the implementation of the third-party SDK. In other words, you must populate this with a value understood by the third-party SDK’s ad server.

  • width: The width of the advertisement in pixels as defined in the MediatedBannerAdView object that initiated this call.

  • height: The height of the advertisement in pixels as defined in the MediatedBannerAdView object that initiated this call.

  • targetingParameters A TargetingParameters object containing targeting information that was passed to our mobile SDK such as age, gender, and location.

Interstitials

Interstitials need to be prefetched by the mediated SDK before being shown to the user. As with banners, you must implement requestAd. You must also implement isReady to let the user know if an ad is available, and show, which displays an ad.

You are responsible for implementing the callbacks that translate the mediated SDK’s events into events that are understood by our SDK. For details, see the example implementation below:

The adaptor must call requestAd when the third-party SDK should begin requesting an ad. It takes the following arguments:
  • mIC: A MediatedInterstitialAdViewController through which the adaptor must send events to our SDK.

  • activity: Activity context through which the adaptor can instantiate its view object.

  • parameter: An optional opaque string passed from the server, this can be used to define SDK-specific parameters such as additional targeting information. The encoding of the contents of this string are entirely up to the implementation of the third-party SDK adaptor.

  • uid: The network ID for this ad call. This ID is opaque to our SDK; the ID’s contents and their encoding are up to the implementation of the third-party SDK. In other words, the parameter must be populated with values understood by the third-party SDK’s ad server.

  • targetingParameters: A TargetingParameters object containing targeting information that was passed to our mobile SDK such as age, gender, and location.

In addition to requestAd, the MediatedInterstitialAdView interface requires you to implement these methods:

  • isReady: Our SDK calls this method to check if the interstitial view is ready when the user calls InterstitialAdView.isReady.

  • show: Our SDK calls this method to show the interstitial view when the user has called InterstitialAdView.show.

Required Callbacks

The callbacks listed below must be implemented by your custom adaptor. Note that these callbacks are required whether the ad in question is a banner or interstitial. You can see examples of their use in the code samples above.

  • onAdLoaded: Called to indicate that the mediated SDK’s request completed and returned a banner successfully.

  • onAdFailed: Called to indicate that the mediated SDK’s request failed to return a valid ad.

Optional Callbacks

The callbacks listed below should be implemented in custom adaptors for both banners and interstitials.

  • onAdClicked: The ad was clicked.

  • onAdExpanded: The ad is presenting a modal view.

  • onAdCollapsed: The ad is dismissing the modal view.

Related Topics