AdLad
§Type Parameters
§Constructors
You can instantiate the AdLad class with a list of plugins that should be supported. You can then make function calls to the AdLad instance, which will pass on requests such as showing full screen ads to the plugin that is currently active. Only a single plugin can be active, which will be picked during instantiation.
There are three methods for picking which plugin should be active:
- First, every plugin can self report to AdLad whether it wishes to be active. Most plugins always want to be active, but some plugins can be configured to only be active depending on the domain the page is embedded on. If multiple plugins wish to be active, the first plugin from the provided list will be picked. This allows you to set a priority each plugin.
- Secondly, you can pick a plugin using the
pluginoption. This will override the priority list, and the request for plugins to be active or not will be ignored. - Lastly, plugins can be activated using the
?adlad=query string. This will override all previous options. However, because this can potentially be abused by players in order to disable ads, there are some configurations available in order to control or completely disable this functionality.
Using the query string to select plugins is the recommended method. Doing it like <this will allow you to provide your domain including the query string to different game portals, which is a much more robust way than trying to figure out where your game is being embedded. The domains from game portals may change at any time, in which case you will have to update its plugin. The query string, on the other hand, can be configured by you and so will likely never change.
If you still want to make sure players can not disable ads using the query string,
you can set invalidQueryStringPluginBehaviour to either "error" or "default"
§Properties
The name of the plugin that is currently active or null when no plugin is active.
This is true when a plugin has initialized and supports the {@link showRewardedAd} method.
When this is true, that is not a guarantee that {@link showRewardedAd} will always show an ad.
It might still fail due to adblockers, time constraints, unknown reasons, etc.
Sends a custom request to the plugin that is currently active.
Every plugin can handle these requests according their own specification.
This allows plugins to extend their functionality with features that are not built-in into AdLad.
For example, an sdk might have support for a happytime() call or getting an invite link.
Example usage
adLad.customRequests.myCoolCustomRequest("foo");
Properties of this object will always be callable, even if the active plugin doesn't implement the custom request.
In the example above, the call will essentially be a no-op if the active plugin doesn't implement myCoolCustomRequest.
You can still call it and you don't have to check if the function exists.
Plugins often share a similar signature for similar requests.
When two plugins require the same arguments, you can use this just fine
and your request will be forwarded to the plugin that is currently active.
But it's possible that two plugins have name clashes between commands and both require a different set of parameters.
In that case you can use {@link customRequestSpecific} to target your parameters to a specific plugin.
This is true when an ad is playing or about to play and your game should be paused.
The difference between this and {@link needsMute} is that this becomes true a little sooner, the moment
an ad is requested. Though the actual order in which the two change might differ per plugin.
Use {@link onNeedsPauseChange} to listen for changes.
This is true when an ad is playing and your audio should be muted.
The difference between this and {@link needsPause} is that this becomes true a little later when an ad
is actually playing. Though the actual order in which the two change might differ per plugin.
Use {@link onNeedsMuteChange} to listen for changes.
This is true when a plugin has initialized and supports the {@link showFullScreenAd} method.
When this is true, that is not a guarantee that {@link showFullScreenAd} will always show an ad.
It might still fail due to adblockers, time constraints, unknown reasons, etc.
This is true when a plugin has initialized and supports the {@link showBannerAd} method.
When this is true, that is not a guarantee that {@link showBannerAd} will always show an ad.
It might still fail due to adblockers, time constraints, unknown reasons, etc.
§Methods
Similar to {@link customRequests} but targets a specific plugin.
If the specified plugin is not the active plugin, this is a no-op.
Example usage
adLad.customRequestsForPlugin("plugin-name").myCoolCustomRequest("foo");
Registers a callback that is fired when {@link canShowBannerAd} changes.
Registers a callback that is fired when {@link canShowFullScreenAd} changes.
Registers a callback that is fired when {@link canShowRewardedAd} changes.
Registers a callback that is fired when {@link needsPause} changes.
Use this to mute your game during ads.
Registers a callback that is fired when {@link needsPause} changes.
Use this to pause your game during ads.
Use this to unregister callbacks registered with {@link onCanShowBannerAdChange}.
Use this to unregister callbacks registered with {@link onCanShowFullScreenAdChange}.
Use this to unregister callbacks registered with {@link onCanShowRewardedAdChange}.
Use this to unregister callbacks registered with {@link onNeedsMuteChange}.
Use this to unregister callbacks registered with {@link onNeedsPauseChange}.
Waits for the plugin to initialize and shows a full screen ad once it's ready.
Waits for the plugin to initialize and shows a rewarded ad once it's ready.