Corona Labs, please listen (adMob banner height)

Solar2D Monetization (in-app purchases, ads, etc.)
#1

I have written about this issue several times but got no response from Corona Labs, but this is really a must have feature so I write again.

AdMob is without any doubt one of the best ad networks out there.

Great that Corona Labs has made a plugin for it and improved it lately.

But it lacks a core feature: API to return the banner ad height.

Because the plugin supports only smart banners, they are different size on different devices (at least in landscape position).

Without knowing the ad height, it is impossible to use it to make the game screen perfect for the user.

E.g. in our new game we would put it on top, but how to know where from should the game start drawing screen objects if we do not know the ad height?

Corona Labs, I am begging you - give as this feature, I am sure many,many developers would appreciate it.

Regards,

Damir.

#2

+1

I’ve been trying to “reverse engineer” their logic just based on experimentation, and it’s seemingly impossible, at least on Android. (and i DO understand all about screen density, screen size classes, etc)

For example, on my 2012 Nexus 7:
800x1280 pixels
213 tvdpi (so a 213/160=1.33125 density relative to “normal” 160dpi)
so 600x961 dps (device-independent pixels)
so in the “large” screen threshold, so aka a “tablet”

Aside: Corona only “sees” 800x1205 of those pixels (due to soft bar) but even if THAT is the value used, it STILL fall in the large/tablet class.

Corona does properly return 213 dpi, so “in theory” I have everything I need to determine device/orientation/tablet and make a good guess at the format that admob will return, but it doesn’t quite work out…

So, portrait orientation app, contentWidth/Height set to exactly 800x1205 for this specific test device, letterbox scaling, contentScaleX/Y verified to be 1.0,1.0, etc… am expecting a 800x90 banner, as per: https://developers.google.com/mobile-ads-sdk/docs/admob/smart-banners

Which ought to perfectly fit width, so ought to require no scaling, so height ought to remain 90 device pixels, right? Wow, this should be the perfect type of device to begin reverse-engineering the plugin’s sizing math, right?

Wrong. I can watch the logcat and see it’s actually requesting/receiving the 600x90 format (tho I’m pretty sure a Nexus 7 is not a “Kindle Fire”).

This is purely a diagnostic app, with a “pixel ruler” background displayed, at exactly 1:1 content-pixel scale, and additionally measuring a live screenshot from device will all confirm that the displayed ad has been scaled up to fit width 800px, thus resulting height is 120px (90 px original height * 800/600 horizontal scale = 120px ad height)

If I *KNEW* which ad format I’d be getting, I could deal with display.contentScaleX/Y to determine what those 120 (or whatever) device pixels work out to in my content pixels. But the admob plugin is just a big obscure black box, confounding me at every turn.

#3

Hi guys. We are aware of this request. We have it on our list, but have a few other things over the next few weeks that are more pressing and that we need to do first. But rest assured we are aware and will address it asap.

#4

Hi David,

thank you for your response and letting as know you are working on it.

Great!

Regards,

Damir.

#5

+1

I’ve been trying to “reverse engineer” their logic just based on experimentation, and it’s seemingly impossible, at least on Android. (and i DO understand all about screen density, screen size classes, etc)

For example, on my 2012 Nexus 7:
800x1280 pixels
213 tvdpi (so a 213/160=1.33125 density relative to “normal” 160dpi)
so 600x961 dps (device-independent pixels)
so in the “large” screen threshold, so aka a “tablet”

Aside: Corona only “sees” 800x1205 of those pixels (due to soft bar) but even if THAT is the value used, it STILL fall in the large/tablet class.

Corona does properly return 213 dpi, so “in theory” I have everything I need to determine device/orientation/tablet and make a good guess at the format that admob will return, but it doesn’t quite work out…

So, portrait orientation app, contentWidth/Height set to exactly 800x1205 for this specific test device, letterbox scaling, contentScaleX/Y verified to be 1.0,1.0, etc… am expecting a 800x90 banner, as per: https://developers.google.com/mobile-ads-sdk/docs/admob/smart-banners

Which ought to perfectly fit width, so ought to require no scaling, so height ought to remain 90 device pixels, right? Wow, this should be the perfect type of device to begin reverse-engineering the plugin’s sizing math, right?

Wrong. I can watch the logcat and see it’s actually requesting/receiving the 600x90 format (tho I’m pretty sure a Nexus 7 is not a “Kindle Fire”).

This is purely a diagnostic app, with a “pixel ruler” background displayed, at exactly 1:1 content-pixel scale, and additionally measuring a live screenshot from device will all confirm that the displayed ad has been scaled up to fit width 800px, thus resulting height is 120px (90 px original height * 800/600 horizontal scale = 120px ad height)

If I *KNEW* which ad format I’d be getting, I could deal with display.contentScaleX/Y to determine what those 120 (or whatever) device pixels work out to in my content pixels. But the admob plugin is just a big obscure black box, confounding me at every turn.

#6

Hi guys. We are aware of this request. We have it on our list, but have a few other things over the next few weeks that are more pressing and that we need to do first. But rest assured we are aware and will address it asap.

#7

Hi David,

thank you for your response and letting as know you are working on it.

Great!

Regards,

Damir.

#8

The Google Play version of the plugin is now alive at:

http://docs.coronalabs.com/plugin/ads-admob-v2/index.html

The only change is the build.settings plugin code to use the new plugin.  You now have an ads.height() call that you can make **AFTER** you call ads.show().  There should be no other changes needed.  This does not address the FPS issues being reported. 

Rob

#9

This is great news.

Maybe it will solve the FPS issue.

Now give us “normal” banners and live is good :slight_smile:

#10

Just wanted to say “thanks!” for this. :slight_smile:
(especially as i’ve been such a whiner on the forums lately :D)

Not intended as whining, but: If I could have had a “wish list” implementation, I would have suggested instead adding a generic ads.getInfo() method (using system.getInfo() as the model) that you could (potentially, as needed, per plugin) implement with any future “querying” needs. This one would have been ads.getInfo(“height”), but who knows what the future might hold? Could save “cluttering” the api with discrete info methods. fwiw

#11

Please look at my thread with test results for the new admob plugin:

http://forums.coronalabs.com/topic/47222-admob-v2-plugin-test-results/

#12

The Google Play version of the plugin is now alive at:

http://docs.coronalabs.com/plugin/ads-admob-v2/index.html

The only change is the build.settings plugin code to use the new plugin.  You now have an ads.height() call that you can make **AFTER** you call ads.show().  There should be no other changes needed.  This does not address the FPS issues being reported. 

Rob

#13

This is great news.

Maybe it will solve the FPS issue.

Now give us “normal” banners and live is good :slight_smile:

#14

Just wanted to say “thanks!” for this. :slight_smile:
(especially as i’ve been such a whiner on the forums lately :D)

Not intended as whining, but: If I could have had a “wish list” implementation, I would have suggested instead adding a generic ads.getInfo() method (using system.getInfo() as the model) that you could (potentially, as needed, per plugin) implement with any future “querying” needs. This one would have been ads.getInfo(“height”), but who knows what the future might hold? Could save “cluttering” the api with discrete info methods. fwiw

#15

Please look at my thread with test results for the new admob plugin:

http://forums.coronalabs.com/topic/47222-admob-v2-plugin-test-results/