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.

 - Andrew Brogdon, Mobile Ads Developer Relations

Over the past few months, a couple new projects designed to streamline AdMob and DFP mediation have launched: mediation groups, open source adapters, and network-specific guides.

Open Source Mediation Adapters on GitHub

In partnership with some of our mediation partners, we've open-sourced many of the most popular adapters used with DFP and AdMob mediation. You can see for yourself at our GitHub repos for iOS and Android:

• https://github.com/googleads/googleads-mobile-android-mediation
• https://github.com/googleads/googleads-mobile-ios-mediation

In addition to adapter source, there's also a project containing example adapter and custom event implementations, plus a test app.

Import Mediation Adapters with CocoaPods and Gradle

In addition to open-sourcing the adapters, we've also made importing compiled adapters into your projects simpler by uploading them to Bintray and making them available via jCenter and CocoaPods. Rather than downloading and manually including libraries, publishers can get the correct adapter simply by updating their Podfile with a line like this:

    pod 'GoogleMobileAdsMediationMoPub'

...or their build.gradle file with a line like this:

    compile 'com.google.ads.mediation:mopub:11.10.1.0'

With many ad networks choosing to distribute their SDKs in the same manner, it's frequently possible to bring a new mediation network into an app with nothing more that a Podfile or build.gradle tweak. For instructions on which gradle artifacts and CocoaPods to use, check the AdMob Mediation Overview (iOS, Android) and look for networks in the "Open source and versioned" section.

Network-specific guides

Each mediated network is a little bit different. They have their own front-end, their own reporting systems, and their own vocabulary including things like "placement," "location," or "zone." Once you start trying to add a second or third network to your mediation waterfall, things can get confusing in a hurry.

To help publishers navigate through these details, we've created network-specific guides for the mediation partners who have joined our open source repositories. Each one includes step-by-step instructions (with screenshots) that guide a publisher all the way from configuring their account in the mediated network's web site to setting up their mediation stack and importing the right adapter.

For more details, there's no better place to go than the guides themselves. You can find them in the AdMob Mediation Overview (iOS, Android).

Questions?

If you've got questions about our open source adapters or the best ways to get up and running with mediation, stop by our support forum.

 - Andrew Brogdon, Mobile Ads Developer Relations

Today, the first episode of the Mobile Ads Garage hits YouTube! 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 a feature, and show screencasts of real implementations on both Android and iOS – all in a friendly format.

The series will make its home on YouTube's Google Developer Channel, where you'll find the first episode in the Mobile Ads Garage playlist along with a sneak peek of the next four.

In addition to being a new way that people can find out about the SDK and how to use it, the series is a way for publishers to let us know what features they'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.

 - Andrew Brogdon, Mobile Ads Developer Relations

Since its release a few years ago, Swift has evolved into a dynamic, modern programming language for developing iOS apps. With its growing popularity and open source, we’ve seen an increase in requests from our publishers to fully support Swift in the Google Mobile Ads SDK. We responded by releasing a complete set of example apps built in Swift, adding Swift code snippets throughout our developer docs, and adding Swift API reference docs to our developer sites.

Our GitHub repo now has Swift example apps for banners, interstitials, and native ads for both AdMob and DFP. We’ve also added a Swift version of our API Demo app. The API Demo app demonstrates features of the Google Mobile Ads SDK, such as new ways to customize ad requests, experiment with multiple ad sizes, and compare AdMob and DFP technologies, to help you improve the user experience and maximize ad revenue.

We’ve also added Swift code snippets to our AdMob, DFP, and AdX developer docs. With nicely formatted widgets that display Swift and Objective-C code side by side, you can now easily compare SDK implementations in both Swift and Objective-C.

Finally, we’ve added Swift API reference docs to our AdMob and DFP developer sites, providing full documentation of our iOS Google Mobile Ads SDK. Now you have access to API reference docs for both Swift and Objective-C, making it easier to integrate with our SDK.

The Google Mobile Ads SDK team is committed to supporting Swift, and we’ll continue to update our SDK, developer docs, and example apps to ensure we provide publishers with full support for the latest version of Swift. Whether you currently develop your iOS apps in Swift, or have plans to do so in the future, we hope the actions we’ve taken to support Swift in our SDK will help make your experience with Swift more enjoyable and your transition to Swift a whole lot easier.

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

 - Tristan Emrich, Mobile Ads Developer Relations

As an avid reader of this blog, you have undoubtedly already seen the announcement that our dear old friend, the client library known as ‘AdsPyGoogle,’ will be sunset on January 5, 2015. Yes—we too at Google are very sad about this.

Fret not! In its place, we have a more than capable replacement in the form of our new GoogleAds Python client library which is more lightweight, has far fewer dependencies, boasts improved utilities and functionality, and perhaps most importantly, supports Python 2.7 as well as 3.x.

If you need a starting point on how to perform this switch, we have a blog post detailing the differences between the two, as well as a nifty migration guide on Github.

As usual, if you have any questions, feedback, or comments, please don’t hesitate to reach out on the DFP or AdWords forums.

 - Nicholas Chen, DFP API Team

In Part I, Chris showed you how to create and traffic a video ad. In Part II, you’ll learn how to get that ad displayed before your video content in Flash, HTML5, iOS, or Android.

The IMA SDK requires you to have an ad tag that points to your ad. An ad tag is a URL that returns a VAST response. The VAST (or VMAP) response contains information about your ad, including tracking URLs, clickthrough destinations, and the media files for the video ad. For more information about VAST, see the IAB website.

If you’re using DFP, the UI can generate an ad tag for you based on your line item and ad unit criteria. To generate the ad tag for your line item, follow these steps.

Now that you have your ad tag, let’s take a look at some of the parameters. We’ll use one of our standard sample tags for this exercise:

http://pubads.g.doubleclick.net/gampad/ads?
    sz=640x360&
    iu=/6062/iab_vast_samples/skippable&
    ciu_szs=300x250,728x90&
    impl=s&
    env=vp&
    gdfp_req=1&
    output=xml_vast2&
    unviewed_position_start=1&
    url=[referrer_url]&
    correlator=[timestamp]&
    scor=[timestamp]

sz

The size of the video ad that you’re requesting.

iu

Your “inventory unit” - the ad unit you created in Part I. This is in the format <network_code>/<ad_unit_code path>.

ciu_szs

If your ad unit has associated companion ads, their sizes will be listed here.

impl

The request mode. Here, “s” for “sync”.

env

The environment. Here, “vp” for “video player”. 

gdfp_req

Indicates that this is a DFP request rather than the legacy Google Ads Manager.

output

The type of output you want from your ad request. Typical values are “vast” or “vmap”.

unviewed_position_start

Enables delayed impressions for your ad. This ensures that an impression isn’t counted until the ad starts playing.

url

The URL of the page requesting ads. This will also be automatically filled in by the SDK.

correlator

This randomly-generated value will be filled in by the SDK. It’s used for a number of things, but they all boil down to detecting ad requests that come from the same instance of a page load.

scor

Like the correlator, but refreshed when your video stream changes rather than when the page refreshes. Used to detect ad requests that come from the same video stream instance.

For more info on these parameters, see this DFP help center article.

Now that you have a basic understanding of your ad tag, it’s time to plug it into your IMA SDK implementation. If you’d like to use a video player with the SDK pre-integrated, we have pre-baked solutions for HTML5, iOS, and Android. If you want to do your own SDK integration, check out the quick start guide for Flash, HTML5, iOS, or Android. In each of the sample implementations, you’ll find a reference to at least one ad tag.

For example, the HTML5 ad tag reference is in ads.js and looks like this:

adsRequest.adTagUrl = “YOUR_AD_TAG_HERE”;

Now fire up the sample and request an ad. Voila! You’ll now see the ad you trafficked in Part I serving as a pre-roll to your video content!

As always, if you have any questions feel free to contact us via the support forum.

 - Shawn Busolits, IMA SDK Team

Editor's note: re posting from DoubleClick Publisher Blog. --Stan Grinberg

In 2010, in order to help publishers maximize the value of every impression, we introduced the new version of DoubleClick for Publishers (DFP).

In the years since, we’ve continued to invest in this platform, including new features that we heard were most important to our publisher partners - like the ability to manage desktop, mobile and video on a single ad server, and tools that help publishers better optimize campaign performance and save time. Today, thousands of publishers, such as The Weather Company, Gawker Media, Forbes, The Wall Street Journal and YouTube, are all leveraging DFP. And over two-thirds of our overall publisher ad impressions run through this new platform, up from one-third last year.

As far as we’ve come, we are just getting started with innovation to help publishers build for the future. To preview just a few of our 2013 plans, we’ll be helping publishers grow with new data-driven revenue models by enabling Audience Extension from directly within DFP. We’re increasing their ability to tap into the accelerating brand opportunity with new ways to measure such as Active View reporting for viewable impressions. We’re investing to make it easier for publishers to manage advertising across devices with tools like the Google Publisher Tag, which automatically selects the appropriate ad for the screen size (aka “responsive design”). And we’ll also be making it faster to access online content: since the new DFP is roughly twice as fast at serving as DART, when we’re done upgrading we’ll be saving Internet users 63 years a day in waiting for ads to serve.

This year our team is shifting all of our effort and investment to DFP to deliver even greater innovations for our partners. With this in mind, we’ll be ending support for our DART for Publishers legacy ad serving platform on September 1, 2013. To ensure continuity of ad serving, support and training, publishers who haven't upgraded to DFP by that date will be automatically scheduled for an upgrade date between September 1 and December 31, 2013 when ad serving on the DART for Publishers legacy platform will cease. Note that publishers using the DFP Small Business platform do not need to take any action and are already supported on the new DFP.

We strongly advise all publishers to complete their upgrades to DFP before September 1 to make sure you are able to use the new DFP to its full potential during the busy 2013 holiday season. Please contact your account manager as soon as possible if you don’t have an upgrade date scheduled. And if you’re not sure who to contact, you can always reach out to our customer support team.

We know our partners are looking for tools that can grow and adapt to the needs of their business not just today, but also for tomorrow, the next year and ten years from now. That’s why we’re fully committed to the new DFP. We’re ready to accelerate our pace of innovation on our platform, and we look forward to helping publishers as they break new ground in digital.

Posted by Jonathan Bellack, Director of Product Management