This offering is currently in Alpha and is subject to change.
The term Banner Native refers to the capability of our Mobile SDK Banner class to return native demand. The banner object – ANBannerAdView in iOS, BannerAdView in Android – is multi-format, returning demand for banner ads and, if enabled via the APIs as described in the examples below, video and native ads. This means that you can instantiate a single Banner class object and pass it a single Member ID and Code (or Placement ID) and access demand across any or all of banner, video and native Media Type formats.
If you decide not use the Banner Native capability you won't notice any significant changes in the manner in which your existing implementations function. There are minor changes to the standard MobileSDK headers (including one iOS header, which has been removed). But other than minor, one-time changes to satisfy the compilation process, there should be no impact on any existing code that uses the Banner class.
The assumption of this document is that you're already familiar with both the Banner and Native classes. To use Banner Native there are a number of significant changes both structurally and procedurally that you must manage. The Banner class with Banner Native behaves like the traditional Native Request class. When the Banner class returns with a native ad object, like traditional Native Request, it returns a Native Response object. This Native Response object can then be used in the traditional manner to display and track the ad content of a native ad object.
As of MobileSDK Version 4.9 for Android and Version 4.8 for iOS, there is one breaking change in the procedure of handling banner and video ad objects via the Banner class. Before the introduction of Banner Native, it was possible to add the Banner class instance view to a view hierarchy, even before the class instance returned the ad object. This made it possible to finalize the display setup of the class even before the lifecycle of loading and fetching the ad object had completed. Although this convenient short-cut meant potentially ignoring the callback that indicates the ad has loaded, it is a common pattern with the MobileSDK.
If the Banner class is used to fetch native ads, the display step MUST wait until after the callback has fired. This is because the callback provides the delivery point for the native ad object, if it is returned, and because it is the only place to distinguish between the return of a native ad object versus a banner or video ad object.
Mobile SDK Structure
- The AdListener defines a method, onAdLoaded(NativeAdResponse response), which must be declared even if it is not used.
- The ANAdDelegate method returns an ad object handler that is defined only by id. (Previous to Version 4.8 the handler was defined as id<ANAdProtocol>.)
- The ANAdDelegate protocol includes the new method ad:didReceivNativeAd:
Examples of Use
Usage of the multi-format BannerAdView class is simply a combination of the usage for banner and traditional native classes.
If you adopt this SDK but do not want to fetch native demand, you still need to implement an overloaded method onAdLoaded that returns NativeAdResponse, but it can be left empty.
If you want to fetch native or a combination of banner, video and/or native, you can use the following code example to get started:
Note the following in how the multi-format BannerAdView is used:
- Enable Native and Video demand for your BannerAdView using setAllowNativeDemand(true,RENDERER_ID) and setAllowVideoDemand(true), respectively. By default these values are false, in which case your BannerAdView will deliver only traditional HTML banner ads. You must explicitly enabled native and video in the app.
- Whereas loadAd may be called as soon as possible, the banner (or video) ad cannot be put into a subview until one of the overloaded onAdLoaded functions has been called. This is because we must first determine the Media Type of the returned Ad.
- A NativeAdResponse is returned as one of the overloaded onAdLoaded calls, which can be handled in the same way as if it were returned in the traditional way by NativeAdRequest. In this case, BannerAdView effectively plays the same role as NativeAdRequest. (See Show Native Ads on Android for more on NativeAdResponse.)
- By default, the mainImage and iconImage are not loaded. You can manually download these images via the URLs returned by the methods getImageUrl() and getIconUrl(), in the class NativeAdReponse.
Usage of the multi-format ANBannerAdView class is simply a combination of the usage for banner and traditional native classes.
If you want to fetch native or a combination of banner, video, and/or native, you can use the following code example to get started:
Note the following in how the multi-format ANBannerAdView is used:
- Enable Native and Video demand for your ANBannerAdView using setAllowNativeDemand:withRendererId and shouldAllowVideoDemand, respectively. By default these values are set to NO, in which case your ANBannerAdView will deliver only traditional HTML banner ads. You must explicitly enabled native and video in the app.
- Whereas loadAd can be called as soon as possible, the banner (or video) ad cannot be put into a subview until the delegate adDidReceiveAd: or ad:didReceiveNativeAd: has been called.
- A native ad object is returned as an instance of ANNativeAdResponse which can then be handled like any other traditional native response class. In this case, ANBannerAdView effectively plays the same role as ANNativeAdRequest. (See Show Native Ads on iOS for more on ANNativeAdResponse.)
- By default, the mainImage and iconImage are not loaded. You can manually download these images via the properties mainImageURL and iconImageURL, in the class ANNativeAdResponse.
If the ANBannerAdView will be displaying placements that include only banner and/or video ads, then display can be (optimistically) handled without using the adDidReceiveAd : delegate method: