You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is related to the experimental native banner feature in the dev branches.
BannerView gives the very nice placeholderBuilder parameter for an app to display its own placeholder while a banner ad is loading. Sometimes the app's placeholder is removed and instead a dark grey rectangle is shown on iOS, or a transparent space is shown on Android, and then the real ad is shown after some time.
After a banner has successfully been displayed and a "no fill" occurs on the next fetch, I would expect the app's errorBuilder to be displayed, or if none was given, the app's placeholderBuilder to be used. Currently, the grey box (iOS) / transparent box (Android) is shown instead.
I spent some time trying to address this in my fork, but had limited success. Perhaps it's best that you take a look.
Summary of expected behavior:
On a successful fill, show the ad.
Before/during the initial loading process, show the placeholder.
On an error, show the error widget, or if no errorBuilder was given, show the placeholder.
If you have other thoughts I'd love to hear them. I'm looking for a flicker-free ad experience with my placeholder used whenever an ad is not available.
The text was updated successfully, but these errors were encountered:
In release/0.8.0-dev.4 I already removed the grey background from iOS banners.
Have you run the app in release mode? I assumed that this delay is caused by the way app was started.
After a banner has successfully been displayed and a "no fill" occurs on the next fetch, I would expect the app's errorBuilder to be displayed, or if none was given, the app's placeholderBuilder to be used.
I don't think it is correct assumption. FairBid tries to refresh banners until attempts limit is reached. After that the last banner is always shown because:
Have you run the app in release mode? I assumed that this delay is caused by the way app was started.
Yes, this happened even in release builds.
FairBid tries to refresh banners until attempts limit is reached. After that the last banner is always shown because:
You're right. Once an ad is filled it doesn't go back to the placeholder or the grey box. That's great!
However, a banner that doesn't get a fill initially will go through the following steps: App Placeholder (1-2 seconds) --> Grey Box (20+ seconds) --> Filled Banner
The update in f43ae3c changes the "Grey Box" step to an empty space. The app's placeholder is still not shown during that time (it should be).
Below is a video demonstrating the issue, recorded on an iPhone 7 Plus using the release/0.8.0-dev.4 branch.
The app placeholder is visible from 0:01 - 0:04 (though the video compression makes it look white, it's actually a light grey box)
The native view transparent box is visible from 0:04 - 0:42 (I would expect to see my app placeholder here, not empty space)
This is related to the experimental native banner feature in the dev branches.
BannerView
gives the very niceplaceholderBuilder
parameter for an app to display its own placeholder while a banner ad is loading. Sometimes the app's placeholder is removed and instead a dark grey rectangle is shown on iOS, or a transparent space is shown on Android, and then the real ad is shown after some time.After a banner has successfully been displayed and a "no fill" occurs on the next fetch, I would expect the app's
errorBuilder
to be displayed, or if none was given, the app'splaceholderBuilder
to be used. Currently, the grey box (iOS) / transparent box (Android) is shown instead.I spent some time trying to address this in my fork, but had limited success. Perhaps it's best that you take a look.
Summary of expected behavior:
errorBuilder
was given, show the placeholder.If you have other thoughts I'd love to hear them. I'm looking for a flicker-free ad experience with my placeholder used whenever an ad is not available.
The text was updated successfully, but these errors were encountered: