Closed rosebm closed 9 months ago
@rosebm - This is expected behaviour. Whilst we might not crash in production builds, we will crash in dev builds if you attempt to call loadAd()
on an ad instance that you have destroy()
ed.
Hi @thomasmso This is completely unacceptable. This breaks a lot of our QA tests. A crash should NEVER be "expected behavior" regardless of the environment. I would really hope you guys prioritize fixing this for all environments so we can bump up your sdk as this is a blocker for us to release as of now.
@MKelman - In this case, I would admit we should document the limitations of the destroy()
and loadAd()
API when used together - we'll call that out in our docs (cc @PLP-Consulting).
However, the alternative of not throwing an exception would be to either fail the ad loads or print some logs, which might've been easily missed. Would you be able to update your integration to avoid the crash?
@thomasmso how sure are you that it wont throw an error in production? We could print some logs so it doesn't crash but we also dont want to lose revenue from not showing ads in our app in parts that it should show ads.
We check for the FLAG_DEBUGGABLE flag first before throwing the exception. But yeah, def. something to fix as to not lose revenue.
@thomasmso but you're saying the ultimate fix is something we need to do on our end? We need to be able to call loadAd after destroyAd though. We have different features that after one feature loads an ad and destroys the ad, we need to load another ad.
@MKelman - We'd recommend using the same instance of the MaxRewardedAd
without destroying it in the first place.
@thomasmso we'll continue to look into your solution.
MAX SDK Version
12.1.0
Device/Platform Info
Android
Current Behavior
The app is crashing, and checking the logcat it says:
I understand that on the latest version v12.1.0 a crash was fixed, but I am able to replicate it.
Expected Behavior
The app doesn't crash
How to Reproduce
Update SDK to v12.1.0
Additional Info
No response