SEARCH
SEARCH_MOBILE_APP
Today we’re announcing the release of beta version 13 of the IMA SDK for iOS. This release includes two new major features:
Prior to today’s release, importing the SDK involved manually adding every header file to your project, importing every header file individually in your source, and manually including the required frameworks. With the new framework model, you can add a single .framework file to your app and replace all of your header import source lines with a single import statement.
If you use CocoaPods, your build will fail after you update to beta 13. But fear not, you can fix this in a matter of seconds with the following steps:
#import “IMA<something>.h”
@import GoogleInteractiveMediaAds;
If you don’t use Cocoapods, your path to upgrade is slightly different. You can update using the following steps:
GoogleInteractiveMediaAds.framework
Since our launch, one of the most requested features has been background ad playback. Suppose, for example, you author a music streaming app, and you want to be able to request and play ads in the background. With today’s release, however, we now support requesting and playing ads in a background service. For more info and implementation instructions, see our Background Ad Playback guide.
As always, if you have any questions feel free to contact us via the support forum.
LocationGroups
CampaignCriterion
It's that time again - time to say goodbye to another version of the DFP API. In accordance with our deprecation schedule, v201403 has been deprecated and is scheduled for sunset on Tuesday, June 30 2015. At that time, any requests made to v201403 will return errors.
If you're currently using v201403, there's still time to migrate to the latest and greatest v201502. To do so, check the release notes to identify any breaking changes, grab the latest version of your client library, and update your code!
Things to look out for include:
- Chris Seeley, DFP API Team
Now that it’s spring again (in the Northern Hemisphere at least), it’s time for DFP’s annual spring cleaning! In this edition, we’ll be doing some pruning of our ReportService. What does this mean for you? We’re sunsetting some reporting dimensions, attributes, and metrics in existing versions (before the version is fully sunset), so your reports will break if you don’t migrate before the shutoff dates. I know what you’re wondering: “should I panic?”. Absolutely not. This type of behavior rarely occurs, so as long as you phase out usage for these particular fields, you should be fine moving forward.
Remember when Doubleclick for Publishers was called DART? I, too, get nostalgic about our old ad server, but it’s been a couple of years since we transitioned to the new DFP platform, and it’s just about time when the merged reporting columns are no longer useful (these columns only existed so you could continue reporting on delivery that spanned DART and DFP). In all versions after v201502, we will no longer provide merged reporting columns and dimension attributes in the API, that is, anything starting with 'MERGED_' or contains '_LIFETIME_MERGED_.' After August 1, 2015, these columns and dimension attributes will stop returning data entirely and will return INVALID_COLUMNS in all versions that still include them.
There are three scenarios in which you’re using these columns:
But wait, there’s more! Our next API version (v201505) will be the last to support some of our infrequently used dimensionFilters.
In each of the cases above, the filters either no longer provide meaningful information (as is the case with mobile vs. web line items and ad units with platform unification complete), or weren’t being used at all.
Similar to the changes above, after August 1, 2015, these dimension filters will return an INVALID_DIMENSION_FILTERS error in any version that still includes them.
So if you’re using any of the reporting features above, consider this an early heads up (and an opportunity) to refactor some of your code for spring cleaning.
As usual, if you have any questions, comments, or concerns, don’t hesitate to let us know on the forums.
- Nicholas Chen, DFP API Team
We have launched the Google Mobile Ads Unity Plugin v2.2.1. The updated v2.2.1 Unity package is available for download on GitHub here.
Google Mobile Ads Unity Plugin v2.2.1 introduces support for additional banner position locations. The full list of banner positions is as follows:
The additional positions are specified by setting the AdPosition value when instantiating a bannerView:
//Create a banner at the top-right of the screen.BannerView bannerView = new BannerView(adUnitId, AdSize.Banner, AdPosition.TopRight);
With the v7.0.0 release, the iOS Ads SDK became a module framework and Google Mobile Ads Unity Plugin v2.2.1 complies with this change. For modules to work, you must enable them in the project build settings. Search for "modules", and set Enable Modules to YES. The Link Frameworks Automatically option should be set to YES as well.
Enable Modules
YES
Link Frameworks Automatically
Unity 5.0 has moved out of beta and brings with it support for Automatic Reference Counting (ARC) for iOS. v2.2.1 of the Unity plugin takes advantage of ARC with no additional changes in project settings or code.
The source code and a sample app for the plugin are available on our GitHub repo. A changelog for this release is listed here. 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.
A few weeks back we hosted a workshop for the Display Ads APIs and SDKs where we gave presentations on the DFP API, IMA SDK, and Mobile Ads SDK. If you weren’t able to attend, or want a refresher on something you saw that day, you can check out our presentation videos and slides. If you have any questions about those videos, feel free to ask on our respective forums:
function listUserProfiles() { // Retrieve the list of available user profiles var profiles = DoubleClickCampaigns.UserProfiles.list(); if (profiles.items) { // Print out the user ID and name of each for (var i = 0; i < profiles.items.length; i++) { var profile = profiles.items[i]; Logger.log('Found profile with ID %s and name "%s".', profile.profileId, profile.userName); } }}
Imagine you’ve just finished creating a line item targeting mobile devices in DFP, and your manager comes to you and says, “Bad news! Our Android developer was just eaten by a bear, so now it’s your job to get that line item into our new app.” Don’t worry! Displaying DFP ads in Android applications is surprisingly easy.
If you’re already using the Mobile Ads SDK in your project, you’re ready to go. If not, check our quick starts for Android Studio and Eclipse to learn the best way to include the SDK.
To display your new line item, you’ll need to retrieve its ad unit ID from DFP. Log into your account, locate the ad unit that targets the new line item, and look for a “Generate tags” button to the right of its name. Clicking that button will display a dialog with some options for the type of tag to generate:
Select “Mobile applications” in the Tag Type dropdown, and you’ll see the correct ad unit ID and ad unit size for your line item. Armed with those two pieces of info, you’re ready to start coding.
DFP banner ads are displayed with the PublisherAdView class. It’s possible to create instances on the fly and add them to a layout programmatically, but the better practice is to define them in your XML layout files. Here’s an example element:
<com.google.android.gms.ads.doubleclick.PublisherAdView android:id="@+id/banner_ad" android:layout_width="wrap_content" android:layout_height="wrap_content" ads:adSize="320x50" ads:adUnitId="/1234567890/DemoAccount/BearRepellent"/>
Note the adSize and adUnitId attributes. These should be set to match the ad unit ID and size shown in the Generate Tags dialog. See our banner guide for more information about setting custom or multiple sizes.
With the PublisherAdView defined in your layout file, you just need to add a few lines of code to its corresponding Java class:
PublisherAdView adView = (PublisherAdView)findViewById(R.id.banner_ad);PublisherAdRequest request = new PublisherAdRequest.Builder().build();adView.loadAd(request);
PublisherAdRequest.Builder is a factory class that builds PublisherAdRequest objects. This example uses a simple, unmodified request, but there are a number of ways to add custom targeting, network extras, and test device information when building your own. See the targeting section of our banner guide for details.
With the layout updated and request code in place, your app is ready to show an ad!
Feel free to use the code from this example in your own applications, and if you have any questions, come and see us on our forum.
