The "Mobile Ad Network Program Participation Requirements" say "You will not add to, delete from, or otherwise modify or alter any Content in any way, including by adding additional information, resizing any Content, removing, obscuring, making invisible ..." I'm just wondering, surely this doesn't include these, does it: bannerAd.setVisibility(View.GONE); [bannerAd setHidden:YES]; In a game it's pretty common to hide the banner during gameplay. Are the banner ads smart enough to know they're hidden and report appropriately? Also, by resizing I assume this refers to shrinking them very small, since most the examples stretch the banners to fill the screen. On a tablet I want to have two banner ads, 1024x50 and 726x90, show one at a time based on orientation, and refresh them individually when their individual visible time crosses a threshold. Is this appropriate?
Thanks for your question. Please make sure to carefully adhere to the legal guidelines when setting up your ad. For your use case, we recommend loading a new ad only at the time when it would be visible to the user. If you prefer to load the banner off-screen then you must immediately move it onto the visible area of the screen once it’s done loading; see the Floating Ad Sample for a demonstration of how can be done:
https://developer.amazon.com/public/apis/earn/mobile-ads/docs/sample-apps#F... An enhancement that we could consider in the future is separating the loading and showing of banner ads just like what's done for interstitial ads. For example, if we allowed you to load an ad without registering an impression (all assets are downloaded from network, but ad is not visible), and then had a separate API to render the ad on the screen (which would then fire the impression pixel), would this better fit your use case? Regarding sizing, we recommend either setting the layout parameters to MATCH_PARENT x WRAP_CONTENT or setting them to the device-independent pixel values of your desired ad size (e.g. 1024x50 dip).
>> if we allowed you to load an ad without registering an impression (all assets are downloaded from >> network, but ad is not visible), and then had a separate API to render the ad on the screen (which >> would then fire the impression pixel), would this better fit your use case? Yes, that would be nice, but not absolutely essential. I can wait until an ad would be visible to the user in order to load it. So it sounds like what counts is how many ad requests I make. It doesn't appear to me that the SDK tracks other things like how long it is displayed or whether it is visible, correct? Based on that, and your suggestions, I will do the following: * Only make a banner ad request at a time when it would be visible to the user * Remove the ad from the view during gameplay, but display it again immediately when the user dies * Once an ad has been visible for 30 seconds (not counting time when it is invisible during gameplay), load a new one * When the orientation changes, remove the current ad from view and make a request for a new banner ad at the appropriate size * On subsequent orientation changes, don't make new requests, just re-display the ad that was loaded previously for that orientation. Once an ad at either orientation reaches 30 seconds of on-screen time, load a new one To the best of my knowledge this adheres to the legal guidelines, but please confirm if you are able. Thanks!
For your use case, assuming that the user will have enough time to clearly see and interact with the ad, we recommend loading a new ad each time the AdLayout would become visible rather than saving an old ad to be displayed again later. We also recommend loading a new ad on orientation change. You can then load another ad after thirty seconds if the user has not exited the current screen.