Google Ads SDK needs updating

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

I am getting an update message from Google in my app console:

2014-09-04 12:22:26.890 AppName[14189:90b] <Google:HTML> Google Mobile Ads SDK: You are currently using 6.8.0 of the SDK. A new version, 6.11.1, is available at http://goo.gl/Zc0BYt . Please consider updating your SDK to get the latest features and bug fixes

Will you guys be updating the SDK soon? :slight_smile:

#2

Hi @tartarsaucemedia,

Are you referring to (and using) the AdMob V2 plugin? Which version of Corona SDK are you developing with?

Brent

#3

I am using Version 2014.2401 (2014.8.14) and did make the necessary changes in build.settings for AdMob V2.

#4

@ Brent 

That message has been there for quite some time when using the Admob V2 plugin.

It started saying that 6.9.x was newer (a few months back), then 6.10.x and now 6.11.1.

#5

Thanks ingemar,

So this isn’t causing any actual issues? It’s just a warning?

Brent

#6

This is just a reminder that there is a newer SDK.  We can’t just upgrade every time there is a new one. Sometimes the updates don’t fix anything relevant to us, or they may contain bugs that would cause other problems.  It takes time to look at a new SDK and evaluate it’s merits and impact before we go re-compile things. 

You will see these messages periodically and we will update when the time is right.

Thanks for letting us know about it.

Rob

#7

@Brent 

It’s just a reminder. It doesn’t cause any issues at all.

@CoronaLabs

They update their SDK’s for a reason and unless it’s a major re-write, recompiling with the latest SDK will not affect the plugin interface much (most likely not at all). Let’s face it. A plugin is just an interface to their SDK nothing more, nothing less. I personally think plugins should always be re-compiled the moment a new SDK is available. Yes, sometimes they introduce breaking changes that will require some work which will take time to test, but that doesn’t happen often.

I have a feeling it’s not really about it taking time to look at the new SDK before recompiling. I think it has more to do with lack of time to keep plugins proactively up to date. This is one of the reasons I think it would be a good idea to OpenSource all your (CoronaLabs developed) plugins. We can then help keep them up to date. 

#8

Hey, Ingemar, What you’re pointing out is interesting – i.e., your suggestion on having all CoronaLabs developed plugins to be OpenSourced.

But if it’s OpenSourced, who will ensure the updates are solid and good enough to be released to be used by all?  Who would be accountable for such plugin?  Who would monitor it?  Who would validate the health of such plugin before it gets automatically plugged in to the build process?

I’m not sure if it’s a good idea for OpenSourced plugin to be out in the wild for anyone to update and have Corona Labs automatically allow the inclusion of such plugin whenever the said plugin is updated without validating it.  (And, I could be wrong, but validating process can require significant allocation of resources that Corona Labs may not be prepared to spare.)

I suppose Corona Labs can publicly post a disclaimer that devs must include such plugin at their own risk.  But then, I’m not sure if that’s enough, and personally, I’m not sure if I’d include such plugin (that are not fully validated) before I know for sure it works.  I would include such plugin only after enough devs used it and confirm it’s working.  I’d be more than delighted to include such validated plugin, but what if the plugin is constantly updated and changed?   I’m not sure if I’d consider adding a plugin that is always changing without solid assurance it works as expected.

Naomi

#9

Think of it. The whole purpose of Open Source is to harness the expertise in a community of developers. Without trust, Open Source projects like Linux and others would’ve been dead a long time ago.

Of course CoronaLabs can’t automatically incorporate every Pull request they get. It has to be managed by them. However in my experience looking over code to see if it meets requirements is a lot quicker than trying to debug/find solutions to problems.

We’re also talking about version control software that shows you exactly what the Pull request is trying to do. And like I said above, we’re talking about a plugin interface to a SDK which is not rocket-science in any way.

Luckily I’m an Enterprise user and can code my own plugins if ever I have an issue.

#10

Hey, Ingemar, I’m not using Enterprise version, so I’d be at a mercy of whatever gets added to the build process.  

That said, I do trust your judgement, and if you absolutely believe Open Sourcing all plugin would work perfectly fine, perhaps it does.

Naomi

#11

Unfortunately when I think more about it, even if they did Open Source the plugins, I worry that nobody would care.

Look at what happened to Widgets 2.0. It’s Open Sourced, and nobody is contributing. Also it’s a two-way street. Both the Community and the Source-owner must be willing to make things happen. I tried contributing to Widgets in the beginning, but got more or less ignored.

#12

Not updating to the new SDK is a mistake imho. A new SDK introdces bug fixes and features that we are missing out on. I too saw the warning message posted by the OP but decided not to alert Corona as I simply did not expect them to respond promptly. They are clearly overworked and under resourced.

I take your point about Open Source and the Linux example. However, the Corona community simply does not have that kind of traction. I, respectfully, do not “trust” the community to devote time to such an effort - as evidenced by Widgets 2.0.

On a wider note, the demise of Corona support starting with Chartboost and PlayHaven and now Gremlin leads me to believe that the future for Corona is not bright. I hope I am wrong. For sure I will not pay the full asking price for a Pro license when my discounted Pro rate expires. Still no Windows phone, a buggy framework and now a 3rd party plugin marketplace that isn’t viable. 

Rant over! :smiley:

#13

i think open-sourcing widgets was a good idea, for those who can fix their own bugs, but as a case-study of community support i’d agree that it falls a bit short.

my impression is that the “o-s community” expects a certain minimum “structure” before they’ll take it upon themselves to improve/upgrade.  so, while widgets has some basic organization in place, it also has lots of weird “gotchas” that (probably?) prevent wider adoption for development.

things like scrollview having “special-case” logic built into the base class for use with date picker, instead of sub-classing it for just the functionality dp requires.  that’s the sort of design that screams “please give me unintended consequences and obscure regression bugs”.  (fe, you fix your scrollview, but therein break your datepicker)

or docs like “all widgets are groups… except scrollview, tableview”, without bothering to say why.  (would have rather seen “MOST widgets are groups, notable exceptions are … because …”)  that sort of half-doc’d stuff litters the code.

it’s “just complicated enough” that newbies probably wouldn’t touch it at all, medium-level devs might get something half-fixed and possibly suffer the above “consequences”; advanced devs might just pass it by as unmaintainable and just roll their own from scratch.

that’s my impression, $0.02, fwiw.  but i still think it’s a great that the source is available.

#14

Hi @tartarsaucemedia,

Are you referring to (and using) the AdMob V2 plugin? Which version of Corona SDK are you developing with?

Brent

#15

I am using Version 2014.2401 (2014.8.14) and did make the necessary changes in build.settings for AdMob V2.

#16

@ Brent 

That message has been there for quite some time when using the Admob V2 plugin.

It started saying that 6.9.x was newer (a few months back), then 6.10.x and now 6.11.1.

#17

Thanks ingemar,

So this isn’t causing any actual issues? It’s just a warning?

Brent

#18

This is just a reminder that there is a newer SDK.  We can’t just upgrade every time there is a new one. Sometimes the updates don’t fix anything relevant to us, or they may contain bugs that would cause other problems.  It takes time to look at a new SDK and evaluate it’s merits and impact before we go re-compile things. 

You will see these messages periodically and we will update when the time is right.

Thanks for letting us know about it.

Rob

#19

@Brent 

It’s just a reminder. It doesn’t cause any issues at all.

@CoronaLabs

They update their SDK’s for a reason and unless it’s a major re-write, recompiling with the latest SDK will not affect the plugin interface much (most likely not at all). Let’s face it. A plugin is just an interface to their SDK nothing more, nothing less. I personally think plugins should always be re-compiled the moment a new SDK is available. Yes, sometimes they introduce breaking changes that will require some work which will take time to test, but that doesn’t happen often.

I have a feeling it’s not really about it taking time to look at the new SDK before recompiling. I think it has more to do with lack of time to keep plugins proactively up to date. This is one of the reasons I think it would be a good idea to OpenSource all your (CoronaLabs developed) plugins. We can then help keep them up to date. 

#20

Hey, Ingemar, What you’re pointing out is interesting – i.e., your suggestion on having all CoronaLabs developed plugins to be OpenSourced.

But if it’s OpenSourced, who will ensure the updates are solid and good enough to be released to be used by all?  Who would be accountable for such plugin?  Who would monitor it?  Who would validate the health of such plugin before it gets automatically plugged in to the build process?

I’m not sure if it’s a good idea for OpenSourced plugin to be out in the wild for anyone to update and have Corona Labs automatically allow the inclusion of such plugin whenever the said plugin is updated without validating it.  (And, I could be wrong, but validating process can require significant allocation of resources that Corona Labs may not be prepared to spare.)

I suppose Corona Labs can publicly post a disclaimer that devs must include such plugin at their own risk.  But then, I’m not sure if that’s enough, and personally, I’m not sure if I’d include such plugin (that are not fully validated) before I know for sure it works.  I would include such plugin only after enough devs used it and confirm it’s working.  I’d be more than delighted to include such validated plugin, but what if the plugin is constantly updated and changed?   I’m not sure if I’d consider adding a plugin that is always changing without solid assurance it works as expected.

Naomi