I\'m confused about how much memory AdMob SDK seem to be using, and where this memory is actually located. Let me explain.
I\'ve got two flavors of
Having test my app with 2 different implementations of AdMob I found that implementing it via java code and not XML is match lighter for the app.
Update No1:
You can also add custom listeners to destroy after some time and recreate in order to handle it even better. Serverside there is also a parameter telling the app ad how soon should ask for a new ad, I am not sure if it exist in all cases but it is there for DFP accounts.
A nice suggested way to implement the ad is that:
new Handler(new Handler.Callback() {
@Override
public boolean handleMessage(Message msg) {
if (!isBeingDestroyed) {
final AdRequest adRequest = new AdRequest();
final AdView adView = (AdView) findViewById(R.id.ad);
adView.loadAd(adRequest);
}
}).sendEmptyMessageDelayed(0, 1000);
also do not forget to call adView.destroy()
onDestroy() activity or when you do not want it any more!
The above way is mentioned here with many useful memory releases!
Update No2: (improvement at Update No1)
An improvement to the suggested handler way.
Using that way you avoid (I hope) the handler callbacks that may be stacked when intentionally an activity created/destroyed before the delayed message is send. This is more likely to happen if you decide increase 1000
milliseconds:
Create a Field for the handler:
private adHandler;
At your onCreate
:
adHandler = new Handler(new Handler.Callback() {
@Override
public boolean handleMessage(Message msg) {
if (!isBeingDestroyed) {
final AdRequest adRequest = new AdRequest();
final AdView adView = (AdView) findViewById(R.id.ad);
adView.loadAd(adRequest);
}
return false;
}
});
adHandler.sendEmptyMessageDelayed(0, 1000);
At your onDestroy
do not forget to "release" the handler:
adHandler.removeCallbacksAndMessages(null);
null removes any callbacks see doc