[FEATURE REQUEST] enable reading Ad content (headline, body, icon, etc.) of NativeAd to be readable from NativeAdController

[ramtinq]

I was hoping if you could implement some getter methods for NativeAdController which return details of the loaded NativeAd. This would be helpful for creating placeholder widgets for our NativeAds so that whenever we are animating them, we'd show the placeholder instead to overcome the issue of low performance in animations

This specifically could be useful in iOS as mentioned in #31 (comment) where the performance impact is high.

It has benefits for both platforms since we can show THE REAL NativeAd only when the user can interact with it and show the placeholder in the rest of situations.

[bdlukaa]

I don't think this is a good idea, since your account may get limited for displaying false ads.

It has benefits for both platforms since we can show THE REAL NativeAd only when the user can interact with it and show the placeholder in the rest of situations.

The user should be able to interact with it whenever the ad is on the screen. The "placeholder" you mentioned could be any other widget.

[ramtinq]

I think showing a placeholder whenever the widget containing the NativeAd is animating is not fraud by any means. Actually, for the general purpose of displaying platform views, this approach is recommended by the docs:
https://flutter.dev/docs/development/platform-integration/platform-views?tab=android-platform-views-java-tab#performance

Furthermore, there can be cases like mine where the NativeAd is placed between a Stack of cards, and only the top card in the Stack is what the user can interact with. Here, we're not really showing the NativeAd, until it is in the top widget of the Stack, and the user can interact with it. This again is not fraud. I just want to show the placeholder whenever the Ad is in the cards other than the top card, and only show it once when it is in the top card. This way, the user won't experience the laggy behavior in iOS whenever the real NativeAd is not shown yet.

[bdlukaa]

You could calculate to display the real NativeAd only when there's one index last to get to the native ad index. Animations on NativeAd is not allowed by admob

[ramtinq]

I do exactly the same thing you mentioned. However, as soon as the NativeAd is inserted to the tree, it makes the upmost widget in the stack (which the user interacts with) laggy. This would be a really bad user experience.

Can you please give any links to the AdMob policies which prohibit animating NativeAds? I'm just putting it in a draggable widget.

At the end, I still think displaying a placeholder for NativeAds in some cases is not fraud. You won't get any impressions, clicks, or any kind of earnings by displaying a placeholder! In fact, you're informing the user that "you're goring to see a NativeAd", without even getting the impression, and without making the app slow due to the existence of a Platform View in the widget tree.

Furthermore, in the Java side of the official SDK, these values which I requested are completely accessible by calling UnifiedNativeAdView object's getter methods, before displaying the NativeAd, and I think having such accessibility could be useful in many cases.

I wish still thank you for the great plugin you've made.

[bdlukaa]

Can you please give any links to the AdMob policies which prohibit animating NativeAds? I'm just putting it in a draggable widget.

You can animate native ads. I got confused because you can't animate banner ads.

Either way, I don't think this is a valid request. I personally don't see a performance issue on Android nor iOS. Android uses Virtual Display, which is not laggy. Most iOS phones have enough hardware capacity to display ads using Hybrid Composition and not affecting performance so much.

The lag you may be seeing may be due to loading the ad as soon as it's implemented to the view. The solution for this would be creating a NativeAdController and preloading the ad.

[ramtinq]

Actually I just did the implementation for Android, and tomorrow I will do the iOS side. I will create a pull request and will be glad to have a small contribution to your amazing package.