LINE Ads Network Guide

# AdLoader API Migration Guide

# Overview

This guide explains how to migrate to the AdLoader API, which is the standard API starting from iOS FiveSDK v3.0.0.

The AdLoader API consolidates the APIs used for SDK initialization and ad loading. The legacy APIs for SDK initialization and ad loading are deprecated, so code changes are required.

This document describes how to apply these changes.

# SDK Initialization

Previously, SDK initialization was done by registering an instance of FADConfig to FADSettings:

With the AdLoader API, SDK initialization is performed by obtaining a FADAdLoader instance for a given FADConfig:

Initialization fails only in very rare cases (for example, when allocating the storage area used by the SDK fails). It does not fail due to reasons such as network errors. Since there is very little chance that retrying will succeed once this initialization fails, retry logic is not required.

We recommend that you keep the obtained FADAdLoader instance in a field that is easily accessible from within your app. The simplest example is to store it on AppDelegate.

By doing this, you can easily use FADAdLoader from various parts of your application.

TIP

FADAdLoader instances are cached internally by the SDK, and the FADAdLoader retrieval process returns the same instance for the same configuration. Using this behavior, you can write code that uses the AdLoader API without explicitly keeping a FADAdLoader instance yourself.

However, there is a cost to guaranteeing thread safety around this cache. Therefore, in general, we recommend that you keep the FADAdLoader instance you obtain once and reuse it.

# Ad Loading

Previously, the ad loading flow looked like this:

  1. Create an ad object.
  2. Register a FADLoadDelegate.
  3. Call loadAdAsync.
  4. Receive a load success callback via fiveAdDidLoad.

With the AdLoader API, ad loading is done with the following steps:

  1. Create a FADAdSlotConfig.
  2. Call a load function on FADAdLoader.
  3. Receive the loaded ad object in the callback passed to the load function.

The load functions for each FADAdLoader ad format are as follows:

Ad Format Load function (Swift) Load function (Objective-C)
Custom layout loadBannerAd(with:withInitialWidth:withLoadCallback:) loadBannerAdWithConfig:withInitialWidth:withLoadCallback:
Rewarded video loadRewardAd(with:withLoadCallback:) loadRewardAdWithConfig:withLoadCallback:
Interstitial loadInterstitialAd(with:withLoadCallback:) loadInterstitialAdWithConfig:withLoadCallback:
Native loadNativeAd(with:withInitialWidth:withLoadCallback:) loadNativeAdWithConfig:withInitialWidth:withLoadCallback:

Below, we explain how to update the implementation of a custom layout ad load flow. Even if the ad format changes, only the load function differs; the migration steps are otherwise the same. You can use this example as a reference when updating other ad formats.

# Example (Custom Layout Ad)

The following code is an example of a custom layout ad loading flow using the legacy API.

We will now rewrite this code to use the AdLoader API. In this example, we assume that the FADAdLoader instance is stored in AppDelegate.

First, instead of creating a FADAdViewCustomLayout ad object directly, create a FADAdSlotConfig:

Next, use a FADAdLoader instance to call the appropriate load function:

FADLoadDelegate is no longer used. Instead, you pass a callback function. Therefore, instead of implementing FADLoadDelegate, you must move the logic previously implemented in that delegate into the “ad load success” and “ad load failure” parts of the callback.

Note that, unlike the previous approach, you must use the ad object returned in the callback instead of self.adCustomLayout.

For now, let’s extract the “ad load success” and “ad load failure” parts into separate methods:

TIP

The load callback is always invoked exactly once. On success, ad is set; on failure, error is set. Therefore, if error is nil, ad is guaranteed to have a value.

For simplicity, this guide uses strong references to self inside the callback, but you can also use a weak reference to further improve safety. However, because the load callback is guaranteed to be called only once and is then released, using a strong reference in this case does not introduce a risk of memory leaks.

Now implement the methods for handling success and failure. Since you don’t store the ad object in self.adCustomLayout, you don’t need to consider the possibility of reusing the same object, and you can omit calls such as removeFromSuperview.

This completes the migration to the AdLoader API. If you are using setEventListener to register event listeners, that part of the code can remain unchanged.

Finally, here is the completed code: