[go: up one dir, main page]

The recently released Version 2.0 of cocos2d for iPhone deprecated the use of RootViewController in cocos2d projects. Previously, we showed you how to integrate AdMob ads by leveraging the RootViewController. Here, we show you the updated way of integrating AdMob ads into cocos2d v2.0 projects.

All of your initialization can now be done in the layer where you’d like the ad to show. In your layer’s init function, you can set up your ad banner as you would normally.

-(id) init
{
    // Do other layer initialization here.

    adBanner_ = [[GADBannerView alloc] initWithAdSize:kGADAdSizeBanner];
    adBanner_.adUnitID = @"YOUR_ADMOB_PUBLISHER_ID";
    adBanner_.delegate = self;
    ….
}

The tricky part here is setting the rootViewController property for your GADBannerView and putting it into your view hierarchy. Version 2.0 of cocos2d uses a UINavigationController as its top-level view controller. The main OpenGL view is placed inside this controller. You want to set your rootViewController to be the main navigation controller.

AppController *app = (AppController*) [[UIApplication sharedApplication] delegate];
[adBanner_ setRootViewController:[app navController]];

There are performance considerations to think about when adding a GADBannerView into your hierarchy. Overlaying UIKit layers on top of OpenGL layers can lead to lower frame rates for apps that draw often. However, with newer hardware, this performance decrease is less of a concern. As always, we recommend that you profile your application’s performance to determine what works in your situation.

For our example, we will add the GADBannerView on top of the OpenGL view. This involves accessing the view being shown from the sharedDirector object.

[[CCDirector sharedDirector].view addSubview:adBanner_];

Remember that since you are creating GADBannerView objects, you will have to clean them up with dealloc as well.

- (void) dealloc {
  adBanner_.delegate = nil;
  [adBanner_ release];
  [super dealloc];
}

You should now see AdMob ads show up in your cocos2d application. If there are any other integration topics you would like to see, or any technical questions you have, please let us know about them on the forum or check out our G+ page.


A new release of the DFA Reporting API, version 1.1, extends the ability of your applications to tap into the power and flexibility offered by our new reporting platform.

Feature Parity with ReportBuilder

Using the DFA Reporting API, you can now take advantage of all of the report types in ReportBuilder:

  • STANDARD
  • REACH
  • PATH_TO_CONVERSION
  • FLOODLIGHT

The API contains support for CROSS_DIMENSION_REACH reports, but the backend currently does not. Support for these reports will be turned on at a later date and will be accessible through version 1.1.

Additionally, you may now set a list of recipients to be emailed when a scheduled report runs. We have paved the way for downloading reports in different formats, though currently CSV is the only available option.

A Few Backwards Incompatible Changes

We have taken the opportunity to make a few backwards incompatible changes to the API. It will not be standard procedure to make changes like this in minor version releases, but since the API is still relatively new, locking down the final structure of our API now will reduce changes later and ease development. These changes include:

  • Report files and report criteria now share the same dateRange kind.
  • The urls object in the File resource has changed to support report formats other than CSV.
  • A customRichMediaEvents and an activities kind have been added, both of which are reused between different report types.

Our updated release notes page has a full list of changes for your reference. As always, we highly value your feedback and questions. Please join us on our forum whenever you’d like to reach us.

Today, we released v6.2 of the AdMob SDK for iOS developers. This release includes a number of bug fixes as well as some important changes for iOS 6 and the iPhone 5. This post will go through some important differences developers should keep in mind when working with AdMob v6.2. All of our developer docs have already been updated to reflect these change.


XCode 4.5 and iOS 6

We’ve made a number of changes to add support for both iOS 6 and the iPhone 5. This means that you will need to use XCode 4.5 and build against iOS 6 when using our SDK. You can still support down to iOS 4.3 by setting your “Deployment Target” to iOS 4.3 in your project’s Application Target.




Support for armv7s

The iPhone 5 is powered by the A6 processor which uses the armv7s architecture, so targeting armv7s will optimize your app to run on iPhone 5. We’ve dropped support for the armv6 architecture and added support for the armv7s architecture in this release (we also still support armv7). New projects created via XCode 4.5 default to supporting armv7 and armv7s, meaning that this shouldn’t be an issue as long as you’re using the correct version of XCode.

If you’re targeting the armv7s architecture, you will not need to add the -all_load linker flag to your projects anymore. If you were using this specifically for AdMob, you can now safely remove the flag from the “Other Linker Flags” section of your project’s “Build Settings”. You will still need to have the -ObjC linker flag in this section.


Identifier for Advertising

We are now also using Apple’s Identifier for Advertising for personalization and reporting. You will have to link against the AdSupport framework in your applications when using the AdMob SDK in order to support this feature. You can do this by adding the AdSupport.framework to the “Linked Framework and Libraries” section of your application’s Target settings. Make sure that you link the framework using the “Optional” setting if your application can run on an iOS version below iOS 6.


Auto Layout Support

Apple introduced Auto Layout for iOS 6 to help support multiple screen sizes. All of our AdMob banners have been updated to work with Auto Layout. When using Auto Layout (in code) with a GADBannerView, you must:

  • Remember to set the translatesAutoresizingMaskIntoConstraints property on the GADBannerView to NO
  • Make sure the GADBannerView’s frame is big enough to receive the ad type requested

We will release some sample code showcasing best practices when using Auto Layout very soon.


You can download the latest SDKs from our downloads page. If you’ve got any other questions or concerns about using the new AdMob SDK, please ask us in the forum or check out our G+ page.

Last week, we caught up with Vishay Nihalani from the AdMob team in Mountain View, CA. Vishay is the Product Manager for the AdMob Mediation effort here at Google. Mediation helps developers easily integrate and manage multiple ad networks into their Android and iOS applications. Vishay was able to provide some useful insight on why AdMob built mediation, what the benefits are, and what to expect in the future. Let’s find out what he had to say.

Hello, Vishay. Thanks for taking the time to talk to us about AdMob Mediation! Can you tell us what prompted AdMob to develop a mediation framework?

That’s a great question. When Google acquired AdMob, we also acquired AdWhirl, an open source ad mediation solution that helped developers fill every ad request instead of only a few requests. The popularity of AdWhirl made it clear that mediation was something that developers wanted.

At Google, we decided to take the concept of AdWhirl a step further by integrating mediation directly within AdMob, allowing us to scale the product and add new features that developers need.

What is the benefit of switching to AdMob Mediation?

Developers should use mediation to make sure that no ad request goes unfilled. AdMob mediation in particular has some cool features that help you to maximize your revenue by using the highest paying networks first. Since many networks tend to focus on specific regions, AdMob allows you to set eCPM values at the country level as well.

Like AdWhirl, AdMob Mediation is free no matter how many impressions you serve, allowing you to scale your app and take full advantage of this feature.

Should I still use mediation if I’m only using AdMob?

Mediation is largely geared for multiple networks, but there are advantages to using mediation even if you’re only using AdMob. Using mediation, you can quickly serve house ads to all your users. You can use mediation to add a promotion advertising campaign for a new app you’ve just launched before showing a network ad, or to promote your other apps if the AdMob network has no ad to fill your request.

Why did AdMob decide to do client-side mediation as opposed to server-side integration?

One of our main goals with AdMob Mediation is to scale to as many ad networks as possible. Not all ad networks have server side APIs, and we didn’t want to have this barrier to joining our mediation offering.

Another huge benefit to client-side mediation is that it is transparent and neutral. Any third party network can easily plug into AdMob Mediation, and all interactions between the third-party SDK and the third-party ad server is completely independent of AdMob. A good example of this is the skyscraper format - even though the AdMob network doesn’t offer skyscraper ads, AdMob Mediation still supports third-party ad networks who want to serve skyscraper ads through mediation.

Finally, doing client-side mediation allows us to easily add new partners. We don’t have to wait for the next AdMob SDK release cycle to launch them.

Can you tell us about any new features coming to AdMob Mediation, or where the product is headed?

We’re planning to make it even easier to integrate mediation into your application by making all ad network placements mediated by default. This means you won’t need to swap out IDs when you switch to mediation. We want to make it easier to help maximize your revenue, and we have some features in the works that we think developers will be excited about!

Enough about mediation...Tell us about some of your hobbies/interests outside of work.

I play a ton of soccer and I love to travel. Sometimes I even travel to watch soccer. I attended the World Cup in 2010, and I’ve already blocked off my calendar for Brazil 2014!

Wow, that’s exciting! Other than the World Cup, what was the most exciting part about visiting South Africa?

I went shark cage diving with great white sharks not far from where the Indian and Atlantic oceans intersect. There was this intense moment where a great white was lured in by the bait and was thrashing at a tuna’s head about a foot away from my face! It was a serious Jaws moment.

Thanks for the interview, Vishay. Now get back to work and help us make more money!


We’re happy to announce the release of v4.1 of the AdSense Host API. Don’t let the numbering fool you, this is a major update that provides a ton of new functionality!

The new version is intended as a full replacement of AdSense Host API v3 for ContentAds hosts, with a few extra features. Changes from v4 include added support for:

With this new release, we're also announcing the sunset of version 3 of the Host API, to take place on January 1, 2013. Over the next few weeks, we will be getting in touch with existing hosts and helping them get started with the migration.

If you’re not an AdSense host yet and are interested in joining the program, take a look at our introduction page to find out more about the requirements and how it works.

Let us know if you have any questions!


Today, we are announcing the deprecation of versions v201108, v201111, and v201201 of the DFP API. In roughly 3 months, on Dec 10th, these versions will be turned off. Turning off older versions allows us to make sure that everyone can benefit from the improvements in more recent releases and to focus on releasing new features.

Although we are not announcing the deprecation of any other versions at this time, we would still like to give our developers using v201203, v201204, and v201206 notice that those versions will most likely be deprecated next. Upgrading to v201208 now will reduce any future development time needed for an upgrade later.

As mentioned in previous deprecation announcements, we will always give at least 3 months notice before turning off a version. Our release notes page also contains changelogs for each version, which will help you migrate to a newer version. If you aren’t using one of our client libraries, now would be a great time to start as well. If you have any feedback or comments about this deprecation, or the API in general, please feel free to leave them on our forum.

 - , DFP API Team

Update: Ad Exchange will be affected by the downtime as well. Please see below for details.

As previously mentioned, we have an upcoming AdWords, Ad Exchange, and DFP service outage. This will occur on Saturday, September 22 -- AdWords, Ad Exchange, and DFP systems will be unavailable from approximately 10:00 am to 8:00 pm Pacific Time (17:00 Saturday to 03:00 Sunday GMT) due to system maintenance.

AdWords
During this time, your campaigns will continue to run as usual (with the settings you established as of 10am PST), but you won’t be able to make SOAP API calls or download reports. Requests to the AdWords API will fail with an HTTP 50x error during the maintenance window. Please also keep in mind that any automated rules scheduled during this time will not run and AdWords scripts will not execute during this period. We encourage you to verify your campaign settings prior to the outage.

Ad Exchange
During this time, your ad serving will continue to run per changes made prior to downtime period, but you will not be able to make API calls to Ad Exchange Buyer SOAP API. On Ad Exchange Buyer REST API, only the Direct Deals related API calls will be affected. For the Ad Exchange Real-Time Bidding Protocol, you will not be able to make changes to pre-targeting settings, everything else should continue to run as usual.

DFP
As mentioned above, ad serving will continue to run per changes made prior to the downtime period. If you use the audience feature in your network, any API call to the AudienceSegmentService service will fail with a SegmentError.UNEXPECTED_ERROR error. Also, if you target any audience segments in your line items, any calls to LineItemService, ForecastService, or LineItemCreativeAssociationService that involve those line items will fail.

We apologize for any inconvenience, and appreciate your patience as our engineers work to keep AdWords, Ad Exchange, and DFP running smoothly.

Version 1.1 of the Buyer REST API has been released bringing the following changes:

  • A list method has been added for the Creatives resource. 
  • The adgroupId has been removed from the Creatives resource. 
  • A region property has been added to the bidderLocation[] object. 

Creatives.List Method added 
The list method retrieves a list of all of the authenticated user's active creatives. Optional parameters allow you to set the maximum number of Creatives resources to return each time you call the method. You can also filter the contents of the list by the status of creatives, for example to restrict the contents of the list to those ads that have been approved. Valid status values are approved, disapproved, and not_checked.

Removed adgroupId property 
Beginning with Version 1.1 of the Buyer REST API, the adgroupId will no longer be returned from method calls. In addition, passing the adgroupId value to a Creatives method will raise an error. However, a creative submitted through the API can be used to respond to a pretargeting match for any ad group. The removal of this value means that the key to uniquely identify a creative now consists of accountId + buyerCreativeId.

Added region property to bidderLocation[] 
The bidderLocation[] list in the Account resource now includes a third value. The region property describes the region for the bidder location. You can contact your customer representative to determine whether or not your account is in the new quota system.

The value of region describes the geographical region from which the Ad Exchange should send requests. This value is used by the new quota system. Allowed values:

  • ASIA 
  • EUROPE 
  • US_EAST 
  • US_WEST 
 -- Irene Smith, Ad Exchange Team

In June we announced the limited release of AdWords scripts, a new AdWords tool that enables you to make changes to an AdWords account, such as updating keywords and ad copy or outputting account statistics, by writing simple JavaScript programs. Today we’re pleased to announce that AdWords scripts is available to all advertisers globally. In addition, we’re launching several frequently requested features that enable advertisers to:
  • Run more complex scripts - We extended the length of script executions from 5 minutes to 30 minutes, allowing you to make more complex changes. In addition, we’ve expanded the entity limit to 100K.
  • Use real-time data to manage campaigns - We’re adding support for Ad Parameters, which allow you to update numeric values in ads without having to delete and re-enter ad copy or wait for policy checks. Here’s a tutorial showing the use of US Geological Survey data to insert dynamic ad text.
  • Automate scripts with scheduling - You can now schedule scripts to run a single time, daily, weekly, or monthly.
To help you get started with AdWords scripts, we’re hosting two training events in the coming weeks.
  • On Tuesday, September 11th at 11:30am PST / 2:30am EST, we’ll be hosting a Hangout on Air through Google Developers Live, targeted to advertisers with more advanced coding skills. Questions asked via Moderator will be answered at the end of the presentation.
  • On Thursday, September 13th at 10amPST / 1pmEST, we’ll be hosting a Learn with Google webinar targeted to advertisers with basic JavaScript experience. During this webinar, we will provide an overview of what can be accomplished with Scripts, walk through ways to customize pre-set Scripts, and show you how to write Scripts from scratch. Click here to register.
Additional resources, including a getting started guide and tutorials, are available at https://developers.google.com/adwords/scripts/. You can also join the AdWords Scripts Forum to get help or share advice on AdWords scripts.

Posted by Katie Miller, Google Ads Team

On Saturday, September 8, AdWords and DFP systems will be unavailable from approximately 10:00am to 11:00am Pacific Time (17:00 to 18:00 GMT) due to system maintenance. A longer downtime will also be scheduled in the next few weeks -- please stay tuned for another blog post with more specific details.

AdWords
During this time, your campaigns will continue to run as usual (with the settings you established as of 10am PST), but you won’t be able to sign into your account or make changes. Requests to the AdWords API will fail with an HTTP 50x error during the maintenance window. Please also keep in mind that any automated rules scheduled during this time will not run and AdWords scripts will not execute during this period. We encourage you to verify your campaign settings prior to the outage.

DFP
As mentioned above, ad serving will continue to run per changes made prior to the downtime period. If you use the audience feature in your network, any API call to the AudienceSegmentService service will fail with a SegmentError.UNEXPECTED_ERROR error. Also, if you target any audience segments in your line items, any calls to LineItemService, ForecastService, or LineItemCreativeAssociationService that involve those line items will fail.

We apologize for any inconvenience, and appreciate your patience as our engineers work to keep AdWords and DFP running smoothly.