For Android developers, Context android.content.Context has a zillion subclasses, some of which are really specific (I’m looking at you, NotificationCompatSideChannelService Context, all of which seem slightly different. Once you start talking about passing these objects from one part of an app to another, which happens during AdMob mediation, it can get confusing in a hurry. In order to keep things straight, engineers building Android custom events and mediation adapters need to make sure they’re handling Contexts properly.
If you’ve ever built a custom event or mediation adapter for AdMob, you’re probably familiar with these two methods:
requestInterstitialAd(Context context,
CustomEventInterstitialListener listener,
String serverParameter,
MediationAdRequest mediationAdRequest,
Bundle customEventExtras)
requestInterstitialAd(Context context,
MediationInterstitialListener listener,
Bundle serverParameters,
MediationAdRequest mediationAdRequest,
Bundle mediationExtras)
They’re from the CustomEventInterstitial MediationInterstitialAdapter Context parameter that can be used to retrieve information about the execution environment, query permissions, and access user preferences. In most cases, that object ends up being the Activity Activity is a subclass of Context), but that’s not guaranteed.
For example, consider an app that switches quickly from one Activity to another, and occasionally shows an interstitial ad during one of the transitions. Requesting a new ad in each onCreate Activity lifecycle is a common solution. Because that class isn’t an Activity, though, it can’t use itself as a Context, and instead must request interstitials using the Application Context subclass). If the app uses custom event and adapter classes that were only tested with Activity objects, they might break!
The best practice here is to make sure to test your custom events and adapters with both Activity and Application objects prior to releasing them. A reliable custom event needs to operate the same no matter which is provided, and the same goes for adapters. If, for some reason, the SDK you’re adapting just can’t work with an Application object as the context parameter, you can always trap this using instanceof and log the error:
@Override
Public void requestInterstitialAd(Context context,
CustomEventInterstitialListener listener,
String serverParameter,
MediationAdRequest mediationAdRequest,
Bundle customEventExtras) {
if (!(context instanceof Activity)) {
Log.w(“Example”, “Context not an Activity. Returning error!”);
listener.onAdFailedToLoad(AdRequest.ERROR_CODE_INVALID_REQUEST);
}
// ... code to request an ad using the Activity context ...
}
If you have technical questions about activities, contexts, or anything else relating to the Google Mobile Ads SDK, stop by our forum.
Andrew Brogdon , Mobile Ads Developer Relations
