Google Ads Developer Blog

OAuth in Ads APIs

Tuesday, August 21, 2012

Authorization is an important concern when writing software that interacts with Google’s Ads APIs. We’ve recently improved our documentation and published resources documenting how to use OAuth2 with many of our Ads APIs.

OAuth2 is an authorization flow that allows you to direct a user to a specially crafted Google URL where they grant permissions to your software to make changes to their account. With an authorized access token, you can make requests to Ads APIs on the user’s behalf. Benefits include:

Users don’t need to provide a username and password - they just log into Google.
No CAPTCHA challenges.
Limited scope - the user will only be prompted to grant access to a specific part of their account. For example, they could grant access to AdWords without the application being able to see their email or calendar.

OAuth2 is supported by:

The Ads API client libraries supported by Google have built-in support for OAuth2. We’ve included examples demonstrating how to use this feature in all client libraries. See your respective product and language product sites for more information on OAuth2.

We’re also hosting a Google Developers Live event covering how to use OAuth2 on August 23rd. This will be recorded if you can’t make it. If you have any questions about OAuth2, please post on the respective product API forums.

- Kevin Winter, AdWords API Team

Introducing the new Ads Developers Google+ Page

Tuesday, August 21, 2012

Today we are excited to introduce a new channel for communication - Ads Developers Google+ Page. It's a place to stay informed, engaged and connected on Ads products and developer tools.

Add our Google+ page to your circles for the latest product and feature announcements, best practices, case studies, as well as opportunities to interact with and learn from Google's Ads Developer Relations team and other members of the developer community.

We look forward to having one place to bring timely updates, concise announcements, and to share information in multimedia formats across all Ads products, as well as to listen and respond to your comments.

- Danial Klimkin, Ads Developer Relations Team.

New Developments for the DFA API

Monday, August 20, 2012

We have some exciting changes and important announcements for the DoubleClick for Advertisers community as we begin to improve our overall approach to APIs for the product. This is just the first of many improvements that will come over the next several quarters.

DFA API v1.19 - Security at the Forefront

The newest release of the DFA API, v1.19, is now available. This release brings two major security enhancements. SSL encryption, a feature we originally slated for v1.18, is now mandatory on all API requests. This is in line with a Google-wide effort to leverage HTTPS connections for greater security.

Secondly, this release of the DFA API supports OAuth2 authentication in addition to the API passwords tied to your DFA user profiles. We recommend using this new approach. In time, we plan to phase out the profile-specific passwords in favor of making OAuth2 the single, standard way to authenticate against our API. Please see our documentation for more information on how OAuth2 is integrated with the DFA API and reference our client libraries, all of which will soon be updated with examples of using OAuth2 instead of an API password.

Our release notes page has been updated with complete notes on v1.19.

DFA Reporting Gets an API

Less than a year ago, we announced the availability of the new DFA Reporting system. This new system offers the power, flexibility and data access required to keep up with today’s always-connected, multi-device consumer. Compared to Report Central, data in the new DFA Reporting system is fresher, can be segmented by the hour, and includes a host of new features including geographic reporting for all ads. Today, we are pleased to launch an API for the new DFA Reporting system.

The DFA Reporting API is a language-neutral REST API that offers programmatic access to the same reports as can be generated through the DFA Reporting user interface. Along with improved speed and performance, the new API will allow you to create, edit, and schedule Standard reports. We will continue to launch additional features to the new DFA Reporting API over the next few months. Support for this API has been added to the Google APIs Client Libraries. The Java library currently has the most complete example set.

Version Enforcement on the Java DART API

The Java DART API, long the bread and butter of integrating with our ReportCentral service, has a large range of versions currently in use. We are going to begin enforcing a minimum version requirement on this API on November 3rd, 2012. At this time, clients will be must be using one of the newest versions of the Java DART API -- version 13.4, version 13.6, or version 13.8. We recommend you take the opportunity to consider the new DFA Reporting API. Come enjoy the benefits of its newer technology.

Changes to Our Deprecation Policy

This past April, Google announced changes to the deprecation policies surrounding our APIs to help keep our products moving and innovating quickly. DFA is joining this overall Google effort. As such, as of November 3rd, 2012, DFA will remove the depreciation policy for all of our APIs.

The removal of the deprecation policy doesn't mean we have changed the way we think about our APIs. As signaled by the launch of the new DFA Reporting API, we are more committed than ever to offering stable and relevant APIs to our developer community. We will continue to work very hard to communicate any changes to our APIs well in advance, regardless of the APIs' deprecation policy. Our commitment to our clients and to the API remains unchanged.

Until November 3,2012 we will continue the deprecation policy we currently have in place. With the the release of v1.19, version v1.17 is now deprecated. Version v1.17 will continue to be supported until September 8th, 2012, when it will be entirely removed from service, as previously announced. Meanwhile, version v1.18 will be deprecated in November and sunset in early December, 2012.

As always, we highly value your feedback and questions. Please join us on our forumwhenever you’d like to reach us.

- Joseph DiLallo, the DFA API Team

Next round of Google Ads Developers Live events

Wednesday, August 8, 2012

Interested in more Google Ads Developers Live (Office Hours) events? We know you are because attendance has been great!

We've scheduled another round of events for AdWords, AdMob, DFP and AdSense APIs. You can view the newly scheduled live events on the Google Ads Developers Live page. Please add the events you are interested in to your calendar. You can follow our schedule by subscribing to the Google Ads Developers Office Hours calendar, which is also linked on this blog’s sidebar.

Just like in previous live events, you can join these hangouts to ask us questions or provide feedback about our products. In response to your request we will be adding AdWords API sessions for the Asia Pacific region and Japan. If you are from Asia Pacific countries or Australia and couldn’t join the hangouts before due to timezone inconvenience, we hope you will find these additional sessions more convenient. The live events in Japan will be in Japanese.

Events will rotate throughout the week to accommodate more people. We are also planning to make some of these events topic-based, where we will introduce you to a new feature of our product and then answer your questions on that topic. The dates and topics for these sessions will be announced in advance in separate blog posts.

In case you haven’t joined us before, you will need 3 things to join the hangout:

A Google+ account (sign up here)
The Google voice and video plugin installed on your computer
A quiet place to hangout so we can hear you

These hangouts are informal and conversational, which make them a great place to ask questions or give us feedback. If you have questions about our office hours, reach out to us on the forums.

- Anash P. Oommen, Ads Developer Relations Team

Getting AdMob ads to work with cocos2D Part 2: Handling Autorotation

Wednesday, August 1, 2012

In the first part of this series, we talked about integrating AdMob ads in a cocos2d application without diminishing performance. However, we conveniently overlooked how you’d go about handling device reorientation. This blog post will outline the two steps necessary for getting autorotation to work using v0.99.5b3 or higher of the cocos2d framework.Step One: Setting UIKit Autorotationcocos2d allows you to handle autorotation in two different ways (UIKit and cocos2d). Since we’re working with both UIKit views as well as Open GL views, we want to rely on UIKit autorotation. If not, we’d have to transform our GADBannerView manually. To make sure you’re using UIKit autorotation, set the GAME_AUTOROTATION directive on your platform of choice to kGameAutorotationUIViewController.Once you’ve done this, check RootViewController.m to make sure shouldAutorotateToInterfaceOrientation: returns YES for all of the orientations that you support. cocos2d produces skeleton code that handles this method differently depending on the autorotation method you’re using, so make sure that you modify the code block where GAME_AUTOROTATION == kGameAutorotationUIViewController.Step Two: Modifying View LayoutThe final step is to modify our resizeViews: method so that it takes the orientation of the device into account when laying out the views. Rewrite resizeViews: as resizeViewForOrientation:, using the orientation parameter to lay out your GADBannerView. The code below, similar to the first blog post, assumes you’re laying out your banner at the top of the screen.- (void)resizeViewsForOrientation:(UIInterfaceOrientation)toInt { // If the banner hasn't been created yet, no need for resizing views. if (!bannerView_) { return; } BOOL adIsShowing = [self.view.subviews containsObject:bannerView_]; if (!adIsShowing) { return; } // Frame of the main RootViewController which we call the root view. CGRect rootViewFrame = self.view.frame; // Frame of the main RootViewController view that holds the cocos2d view. CGRect glViewFrame = [[CCDirector sharedDirector] openGLView].frame; CGRect bannerViewFrame = bannerView_.frame; CGRect frame = bannerViewFrame; // The updated x and y coordinates for the origin of the banner. CGFloat yLocation = 0.0; CGFloat xLocation = 0.0; // Move the root view underneath the ad banner. glViewFrame.origin.y = bannerViewFrame.size.height; // Center the banner using the value of the origin. if (UIInterfaceOrientationIsLandscape(toInt)) { // The superView has not had its width and height updated yet so // use those values for the x and y of the new origin respectively. xLocation = (rootViewFrame.size.height - bannerViewFrame.size.width) / 2.0; } else { xLocation = (rootViewFrame.size.width - bannerViewFrame.size.width) / 2.0; } frame.origin = CGPointMake(xLocation, yLocation); bannerView_.frame = frame; if (UIInterfaceOrientationIsLandscape(toInt)) { // The super view's frame hasn't been updated so use its width // as the height. glViewFrame.size.height = rootViewFrame.size.width - bannerViewFrame.size.height; glViewFrame.size.width = rootViewFrame.size.height; } else { glViewFrame.size.height = rootViewFrame.size.height - bannerViewFrame.size.height; } [[CCDirector sharedDirector] openGLView].frame = glViewFrame; } Now that you’re handling rotation, you’re going to have to resize your views in two different places. We’ve already covered this in initGADBanner: in the first post (simply use the interfaceOrientation property of UIViewController to call resizeViewsForOrientation: instead of resizeViews:). Here, we also have to call resizeviewsForOrientation: in willRotateToInterfaceOrientation:duration: as well. You can add this call after the skeleton code that cocos2d provides.Ads inside your cocos2d application should now stay docked in place whenever device rotations occur. You can check out a full example from this blog post here. As always, feel free to direct any questions you have to our forum or join us for our upcoming hangout.

- Raj Parameswaran, AdMob Team

Getting AdMob ads to work with cocos2D

Tuesday, July 31, 2012

cocos2d for iPhone is a popular framework for building 2D games for iOS. Integrating AdMob ads into cocos2d apps has gotten significantly easier with the latest version of the framework; This blog post will show you three things to keep in mind using v0.99.5b3 or higher of the cocos2d framework. It is assumed that you already have some familiarity with cocos2d.InitializationCreate and initialize a GADBannerView in the RootViewController class. You can put this code into a new method knowing that it will be called from the AppDelegate after the view hierarchy has been set up. This code adds to the standard banner view example in the docs.- (void)initGADBanner { // NOTE: // Add your publisher ID here and fill in the GADAdSize constant for // the ad you would like to request. bannerView_ = [[GADBannerView alloc] initWithAdSize:kGADAdSizeBanner]; bannerView_.adUnitID = @"PUBLISHER_ID_HERE"; bannerView_.delegate = self; [bannerView_ setRootViewController:self]; [self.view addSubview:bannerView_]; [bannerView_ loadRequest:[self createRequest]]; // Use the status bar orientation since we haven't signed up for // orientation change notifications for this class. [self resizeViews]; } Performance ConsiderationsNotice the addSubview: in initGADBanner:. Why did we add the GADBannerView directly to the RootViewController’s hierarchy instead of the cocos2d scene’s hierarchy? cocos2d scenes are OpenGL views, whereas our GADBannerView is a UIWebView wrapped in a native UIView. OpenGL views will usually be refreshed often, whereas our GADBannerView will be mostly static. Placing our GADBannerView on top of the OpenGL view therefore can lead to a performance decrease as the device will have more drawing to do.You can test if this performance decrease is significant for your specific project by logging the frame rate when you place the ad within the OpenGL view and outside of it. The performance cost is usually only significant when you are dealing with very complex hierarchies.View LayoutSince we’ve decided to place our GADBannerView into the RootViewController’s view hierarchy, we also need to now make sure to resize our cocos2d view to make space for our GADBannerView. The resizeViews: in initGADBanner: is called for this purpose. The implementation for resizeViews: is below. The main OpenGL view which encompasses all of the cocos2d scenes can be grabbed using the +sharedDirector object. The code below assumes you’re going to display the ad at the top of your screen, and have a device that’s in landscape.- (void)resizeViews: { // If the banner hasn't been created yet, no need for resizing views. if (!bannerView_) { return; } // If ad is not showing, no need to resize views. BOOL adIsShowing = [self.view.subviews containsObject:bannerView_]; if (!adIsShowing) { return; } // Frame of the main RootViewController which we call the root view. CGRect rootViewFrame = self.view.frame; // Frame of the main RootViewController view that holds the cocos2d view. CGRect glViewFrame = [[CCDirector sharedDirector] openGLView].frame; CGRect bannerViewFrame = bannerView_.frame; CGRect frame = bannerViewFrame; // The updated x and y coordinates for the origin of the banner. CGFloat yLocation = 0.0; CGFloat xLocation = 0.0; // Move the root view underneath the ad banner. glViewFrame.origin.y = bannerViewFrame.size.height; // The superView has not had its width and height updated yet so use those // values for the x and y of the new origin respectively. The game is in // landscape. xLocation = (rootViewFrame.size.height - bannerViewFrame.size.width) / 2.0; frame.origin = CGPointMake(xLocation, yLocation); bannerView_.frame = frame; // The super view's frame hasn't been updated so use its width // as the height. Assume device is in landscape. glViewFrame.size.height = rootViewFrame.size.width - bannerViewFrame.size.height; glViewFrame.size.width = rootViewFrame.size.height; [[CCDirector sharedDirector] openGLView].frame = glViewFrame; } With that, you should now see AdMob ads show up in your cocos2d application. Look out for a follow-up to this blog post where we will discuss how to handle autorotation. As always, feel free to direct any questions you have to our forum or join us for our upcoming hangout.

- Raj Parameswaran, AdMob Team

AdMob SDK 6.1 Released

Monday, July 23, 2012

Last week, we released AdMob SDK v6.1 for both Android and iOS. This SDK contains a number of important bug fixes and exciting new features including:Additional DoubleClick supportDoubleClick publishers will be happy to know that AdMob now provides support for app events, giving them the ability to execute custom code in their application when a creative dispatches an app event. Additionally, the new SDK provides support for multiple ad sizes using the same banner.Easy access to Google AnalyticsYou’ll notice we’ve included the latest Google Analytics package in the “Add-Ons” directory. The new mobile app analytics provides the same best-in-class Google Analytics reporting, but for mobile apps.If you have any questions about the AdMob SDK, please let us know on the forum or hang out during our upcoming AdMob/DFP office hours. For more information about this new SDK, take a look at our release notes.

- Raj Parameswaran, AdMob Team

Ads Developer Blog

OAuth in Ads APIs

Introducing the new Ads Developers Google+ Page

New Developments for the DFA API

Next round of Google Ads Developers Live events

Getting AdMob ads to work with cocos2D Part 2: Handling Autorotation

Getting AdMob ads to work with cocos2D

AdMob SDK 6.1 Released

Labels

Archive