First impression

[davebollinger]

More info:  I think the above correction in my code fixed the segfault, but I’m still left with with one that now more closely resembles the one initially reported by ubj3d.android.  As with that report, it took a couple dozen ad views before this occurred:

V/AdBuddizCoronaBinding( 8096): didShowAd V/AdBuddizCoronaBinding( 8096): com.naef.jnlua.LuaRuntimeException: 143619.425 V/AdBuddizCoronaBinding( 8096):         at com.naef.jnlua.LuaState.lua\_pcall(Nat ive Method) V/AdBuddizCoronaBinding( 8096):         at com.naef.jnlua.LuaState.call(Unknown Source) V/AdBuddizCoronaBinding( 8096):         at plugin.adbuddiz.LuaLoader.sendRuntime Event(Unknown Source) V/AdBuddizCoronaBinding( 8096):         at plugin.adbuddiz.LuaLoader$1.didShowAd (Unknown Source) V/AdBuddizCoronaBinding( 8096):         at com.purplebrain.adbuddiz.sdk.AdBuddiz .b(Unknown Source) V/AdBuddizCoronaBinding( 8096):         at com.purplebrain.adbuddiz.sdk.AdBuddiz .a(Unknown Source) V/AdBuddizCoronaBinding( 8096):         at com.purplebrain.adbuddiz.sdk.a.run(Un known Source) V/AdBuddizCoronaBinding( 8096):         at android.os.Handler.handleCallback(Han dler.java:733) V/AdBuddizCoronaBinding( 8096):         at android.os.Handler.dispatchMessage(Ha ndler.java:95) V/AdBuddizCoronaBinding( 8096):         at android.os.Looper.loop(Looper.java:13 6) V/AdBuddizCoronaBinding( 8096):         at android.app.ActivityThread.main(Activ ityThread.java:5017) V/AdBuddizCoronaBinding( 8096):         at java.lang.reflect.Method.invokeNative (Native Method) V/AdBuddizCoronaBinding( 8096):         at java.lang.reflect.Method.invoke(Metho d.java:515) V/AdBuddizCoronaBinding( 8096):         at com.android.internal.os.ZygoteInit$Me thodAndArgsCaller.run(ZygoteInit.java:779) V/AdBuddizCoronaBinding( 8096):         at com.android.internal.os.ZygoteInit.ma in(ZygoteInit.java:595) V/AdBuddizCoronaBinding( 8096):         at dalvik.system.NativeStart.main(Native  Method) I/ActivityManager(  527): Process org.davebollinger.eggheadzbounce (pid 8096) ha s died. I/WindowState(  527): WIN DEATH: Window{42719ca0 u0 org.davebollinger.eggheadzbo unce/com.ansca.corona.CoronaActivity}

BTW, unrelated, but it is strictly *necessary* to suspend the main thread during ad display?  I already have my own mechanisms in place for “pausing in place” during interstitials, so the extra actual system-level suspend and resume just add extra delay to the whole process (in particular, the resume in my case takes nearly a full second after ad dismissal).  Is the app suspend something that could potentially be made optional, under developer control?  Thanks for considering.

[AdBuddiz]

Dave,

Regarding your error, could you please send me your apk via mail and instructions for me to try to reproduce it on my device? I’d do my best to release a fix asap.

Regarding your question, AdBuddiz uses a native Android Activity. When we display an Ad, an Activity is started and added on the stack. The previous Activity is normally called on its lifecycle onPause, then onResume when the ad is dismissed. Do you think it can be possible to optimize your code and make your onResume faster?

[AdBuddiz]

I think we may have found a possible explanation. Our plugin was using the luaState directly in our Java listener when sending events which is apparently not a good way to do it because it seems it can corrupt the luaState with race conditions. The bugs you experienced were all related to events so it seems coherent.

We just pushed a fix that now uses a CoronaRuntimeTaskDispatcher and CoronaRuntimeTasks to send events. We hope it’ll fix the bug but as we can’t reproduce the bug on our apps we’re not 100% sure.

Would you please send us your feedback when Corona will have pushed the fix live?

Thanks and really sorry about that, we’re new to the Corona world, we love your support and help to make things better.

[nick_sherman]

Have just implemented this to test in my new app. Easy to integrate and looks slick - but the progress bar that comes up when you click on an ad is concerning, it takes upwards of 5-10 seconds for the store to load. If I was a user I’m not sure I’d have the patience to wait and would just click ‘X’, even if I’d initially been enticed to click on the ad.

[AdBuddiz]

Hi Nick, thanks for your feedback.

The progress bar really depends on your network. The only thing done in background is a request to the advertiser servers about the click. Then as soon as we get a response with unique tracking link, we open the Store with it.

Most of the time, it takes less than 1.5s between click and the Store (usually, advertisers servers answer in less than 300ms). What network do you use? Does it always take 5-10s?

FYI, for the first 5 seconds, the ‘X’ is replaced with ‘…’ and is not clickable. So user can only stop requests longer than 5s (We don’t want to block a user more than 5s if he has a network issue) which are very very rare with good networks.

Some ad networks open the link in the user browser (chrome, safari…), we think it’s not great for the user experience.

[davebollinger]

@AdBuddiz

Dave,

Regarding your error, could you please send me your apk via mail and instructions for me to try to reproduce it on my device? I’d do my best to release a fix asap.

Regarding your question, AdBuddiz uses a native Android Activity. When we display an Ad, an Activity is started and added on the stack. The previous Activity is normally called on its lifecycle onPause, then onResume when the ad is dismissed. Do you think it can be possible to optimize your code and make your onResume faster?

Great news on addressing the bug, will test it out once it’s “live” in build environment.

Re second point:  I don’t think there’s a whole lot I can do.  From my understanding, at least on Android (can’t say for iOS), Corona must release all openGL/openAL contexts on suspend, and then recreate/restore them from scratch on resume.  So resume time doesn’t seem much affect by OS-level stuff, rather mainly dependent on extent of graphics/audio assets – and it really doesn’t take that much until you can “feel it”.

See attached project with a very trivial graphic/audio load.  Go back and forth from title to play, ads will appear after play before title about half the time.  The ad display will suspend just prior to transition (ie, play scene remains underneath), so what you’re looking for is the “lag” between closing the ad and the transition animation resuming.

On my Nextus 7 2012 it’s maybe a quarter-second or so, but it’s at least enough to feel for “proof”.  It’s more significant on “real” apps with “real” assets loaded.  If there’s nothing that can be done about it then “oh well”, but I thought I’d at least pose the question.

[AdBuddiz]

Hi Dave, thanks a lot for the app sample!

I tried it on a Nexus 5 and honestly the glitch was almost not noticeable. But I totally get your point and understand that with a bigger app and a slower device it could be something that we could improve.

We’re definitely adding this to the roadmap but I prefer to be honest with you, we already have a pretty full roadmap so it might take some time. We really want to keep our SDK very easy to integrate and very clean for the user (the back button on Android should close the ad for example) so making the AdActivity optional may not be very easy to do but that’s our job and we’ll find a great way

Thanks for your time, I hope the new plugin version will be live soon.

[nick_sherman]

@AdBuddiz

Hi Nick, thanks for your feedback.

The progress bar really depends on your network. The only thing done in background is a request to the advertiser servers about the click. Then as soon as we get a response with unique tracking link, we open the Store with it.

Most of the time, it takes less than 1.5s between click and the Store (usually, advertisers servers answer in less than 300ms). What network do you use? Does it always take 5-10s?

FYI, for the first 5 seconds, the ‘X’ is replaced with ‘…’ and is not clickable. So user can only stop requests longer than 5s (We don’t want to block a user more than 5s if he has a network issue) which are very very rare with good networks.

Some ad networks open the link in the user browser (chrome, safari…), we think it’s not great for the user experience.

This was on a very fast 3G network connection - it’s so good and reliable I generally tether off that rather than my fibre-optic wifi…will give it another try tomorrow.

[AdBuddiz]

Hi Nick, thanks, keep me posted regarding the results.

Regarding the crash on Android, the fix for the plugin is normally live now thanks to Corona!

Please try it and tell me if everything is fine now.

Thanks all.

[davebollinger]

This is one of those “can’t prove a negative” -type situations, so I hesitate to jump up and down shouting the “fixed” word, but signs are good…

With previous version, it was relatively easy to duplicate the crash after a couple dozen or so shows.

With new version, over the course of a busy morning of play-testing (ie not exclusively focused on ad testing) I’ve yet to experience the problem again.

So at the very least. the change has greatly improved stability.  Problem hasn’t yet recurred, which of course isn’t conclusive, but I’m willing to assume it’s fixed unless/until some new evidence to the contrary.  :)

[AdBuddiz]

Thanks for your quick feedback Dave!

The fix we added seems correct then, we now access the luaState on the right thread and no race condition could happen thanks to the use of a taskDispatcher.

If anyone encounters the bug again, please tell us.

I hope that it is now ok for ubj3d too!

Best,