For Android developers, Context objects can be tricky. To start with, android.content.Context has a zillion subclasses, some of which are really specific (I’m looking at you, NotificationCompatSideChannelService). On top of that, there are a bunch of available calls to retrieve the current 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 and MediationInterstitialAdapter interfaces, respectively, and are used to request interstitial ads from custom events and adapters. Both include a 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 an app is displaying when its ad request is made (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 method will likely waste resources, so offloading that work to a separate class that lives outside the 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 object (another 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