We are pleased to announce the release of the IMA SDK for iOS v3.1.0. This release contains support for Picture in Picture in iOS 9 and HTML5 companion ads. It also introduces a new API, [IMAAdsManager discardAdBreak], for discarding ad breaks. In addition, we have changed where IMAContentPlayhead is passed to the SDK.
[IMAAdsManager discardAdBreak]
IMAContentPlayhead
Picture in Picture (PiP) is a feature that was introduced in iOS 9, and now IMA publishers can add it to their existing IMA implementation. For more information, please see our PiP guide.
The IMA SDK now supports HTML5 companion ads. There is no implementation change required to use HTML5 companion ads. The SDK uses the same companion ad slot classes and delegates as before.
We have also introduced a new API for discarding ad breaks. Publishers can use [IMAAdsManager discardAdBreak] to implement timeout policies for their apps and to have more control over ad playback.
IMAContentPlayhead is now passed into IMAAdsRequest instead of the IMAAdsManager. This change will require an update to existing implementations.
IMAAdsManager
If you have any questions about these changes, feel free to contact us via the support forum.
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.
Context
android.content.Context
NotificationCompatSideChannelService
Contexts
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.
CustomEventInterstitial
MediationInterstitialAdapter
Activity
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!
onCreate
Application
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:
instanceof
@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.
PHASING_OUT
We're pleased to announce that we’ll be holding a series of Display Ads API Workshops in March 2016. These workshops are a half-day of tech talks, group discussions, and office hours geared toward developers who use the DoubleClick for Publishers API, Interactive Media Ads SDK, or Mobile Ads SDKs.
These API workshops are a great way for you to meet with the display ads API team and ask questions in person. The workshops are also a great opportunity for members of the community to bring their feedback directly to us, and exchange ideas and best practices with fellow developers.
The workshops will be held in the following cities:
For more information on the workshops’ agenda and a preview of our talks, please see our workshop page.
As always, if you have any questions, feel free to drop us a line on the DFP API forums, IMA SDK forums, Mobile Ads SDK forums, or the Ads Developer Google+ page.
- Vincent Tsao, DFP API Team
It's been two years since we moved to a regular deprecation schedule. And thanks to developers like you, we've been able to regularly release new versions and features while maintaining code health.
To continue this trend, we'll be simplifying the sunset schedule by tightening our belts a little. Starting with v201511, versions will be sunset one year after release. This will help us reduce the number of out-of-band deprecations. A shorter lifecycle means dated features can ride off into the sunset as intended. Plus, it's easy to remember when the version you're using is about to bite the dust, even if you're not signed up for deprecation announcements or don't obsessively check our deprecation schedule.
We strive to make upgrades easy. If you think they're not, please tell us why on our developer forum so we can make it better.
- Chris Seeley, DFP API Team
