Summary
The rendering BannerView (org.prebid.mobile.api.rendering.BannerView) gives consumers no way to learn which requested size actually won after a render. Its BannerViewListener.onAdLoaded(BannerView) carries no size, and there is no getter for the rendered creative's dimensions. iOS's rendering API already provides this via bannerView(_:didReceiveAdWithAdSize:).
Why it matters
For a multi-size rendering placement — multiple sizes requested on one BannerView via addAdditionalSizes(...) (e.g. 300x250 + 320x50) — the host must reserve the bounding box of all requested sizes up front. When a smaller creative wins, the host has no signal to shrink the slot to the rendered size, leaving empty space below the ad. This only affects the pure-rendering (no ad server) path; the GAM event-handler path gets the served view and can read its size.
BannerView already knows the winning size internally: displayPrebidView() sizes the child with bidResponse.getWinningBidWidthHeightPairDips(context), and bidResponse is a field with a getBidResponse() getter — the winning bid's w/h are available at onAdLoaded time.
Proposal
Surface the won creative size on the rendering BannerView. Two non-breaking options:
- Getters (preferred — no interface change):
getCreativeWidth() / getCreativeHeight() returning the winning bid's dp dimensions (0 when no fill), delegating to the already-populated bidResponse.getWinningBid(). Consumers read them inside onAdLoaded(BannerView).
- An additional
BannerViewListener callback carrying the size (would need a default method to stay non-breaking).
iOS parity: matches bannerView(_:didReceiveAdWithAdSize:).
Context
Came up implementing multi-size outstream/banner placements on top of the rendering API (related to the multiformat work in #999 / #1000). Happy to open a PR with option 1 if the approach looks good.
(Filed with AI assistance.)
Summary
The rendering
BannerView(org.prebid.mobile.api.rendering.BannerView) gives consumers no way to learn which requested size actually won after a render. ItsBannerViewListener.onAdLoaded(BannerView)carries no size, and there is no getter for the rendered creative's dimensions. iOS's rendering API already provides this viabannerView(_:didReceiveAdWithAdSize:).Why it matters
For a multi-size rendering placement — multiple sizes requested on one
BannerViewviaaddAdditionalSizes(...)(e.g. 300x250 + 320x50) — the host must reserve the bounding box of all requested sizes up front. When a smaller creative wins, the host has no signal to shrink the slot to the rendered size, leaving empty space below the ad. This only affects the pure-rendering (no ad server) path; the GAM event-handler path gets the served view and can read its size.BannerViewalready knows the winning size internally:displayPrebidView()sizes the child withbidResponse.getWinningBidWidthHeightPairDips(context), andbidResponseis a field with agetBidResponse()getter — the winning bid'sw/hare available atonAdLoadedtime.Proposal
Surface the won creative size on the rendering
BannerView. Two non-breaking options:getCreativeWidth()/getCreativeHeight()returning the winning bid's dp dimensions (0 when no fill), delegating to the already-populatedbidResponse.getWinningBid(). Consumers read them insideonAdLoaded(BannerView).BannerViewListenercallback carrying the size (would need a default method to stay non-breaking).iOS parity: matches
bannerView(_:didReceiveAdWithAdSize:).Context
Came up implementing multi-size outstream/banner placements on top of the rendering API (related to the multiformat work in #999 / #1000). Happy to open a PR with option 1 if the approach looks good.
(Filed with AI assistance.)