Open GoogleCodeExporter opened 8 years ago
Are there any updates on this?
I have also met this problem, and as I know the issue is caused by the
InMobi SDK. But there are no updates yet on InMobi side.
Original comment by gabor.ta...@gmail.com
on 30 Mar 2011 at 8:39
Also seeing this behavior in AdWhirl v3.0.
Original comment by goo...@yourarcade.com
on 4 Apr 2011 at 8:49
same here, althought i thought it was millenial causing this. maybe its a
general adwhirl issue?
basically ti will start flipping through ads like 1 per second, then stop on
one for a while, then go crazy requesting ads one after a nother non stop till
the phone is rebooted. crazyness
Original comment by mike24...@gmail.com
on 15 Apr 2011 at 9:32
The new InMobiAdapter will be launched soon which will resolve this issue.
Original comment by rish2c...@gmail.com
on 18 Apr 2011 at 10:20
Hello. Any word on when the InMobi adapter will be fixed?
Original comment by chad...@gmail.com
on 25 Apr 2011 at 8:29
You can fix this yourself by adding a flag to the InMobiAdapter that only
allows adRequestFailed to fire once (something like the attached file). It's a
simple hack but doesn't fix the underlying synchronization issue so the same
situation could certainly be caused by another ad provider.
The underlying problem is that a second scheduled update should not be allowed
while a previous update is pending. I took a quick look at the and the existing
workflow didn't make it easy to determine whether it's a scheduled or immediate
update. In the end I ended up writing my own simplified mediation layer and
keeping track of the ScheduledFuture<?>:
---
if (_pendingLoad != null && !_pendingLoad.isDone()){
Log.e(Constants.TAG, "rotateAdDelayed() called while previous call still pending");
return;
}
_pendingLoad = _scheduler.schedule(...);
---
The down side is that there are now instances where my application could
potentially stop rotating ads. I need to figure out a watchdog solution to kill
a ScheduledFuture that has timed out and fire up another. In the end I figured
a small chance of not displaying ads was a better user experience than
guaranteeing multiple threads and flickering ads (that that can never click on
anyway...).
I might come back and look at the AdWhirl issue assuming someone else isn't
already but didn't have time now.
Original comment by mach...@gmail.com
on 27 Jun 2011 at 10:37
Attachments:
You can also use the InMobi adapter from the link below which has been updated
for ver 3.0.0 of the Adwhirl SDK. This should resolve the ad request failed.
Please note, you will need to use the Ver. 2.0 or 2.1 of the InMobi SDK with
ver. 3.x of the Adwhirl SDK
InMobi Adapter: http://dl.dropbox.com/u/30899852/InMobiAdapter.java
If you are using the Adwhirl Compiled Jar, please use the following:
http://dl.dropbox.com/u/30899852/adWhirl/AdWhirlSDK_Android_3.0.0.jar
This jar has been compiled for Ver. 3.0.0 with all the default SDKs and
Adapters of the other Ad Networks and the updated InMobi Adapter.
Hope this helps. For further assistance with InMobi, please contact
helpdesk@inmobi.com
Full Disclosure: I work for the Global Ops team of InMobi
Original comment by ana...@gmail.com
on 28 Jun 2011 at 6:06
Is this still an issue with the latest version of InMobi and AdWhirl? I know
we updated our adapter to tell the IMAdView to stop refreshing on its own. Did
that fix the problem?
Original comment by wesgood...@google.com
on 30 Nov 2011 at 9:33
Original issue reported on code.google.com by
the.k...@gmail.com
on 11 Mar 2011 at 12:02Attachments: