[go: nahoru, domu]

Today we're announcing a behavior change when requesting test ads using the Google Mobile Ads SDK. It enables you to test your own ad units while also ensuring that you are in test mode.

When using the Google Mobile Ads SDK during development, we recommend that you configure your device to request test ads. Always testing with test ads is important so you avoid having your account flagged for invalid activity.

Previously, enabling test ads resulted in the same sample ad like this one being shown in your app:

While this worked well as a basic check, it didn't allow for testing what real ads would look like in a production environment. For example, you couldn't test your mediation configurations or the different types of banner and interstitial formats that AdMob offers. The update we're rolling out addresses these problems.

New Test Ad Behavior

Starting today, apps built against Google Mobile Ads SDK 11.6.0 or higher on Android or 7.26.0 or higher on iOS can take advantage of the new behavior of test ads, which serves production-looking ads without charging advertisers. With this change, you can safely test the clickthrough behavior of your ads without your account getting flagged for invalid activity.

Banner, interstitial, and rewarded test ads now show a "Test Ad" label in the top-middle of the ad to give you a visual indicator that the ad returned is actually a test ad.

Sample 300x250 Banner ad

For native advanced test ads, the headline asset has the text "Test Ad" prepended.

Sample native content ad.

Test ads with Mediation

When using mediation, ads shown from third-party ad networks won't display the test ad label. Only Google ads show the test ad label. You are responsible for ensuring that your testing of third-party ad networks is compliant with their stated policies. See each mediation network's respective mediation guide for more information on how to enable test ads on those networks.

See the testing guide (Android | iOS) for more information on how to enable test ads in the Google Mobile Ads SDK. If you have any questions, contact us on the developer forum.

In the Google Mobile Ads SDK Android version 11.2.0 and iOS version 7.21.0, we added multiple native ads, a new feature for AdMob Native Ads Advanced. This feature lets you load up to five unique native ads with a single request. If you're showing native ads in a scrolling feed, this will allow you to get a batch of ads different from one another. It also means fewer network calls, which improves latency.

If you're displaying multiple native ads in a feed and loading ads one by one, converting to the new API should be fairly straightforward.

First, make a decision about how many ads you wish to fetch in one request. This is a function of how frequently you display ads in your feed. If you request five ads, AdMob will return the top five ads, ordered by eCPM value. If only three ads are available for the ad unit, only three ads will be returned.

iOS Implementation

Before initializing your ad loader, you need to create an instance of GADMultipleAdsAdLoaderOptions and set the numberOfAds property. Then include this object in the array of options when calling GADAdLoader's initializer:

override func viewDidLoad() {
    super.viewDidLoad()

    let multipleAdsOptions = GADMultipleAdsAdLoaderOptions()
    multipleAdsOptions.numberOfAds = 5

    adLoader = GADAdLoader(adUnitID: YOUR_AD_UNIT_ID, rootViewController: self,
        adTypes: [GADAdLoaderAdType.nativeContent,
                  GADAdLoaderAdType.nativeAppInstall],
        options: [multipleAdsOptions])
    adLoader.delegate = self
    adLoader.load(GADRequest())
  }

When requesting multiple native ads, you will still get individual callbacks when each ad is loaded. For example, for an app install ad you will have a callback to -adLoader:didReceiveNativeAppInstallAd:, and for a content ad -adLoader:didReceiveNativeContentAd:. This way you don't need to change the way the ads are received and shown.

To determine when ads have finished loading, there are two new APIs available:

  1. On the GADAdLoader object, a new property, loading, has been added. It returns true if a request is in progress, and false otherwise. You can check this property after each ad has loaded to find out if loading ads has completed.
  2. On the GADAdLoaderDelegate, the adLoaderDidFinishLoading: method has been added. It's invoked when all ads for a request have been returned.

Android Implementation

The Android implementation is similar to iOS. There's a new method on AdLoader, loadAds() which accepts the number of ads to load. There's also a new isLoading() method that indicates whether a request is currently in progress.

For a detailed walkthrough of the implementations, see the AdMob Native Ads Advanced implementation guides (iOS | Android). If you have any questions about this feature in the Google Mobile Ads SDK, please drop us a line at the developer forum.

One of the biggest cheers from the crowd at I/O '17 came in response to Stephanie Saad Cuthbertson's announcement that Kotlin would be an officially supported language for Android development starting with Android Studio 3.0. If you're an AdMob or Doubleclick publisher who's been eager to make the leap to a new language, we've got another announcement you might like: now that the new version of Android Studio has launched, we've released bunch of new mobile ads resources to support the Kotlin community.

If you haven't seen Kotlin yet, it's a statically typed language developed by JetBrains that compiles down to the same JVM bytecode that Java does, but includes a number of new features that can make Android development faster and easier. Things like dedicated data classes with less boilerplate, the Elvis operator, lambdas, SAM conversion, explicit nullability for references, and lots of other modern language features come built-in. For more information, see Introduction to Kotlin (also from I/O '17) in which Andrey Breslav and Hadi Hariri code up examples of the language's best features:

When you're done, you can see those same features in action in our new developer resources, which are now available to the AdMob and Doubleclick publisher community.

Samples

The Mobile Ads DevRel team maintains a GitHub repository of Android samples covering our API, and we've pushed Kotlin versions for each ad format. If you been wondering how Kotlin's Android extensions work with AdMob's banner ad layouts, for example, we've got a new sample app that'll show you. If you're curious how native ads work with all the new nullability stuff, we've got you covered with Kotlin samples for those formats as well.

In addition, we've included a new version of our API Demo app, which features a navigation drawer full of individual API demos for things like banner sizes, category exclusions, and more, all in Kotlin.

Implementation Guides

We've also updated our publisher guides with Kotlin snippets wherever code is shown. Similar to the mobile ads guides for iOS (which show either Swift or Objective-C syntax with a click of a tab), the Android guides now let developers easily switch back and forth between Java and Kotlin implementations.

Questions?

If you take a look at the Kotlin guides and samples and find you've got questions about the best way to implement something in Android's first ever new language, stop by our support forum. Our staff there will be happy to help.

Cross-posted from the AdMob blog.

Every interaction a user has with your app matters. That's why we're constantly evolving our advertising recommendations and policies to ensure that no matter where and on what device users are engaging with your apps, they have good experiences.

Example of ad appearing outside of "safe area" on iPhone X

With the launch of the iPhone X, app developers now need to plan for new design considerations as the rounded corners, notch, and home screen indicator on the extended screen can obscure content and lead to poor ad experiences for users when ads are placed in these areas.

That's why we've put together a guide to help you adapt your ad strategy for iPhone X. This includes guidance for how you can shift placement of banner or native ads to designated "safe areas" for this new device.

We've also updated our policies to indicate that ads must not be placed where objects may interfere with the user's typical interaction with the ad or app, such as under the home screen indicator on the iPhone X.

Please review these policy updates and our suggested implementation guide to ensure you're compliant by November 20th.

If you have any questions, visit the AdMob Help Center or contact your Google account team.

Posted by Pablo Alvarez, Product Manager, AdMob

We're pleased to announce that we'll be holding a series of Display Ads API Workshops in April 2017. These workshops are a half-day of tech talks, group discussions, networking activities, and one-on-one time with Googlers geared toward developers who use the DoubleClick for Publishers API, Interactive Media Ads SDK, or Mobile Ads SDKs.

These workshops offer you the following:

  • A great way for you to meet with the display ads API team to ask questions in person and give feedback directly to us.
  • A great opportunity to meet and exchange ideas with fellow developers in the community.
  • Previews of API and SDK roadmaps and select upcoming features.
  • For the first time, one-on-one office hours with ads API Googlers. Sign-ups will be available on-site on the day of the workshops.

The workshops will be held in the following cities:

For more information on the 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.

We recently launched v3.3.0 of the Google Mobile Ads Unity Plugin with support for ad position offsets and Unity 5.6 compatibility. The updated v3.3.0 Unity package is available for download from the Google Mobile Ads Unity Plugin GitHub repository.

Ad positions offsets

Version 3.3.0 of Google Mobile Ads Unity Plugin adds the ability to specify an x and y position for both BannerView and NativeExpressAdView objects. To position ad views outside of the existing AdPosition values, provide x and y offsets instead of an AdPosition when instantiating an ad view, as shown below.

BannerView bannerView = new BannerView(adUnitId, AdSize.SmartBanner, 50, 50);

The code snippet above creates a BannerView offset from the top-left corner of the screen by 50 density independent pixels in the x and y axis. NativeExpressAdView positions can be offset in the same manner, as shown below.

NativeExpressAdView nativeExpressAdView = new NativeExpressAdView(
        adUnitId, new AdSize(320, 150), 50, 50);

Support for Unity 5.6

Although Unity 5.6 is still in beta, the latest version of the Google Mobile Ads Unity plugin includes changes to be fully compatible with the upcoming release.

In addition to the new features outlined above, it is recommended to update to the latest version of the Google Mobile Ads plugin to take advantage of stability and bug fixes. The source code and a sample app for the plugin are available in our GitHub repo, as is the full changelog for this release. If you have any questions about Unity integration, you can reach us on our developer forum.

If you've created a Native Express ad unit recently, you may have noticed a new template format alongside App Install and Content: Video App Install. In the past few weeks, AdMob has rolled out support for video assets in Native Ads Express, giving publishers a new way to create more engaging presentations for their users.

How to get started

Enabling video demand for a Native Express ad unit is easy. Just open the ad unit's settings in the AdMob console, and look for the Ad type checkboxes at the top of the editor:

Check the checkbox marked "Video app install," and save the change. In a short while, your ad unit will start serving video creatives alongside the other two formats, with no code changes to your app required. That means you can update your existing apps to display this new format without redeploying to the Play Store or App Store.

An important thing to note is that video creatives are only available for ad units using the Large template size. The video player needs a certain amount of space, and the Large template ensures that it's available.

Customizing the experience

While there's no mobile code required to take advantage of Native Express Video, AdMob has introduced some new features to the API that allow publishers to customize the user experience. In particular, a new video options class (VideoOptions on Android, and GADVideoOptions on iOS) gives publishers a way to influence how the ads behave.

For example, the following code will cause video ads appearing in an Android NativeExpressAdView to begin playing with their audio on:

mAdView = (NativeExpressAdView) findViewById(R.id.adView);
mAdView.setVideoOptions(new VideoOptions.Builder()
    .setStartMuted(false)
    .build());

Staying in the know

App publishers can retrieve information about the video assets in their ads through the use of a video controller object (VideoController on Android, GADVideoController on iOS). The ad view classes for native express have been updated to include video controller properties that apps can grab and query for info like whether a video is present in the ad, and what its aspect ratio is. Even if the ad doesn't contain an video asset (or no ad has been loaded at all), you'll always get a valid reference to the ad view's video controller.

For example, here's a Swift snippet that shows how to check if an ad that just loaded contains a video asset:

func nativeExpressAdViewDidReceiveAd(_ nativeExpressAdView: GADNativeExpressAdView)
{
  if nativeExpressAdView.videoController.hasVideoContent() {
    print("Received an ad with a video asset.")
  } else {
    print("Received an ad without a video asset.")
  }
}

More Info

Native Express is designed to make implementing native ads easy, but if you have questions about how to get up and running or how you can best put it to use in your apps, stop by our support forum. The Mobile Ads Garage recently released an episode covering Native Express Video as well, with feature details and screencasts for iOS and Android:

Episode twelve of The Mobile Ads Garage is live on YouTube! If you haven't seen it before, The Mobile Ads Garage is a video tutorial series that covers how to use the Mobile Ads SDK to display ads from AdMob and DoubleClick for Publishers. Each episode covers one aspect of the SDK, breaks down the feature, and shows screencasts of real implementations on both Android and iOS – all in a friendly format.

With their customizable presentations and ability to be precached, Native Express ads fit right in with list-based user interfaces:

In this deep dive episode of the Mobile Ads Garage, you'll learn how to integrate Native Express ads into an iOS app that uses a UITableViewController for its primary UI. Along the way you'll get a detailed set of step and see screencasts of an implementation in Xcode. The episode also covers a handy technique for tapping into the ad lifecycle to load native express ads sequentially, from the top of the list to the bottom.

If you like the video, save the Mobile Ads Garage playlist to your YouTube Playlist collection and you'll never miss an episode.

We'd love to hear which AdMob features you'd like to learn more about. The comment sections for the videos are open, and you're welcome to toss out ideas for new episodes and examples you'd like to see. If you have a technical question relating to something discussed in one of the episodes, you can bring it to our support forum.

Until next time, be sure to stay connected on all things AdMob by following our Twitter, LinkedIn and Google+ pages.

Today we're excited to announce iOS and Android sample projects that display AdMob Native Express ads in a feed. These samples address a common use case for monetizing apps with feeds or lists of content. The iOS (Swift and Objective-C) apps display Native Express ads in a UITableView and the Android app shows them in a RecyclerView.

Native Express ads work well in lists of content for two reasons. First, impressions are not counted until the ad is on screen, which enables you to preload the ads ahead of time. Preloading can help with optimizing scroll performance by making sure the ad is ready to be displayed when the user scrolls through the list. Second, you have more control over the styling of the ads, allowing you to create presentations that fit naturally with your content.

You can check out these sample apps by downloading them from our iOS and Android GitHub repos, and you can see them being coded in the Mobile Ads Garage YouTube series. Episode 11 walks you through the implementation for adding native ads into an Android RecyclerView. Episode 12, which will cover the implementation of native ads in an iOS UITableView, is due out next week.

If you have any questions or feedback regarding our SDK, feel free to contact us through our forum.

Episode 11 of The Mobile Ads Garage is live on YouTube! If you haven't seen it before, The Mobile Ads Garage is a video tutorial series that covers how to use the Mobile Ads SDK to display ads from AdMob and Doubleclick for Publishers. Each episode covers one aspect of the SDK, breaks down the feature, and shows screencasts of real implementations on both Android and iOS – all in a friendly format.

In a break with tradition, this video is a deep technical dive on one subject: Native Ads Express in an Android RecyclerView. You'll learn how to modify an existing RecyclerView implementation to include Native Express ads, all the way from updating the adapter to loading the ads. In addition, you'll get a clever trick that makes sure your ads are always sized to match the UI, so they fit right in with your content.

If you haven't used Native Ads Express before, you can see them in action in Episode 7. Andrew and Gary cover all the basics: loading ads, placing them in layouts and storyboards, and using CSS to style the ads to match your app.


If you like the video, save the Mobile Ads Garage playlist to your YouTube Playlist collection and you'll never miss an episode.

We'd love to hear which AdMob features you'd like to learn more about. The comment sections for the videos are open, and you're welcome to toss out ideas for new episodes and examples you'd like to see. If you have a technical question relating to something discussed in one of the episodes, you can bring it to our support forum.

Until next time, be sure to stay connected on all things AdMob by following our Twitter, LinkedIn and Google+ pages.

Episode 10 of The Mobile Ads Garage is live on YouTube! If you haven't seen it before, the Mobile Ads Garage is a video tutorial series that covers how to use the Mobile Ads SDK to display ads from AdMob and DoubleClick for Publishers. Each episode covers one aspect of the SDK, breaks down the feature, and shows screencasts of real implementations on both Android and iOS – all in a friendly format.

Knowing what's going on with your ads is a big part of maintaining a great user experience. In the latest episode of the Mobile Ads Garage, you'll see how to tap into the ad lifecycle so your app's informed of loads, clickthroughs, and other key events. You'll also get a detailed breakdown of the steps that occur in the life of an ad, info about which classes and callbacks to use for common tasks like pausing game engines and muting audio, and a real world example of how to put it all together.


If you like the video, save the Mobile Ads Garage playlist to your YouTube Playlist collection and you'll never miss an episode.

We'd love to hear which AdMob features you'd like to learn more about. The comment sections for the videos are open, and you're welcome to toss out ideas for new episodes and examples you'd like to see. If you have a technical question relating to something discussed in one of the episodes, you can bring it to our support forum.

Until next time, be sure to stay connected on all things AdMob by following our Twitter, LinkedIn and Google+ pages.

Following its launch at the 2016 Game Developer’s Conference, AdMob’s mediation support for rewarded video ads has been a hit with publishers and users alike, with rapid adoption on both Android and iOS platforms.

Our growing list of mediation partners includes eight different ad networks. Choosing AdMob for your rewarded video mediation platform gives you access to ad content from all of them, while you develop against a single API from AdMob. Now, with the launch of custom events for rewarded video, you can also request and display rewarded videos from ad networks that are not directly supported by AdMob.

Our implementation guide for rewarded video adapters (Android | iOS) outlines how to implement an adapter that can serve rewarded video ads from a third party ad network. Special attention should be paid to steps specific to custom events that are summarized below:

Adding a custom event to your ad unit

To define a custom event, you must first create it in the AdMob interface at apps.admob.com. You can find instructions for creating a custom event in this help center guide.

Retrieving server parameters

The optional server parameter passed to your custom event is accessed via a special key. Here’s an example showing how to access the value in a rewarded video adapter:

Android

String parameter = serverParameters.getString(
    MediationRewardedVideoAdAdapter.CUSTOM_EVENT_SERVER_PARAMETER_FIELD);

iOS

NSString *parameter = [self.connector.credentials
    objectForKey:GADCustomEventParametersServer];

You can find additional documentation on rewarded video ads in our Get Started guides (Android | iOS), and more information about mediation is available in our mediation guides (Android | iOS). For any other questions about rewarded video mediation, you can reach us through our developer forum.

Episode nine of The Mobile Ads Garage is live on YouTube! If you haven't seen it before, The Mobile Ads Garage is a video tutorial series that covers how to use the Mobile Ads SDK to display ads from AdMob and DoubleClick for Publishers. Each episode covers one aspect of the SDK, breaks down the feature, and shows screencasts of real implementations on both Android and iOS – all in a friendly format.

In this episode of The Mobile Ads Garage, we discuss mediation, which is a way for publishers to get multiple networks of advertisers competing to display ads in their apps. We’ll show you how AdMob mediation works and what it can do for your business. Learn the pros and cons of mediation, see the details of implementation, and find out whether it’s right for your app. You'll also get screencasts for Android and iOS showing the integration of a third-party SDK, plus links to samples, written resources, and Gary the Graphics Guy acting like his usual, snarky self.

If you like the video, save the Mobile Ads Garage playlist to your YouTube Playlist collection and you'll never miss an episode.

We’d love to hear which AdMob features you’d like to learn more about. The comment sections for the videos are open, and you're welcome to toss out ideas for new episodes and examples you'd like to see. If you have a technical question relating to something discussed in one of the episodes, you can bring it to our support forum.

We recently launched v3.0.7 of the Google Mobile Ads Unity Plugin. The updated v3.0.7 Unity package is available for download from the Google Mobile Ads Unity Plugin GitHub repository.

Native Ads Express

This release introduces support for Native Ads Express. With Native Ads Express, you can create CSS templates that define how ads are presented in your app (things like image sizes, fonts, colors, and so on). These CSS templates are used to generate ad creatives that complement the native look and feel of your app. You can find more information on integrating Native Ads Express into Unity applications in our developer docs.

Android IL2CPP

The v3.0.7 release resolves compatibility issues with the IL2CPP scripting backend and the Google Mobile Ads Unity Plugin. This allows the use of the the IL2CPP scripting backend, a high-performance alternative to the Mono virtual machine and AOT compiler, in Unity applications with the Google Mobile Ads SDK.

The source code and a sample app for the plugin are available in our GitHub repo, as is a changelog for this release. If you have any questions about Unity integration, you can reach us on our developer forum.

With the Firebase 3.6.0 launch comes the release of version 7.11.0 of the Google Mobile Ads SDK, which has been optimized for the latest release of iOS. Any app that supports iOS 10 should be built against v7.11.0 or higher of the Mobile Ads SDK. AdMob publishers can grab the latest version of the SDK using the Firebase/AdMob CocoaPod or via the Firebase manual download. DFP publishers can get the latest version from the Google-Mobile-Ads-SDK CocoaPod or via the Mobile Ads SDK manual download.

What changed?

With the rollout of iOS 10, the App Store’s privacy policy requires apps to provide a usage description when attempting to access privacy-sensitive data, such as a user’s calendar or Bluetooth. You may have seen the following errors when attempting to upload your app to iTunes Connect:

"This app attempts to access privacy-sensitive data without a usage description. The app's Info.plist must contain an NSCalendarsUsageDescription key with a string value explaining to the user how the app uses this data."

"This app attempts to access privacy-sensitive data without a usage description. The app's Info.plist must contain an NSBluetoothPeripheralUsageDescription key with a string value explaining to the user how the app uses this data."

The latest version of the Mobile Ads SDK has been updated for iOS 10, and will no longer cause these errors to appear.

Information for MRAID creative designers

To comply with the App Store privacy changes, we removed support for the mraid.createCalendarEvent() and mraid.storePicture() methods. You will now see that the mraid.supports("calendar") and mraid.supports("storePicture") methods always return false. Per the MRAID v2 spec, MRAID creatives should check for support of these features before using them, and correctly handle the case where they’re unavailable.

If you have any questions regarding these changes, please contact us through our forum.

A new episode of The Mobile Ads Garage has hit YouTube! If you haven't seen it before, The Mobile Ads Garage is a video tutorial series that covers how to use the Mobile Ads SDK to display ads from AdMob and Doubleclick For Publishers. Each episode covers one aspect of the SDK, break down the feature, and show screencasts of real implementations on both Android and iOS – all in a friendly format.

In the last episode, Andrew and Gary the Graphics Guy showed you how to implement AdMob interstitials on iOS and Android. Now they're back to show you how to put interstitials to work in the best ways possible. When is the best time to display? How early should you request an ad, and how often should your users see one? You'll get answers to these questions and more, along with cupcakes, cats who can play chess, and what appears to be a cloning incident gone awry.


If you like the video, save the Mobile Ads Garage playlist to your YouTube Playlist collection and you'll never miss an episode.

We’d love to hear which AdMob features you’d like to learn more about. The comment sections for the videos are open, and you're welcome to toss out ideas for new episodes and examples you'd like to see. If you have a technical question relating to something discussed in one of the episodes, you can bring it to our support forum.

During the keynote at I/O 2016, we announced that Firebase has become a complete mobile platform that helps developers build high-quality apps, grow their user base, and earn more money. AdMob is part of how Firebase helps publishers earn revenue, and now that the dust has settled on I/O, you might have some questions about what the change means and how it affects people already monetizing with AdMob ads.

How does this affect my existing apps?

The short answer is: however you want it to. The apps you've already built are just fine the way they are, and they can keep monetizing with AdMob exactly as they do now, without changes. We've also made sure that when you do make the decision to integrate Firebase, the process is simple and straightforward. You can link your AdMob apps to Firebase projects right from the AdMob console. Firebase Analytics comes out of the box with the Firebase SDK, and you're free to choose the particular combination of Firebase services that fits your app.

Do I have to use Firebase with my new apps?

Nope. If you prefer to use AdMob by itself, that's just fine. You can import the Google Mobile Ads SDK the same way you do now, and continue to create ad units, campaigns, and reports at apps.admob.com.

My app is small! How big is the Firebase SDK?

We know SDK size is a big deal for mobile developers, and Firebase has been designed from the start to minimize its footprint. Publishers can pick and choose which services they're interested in, and only need the gradle libraries and frameworks they actually use. In our testing on Android, for example, importing the Mobile Ads SDK using the firebase-ads:9.0.0 gradle library instead of play-service-ads:9.0.0 increased the post-ProGuard size of our banner example's APK by about 100kB (though your results may vary).

Which Firebase service should I start with first?

All of the services are built to help mobile developers through the “develop, grow, and earn" lifecycle, so it depends which stage you’re at. Analytics, though, is something that every app can benefit from. Just by registering a Firebase project and importing the Firebase SDK into your app, you can start monetizing more intelligently with Firebase's free and unlimited analytics solution. Things like sessions, user demographics, revenue from in-app products, and a lot more will appear in the Firebase Analytics dashboard, with no extra code required.

Publishers can also add their own Analytics events and track them to improve their monetization strategy. For example, by adding events to monitor how users navigate between screens within an app, publishers can better understand the flow of action and find the best places to show interstitials without disrupting their users.

Are AdMob's developer resources going away?

No. The developer site has moved to a new domain, and we've added new content where appropriate, but everything you're used to is still there.

Our samples for iOS and Android now include the Firebase SDK when they build. We've also changed our quick-start guides for iOS and Android to help publishers get on board with Firebase, and the guys behind the Mobile Ads Garage are cooking up a new episode right now.

For more direct support, Firebase has a bunch of options, and as always, If you have technical questions about the Mobile Ads SDK, you're welcome to stop by our support forum.

The Mobile Ads Garage is a new series that covers how to use the Mobile Ads SDK to display ads from AdMob and Doubleclick For Publishers. Each episode will cover one aspect of the SDK, break down the feature, and show screencasts of real implementations on both Android and iOS – all in a friendly format.

With two episodes on banner ads on the books, the Mobile Ads Garage now turns its focus to interstitial ads.

Andrew and Gary the Graphics Guy are back this week with a detailed explanation of the interstitial ad lifecycle, how to load ads, and how to display at just the right time. Along the way you'll get screencasts of Android Studio and Xcode, plus links to guides, samples, and other resources.


If you like the video, save the Mobile Ads Garage playlist to your YouTube Playlist collection and you'll never miss an episode.

We’d love to hear which AdMob features you’d like to learn more about. The comment sections for the videos are open, and you're welcome to toss out ideas for new episodes and examples you'd like to see. If you have a technical question relating to something discussed in one of the episodes, you can bring it to our support forum.

Ever wondered about the best ways to monetize with banner ads while maintaining a great user experience? If so, the Mobile Ads Garage is here to help. In the third episode, Andrew and Gary the Graphics Guy cover how to integrate banner ads into a mobile app's UX, with a little help from Aunt Betty, hairless cats, and discount moose repellent. You'll see detailed breakdowns of things to avoid, plus reliable best practices that you can take back to your own apps. As always, links to guides, samples, and other resources are included.


If you like the video, save the Mobile Ads Garage playlist to your YouTube Playlist collection and you'll never miss an episode.

We’d love to hear which AdMob features you’d like to learn more about. The comment sections for the videos are open, and you're welcome to toss out ideas for new episodes and examples you'd like to see. If you have a technical question relating to something discussed in one of the episodes, you can bring it to our support forum.

Registering for banner and interstitial ad events is a handy way for Unity developers using the Google Mobile Ads Unity Plugin to track ad lifecycle events -- things like when an ad is loaded or when an ad click causes the app to be backgrounded. For Unity developers deploying to the Android platform, though, it's important to be aware that ad event handler methods are not invoked on the main thread. As a consequence, Unity methods that must be called on the main thread cannot be executed within ad event handler methods.

Consider the following example:

AudioSource audio = GetComponent<AudioSource>();
...
public void HandleInterstitialClosed(object sender, EventArgs args)
{
    audio.mute = false;
}

The code above, which modifies the volume of an audio source from within an ad event handler method, results in the following error:

ArgumentException: set_volume can only be called from the main thread

To get around this, we recommend setting a flag when an event happens, and polling for a state change within the Update() method of your Unity script.

For actions required to be performed on the main thread after showing an ad, set a flag on the OnAdClosed ad event. The update method can poll the value of this flag and perform actions as necessary. The code below illustrates how to implement this approach.

private bool interstitialClosed;

void Start()
{
    InterstitialAd interstitial = new InterstitialAd("YOUR_AD_UNIT_ID");
    interstitial.OnAdClosed += HandleInterstitialClosed;
    interstitialClosed = false;
    ...
}

void Update()
{
    if (interstitialClosed)
    {
        // Perform actions here.
        audio.mute = false;
    }
}

public void HandleInterstitialClosed(object sender, EventArgs args)
{
    interstitialClosed = true;
}

If you have any questions about Unity integration, you can reach us on our forum. You can also find our quick-start guide here. Remember that you can also find us on Google+, where we have updates on all of our Google Ads developer products.