The IMA SDK for iOS version beta7 will introduce some changes in the way you tell the SDK about your display area and companion slots, which lays the groundwork for more versatility in displaying ads. While these new, more versatile features aren’t quite ready yet, we recommend building with beta7 so you'll be prepared to take advantage of upcoming greater versatility and extending support to future iOS platforms.
In the beta6 version of the SDK, the IMAAdsManager contains an adView which you add to your UI to display ads (IMAAdsManager.adView). In the beta7 version of the SDK, you will provide the SDK with a UIView in which it will display ads when they are ready. This is done via the new IMAAdDisplayContainer. This new object will also contain information about your companion ad slots (but more on that later):
self.adDisplayContainer = [[IMAAdDisplayContainer alloc] initWithAdContainer:self.videoView companionSlots:nil];
In the example, we use the videoView as the UIView for the ad container. The SDK simply adds views to the provided UIView to display ads, so you won’t lose the required components for the content player already in the videoView. This IMAAdDisplayContainer will be passed to the IMAAdRequest, in place of the current companionSlots parameter:
IMAAdsRequest *request = [[IMAAdsRequest alloc] initWithAdTagUrl:self.adTagUrlTextField.text adDisplayContainer:self.adDisplayContainer userContext:nil];
In the beta6 version of the SDK, you provide the IMAAdsRequest with an NSArray of IMACompanionSlot objects, each of which is initialized with a width and height. When ads are loaded, you add these to your UI:
// Create your companion slots. NSMutableDictionary *companions = [NSMutableDictionary dictionary]; companions[@"300x50"] = [[IMACompanionAdSlot alloc] initWithWidth:300 height:50]; self.companionSlots = companions; ... // Give the companion slots to the IMAAdsRequest. IMAAdsRequest *request = [[IMAAdsRequest alloc] initWithAdTagUrl:self.adTagUrlTextField.text companionSlots:[self.companionSlots allValues] userContext:nil]; ... // Once ads have been loaded, display the companion ads. [self.smallCompanionSlot addSubview: ((IMACompanionAdSlot *)self.companionSlots[@"300x50"]).view];
// Create your companion slots. NSMutableDictionary *companions = [NSMutableDictionary dictionary]; companions[@"300x50"] = [[IMACompanionAdSlot alloc] initWithView:self.smallCompanionSlot width:300 height:50]; self.companionSlots = companions; // Give the companion slots to the IMAAdDisplayContainer. self.adDisplayContainer = [[IMAAdDisplayContainer alloc] initWithAdContainer:self.videoView companionSlots:[self.companionSlots allValues]]; // Request ads with the IMAAdDisplayContainer. IMAAdsRequest *request = [[IMAAdsRequest alloc] initWithAdTagUrl:self.adTagUrlTextField.text adDisplayContainer:self.adDisplayContainer userContext:nil];
These changes will allow for continued support of YouTube-hosted ads (including TrueView), as well as allow you to provide a custom player for ads further down the road, similar to the HTML5 custom playback option. A custom ad player is not intended to be used by everyone - in fact most of you will not need it - but it will offer support for some additional features in the future.
As always, if you have any questions feel free to contact us via the support forum.
- Shawn Busolits, IMA SDK Team
displaySelect
SEARCH
contentNetwork = false
networkSettings
true
Summary: Legacy AdMob will sunset August 31st, 2014. The Google Play store will not accept apps using the legacy SDK after August 1st, 2014. Please update.
Greetings AdMob Developers!
We're pleased to announce we've completed the rollout of the new AdMob to over 200 countries. AdMob is now a complete platform for developers to monetize, promote and analyze their apps, with Google Analytics directly available in the AdMob interface. We hope you enjoy the new features it provides, including ad network optimization and simplified mediation. You can read more about the new features and changes in this help center doc.
Since the new AdMob is now available to everyone, we’re beginning our deprecation of the legacy AdMob, and will be sunsetting the old platform on August 31st, 2014. After August 31st:
Please upgrade to the new AdMob as soon as possible - and definitely before the end of August. If you encounter difficulties, please see the help docs and support forms in our Help Center.
We also want to remind you that after August 1st, 2014, the Google Play Store will no longer accept apps using the legacy AdMob SDK. If you're an Android publisher, you should migrate to Google Play Services as soon as possible. We have plenty of resources for you including our migration guide and intro video - and if you still need help, please ask your technical questions on our forum.
We hope that you're as excited about the evolution of AdMob as we are!
When you make an ad request using the Google Mobile Ads SDK, you’re probably setting an AdListener or GADBannerViewDelegate to listen for ad events. The click events for these listeners are slightly different on Android and iOS, so today we’ll take a deeper look at what events get invoked when an ad click:
Here are the ad events that get called when an ad opens an overlay:
These events are pretty straightforward. When the ad overlay opens, you get a single callback. When the ad overlay closes, Android notifies you the moment the event happens, while iOS notifies you right before and after the event happens.
When an ad launches an external application, the ad events are slightly different:
Notice how on Android you still get the onAdOpened and onAdClosed events even if an ad leaves an application. But on iOS, the adViewWillPresentScreen and adViewWillDismissScreen/adViewDidDismissScreen events are only invoked when presenting and dismissing modal views.
onAdOpened
onAdClosed
adViewWillPresentScreen
adViewWillDismissScreen/adViewDidDismissScreen
So how do you know when the user returns to your iOS app? You can listen for the applicationWillEnterForeground delegate method that iOS provides.
Hopefully you’re already requesting test ads during application development. If you’re making test requests, you should already see these ads showing up in your development environment:
On iOS, you can use these ads to test both ad click behaviors. If you click the banner, the Google Mobile Ads SDK will launch an external web browser and call adViewWillLeaveApplication. If you click the icon in the bottom-left corner of the ad, the SDK will launch an overlay and adViewWillPresentScreen will get called.
adViewWillLeaveApplication
Hopefully this clears up any confusion regarding any ad click events. If you have any additional questions, we’ll field them on our forum. You can also find us on Google+.
- Eric Leichtenschlag, Mobile Ads Developer Relations
These workshops are a great way for you to meet with the display ads API team and ask questions in person. This is also a key occasion for members of the community to bring their feedback directly to us. Most of all, it's a great opportunity for you to exchange ideas and best practices with fellow developers.
We are inviting you to join us in the following cities:
Please fill out this registration form if you're interested in attending one of these workshops. Due to limited space, we cannot guarantee admittance, but we’ll send a confirmation email in the coming weeks to let you know if you have a spot.
To receive announcements of upcoming Ads API Workshops on Display, please join this mailing list.
Hope to see you there!
- Adam Rogal, DFP API Team
mvn appengine:devserver
Today, we’re delighted to announce the launch of the Google Mobile Ads Unity Plugin v2.1, now with interstitial ads. You can start playing around with the latest code by grabbing the v2.1 Unity package on GitHub.
There are four steps required to integrate interstitial ads:
InterstitialAd
The first three steps can be performed at the same time, and can even live in its own helper function:
public InterstitialAd CreateAndLoadInterstitial() { // Initialize an InterstitialAd. InterstitialAd interstitial = new InterstitialAd("MY_AD_UNIT_ID"); // Register for ad events. interstitial.AdLoaded += delegate(object sender, EventArgs args) {}; interstitial.AdFailedToLoad += delegate(object sender, AdFailToLoadEventArgs args) {}; interstitial.AdOpened += delegate(object sender, EventArgs args) {}; interstitial.AdClosing += delegate(object sender, EventArgs args) {}; interstitial.AdClosed += delegate(object sender, EventArgs args) {}; interstitial.AdLeftApplication += delegate(object sender, EventArgs args) {}; // Load the InterstitialAd with an AdRequest. interstitial.LoadAd(new AdRequest.Builder().Build()); }
You should wait to show the interstitial until a good stopping point in your app, for example when the user finishes a level in your game. Remember to check that the interstitial has finished loading before you show it:
// Call this when a level finishes. public void LevelFinished() { if (interstitial.isLoaded()) { interstitial.Show(); } }
Keep in mind that an interstitial is a one-time use object. Once the interstitial is closed, you can dispose of the object and prepare another one. This can be implemented directly in the AdClosed event.
AdClosed
interstitial.AdClosed += delegate(object sender, EventArgs args) { interstitial.Destroy(); interstitial = CreateAndLoadInterstitial(); };
In this release, we also changed our ad events to be of type EventHandler instead of Action for both BannerView and InterstitialAd. This means your callback methods now take an object representing the event sender, and an EventArgs:
BannerView
object
interstitial.AdLoaded = delegate(object sender, EventArgs args) { print(“Interstitial Loaded”); };
The only event with special event args is AdFailedToLoad. It passes an instance of AdFailedToLoadEventArgs with a Message describing the error.
AdFailedToLoad
Message
interstitial.AdFailedToLoad = delegate(object sender, AdFailedToLoadEventArgs args) { print("Interstitial Failed to load: " + args.Message); };
The source code as well as a sample app for the plugin is available on our googleads-mobile-plugins GitHub repo. If you have any questions about Unity integration, you can reach us on our forum. Remember that you can also find us on Google+, where we have updates on all of our Google Ads developer products.
If you pay close attention to your network traffic, you’ve probably noticed that the IMA SDK is hosted on s0.2mdn.net. Last week we started migrating traffic from this domain to imasdk.googleapis.com. This will be a gradual migration - we will not move all traffic at once. Instead, we’ve started putting all HTML5 traffic on the new domain. Flash and native SDKs will follow shortly. For updates on our progress, check out the "Domain Migration Status” forum thread. The old domain will continue to work for the remainder of the year, but we encourage you to move early.
Today, we’re excited to announce a new release to both our Android and iOS Google Mobile Ads SDKs. The key new features added in these releases are in-app purchase ads for both platforms and new mediation APIs for Android.
In this release we’ve added SDK-level support (front-end support coming soon!) for running house ads that can initiate an in-app purchase. In-app purchase ads require that you set an in-app purchase listener on your interstitial ad. If an in-app purchase ad is shown, it will present the user with an option to buy one or more items that you have configured:
When the user clicks Buy now, the SDK will invoke your in-app purchase listener with the purchase information necessary to start a transaction for that product. You are responsible for implementing the in-app purchase flow from this point. Full implementation details can be found in our Android and iOS documentation.
Note: Front-end support for this feature is not available yet, but is coming soon.
As part of our Google Play services API revamp, we’ve added new mediation APIs (which we’re calling mediation v2) to make it easier for ad networks to create mediation adapters.
Don’t worry! We’re still supporting mediation adapters written against mediation v1 APIs. This change won’t require any immediate updates to your apps.
If you previously passed extra parameters to third party networks, note that this process has changed for mediation v2. You’ll now pass a bundle to the ad network, keyed by its mediation v2 adapter class. Here is an example of passing extra parameters to AdMob:
Bundle adMobBundle = new Bundle(); adMobBundle.putString("color_bg", "AAAAFF"); AdRequest request = new AdRequest.Builder() .addNetworkExtrasBundle(AdMobAdapter.class, adMobBundle) .build();
You can also use this snippet to check for the existence of mediation v2 support. If this snippet compiles, then the adapter supports mediation v2. If there is a compilation error saying that the arguments don’t match the arguments for addNetworkExtrasBundle(Class, Bundle), then that adapter class does not support mediation v2.
addNetworkExtrasBundle(Class, Bundle)
See the documentation for more information on passing parameters to mediation v2.
The 6.9.2 iOS SDK release has dropped support for iOS 4.3. By dropping iOS 4.3, the SDK can take advantage of automatic reference counting (ARC) weak references to provide a more stable release. The SDK still supports iOS 5.0 and above.
Check out the downloads page to grab the latest iOS release. A new Google Play services revision will soon be available in Android’s SDK Manager.
