[Appodeal] ​The application is slowed down during the process of caching ads and displaying banners.

Hi everyone!

One more trouble with Appodeal :frowning:

The application is slowed down during the process of caching and displaying banners. At the same time, caching interstitials is almost imperceptible.

Does anyone have any idea how to avoid this (besides disabling banners in the application)?

This is critical, especially on older devices.

Testing was conducted (iOS) on iPhone 5, iPhone 6s Plus, iPhone 7, iPad Mini 2, iPad Air 2 and (Android) Huawei Nova Lite 2017 (SLA-L22), Huawei MediaPad M3.

Thanks to everyone anyway!

I’ve noticed slowdowns and hiccups with a variety of ad networks and ad types.  

This is somewhat unavoidable as the plugins need to download ad content.  Sometimes that content comes in one big gulp.  Sometimes it doesn’t.  I also wouldn’t’ be surprised if some ad plugins stream their videos instead of downloading them first.

Anyways, the only sure solution is to avoid initializing and or loading when you’ve got something you need to display or your app is busy.  i.e. schedule these ad activities for when you app is idle or less busy.

I see many people do this when starting up:

  • ad.init()
  • ad.load()
  • ad.show()
  • Call composer goto.scene()

This is asking for trouble.  Not only does it ignore the need to wait for the init to complete, it also puts all that interrupting activity in front of the scene create() and display work.

This is better for splash screens:

  • Call composer goto.scene()
  • wait till scene loads and then call:
    • ad.init()
  • in listener, on ‘init’ ad.load()
  • in listener, on ‘loaded’ ad.show()

and game over scenes:

  • Call composer goto.scene()
  • wait till scene loads and then call:
    • ad.load()
  • in listener, on ‘loaded’ ad.show()

Hi!

It’s a well known issue, both Corona and Appodeal teams are working hard on performance improvement in their next releases. Mostly come from Admob’s animated banners.

Hi, roaminggamer!

Thank you for reply!

Manual control over ads is the only solution for now. 

I’m trying to find in the application places for caching banners with the least impact on performance. The most interesting thing in this problem is the lack of performance degradation when caching other types of advertising (Rewarded video, Interstitials).

But, as pointed out by karpovpw, this problem is known, and both Corona and Appodeal teams are working on it.

Hi, karpovpw!

Thank you for reply!

I hope this problem will be solved in the near future. Is there at least an approximate time frame?

Thank you again :slight_smile:

Well, the thing is - it’s more of an ads providers issue. They should update their sdks, then Appodeal should update their sdk (which takes quite some time, qa, betas and stuff) and then we can update our sample with the latest and greatest.

Sadly, I can’t give you an ETA on this issue for now.

I understood you. In this case, the only option at the moment is manual cache management of banners.

Could you clarify a couple of points.

  1. At the start of the application, I initialize the Appodeal plugin.

  2. The “init” phase calls the appodeal.load(banner) function.

  3. The “load” phase calls the function appodeal.show(banner).

  4. In the future, I call the appodeal.load (banner) function in the moments that are suitable for caching banners without affecting the performance of the application. At the same time, after the download is complete, the “load” phase will call the function appodeal.show(banner).

It is right?

I highly recommend to check docs before using some specific plugin (and this goes basically for everything where docs is available, not just Corona related stuff).

Take a closer look at https://docs.coronalabs.com/plugin/appodeal/load.html :

By default, Appodeal automatically caches ads in the background, so there is normally no need to load ads in advance. To use this function, you must turn off automatic caching as described in the documentation for appodeal.init().

I re-read this section along and across, repeatedly. :slight_smile:

I had a doubt about using the appodeal.hide when showing a new banner but I figured out this question.

And regarding the disabling of auto-caching @ appodeal.init, this is the first thing I did when using manual control of banners.

Thank you.

Well then, the case you’ve described looks ok for me.

I’ve noticed slowdowns and hiccups with a variety of ad networks and ad types.  

This is somewhat unavoidable as the plugins need to download ad content.  Sometimes that content comes in one big gulp.  Sometimes it doesn’t.  I also wouldn’t’ be surprised if some ad plugins stream their videos instead of downloading them first.

Anyways, the only sure solution is to avoid initializing and or loading when you’ve got something you need to display or your app is busy.  i.e. schedule these ad activities for when you app is idle or less busy.

I see many people do this when starting up:

  • ad.init()
  • ad.load()
  • ad.show()
  • Call composer goto.scene()

This is asking for trouble.  Not only does it ignore the need to wait for the init to complete, it also puts all that interrupting activity in front of the scene create() and display work.

This is better for splash screens:

  • Call composer goto.scene()
  • wait till scene loads and then call:
    • ad.init()
  • in listener, on ‘init’ ad.load()
  • in listener, on ‘loaded’ ad.show()

and game over scenes:

  • Call composer goto.scene()
  • wait till scene loads and then call:
    • ad.load()
  • in listener, on ‘loaded’ ad.show()

Hi!

It’s a well known issue, both Corona and Appodeal teams are working hard on performance improvement in their next releases. Mostly come from Admob’s animated banners.

Hi, roaminggamer!

Thank you for reply!

Manual control over ads is the only solution for now. 

I’m trying to find in the application places for caching banners with the least impact on performance. The most interesting thing in this problem is the lack of performance degradation when caching other types of advertising (Rewarded video, Interstitials).

But, as pointed out by karpovpw, this problem is known, and both Corona and Appodeal teams are working on it.

Hi, karpovpw!

Thank you for reply!

I hope this problem will be solved in the near future. Is there at least an approximate time frame?

Thank you again :slight_smile:

Well, the thing is - it’s more of an ads providers issue. They should update their sdks, then Appodeal should update their sdk (which takes quite some time, qa, betas and stuff) and then we can update our sample with the latest and greatest.

Sadly, I can’t give you an ETA on this issue for now.

I understood you. In this case, the only option at the moment is manual cache management of banners.

Could you clarify a couple of points.

  1. At the start of the application, I initialize the Appodeal plugin.

  2. The “init” phase calls the appodeal.load(banner) function.

  3. The “load” phase calls the function appodeal.show(banner).

  4. In the future, I call the appodeal.load (banner) function in the moments that are suitable for caching banners without affecting the performance of the application. At the same time, after the download is complete, the “load” phase will call the function appodeal.show(banner).

It is right?

I highly recommend to check docs before using some specific plugin (and this goes basically for everything where docs is available, not just Corona related stuff).

Take a closer look at https://docs.coronalabs.com/plugin/appodeal/load.html :

By default, Appodeal automatically caches ads in the background, so there is normally no need to load ads in advance. To use this function, you must turn off automatic caching as described in the documentation for appodeal.init().

I re-read this section along and across, repeatedly. :slight_smile:

I had a doubt about using the appodeal.hide when showing a new banner but I figured out this question.

And regarding the disabling of auto-caching @ appodeal.init, this is the first thing I did when using manual control of banners.

Thank you.

Well then, the case you’ve described looks ok for me.