Choose the Right Integration Type - MoPub-Solutions-Eng/mopub.wiki.android.native.betasite GitHub Wiki
In the Native Ad Integration Types Overview, we introduced three integration types:
In order to determine the right native ad integration for your app, the below decision tree can be referenced:
Based on Your Ad Request Mechanism
You can begin your decision process by thinking about how you want to request ads.
I. Request ad in your current Activity
Integration type consideration: Ad Placer > Manual > Custom Manual
In a simple case where publishers want to request and render ads in the same Activity, either integrations types (Manual and Custom Manual) can be leveraged here.
II. Request ad in an AsyncTask
Integration type consideration: Manual > Custom Manual
If you are performance-minded, and have robust apps, you may want to to request ads asynchronously in an AsyncTask away from other heavy app activities.
An AsyncTask can be its own class, or can be bundled within an Activity. It has three stages, of which the second stage performs work away from the main thread. This time away from the main thread can be used for intensive tasks. As illustrated below, publishers need to surface back to the main thread when they instantiate their MoPubNative object. To request subsequent ads, sequentially rerun the AsyncTask. In this case, the ideal approach will be using Manual or Custom Manual integrations.
III. Request ad in your Application class
Integration type consideration: Manual > Custom Manual
If you want to request ads in another Activity or outside An activity, you may have to leverage a global (Application-level) ad loader class, which is accessible from everywhere inside the app. Code inside the Application class is the first to run on app launches, and can run outside an Activity via a global Context. In this sample, the ad is only requested once per app launch. To request another ad, terminate the app and relaunch it. The Advanced example allows the above logic to be reusable, so that you do not have to relaunch your app.
a. Extending Application Class (Basic)
Have a one-time global ad loader accessible across Activities:
b. Extending Application Class (Advanced):
Allows ads to be requested on demand across Activities. The logic is reusable.
Based on Your Ad Presentation
If you do not want to orient your decision process around the ad request, you can approach it from the ad presentation perspective.
In-Feed Ad View
Integration type consideration: Ad Placer > Manual > Custom Manual
To place native ad in continuous content feed, we strongly recommend to use Ad Placer integration, having the SDK handle everything for you. As mentioned in the previous section, the SDK provides pre-built adapters to facilitating placing ad in a ListView, RecyclerView or GridView, or you can build own adapter to use in your custom stream.
For cases where there is a mix of a content stream and specific requirements for either the Manual/Custom Manual approach, you could request a few single ad views and inject them into your own layout to achieve the same effect.
Single Ad View
Integration type consideration: Manual > Custom Manual
To place native ad in a single ad slot, like a regular 300x250 banner ad or a fullscreen ad, we recommend using the Manual approach. Via AdapterHelper, the SDK will return a pre-populated ad view with trackers integrated, so you can display that at a desired place.
