Showing posts with label admob_sdk. Show all posts
Showing posts with label admob_sdk. Show all posts

Thursday, August 23, 2012

Docs Grow Ears: Google Feedback now in Google Ads Developer Documentation


If you've recently visited any of the Google Ads Developer documentation, you may have noticed a "Feedback on this document" link at the top right corner of a page. That's right—you can now use that link to report errors, comment on existing content, or request further clarification for any of the Google Ads Developer docs:




In addition to this new channel, you can continue to reach out to us through the developer forums or Google Developers Live events.



Quang Nguyen, Ads Developer Relations Team

Wednesday, August 22, 2012

Announcing Ad Catalog v2 for iOS


We are pleased to announce the release of Ad Catalog v2 for iOS. Ad Catalog is a sample application which showcases a number of best practices when it comes to integrating AdMob ads into your iOS application.




This updated version shows how to integrate AdMob ads into four different types of iOS layouts - TabbedView, TableView, ScrollView and OpenGLView. Highlights include:



  • The TabbedView example shows how to correctly implement a GADBannerView singleton that gets reused across many different views

  • The TableView example shows how to correctly reuse a single ad inside multiple cells in a TableView

  • The OpenGL and ScrollView examples show how to correctly dock an ad to the top or bottom of your screen, outside of your content





You can download a zip file from the google-mobile-dev download page, or you can get the source by taking a look at our online repository.




If you have any comments, questions, or feature requests for Ad Catalog, please let us know about them on the forum or during our office hours.






Tuesday, August 21, 2012

Introducing the new Ads Developers Google+ Page


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.



Wednesday, August 8, 2012

Next round of Google Ads Developers Live events


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:


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.




Wednesday, August 1, 2012

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

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 Autorotation

cocos2d 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 Layout

The 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.





Tuesday, July 31, 2012

Getting AdMob ads to work with cocos2D

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.




Initialization

Create 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 Considerations

Notice 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 Layout

Since 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.





Monday, July 23, 2012

AdMob SDK 6.1 Released

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 support

DoubleClick 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 Analytics

You’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.





Thursday, June 28, 2012

Keeping A Smart Banner Docked To The Bottom Of The Screen on iOS


Smart Banner advertisements, introduced in AdMob SDK v6.0, help developers utilize the full width of the iPhone and iPad screen for displaying ads. You still have to be smart about using Smart Banners! We are noticing that some of you are having a hard time resetting your ad’s origin when a re-orientation of the device occurs. More specifically, not resetting the ad’s origin correctly causes ads to disappear offscreen after orientation changes. In this blog post, we’ll show you how to keep a Smart Banner docked to the bottom of the screen on iOS.




The first thing to do is to initialize a Smart Banner at the bottom of the device’s screen. You can do this by giving the ad an origin corresponding to the screen bottom.




// Initialize the banner docked to the bottom of the screen.
// We start in a portrait orientation so use kGADAdSizeSmartBannerPortrait.
CGPoint origin = CGPointMake(0.0,
self.view.frame.size.height -
CGSizeFromGADAdSize(
kGADAdSizeSmartBannerPortrait).height);

self.adBanner = [[[GADBannerView alloc]
initWithAdSize:kGADAdSizeSmartBannerPortrait
origin:origin] autorelease];

//Continue rest of initialization here



Every time an orientation change occurs, you have to reset the ad’s orientation so it continues to stay docked to the bottom. The best place to implement the above logic is in the willAnimateRotationToInterfaceOrientation:duration: method since the view’s frame has been updated to the new orientation




Update the origin by utilizing the Smart Banner constant that is applicable to your current orientation. The only value that should change is your y-origin, since your x-origin should remain at 0.




-(void)willAnimateRotationToInterfaceOrientation:(UIInterfaceOrientation)toInt
duration:(NSTimeInterval)duration {
// The updated y value for the origin.
CGFloat yLocation;

// Set a new frame to update the origin on orientation change. Remember to set
// adSize first before you update the frame.
if (UIInterfaceOrientationIsLandscape(toInt)) {
self.adBanner.adSize = kGADAdSizeSmartBannerLandscape;
yLocation = self.view.frame.size.width -
CGSizeFromGADAdSize(kGADAdSizeSmartBannerLandscape).height
} else {
self.adBanner.adSize = kGADAdSizeSmartBannerPortrait;
yLocation = self.view.frame.size.height -
CGSizeFromGADAdSize(kGADAdSizeSmartBannerPortrait).height);
}

CGRect frame = self.adBanner.frame;
frame.origin = CGPointMake(0.0, yLocation);
self.adBanner.frame = frame;
}



If you’re not using mediation, changing the adSize after your first request will cause another request to be made. Make sure that you set the frame after you modify the adSize. This ensures that the ad transition looks smooth across orientation changes.




Your Smart Banner ads are now even smarter. As the orientation of the device changes, your ads should stay docked to the bottom of the screen. If you have any questions about Smart Banners or about the AdMob SDK, feel free to post them in our forum or keep on the lookout for upcoming Hangout office hours.





Thursday, June 21, 2012

Show a Custom Image When No AdMob Ad Is Available: Part 2

We previously discussed how to show a custom image using the Google AdMob SDK when an ad request can’t be filled. In the second and final part of this series, we’ll explain how to resume showing AdMob ads if, for example, internet connectivity is restored.



In part 1, we demonstrated how to hide the ad and display a custom image when the first ad request fails. However, the AdMob SDK doesn't make another ad request until it successfully receives an ad, so you must schedule your own refresh. Here’s how to do it:




private final Handler refreshHandler = new Handler();
private final Runnable refreshRunnable = new RefreshRunnable();
private boolean firstAdReceived = false;

@Override
public void onFailedToReceiveAd(Ad ad, ErrorCode code) {
if (!firstAdReceived) {
// Keep code from part 1.
...
// Schedule an ad refresh.
refreshHandler.removeCallbacks(refreshRunnable);
refreshHandler.postDelayed(
refreshRunnable, REFRESH_RATE_IN_SECONDS * 1000);
}
}

private class RefreshRunnable implements Runnable {
@Override
public void run() {
// Load an ad with an ad request.
adView.loadAd(new AdRequest());
}
}


A Handler is used to schedule an ad refresh at your desired refresh rate. Before making the postDelayed call, the handler removes any pending posts that may be queued.



With these changes, your application will request an AdMob ad at a regular interval. Once a request is successful, the existing code in onReceiveAd swaps out your custom image with an AdMob ad, and AdMob starts refreshing automatically.



If the user either leaves your app or clicks on your custom ad, you want to pause your refresh handler when your app is not visible to the user. This is an Android best practice that will help preserve battery life. You can override Android’s onStop and onStart callbacks to stop and start ad refreshes, as shown below:




@Override
public void onStop() {
super.onStop();
// Remove any pending ad refreshes.
refreshHandler.removeCallbacks(refreshRunnable);
}

@Override
public void onStart() {
super.onStart();
if (!firstAdReceived) {
// Request a new ad immediately.
refreshHandler.post(refreshRunnable);
}
}


This code prevents your app from making ad requests when the user exits your app but immediately requests an ad when the user returns to your app.



That’s it! You’ve successfully integrated a placeholder image into your application to stand in when an ad request can’t be filled. Check out the full example if you have trouble setting up the code.

As always, let us know on the forum if you have any questions about the Google AdMob SDK, or join us during office hours.