Working with Banner Views

Responding to Banner Events

Most banner view delegates implement all of the following behaviors:

- (BOOL)bannerViewActionShouldBegin:(ADBannerView *)banner willLeaveApplication:(BOOL)willLeave

{

    NSLog(@"Banner view is beginning an ad action");

    BOOL shouldExecuteAction = [self allowActionToRun]; // your application implements this method

    if (!willLeave && shouldExecuteAction)

    {

        // insert code here to suspend any services that might conflict with the advertisement

    }

    return shouldExecuteAction;

}

- (void)bannerViewDidLoadAd:(ADBannerView *)banner

{

    if (!self.bannerIsVisible)

    {

        [UIView beginAnimations:@"animateAdBannerOn" context:NULL];

// Assumes the banner view is just off the bottom of the screen.

        banner.frame = CGRectOffset(banner.frame, 0, -banner.frame.size.height);

        [UIView commitAnimations];

        self.bannerIsVisible = YES;

    }

}

- (void)bannerView:(ADBannerView *)banner didFailToReceiveAdWithError:(NSError *)error

{

   if (self.bannerIsVisible)

    {

        [UIView beginAnimations:@"animateAdBannerOff" context:NULL];

// Assumes the banner view is placed at the bottom of the screen.

        banner.frame = CGRectOffset(banner.frame, 0, banner.frame.size.height);

        [UIView commitAnimations];

        self.bannerIsVisible = NO;

    }

}

Canceling an Advertising Action

When the banner view covers your application’s user interface to perform its action, your application continues to receive events. Your application can read the bannerViewActionInProgress property of the banner view to determine whether a banner action is executing. Your application should scale back its activities and avoid actions that require interaction with the user.

If an event occurs that requires the user’s attention, you can invoke the banner view’s cancelBannerViewAction method to cancel the advertising action. The action ends, and the banner view calls the delegate’s bannerViewActionDidFinish: method.

Changing the Banner Size Dynamically

Applications that intend to resize the banner view after creation should configure the requiredContentSizeIdentifiers property with the set of all possible sizes the view can take in your application. The most common reason to support multiple sizes in your application is to support orientation changes. If your application changes its interface in response to an orientation change, it should resize the banner view to fit the new orientation.

Listing 2-4 shows how a view controller could configure the banner view to download advertisements that have both portrait and landscape images:

Listing 2-4  Configuring a banner view to handle landscape and portrait orientations

self.bannerView.requiredContentSizeIdentifiers = [NSSet setWithObjects: ADBannerContentSizeIdentifierPortrait, ADBannerContentSizeIdentifierLandscape, nil];

When an orientation change occurs, your view controller’s willRotateToInterfaceOrientation:duration: method changes the banner size.

Listing 2-5  Responding to an orientation change

- (void)willRotateToInterfaceOrientation:(UIInterfaceOrientation)toInterfaceOrientation duration:(NSTimeInterval)duration

{

    if (UIInterfaceOrientationIsLandscape(toInterfaceOrientation))

        self.bannerView.currentContentSizeIdentifier =

            ADBannerContentSizeIdentifierLandscape;

    else

        self.bannerView.currentContentSizeIdentifier =

            ADBannerContentSizeIdentifierPortrait;

}

When your application configures the requiredContentSizeIdentifiers property with more than one banner size, the iAd service only downloads advertisements that provide images for all of the specified sizes. This allows the banner view to seamlessly change the displayed advertisement when your application changes the size of the view. As this restricts the ads available to the banner view, you should only configure the requiredContentSizeIdentifiers property with sizes that are actually used by your application.

Banner View Best Practices

When designing your application, keep the following principles in mind:

• Only create a banner view when you intend to display it to the user. Otherwise, it may cycle through ads and deplete the list of available advertising for your application.

• If the user navigates from a screen of content with a banner view to a screen that does not have a banner view, and you expect them to be on that screen for a long period of time, remove the banner view from the view hierarchy, set its delegate to nil and release it before transitioning to the new screen of content. More generally, avoid keeping a banner view around when it is invisible to the user.

• When your application creates a banner view, there is a delay before the view can actually display an advertisement. If you intend to use that banner view on a screen of content that is only visible to the user for a short period of time, the banner may not have enough time to download an advertisement before a user finishes interacting with that screen of content. Instead, your application should create a single banner view and use it throughout your user interface. As the user navigates around your application, your application moves the banner view onto any screen that is expected to display a banner. The iAdSuite sample demonstrates how to implement this technique.

• When an ad transitions to a rich media experience, iAd consumes additional memory so that it can display an interactive ad to the user. This memory comes from your application’s available memory. Your application must scale back its activities to allow the ad to run smoothly and respond quickly to low-memory conditions by releasing large objects that can be easily recreated after the user finishes interacting with the ad.