New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Preloaded banner causes "AdWidget is already in the Widget tree" on first navigation, then OK all next navigations #878
Comments
Hi @large, Thank you for flagging this issue. I am able to replicate with your sample application. I have escalated this for a fix. |
I'm encountering a similar problem. To illustrate, let's say I have three screens. I'm currently loading banner ads in "bannerAdWidget" and displaying the same ad in all three screens. However, this approach triggers a warning: Ensure that a single ad object is not utilized across multiple AdWidgets. Requirement - Is there a solution available at the moment or planned for the near future that would allow for loading ads in one AdWidget and subsequently using them throughout the entire app, essentially attaching and detaching them as needed? |
hi @malandr2, |
Hi @bruce-yan, I don't have a concrete timeline to share but it is something the greater team is aware of. I will follow-up here as soon as I have an update. |
Any news on this? @malandr2 |
Hi @andreasAasheim, thanks for following up. The team has looked this over and the error that is occurring here is done by design. The example app provided by OP tries to reuse ads from a list but the ads are already assigned into a View tree which is why there is the the error even if the tree has been removed from the stack. To address @Patelparth2442, I don't think there are plans to enable multiple ad loads on one AdWidget. Without getting too specific as it depends on app implementation, we recommend a different way to manage the preloaded banner ads. Thanks all. |
@malandr2 then how should this be handled correctly then? I am missing a good example for reuse of preloaded banner ads. No preloading ensure that ads loads, but you get alot(!) of requests resulting in few impressions. It could take off some serverload to instruct us on how you would like this handled 😁 |
I can help you with this you match rate is too low probably you have to go with instant load and show ads method. |
I figured out why the stats was so off, because of mediation. Screenshot is from front page of admob. The "Reports" tab showed me that 1 request from the app generate x-number of requests to each mediation network (requests). The one that actally shows an ad (match request) is normally 1 (or 0 if no ad is return). Ref https://support.google.com/admob/answer/3436433 |
@large does it mean, that I need to load bannerAd for each screen in my app. I have the app with 5 screens.
I need Ad at every screen(including home). Do I need to make BannerAd and load it for every navigation to the screen? So, instead of one load request per app, i will have a lot of load based on number of navigations? Am I right? If yes - isn't it a violation of admob's policy? Will appreciate any help |
Issue is related to finding a good way to have preloaded banners and possibility to navigate as expected.
Plugin Version
google_mobile_ads: ^3.0.0
Steps to Reproduce
Clone example app: https://github.com/large/admobpreload
This is a quick hack to try to create a preloading of banner (pro example much wanted!) to get a better experience in app.
Reuse will cause 3-6 seconds loading time and user are long gone many times when it is ready.
See example on video
https://github.com/googleads/googleads-mobile-flutter/assets/535446/4c644001-fad2-439d-8986-fa795450c178
Expected results:
Navigator.of(context).pushNamedAndRemoveUntil(...)
should give a "clean stack" so you only have one window.The Adwidget could be reused on each page for minimum loadingtime on a "single window" application without hickups.
Actual results:
First navigation will always give the "This AdWidget is already in the Widget tree", then show as normal on the navigation later on using
pushNamedAndRemoveUntil(...)
Backgroundinfo:
Navigator.of(context).pushNamed(¨¨, (Route<dynamic> route) => false)
will stack windows and error is "correct" on this (several instances).The
Navigator.of(context).pushReplacementNamed(..)
does not remove the the stack only replace the route it is navigating to. So this could also fail as expected. But theLogs
The text was updated successfully, but these errors were encountered: