The following happens on my Samsung Galaxy S3 with Android 4.3 as well as on my Galaxy S with Android 2.3.4.
Issue seems to occur only on Android. iPad 3 with iOS 8.0.2 works fine.
Repro steps:
Suspend your app when an interstitial or MoreApps is displayed by pressing the HOME button.
Resume your app.
Expected:
The app resumes showing the interstitial / MoreApps from step 1.
Observed:
The app resumes without showing the interstitial / MoreApps from step 1. This wouldn’t be a big issue if showing new interstitials / MoreApps would work. However, now we are unable to show new interstitials / MoreApps because chartboost thinks the one from step 1 was still visible (event info claims IMPRESSION_ALREADY_VISIBLE). The interstitial / MoreApps from step 1 is not visible at all (no frame, no close button; looks like it is either completely transparent or hidden under my apps’ content or out of screen).
As a workaround I will perhaps do a native.requestExit() in the next applicationSuspend when I detect the IMPRESSION_ALREADY_VISIBLE from above to make chartboost re-init itself when the app is resumed (in fact re-started).
I’ve got a reply back from Chartboost.
They said they have another report that is loosy related to this issue, but it involves IMPRESSION_ALREADY_VISIBLE. That issue will be fixed in 5.0.4 which is to be released soon. He suspects that the fix might solve your problem as well.
He also asked if your issue happens every time or just occasionally?
So far I was able to reproduce this every time (I tried it approx. 15 times), so it doesn’t seem that it happens occasionally.
(btw, my app’s UI is NOT blocked when this happens; everything works fine; it’s just that the chartboost impression is not visible and I can’t show new impressions because of this).
I tried Chartboost’s Android SDK two years ago for the first time using the normal Android Java approach.
It didn’t impress me back then.
There were some severe issues which lead to a bad user experience: In 2012 I was in contact with Chartboost’s team because of problems regarding orientation and orientation changes (back then the Android SDK ALWAYS showed portrait interstitials, even if you locked your app to be landscape). There was no solution for this, so you were forced to make portrait only apps or must not use interstitials at all (MoreApps worked fine afaik).
I’m not sure about the following, but my gut instinct says that the issue I’m reporting here in this thread already existed back then as I never noticed many impressions (unfortunately I didn’t investigate this as I just thought my fill rate was low).
So yeah, let’s hope…
With Corona SDK and your plugin I’ll give it a try.
The Chartboost SDK has an internal variable called autoCacheAds that is turned on by default which may be interfering with the display of an ad after resume. They asked to try turning off auto cache to see if this issue still occurs.
I’ve released a new version of my plugin that exposes this internal variable so you can set it in your code.
Use chartboost.autoCacheAds([true|false]) to enable/disable auto caching. As said above it’s enabled by default if you don’t call it.
The new version of the plugin and documentation is immediately available on my GitHub Page:
Yeah. I don’t understand why it’s taking such a long time. I see that the latest version is still not available on their servers.
I updated the central repository almost 24 hours ago, but it’s still not available. The update should automatically be available to subscribers within a few hours of upload.
I’ve emailed the guys at CoronaLabs, asking what’s wrong. No reply yet, so I guess I will not be hearing anything until after the weekend. Sorry about that…
ingemar, calling chartboost.autoCacheAds(false) didn’t help. I tried calling it right after chartboost.init(…) as well as before and after each chartboost.startSession(…), but still getting IMPRESSION_ALREADY_VISIBLE on my Galaxy S3.
Thanks for your efforts, though. I really appreciate that.
As a workaround I will perhaps do a native.requestExit() in the next applicationSuspend when I detect the IMPRESSION_ALREADY_VISIBLE from above to make chartboost re-init itself when the app is resumed (in fact re-started).
I’ve got a reply back from Chartboost.
They said they have another report that is loosy related to this issue, but it involves IMPRESSION_ALREADY_VISIBLE. That issue will be fixed in 5.0.4 which is to be released soon. He suspects that the fix might solve your problem as well.
He also asked if your issue happens every time or just occasionally?
So far I was able to reproduce this every time (I tried it approx. 15 times), so it doesn’t seem that it happens occasionally.
(btw, my app’s UI is NOT blocked when this happens; everything works fine; it’s just that the chartboost impression is not visible and I can’t show new impressions because of this).
I tried Chartboost’s Android SDK two years ago for the first time using the normal Android Java approach.
It didn’t impress me back then.
There were some severe issues which lead to a bad user experience: In 2012 I was in contact with Chartboost’s team because of problems regarding orientation and orientation changes (back then the Android SDK ALWAYS showed portrait interstitials, even if you locked your app to be landscape). There was no solution for this, so you were forced to make portrait only apps or must not use interstitials at all (MoreApps worked fine afaik).
I’m not sure about the following, but my gut instinct says that the issue I’m reporting here in this thread already existed back then as I never noticed many impressions (unfortunately I didn’t investigate this as I just thought my fill rate was low).
So yeah, let’s hope…
With Corona SDK and your plugin I’ll give it a try.
The Chartboost SDK has an internal variable called autoCacheAds that is turned on by default which may be interfering with the display of an ad after resume. They asked to try turning off auto cache to see if this issue still occurs.
I’ve released a new version of my plugin that exposes this internal variable so you can set it in your code.
Use chartboost.autoCacheAds([true|false]) to enable/disable auto caching. As said above it’s enabled by default if you don’t call it.
The new version of the plugin and documentation is immediately available on my GitHub Page: