LogoLogo
My AppsLive demoNewsArticles
  • Introduction
  • 📌Product updates: 2025
    • 2024
    • 2023
  • Getting Started
    • Registration
    • Adding a space
    • Adding an app to the space
  • Basic Events & Custom Events
  • Integration
    • Expert Tips
      • What to track
      • Payments & Anti-cheat
      • Check your integration
    • Integration of SDK 2.0+
      • SDK Integration
        • Android
        • iOS
        • macOS
        • Windows
        • Web
          • Web SDK Integration
          • Web SDK Releases
        • Unity
        • Unreal Engine
        • Godot Engine
      • Automatic payment tracking
        • App Store
        • Google Play
      • Setting up Events
        • Basic methods
        • Secondary methods
        • User profile
        • Anticheat methods
        • Track sessions
      • Push notifications
        • Android
        • iOS
        • Windows (UWP)
        • Unity
          • Android
          • iOS
          • Windows (UWP/WSA)
        • Unreal Engine
      • A/B testing
        • Description of A/B testing on the SDK side
        • Working with A/B tests in the devtodev interface
        • A/B testing examples
    • Integration of SDK 1.0+ (deprecated)
      • SDK Integration
        • iOS
        • Android
        • Windows 8.1 and 10
        • Web
        • Unity
        • Mac OS
        • Adobe Air
        • UE4
      • Setting up Events
        • Basic methods
        • Secondary methods
        • User profile
        • Anti-cheat Methods
      • Push Notifications
        • IOS
        • Android
        • Windows 8.1 and Windows 10
        • Unity
        • Abode Air
        • UE4
    • Test Devices
    • Server API
      • Data API 2.0
      • Subscription API
      • Push API
        • IOS
        • Android
        • Windows UWP
        • Windows
      • Raw Export
      • Labels API
      • Data API
    • Import historical data via API
    • Data Export
      • Data Export to Cloud Storage (BigQuery / Amazon S3)
  • 3rd Party Sources
    • Attribution Trackers
      • AppsFlyer
      • Adjust
      • Branch.io
      • Kochava
      • Tenjin
      • Tune (MAT)
      • Singular
      • Custom postback API
      • Facebook Ads referral decryption
    • App Marketplace Data
      • App Store Connect Stats
      • App Store Subscriptions
      • Google Play Console Stats
      • Google Play Subscriptions
      • AppGallery Connect Stats
    • Ad revenue
      • AdColony
      • AdMob
      • Facebook
      • MoPub
      • Unity Ads
      • Vungle
      • Ad revenue API
    • Cohort export
  • Reports and Functionality
    • Space-related Reports and Functionality
      • Overview
      • Custom dashboards & Reports
      • SQL
        • SQL tips
        • SQL Query examples
      • Audience overlap
    • Project-related Reports and Functionality
      • Overview
        • Real-Time Dashboard
        • Acquisition reports
        • Engagement reports
        • Monetization reports
        • In-game analysis reports
        • Cohort analysis
      • Reports
      • Push Notifications
        • Android Notifications
        • IOS Notifications
        • Windows Notifications
        • Button Templates
      • Predictions
      • Users & Segments
      • Filters
      • A/B Testing
      • Tuning
      • Settings
  • Metrics and Glossary
    • Ad networks metrics
    • Market Metrics
    • Prediction Metrics
    • SDK Metrics
    • Subscription metrics
  • Space Management
  • User Profile Management
  • Limits
  • Scenarios and Best Practices
    • Analytics use cases
    • Match-3
    • MMORPG Games
    • Hyper-Casual games
    • Social Casino
    • RPG games
    • Farming games
    • Non-gaming app
    • Acquisition Example
  • FAQ
    • Identification
    • Raw Data
    • All about data discrepancies
  • Slack
Powered by GitBook
On this page
  • Step 1
  • Step 2
  • Step 3
  • Step 4
  • Examples of SDK integration intended for working with A/B tests
  • Some features of A/B testing
  • Description of external interfaces

Was this helpful?

Export as PDF
  1. Integration
  2. Integration of SDK 2.0+
  3. A/B testing

Description of A/B testing on the SDK side

Step 1

Some operations can take a while because the SDK operates asynchronously. These operations are:

A/B test configuration.

After you’ve created an A/B test in the web interface, the SDK will receive its configuration via the network. Use the remoteConfigWaiting property in the DTDRemoteConfig class to set the maximum time allowed for waiting for the A/B test configuration.

remoteConfigWaitingis set in seconds

By default, the remoteConfigWaiting value is equal to null. This means that the test configuration waiting time is unlimited. The limitation is important in case the test that you are about to execute can influence your app functioning.

Example: DTDRemoteConfig.remoteConfigWaiting = 10

In this case, the SDK will wait for the A/B test configuration for 10 seconds. If it won’t receive the config during the allocated time, it will notify the developer by using the onReceived(result: DTDRemoteConfigReceiveResult) method with Failure value and disable the A/B testing until the next SDK initialization.

Waiting for an A/B test group.

After the SDK finds a test, it will wait for a suitable group to include the user into and start the experiment.

By default, waiting time (groupDefinitionWaiting) is 10 seconds.

You can change this value up or down.

Example: DTDRemoteConfig.groupDefinitionWaiting = 15

In this case, the SDK will wait for a group for no more than 15 seconds. If It can't find a suitable test for 15 seconds, it will be cancelled and its activation will be impossible. After the next SDK initialization (app restart), the user will have another chance to participate in the test.

The DTDRemoteConfig.remoteConfigWaiting and DTDRemoteConfig.groupDefinitionWaitingvalues can be set only prior to SDK initialization!

Step 2

In the DTDRemoteConfig class you need to set the default variables and their values using the DTDRemoteConfig.defaults property.

The variable values in the defaults property do not change on the SDK side.

After setting up DTDRemoteConfig.defaults, you can receive the variable values by using the DTDRemoteConfig.config property.

When working with A/B tests, always use the config property to receive the actual variables and their values!

If for some reasons, the device can not be included in the test (no network or network problems, devtodev did not assign it to a group, incorrect SDK implementation, etc.) DTDRemoteConfig.config will return default values. Using this approach, you can always shape the desirable UI and the business logic of the app.

Step 3

To work with A/B testing, use the DTDAnalytics.initializeWithAbTest initialization method.

If you used DTDAnalytics.initialize previously, you need to replace it with DTDAnalytics.initializeWithAbTest as the SDK initialization method.

The DTDRemoteConfigListener interface is added to the initializeWithAbTest method. It implements three methods:

  • onReceived(result: DTDRemoteConfigReceiveResult)

  • onPrepareToChange()

  • onChanged(result: DTDRemoteConfigChangeResult, error: Error?)

The DTDRemoteConfigListenermethods are not called in the main thread - you need to keep this in mind when interacting with UI elements of the app. Also, do not execute operations that block the thread in the DTDRemoteConfigListener methods, because this will disable the SDK operation (see examples).

To work with A/B testing, use the [DTDAnalytics applicationKey:* abConfigListener:*] initialization method.

If you used [DTDAnalytics applicationKey:*] previously, you need to replace it with [DTDAnalytics applicationKey:* abConfigListener:*] as the SDK initialization method.

The DTDRemoteConfigListener interface is added to the [DTDAnalytics applicationKey:* abConfigListener:*] method. It implements three methods:

  • -(void)onReceivedResult:(enum DTDRemoteConfigReceiveResult)result

  • -(void)onPrepareToChange

  • -(void)onChangedResult:(enum DTDRemoteConfigChangeResult)result error:(NSError *)error

The DTDRemoteConfigListenermethods are not called in the main thread - you need to keep this in mind when interacting with UI elements of the app. Also, do not execute operations that block the thread in the DTDRemoteConfigListener methods, because this will disable the SDK operation (see examples).

To work with A/B testing, use the DTDAnalytics.initializeWithAbTest initialization method.

If you used DTDAnalytics.initialize previously, you need to replace it with DTDAnalytics.initializeWithAbTest as the SDK initialization method.

The IRemoteConfigListener interface is added to the initializeWithAbTest method. It implements three methods:

  • onReceived(result: DTDRemoteConfigReceiveResult)

  • onPrepareToChange()

  • onChanged(result: DTDRemoteConfigChangeResult, ex: Exception?)

The DTDRemoteConfigListenermethods are not called in the main thread - you need to keep this in mind when interacting with UI elements of the app. Also, do not execute operations that block the thread in the DTDRemoteConfigListener methods, because this will disable the SDK operation (see examples).

To work with A/B testing, use the DTDAnalytics.INSTANCE.initializeWithAbTest initialization method.

If you used DTDAnalytics.INSTANCE.initialize previously, you need to replace it with DTDAnalytics.INSTANCE.initializeWithAbTest as the SDK initialization method.

The IRemoteConfigListener interface is added to the initializeWithAbTest method. It implements three methods:

  • void onReceived(@NonNull DTDRemoteConfigReceiveResult result)

  • void onPrepareToChange()

  • void onChanged(@NonNull DTDRemoteConfigChangeResult result, @Nullable Exception ex)

The DTDRemoteConfigListenermethods are not called in the main thread - you need to keep this in mind when interacting with UI elements of the app. Also, do not execute operations that block the thread in the DTDRemoteConfigListener methods, because this will disable the SDK operation (see examples).

To work with A/B testing, use the DTDAnalytics.InitializeWithAbTests initialization method.

If you used DTDAnalytics.Initialize previously, you need to replace it with DTDAnalytics.InitializeWithAbTests as the SDK initialization method.

The DTDRemoteConfigListener interface is added to the InitializeWithAbTests method. It implements three methods:

  • OnReceived(DTDRemoteConfigReceiveResult result)

  • OnPrepareToChange()

  • OnChanged(DTDRemoteConfigChangeResult result, string exceptionMessage = null)

The DTDRemoteConfigListenermethods are not called in the main thread - you need to keep this in mind when interacting with UI elements of the app. Also, do not execute operations that block the thread in the DTDRemoteConfigListener methods, because this will disable the SDK operation (see examples).

To work with A/B testing, use the DTDAnalytics.InitializeWithAbTests initialization method.

If you used DTDAnalytics.Initialize previously, you need to replace it with DTDAnalytics.InitializeWithAbTests as the SDK initialization method.

The IDTDRemoteConfigListener interface is added to the InitializeWithAbTests method. It implements three methods:

  • OnReceived(DTDRemoteConfigReceiveResult result)

  • OnPrepareToChange()

  • OnChanged(DTDRemoteConfigChangeResult result, string error)

The DTDRemoteConfigListenermethods are not called in the main thread - you need to keep this in mind when interacting with UI elements of the app. Also, do not execute operations that block the thread in the DTDRemoteConfigListener methods, because this will disable the SDK operation (see examples).

Known Limitations: A/B Testing in Restricted Browser Environments

When running the A/B testing module in an iframe, certain browsers with strict privacy settings (e.g., Safari, Firefox, Brave) may block access to storage mechanisms such as cookies or localStorage. This limitation prevents the proper functioning of A/B tests in these environments. SDK is checking the possibility of accessing storage and will turn off the A/B testing for such a user/device if that's the case.

To work with A/B testing, use the devtodev.initializeWithAbTest initialization method.

If you used devtodev.initialize previously, you need to replace it with devtodev.initializeWithAbTest as the SDK initialization method.

The initializeWithAbTest method as a third parameter takes an object with 3 Callable as arguments, to work with A/B tests it is necessary to implement:

  • onReceived(result: DTDRemoteConfigReceiveResult)

  • onPrepareToChange()

  • onChanged(result: DTDRemoteConfigChangeResult, error: String)

window.devtodev.initializeWithAbTest(
    appKey, 
    {
        userId: userId,
        logLevel: logLevel,
        trackingAvailability: true,
    },
    {
        onReceived: function(result) {
            console.log('onReceived callback', result)
        },
        onPrepareToChange: function() {
            console.log('onPrepareToChange callback')
        },
        onChanged: function(result, error) {
            console.log('onChanged callback', result, error)
        }
    }
)

To work with A/B testing, use the UDTDAnalyticsBPLibrary::InitializeWithAbTest initialization method.

If you used UDTDAnalyticsBPLibrary::Initialize previously, you need to replace it with UDTDAnalyticsBPLibrary::InitializeWithAbTest as the SDK initialization method.

Implements three delegate methods:

  • onRemoteConfigReceive(EDTDRemoteConfigReceiveResult result)

  • onRemoteConfigPrepareToChange()

  • onRemoteConfigChange(EDTDRemoteConfigChangeResult result, FString error)

DECLARE_DELEGATE(FDTDRemoteConfigPrepareToChangeDelegate);
DECLARE_DELEGATE_OneParam(FDTDRemoteConfigReceiveResultDelegate, EDTDRemoteConfigReceiveResult);
DECLARE_DELEGATE_TwoParams(FDTDRemoteConfigChangeResultDelegate, EDTDRemoteConfigChangeResult, const FString&);

To work with A/B testing, use the DTDAnalytics.InitializeWithAbTest initialization method.

If you used DTDAnalytics.initialize previously, you need to replace it with DTDAnalytics.initializeWithAbTest as the SDK initialization method.

The InitializeWithAbTest method takes 3 Callable as arguments, to work with A/B tests it is necessary to implement:

  • onRemoteConfigReceive(result: GDDTDRemoteConfigReceiveResult.ReceiveResult)

  • onRemoteConfigPrepareToChange()

  • onRemoteConfigChange(result: GDDTDRemoteConfigChangeResult.ChangeResult, error: String)

Step 4

Methods implementation for working with A/B tests. When suitable conditions for the test occur, the following chain of events gets initiated:

  • Calling onReceived method

  • Calling onPrepareToChange method

  • Calling onChanged method

OnReceived

The onReceived method is triggered every time when the SDK loads A/B test configuration. The result argument returns the following:

  • Success if the configuration was loaded in the time provided. Time is set by the user in DTDRemoteConfig.remoteConfigWaiting.

  • Failure if the config wasn’t received during the provided time defined by the user in DTDRemoteConfig.remoteConfigWaiting.

  • Empty if the configuration was loaded in the time provided, but the list of experiments is empty. Time is set by the user in DTDRemoteConfig.remoteConfigWaiting.

If the DTDRemoteConfig.remoteConfigWaiting’s default value is equal to null, the OnReceived method and DTDRemoteConfigReceiveResult.Success are called when the config is received. The time of the OnReceived call depends on the network speed.

OnPrepareToChange

The onPrepareToChange() method is designed to notify the developer that the configuration of the A/B tests will be changed (the test is found or canceled, switch to a user who is not participating in the experiment, etc. (see Some features in the behavior of interfaces)).

SDK asynchronous behavior causes a gap in time between the moment the suitable conditions for the test occur and its possible activation. You need to keep this in mind when changing the app’s UI and UX and pause the user’s interaction with the app until it comes into action:

  • onChanged (see onChanged description) and a decision on test participation with a new config is made (see applyConfig description).

  • A timer on the developer’s side. The timer defines the time allocated for new config waiting. After the time has run out, waiting for the config should be canceled.

See the implementation example (Scenario 1)

After calling onPrepareToChange, the SDK executes an asynchronous request for entering the test. That will result in calling onChanged.

In case of disruption of the Internet connection or loss of focus, the test will be considered canceled until the next app launch.

onChanged

The onChanged method is triggered in one of the following cases:

  • The DevToDev server offers to enroll in a test. onChanged() with DTDRemoteConfigChangeResult.success is called

  • The DevToDev server refuses to execute the test. onChanged() with DTDRemoteConfigChangeResult.failure is called

  • The device has no internet connection. onChanged() with DTDRemoteConfigChangeResult.failure is called

  • If the offer is received after the 30 second waiting time has expired onChanged() with DTDRemoteConfigChangeResult.failure is called

  • The test was previously activated (during the initialization) onChanged() with DTDRemoteConfigChangeResult.success is called

If the onChanged method is triggered with status == DTDRemoteConfigChangeResult.success value, the possible options are:

  • Accept the configuration by calling the DTDRemoteConfig.applyConfig() method If the configuration is accepted, the default parameters and group parameters (issued by the server) will overlap. After that, the parameters of the new configuration will be available in DTDRemoteConfig.config (you can use them to change the behavior or the interface of the app).

  • Refuse enrollment in the test DTDRemoteConfig.resetConfig() If the test enrollment is refused or the time for decision making is up, the SDK will temporarily flag the test and it will become unavailable until the next initialization. After the next initialization, the test will be available for participation when its requirements are fulfilled.

In the cases where status == DTDRemoteConfigChangeResult.failure, the DTDRemoteConfig.applyConfig() method will be triggered and the default configuration will stay in place.

Examples of SDK integration intended for working with A/B tests

Set the default values DTDRemoteConfig.defaults = ["button_color": "green", "button_size": "8"]

Variable names have to be the same as in the ‘Group settings’ section of the web interface (see ‘web’ above). When the SDK gets included in the A/B test, the devtodev server automatically assigns it to a group.

SDK will not use new variable values that are not set in DTDRemoteConfig.defaults

Example of the DTDRemoteConfig.configvalue variants:

Key/Value
defaults
Control Group
Group A
Group B

button_color

green

green

blue

gray

button_size

8

8

12

14

Example of SDK initialization that includes A/B testing:

import UIKit
import DTDAnalytics

@main
class AppDelegate: UIResponder, UIApplicationDelegate, DTDRemoteConfigListener {
    func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool {
        // Config timeout, optional
        DTDRemoteConfig.remoteConfigWaiting = 10.0
        // Group timeout, optional
        DTDRemoteConfig.groupDefinitionWaiting = 15.0
        // Implementation defaults params
        DTDRemoteConfig.defaults = ["button_color": "green",
                                    "button_size": "8"]
        // Initialize SDK with ab test
        DTDAnalytics.initializeWithAbTest(applicationKey: "appKey",
                                          abConfigListener: self)
        return true
    }

    // The method is called when the configuration has been received
    func onReceived(result: DTDRemoteConfigReceiveResult) {
        print("Configuration received, result \(result)")
    }

    // Called when experiment is found
    func onPrepareToChange() {
        print("Experiment found")
    }

    // Called when SDK receives config
    func onChanged(result: DTDRemoteConfigChangeResult, error: Error?) {
        print("DTDRemoteConfigChangeResult: \(result)")
        if let error = error {
            print("DTDRemoteConfigError: \(error.localizedDescription)")
        }
        DTDRemoteConfig.applyConfig()
        // Use here or notify config listeners that actualConfig is ready
        let btnColorRemoteValue = DTDRemoteConfig.config["button_color"].stringValue
        let btnSizeRemoteValue = DTDRemoteConfig.config["button_size"].stringValue
        print("button color: \(btnColorRemoteValue)")
        print("button size: \(btnSizeRemoteValue)")
    }
}

Set the default values DTDRemoteConfig.defaults = @{"button_color": @"green", @"button_size": @"8"}

Variable names have to be the same as in the ‘Group settings’ section of the web interface (see ‘web’ above). When the SDK gets included in the A/B test, the devtodev server automatically assigns it to a group.

SDK will not use new variable values that are not set in DTDRemoteConfig.defaults

Example of the DTDRemoteConfig.configvalue variants:

Key/Value
defaults
Control Group
Group A
Group B

button_color

green

green

blue

gray

button_size

8

8

12

14

Example of SDK initialization that includes A/B testing:

#import "AppDelegate.h"
#import "DTDAnalytics/DTDAnalytics-Swift.h"

@interface AppDelegate () <DTDRemoteConfigListener>

@end

@implementation AppDelegate

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
    // Config timeout, optional
    DTDRemoteConfig.remoteConfigWaiting = 10.0;
    // Group timeout, optional
    DTDRemoteConfig.groupDefinitionWaiting = 15.0;
    // Implementation defaults params
    DTDRemoteConfig.defaults = @{@"button_color": @"green",
                                 @"button_size": @"8"};
    [DTDAnalytics applicationKey:@"appKey" abConfigListener:self];
    return YES;
}

// The method is called when the configuration has been received
- (void)onReceivedResult:(enum DTDRemoteConfigReceiveResult)result {
    NSLog(@"Configuration received, result %ld", (long)result);
}

// Called when experiment is found
- (void)onPrepareToChange {
    NSLog(@"Experiment found");
}

- (void)onChangedResult:(enum DTDRemoteConfigChangeResult)result error:(NSError *)error {
    NSLog(@"DTDRemoteConfigChangeResult: %ld", (long)result);
    if (error) {
        NSLog(@"DTDRemoteConfigError: %@", error.localizedDescription);
    }
    [DTDRemoteConfig applyConfig];
    // Use here or notify config listeners that actualConfig is ready
    NSString *btnColorRemoteValue = DTDRemoteConfig.config[@"button_color"].stringValue;
    NSString *btnSizeRemoteValue = DTDRemoteConfig.config[@"button_size"].stringValue;
    NSLog(@"button color: %@", btnColorRemoteValue);
    NSLog(@"button size: %@", btnSizeRemoteValue);
}
@end

Set the default values DTDRemoteConfig.defaults = mapOf("button_color" to "green", "button_size" to "8")

Variable names have to be the same as in the ‘Group settings’ section of the web interface (see ‘web’ above). When the SDK gets included in the A/B test, the devtodev server automatically assigns it to a group.

SDK will not use new variable values that are not set in DTDRemoteConfig.defaults

Example of the DTDRemoteConfig.configvalue variants:

Key/Value
defaults
Control Group
Group A
Group B

button_color

green

green

blue

gray

button_size

8

8

12

14

Example of SDK initialization that includes A/B testing:

class MainActivity : AppCompatActivity(), DTDRemoteConfigListener {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_main)
        
        // Config timeout, optional
        DTDRemoteConfig.remoteConfigWaiting = 10.0
        // Group timeout, optional
        DTDRemoteConfig.groupDefinitionWaiting = 15.0
        // Implementation defaults params
        DTDRemoteConfig.defaults = mapOf("button_color" to "green", "button_size" to "8")
        // Initialize SDK with ab test
        DTDAnalytics.initializeWithAbTest(appKey = "appKey", context = this, abConfigListener = this)
    } 
    
    /**
     * The method is called when the configuration has been received
     */
    override fun onReceived(result: DTDRemoteConfigReceiveResult) {
       Log.d("D2D", "Configuration received") 
    }
    
    /**
     * Called when experiment is found
     */
    override fun onPrepareToChange() {
       Log.d("D2D", "Experiment found") 
    }

    /**
     * called when SDK receives config
     */
    override fun onChanged(result: DTDRemoteConfigChangeResult, ex: Exception?) {
        Log.d("D2D", "DTDRemoteConfigChangeResult: ${result.name}")
        ex?.let {
            Log.d("D2D", "DTDRemoteConfigErr: ${ex.message}")
        }
        DTDRemoteConfig.applyConfig()
        // Use here or notify config listeners that actualConfig is ready
        val btnColorRemoteValue = DTDRemoteConfig.config["button_color"].stringValue
        val btnSizeRemoteValue = DTDRemoteConfig.config["button_size"].stringValue
        Log.d("D2D", "button color: $btnColorRemoteValue")
        Log.d("D2D", "button size: $btnSizeRemoteValue")
    }
}

Set the default values:

HashMap<String, Object> map = new HashMap<>();
map.put("button_color", "green");
map.put("button_size", "8");
DTDRemoteConfig.INSTANCE.setDefaults(map);

Variable names have to be the same as in the ‘Group settings’ section of the web interface (see ‘web’ above). When the SDK gets included in the A/B test, the devtodev server automatically assigns it to a group.

SDK will not use new variable values that are not set in DTDRemoteConfig.defaults

Example of the DTDRemoteConfig.configvalue variants:

Key/Value
defaults
Control Group
Group A
Group B

button_color

green

green

blue

gray

button_size

8

8

12

14

Example of SDK initialization that includes A/B testing:

public class MainActivityJava extends AppCompatActivity implements DTDRemoteConfigListener {

    @Override
    protected void onCreate(@Nullable Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);

        // Config timeout, optional
        DTDRemoteConfig.INSTANCE.setRemoteConfigWaiting(10.0);
        // Group timeout, optional
        DTDRemoteConfig.INSTANCE.setGroupDefinitionWaiting(15.0);
        // Implementation defaults params
        HashMap<String, Object> map = new HashMap<>();
        map.put("button_color", "green");
        map.put("button_size", "8");
        // Initialize SDK with ab test
        DTDRemoteConfig.INSTANCE.setDefaults(map);
    }

    @Override
    public void onReceived(@NonNull DTDRemoteConfigReceiveResult result) {
        Log.d("D2D", "Configuration received");
    }

    @Override
    public void onPrepareToChange() {
        Log.d("D2D", "Experiment found");
    }

    @Override
    public void onChanged(@NonNull DTDRemoteConfigChangeResult result, @Nullable Exception ex) {
        Log.d("D2D", "DTDRemoteConfigChangeResult: " + result.name());
        if (ex != null) {
            Log.d("D2D", "DTDRemoteConfigErr: " + ex);
        }

        DTDRemoteConfig.INSTANCE.applyConfig();
        // Use here or notify config listeners that actualConfig is ready
        String btnColorRemoteValue = DTDRemoteConfig.INSTANCE.getConfig().get("button_color").getStringValue();
        String btnSizeRemoteValue = DTDRemoteConfig.INSTANCE.getConfig().get("button_size").getStringValue();
        Log.d("D2D", "button color: " + btnColorRemoteValue);
        Log.d("D2D", "button size: " + btnSizeRemoteValue);
    }
}

Set the default values:

DTDRemoteConfig.Defaults = new Dictionary<string, object>
{
   {"button_color", "green"},
   {"button_size", 8}
};

Variable names have to be the same as in the ‘Group settings’ section of the web interface (see ‘web’ above). When the SDK gets included in the A/B test, the devtodev server automatically assigns it to a group.

SDK will not use new variable values that are not set in DTDRemoteConfig.Defaults

Example of the DTDRemoteConfig.Config value variants:

Key/Value
defaults
Control Group
Group A
Group B

button_color

green

green

blue

gray

button_size

8

8

12

14

Example of SDK initialization that includes A/B testing:

using System.Collections.Generic;
using DevToDev.Analytics;
using DevToDev.Analytics.ABTest;
using UnityEngine;

namespace AbTesting
{
    public class Example : MonoBehaviour, IDTDRemoteConfigListener
    {
        private void Start()
        {
            DontDestroyOnLoad(this);
            // Config timeout, optional
            DTDRemoteConfig.RemoteConfigWaiting = 10.0;
            // Group timeout, optional
            DTDRemoteConfig.GroupDefinitionWaiting = 15.0;
            // Implementation defaults params
            DTDRemoteConfig.Defaults = new Dictionary<string, object>
            {
                {"button_color", "green"},
                {"button_size", 8}
            };

            // Initialize SDK with ab test
            DTDAnalytics.InitializeWithAbTests("app_key", this);
        }

        // The method is called when the configuration has been received
        public void OnReceived(DTDRemoteConfigReceiveResult result)
        {
            Debug.Log($"Configuration received, result {result}");
        }
        
        // Called when experiment is found
        public void OnPrepareToChange()
        {
            Debug.Log("Experiment found");
        }

        // Called when SDK receives config
        public void OnChanged(DTDRemoteConfigChangeResult result, string exceptionText = null)
        {
            Debug.Log($"DTDRemoteConfigChangeResult: {result}");
            if (exceptionText != null)
            {
                Debug.Log($"DTDRemoteConfigError: {exceptionText}");
            }

            // Use here or notify config listeners that actualConfig is ready
            DTDRemoteConfig.ApplyConfig();
            var buttonColorRemoteValue = DTDRemoteConfig.Config["button_color"].StringValue();
            var buttonSizeRemoteValue = DTDRemoteConfig.Config["button_size"].IntValue();
            Debug.Log($"button color: {buttonColorRemoteValue}");
            Debug.Log($"button size: {buttonSizeRemoteValue}");
        }
    }
}

Set the default values:

DTDRemoteConfig.Defaults = new Dictionary<string, object> 
{
  ["button_color"] = "green",
  ["button_size"] = 8
};

Variable names have to be the same as in the ‘Group settings’ section of the web interface (see ‘web’ above). When the SDK gets included in the A/B test, the devtodev server automatically assigns it to a group.

SDK will not use new variable values that are not set in DTDRemoteConfig.Defaults

Example of the DTDRemoteConfig.Config value variants:

Key/Value
defaults
Control Group
Group A
Group B

button_color

green

green

blue

gray

button_size

8

8

12

14

Example of SDK initialization that includes A/B testing:

using DevToDev.Analytics;
using System.Collections.Generic;
using System.Diagnostics;

class MyRemoteConfigListener : IDTDRemoteConfigListener
{
    /**
     * The method is called when the configuration has been received
     */
    public void OnReceived(DTDRemoteConfigReceiveResult result)
    {
      Debug.WriteLine("Configuration has been received!");
    }
    
    /**
     * Called when experiment is found
     */
    public void OnPrepareToChange()
    {
      Debug.WriteLine("Experiment was found!");
    }
    
    /**
     * Called when SDK receives config
     */
    public void OnChanged(DTDRemoteConfigChangeResult result, string error)
    {
      Debug.WriteLine($"Result: {result}");
      if (result == DTDRemoteConfigChangeResult.Failure)
      {
        Debug.WriteLine($"Error: {error}");
      }
      
      DTDRemoteConfig.ApplyConfig();
      DTDRemoteConfig.ApplyConfig();
      var buttonColorRemoteValue = DTDRemoteConfig.Config["button_color"].StringValue;
      var buttonSizeRemoteValue = DTDRemoteConfig.Config["button_size"].IntValue;
      Debug.WriteLine($"button color: {buttonColorRemoteValue}");
      Debug.WriteLine($"button size: {buttonSizeRemoteValue}");
      // Use here or notify config listeners that config is ready
    }
}
  
public static class Program
{
    public static void Main(string[] args)
    {
        // Config timeout, optional
        DTDRemoteConfig.RemoteConfigWaiting = 10;
        
        // Group timeout, optional
        DTDRemoteConfig.GroupDefinitionWaiting = 15;
        
        // Implementation defaults params
        DTDRemoteConfig.Defaults = new Dictionary<string, object> 
        {
          ["button_color"] = "green",
          ["button_size"] = 8
        };
        
        // Create listener
        var listener = new MyRemoteConfigListener();
        
        // Initialize SDK with ab test
        DTDAnalytics.InitializeWithAbTest("appKey", listener);
    }
}

Set the default values DTDRemoteConfig.SetDefaults()

Variable names have to be the same as in the ‘Group settings’ section of the web interface (see ‘web’ above). When the SDK gets included in the A/B test, the devtodev server automatically assigns it to a group.

SDK will not use new variable values that are not set in DTDRemoteConfig.defaults

Example of the DTDRemoteConfig value variants:

Key/Value

defaults

Control Group

Group A

Group B

button_color

green

green

blue

gray

button_size

8

8

12

14

Example of SDK initialization that includes A/B testing:

window.devtodev.remoteConfig.defaults = {
   button_color: 'green',
   button_size:  8
}
window.devtodev.initializeWithAbTest(
    appKey, 
    {
        userId: userId,
        logLevel: logLevel,
        trackingAvailability: trackingAvailability,
    },
    {
        onReceived: function(result) {
            console.log('onReceived callback', result)
        },
        onPrepareToChange: function() {
            console.log('onPrepareToChange callback')
        },
        onChanged: function(result, error) {
            console.log('onChanged callback', result, error)
            window.devtodev.remoteConfig.applyConfig()
            var config = window.devtodev.remoteConfig.config // DTDRemoteConfigCollection
            var buttonSizeRemoteValue =  window.devtodev.remoteConfig.config["button_size"].intValue;
            var buttonColorRemoteValue = window.devtodev.remoteConfig.config["button_color"].stringValue;
            console.log("button color: ", buttonColorRemoteValue);
            console.log("button size: ", buttonSizeRemoteValue);
        }
    }
)

Set the default values:

// Implementation defaults params
FDTDRemoteConfigDefaults defaults;
defaults.StringDefaults.Add("button_color", "green");
defaults.IntegerDefaults.Add("button_size", 8);

Variable names have to be the same as in the ‘Group settings’ section of the web interface (see ‘web’ above). When the SDK gets included in the A/B test, the devtodev server automatically assigns it to a group.

SDK will not use new variable values that are not set in DTDRemoteConfig.defaults

Example of the DTDRemoteConfig.configvalue variants:

Key/Value
defaults
Control Group
Group A
Group B

button_color

green

green

blue

gray

button_size

8

8

12

14

Example of SDK initialization that includes A/B testing:

#include "DTDAnalytics/Public/DTDAnalyticsBPLibrary.h"
#include "DTDAnalytics/Public/DTDRemoteConfigBPLibrary.h"

UDTDAnalyticsBPLibrary::SetLogLevel(EDTDLogLevel::Debug);

// Config timeout, optional
UDTDRemoteConfigBPLibrary::SetRemoteConfigWaiting(10.0f);
// Group timeout, optional
UDTDRemoteConfigBPLibrary::SetGroupDefinitionWaiting(15.0f);

// Implementation defaults params
FDTDRemoteConfigDefaults defaults;
defaults.StringDefaults.Add("button_color", "green");
defaults.IntegerDefaults.Add("button_size", 8);

UDTDRemoteConfigBPLibrary::SetDefaults(defaults);

// The method is called when the configuration has been received
const auto onConfigReceive = new FDTDRemoteConfigReceiveResultDelegate();
onConfigReceive->BindLambda([=](EDTDRemoteConfigReceiveResult result)
{	
	UE_LOG(LogTemp, Warning, TEXT("Configuration received, result %s"), *UEnum::GetValueAsString(result));
});

// Called when experiment is found
const auto onPrepareToChange = new FDTDRemoteConfigPrepareToChangeDelegate();
onPrepareToChange->BindLambda([=]()
{
	UE_LOG(LogTemp, Warning, TEXT("Experiment found"));
});

// Called when SDK receives config
const auto onConfigChange = new FDTDRemoteConfigChangeResultDelegate();
onConfigChange->BindLambda([=](EDTDRemoteConfigChangeResult result, const FString& error)
{
	UE_LOG(LogTemp, Warning, TEXT("DTDRemoteConfigChangeResult: %s"), *UEnum::GetValueAsString(result));
	if (!error.IsEmpty()) {
		UE_LOG(LogTemp, Warning, TEXT("DTDRemoteConfigError: %s"), *error);
	}

	// Use here or notify config listeners that actualConfig is ready
	UDTDRemoteConfigBPLibrary::ApplyConfig();

	FString ButtonColorRemoteValue = UDTDRemoteConfigBPLibrary::GetRemoteConfigValue("button_color").StringValue;
        int32 buttonSizeRemoteValue = UDTDRemoteConfigBPLibrary::GetRemoteConfigValue("button_size").IntegerValue;
	UE_LOG(LogTemp, Warning, TEXT("button color: : %s"), *ButtonColorRemoteValue);
	UE_LOG(LogTemp, Warning, TEXT("button size:: %d"), buttonSizeRemoteValue);
});

// Initialize SDK with ab test
UDTDAnalyticsBPLibrary::InitializeWithAbTest("AppKey", *onConfigChange, *onPrepareToChange, *onConfigReceive);

Set the default values DTDRemoteConfig.SetDefaults()

Variable names have to be the same as in the ‘Group settings’ section of the web interface (see ‘web’ above). When the SDK gets included in the A/B test, the devtodev server automatically assigns it to a group.

SDK will not use new variable values that are not set in DTDRemoteConfig.defaults

Example of the DTDRemoteConfig value variants:

Key/Value
defaults
Control Group
Group A
Group B

button_color

green

green

blue

gray

button_size

8

8

12

14

Example of SDK initialization that includes A/B testing:

func _ready():
    	# Config timeout, optional
	DTDRemoteConfig.SetRemoteConfigWaiting(10)
	# Group timeout, optional
	DTDRemoteConfig.SetGroupDefinitionWaiting(10)
    	# Implementation defaults params
	var defaults = GDDTDRemoteConfigDefaults.new()
	defaults.AddStringValue("button_color", "green")
	defaults.AddIntegerValue("button_size", 8)
	DTDRemoteConfig.SetDefaults(defaults)
    	# Initialize SDK with ab test
	DTDAnalytics.SetLogLevel(GDDTDLogLevel.Debug)
	DTDAnalytics.InitializeWithConfigWithAbTest(
		"appKey",
		onRemoteConfigChange,
		onRemoteConfigPrepareToChange,
		onRemoteConfigReceive)

# The method is called when the configuration has been received
func onRemoteConfigReceive(result: GDDTDRemoteConfigReceiveResult.ReceiveResult):
	match result:
		GDDTDRemoteConfigReceiveResult.ReceiveResult.Failure:
			print("onRemoteConfigReceive result = Failure")
			
		GDDTDRemoteConfigReceiveResult.ReceiveResult.Success:
			print("onRemoteConfigReceive result = Success")
			
		GDDTDRemoteConfigReceiveResult.ReceiveResult.Empty:
			print("onRemoteConfigReceive result = Empty")
			
		_:
			print("onRemoteConfigReceive result = Unknown")

# Called when experiment is found		
func onRemoteConfigPrepareToChange():
	print("Experiment found")
			
# Called when SDK receives config
func onRemoteConfigChange(result: GDDTDRemoteConfigChangeResult.ChangeResult, error: String):
	if !error.is_empty(): 
		print("error = " + error)
		
	match result:
		GDDTDRemoteConfigChangeResult.ChangeResult.Failure:
			print("onRemoteConfigChange result = Failure")	
			
		GDDTDRemoteConfigChangeResult.ChangeResult.Success:
			
			print("onRemoteConfigChange result = Success")
		_: 
			print("onRemoteConfigChange result = Unknown")
			
	DTDRemoteConfig.ApplyConfig()
	
	# Use here or notify config listeners that actualConfig is ready
	var btnColorRemoteValue = DTDRemoteConfig.GetRemoteConfigValue("button_color").GetStringValue()
	var btnSizeRemoteValue = DTDRemoteConfig.GetRemoteConfigValue("button_size").GetStringValue()
	print("button color: " + btnColorRemoteValue)
	print("button size: " + btnSizeRemoteValue)

Some features of A/B testing

When the SDK finds a suitable test(s), it calls the onPrepareToChange method and reports it. Then the SDK starts a timer for 30 seconds and sends a request to the devtodev server. The server returns an experiment number and information about a group. Or the server answers that the user can not participate in the test. This process takes some time. The request and answer can take as little as milliseconds, or much longer (30 seconds maximum) if, for example, the device’s internet connection is bad. Below, you can find several use cases that may help you to solve this problem if your app’s interface is sensitive to waiting for the config from devtodev.

Description of external interfaces

DTDRemoteConfig

When working with this class, the SDK provides synchronization of threads that aims at providing safe operation taking into account the asynchrony of the SDK.

Property
Description

remoteConfigWaiting: Double

Wait time for A/B test configuration.

Default value - 0.0 (measured in seconds)

groupDefinitionWaiting: Double

Wait time for test group.

Default value - 10.0 (measured in seconds)

defaults: [String, Any]

Variables and their default values

config: DTDRemoteConfigCollection

Wrapper for remote parameters in the form of a collection. It allows access to the configuration values by using the subscripting syntaxis.

Actual variables and their values for working with A/B tests

applyConfig()

It applies the A/B testing configuration. After the call, the default parameters get matched with the group parameters.

resetConfig()

It cancels a suitable or running test

cacheTestExperiment()

A debug method for saving a test experiment after restarting the application

Property
Description

remoteConfigWaiting: double

Wait time for A/B test configuration.

Default value - 0.0 (measured in seconds)

groupDefinitionWaiting: double

Wait time for test group.

Default value - 10.0 (measured in seconds)

defaults: NSDictionary<NSString *,id>

Variables and their default values

config: DTDRemoteConfigCollection

Wrapper for remote parameters in the form of a collection. It allows access to the configuration values by using the subscripting syntaxis.

Actual variables and their values for working with A/B tests

(void) applyConfig

It applies the A/B testing configuration. After the call, the default parameters get matched with the group parameters.

(void) resetConfig

It cancels a suitable or running test

(void) cacheTestExperiment

A debug method for saving a test experiment after restarting the application

Property
Description

remoteConfigWaiting: Double

Wait time for A/B test configuration.

Default value - 0.0 (measured in seconds)

groupDefinitionWaiting: Double

Wait time for test group.

Default value - 10.0 (measured in seconds)

defaults: Map<String, Any>

Variables and their default values

config: DTDRemoteConfigCollection

Wrapper for remote parameters in the form of a collection. It allows access to the configuration values by using the subscripting syntaxis.

Actual variables and their values for working with A/B tests

applyConfig()

It applies the A/B testing configuration. After the call, the default parameters get matched with the group parameters.

resetConfig()

It cancels a suitable or running test

cacheTestExperiment()

A debug method for saving a test experiment after restarting the application

Property
Description

setRemoteConfigWaiting()

Wait time for A/B test configuration.

Default value - 0.0 (measured in seconds)

getRemoteConfigWaiting()

Wait time for test group.

setGroupDefinitionWaiting()

Wait time for test group.

Default value - 10.0 (measured in seconds)

getGroupDefinitionWaiting()

Get time for test group.

setDefaults(Map<String, ? extends Object>)

Set map of variables and their default values

Map<String,Object> getDefaults()

Get map of variables and their default values

DTDRemoteConfigCollection getConfig()

Wrapper for remote parameters in the form of a collection. It allows access to the configuration values by using the subscripting syntaxis.

Actual variables and their values for working with A/B tests

applyConfig()

It applies the A/B testing configuration. After the call, the default parameters get matched with the group parameters.

resetConfig()

It cancels a suitable or running test

cacheTestExperiment()

A debug method for saving a test experiment after restarting the application

Property
Description

double RemoteConfigWaiting {get;set;}

Wait time for A/B test configuration.

Default value - 0.0 (measured in seconds)

double GroupDefinitionWaiting {get;set}

Wait time for test group.

Default value - 10.0 (measured in seconds)

Dictionary<string, object> DTDRemoteConfig.Defaults {get;set}

Variables and their default values

DTDRemoteConfigCollection DTDRemoteConfig.Config

Wrapper for remote parameters in the form of a collection. It allows access to the configuration values by using the subscripting syntaxis.

Actual variables and their values for working with A/B tests

void ApplyConfig()

It applies the A/B testing configuration. After the call, the default parameters get matched with the group parameters.

void ResetConfig()

It cancels a suitable or running test

void CacheTestExperiment()

A debug method for saving a test experiment after restarting the application

Property
Description

RemoteConfigWaiting: double

Wait time for A/B test configuration.

Default value - 0.0 (measured in seconds)

GroupDefinitionWaiting: double

Wait time for test group.

Default value - 10.0 (measured in seconds)

Defaults: IDictionary<String, object>

Variables and their default values

Config: DTDRemoteConfigCollection

Wrapper for remote parameters in the form of a collection. It allows access to the configuration values by using the subscripting syntaxis.

Actual variables and their values for working with A/B tests

ApplyConfig()

It applies the A/B testing configuration. After the call, the default parameters get matched with the group parameters.

ResetConfig()

It cancels a suitable or running test

CacheTestExperiment()

A debug method for saving a test experiment after restarting the application

Property
Description

remoteConfigWaiting

Wait time for A/B test configuration.

Default value - 0 (measured in seconds)

groupDefinitionWaiting

Wait time for test group.

Default value - 15 (measured in seconds)

defaults

Variables and their default values

config

Wrapper for remote parameters in the form of a collection. It allows access to the configuration values by using the subscripting syntaxis.

Actual variables and their values for working with A/B tests

applyConfig()

It applies the A/B testing configuration. After the call, the default parameters get matched with the group parameters.

resetConfig()

It cancels a suitable or running test

cacheTestExperiment()

A debug method for saving a test experiment after restarting the application

Property
Description

SetRemoteConfigWaiting(float value)

Wait time for A/B test configuration.

Default value - 0.0 (measured in seconds)

float GetRemoteConfigWaiting()

Wait time for test group.

SetGroupDefinitionWaiting(float value)

Wait time for test group.

Default value - 10.0 (measured in seconds)

GetGroupDefinitionWaiting()

Get time for test group.

SetDefaults(const FDTDRemoteConfigDefaults& defaults)

Set USTRUCT with variables and their default values

TMap<FString, FDTDRemoteConfigValue> GetConfig()

Actual variables and their values for working with A/B tests

FDTDRemoteConfigValue GetRemoteConfigValue(const FString& key)

Return actual value for variable key

bool HasKey(const FString& key)

Verify if there are any values associated with the variable key in the remote configuration.

ApplyConfig()

It applies the A/B testing configuration. After the call, the default parameters get matched with the group parameters.

ResetConfig()

It cancels a suitable or running test

CacheTestExperiment()

A debug method for saving a test experiment after restarting the application

Property
Description

void SetRemoteConfigWaiting(int value)

Wait time for A/B test configuration.

Default value - 0 (measured in seconds)

int GetRemoteConfigWaiting()

Wait time for test group.

void SetGroupDefinitionWaiting(int value)

Wait time for test group.

Default value - 10 (measured in seconds)

int GetGroupDefinitionWaiting()

Get time for test group.

void SetDefaults(defaults: GDDTDRemoteConfigDefaults)

Set GDDTDRemoteConfigDefaults with variables and their default values

GDDTDRemoteConfigValue GetRemoteConfigValue(key: String)

Return actual value for variable key

bool HasKey(key: String)

Verify if there are any values associated with the variable key in the remote configuration.

void ApplyConfig()

It applies the A/B testing configuration. After the call, the default parameters get matched with the group parameters.

void ResetConfig()

It cancels a suitable or running test

void CacheTestExperiment()

A debug method for saving a test experiment after restarting the application

DTDRemoteConfigCollection

Wrapper for remote parameters collection. Enables access to configuration values by using subscripting syntax.

Method

hasKey(key)

Return true if current configuration has value for a key.

values

Returns the plain object of the current configuration with key/values pairs

Method

hasKey(key: String)

Return true if current configuration has value for a key.

DTDRemoteConfigValue

Wrapper for working with remote configuration variables. It represents a method for data source identification, as well as methods for presenting values in the form of various data types.

type
Description

DTDRemoteConfigSource.Default

The variable is set by default.

DTDRemoteConfigSource.Remote

The variable is set by the test group.

DTDRemoteConfigSource.Empty

The variable is not found in the remote configuration.

Property
type
Description

stringValue

String?

Gets the value as an optional string.

floatValue

Float

Gets the value as a Float.

doubleValue

Double

Gets the value as a Double.

Int32Value

Int32

Gets the value as an Int32.

Int64Value

Int64

Gets the value as an Int64.

integerValue

Int

Gets the value as an Int.

boolValue

Bool

Gets the value as a Bool.

Property
type
Description

stringValue

NSString

Gets the value as an optional string.

floatValue

float

Gets the value as a Float.

doubleValue

double

Gets the value as a Double.

Int32Value

long

Gets the value as an long.

Int64Value

long long

Gets the value as an long long.

integerValue

NSInteger

Gets the value as an NSInteger.

boolValue

BOOL

Gets the value as a Bool.

Property
type
Description

stringValue

String?

Gets the value as an optional string.

floatValue

Float

Gets the value as a Float.

doubleValue

Double

Gets the value as a Double.

intValue

Int

Gets the value as an int.

longValue

Long

Gets the value as an long.

booleanValue

Boolean

Gets the value as a Bool.

Property
type
Description

getStringValue

String

Gets the value as an optional string.

getFloatValue

float

Gets the value as a Float.

getDoubleValue

double

Gets the value as a Double.

getIntValue

int

Gets the value as an Int.

getLongValue

long

Gets the value as an Long.

getBooleanValue

Boolean

Gets the value as a Boolean.

Property
type
Description

StringValue

string

Gets the value as an optional string.

FloatValue

float

Gets the value as a float.

DoubleValue

double

Gets the value as a double.

LongValue

long

Gets the value as an long.

IntValue

int

Gets the value as an int.

BoolValue

bool

Gets the value as a bool.

Property
type
Description

StringValue

String

Gets the value as an optional string.

FloatValue

float

Gets the value as a float.

DoubleValue

double

Gets the value as a double.

Int16Value

Int16

Gets the value as an Int16

Int32Value

Int32

Gets the value as an Int32

Int64Value

Int64

Gets the value as an Int64

BoolValue

bool

Gets the value as a bool.

Property
Type
Description

StringValue

String

Gets the value as an optional string.

FloatValue

Number

Gets the value as a float number

DoubleValue

Number

Gets the value as a double number

LongValue

String

Gets the value as a long

NB: can be simulated only via string in JavaScript

IntValue

Number

Gets the value as a number

BoolValue

Boolean

Gets the value as a boolean

Property
type
Description

StringValue

FString

Gets the value as an string.

FloatValue

float

Gets the value as a float.

LongValue

int64

Gets the value as an long.

IntValue

int32

Gets the value as an int.

BoolValue

bool

Gets the value as a bool.

Source

EDTDRemoteConfigSource

Gets source of the value.

Property
type
Description

GetStringValue

String

Gets the value as an string.

GetFloatValue

float

Gets the value as a float.

GetIntValue

int

Gets the value as an int.

GetBoolValue

bool

Gets the value as a bool.

GetSource

GDDTDRemoteConfigSource.Source

Gets source of the value.

DTDRemoteConfigListener

Not applied for Web SDK

It implements methods that report the status of A/B tests.

Method
Description

onReceived(result: DTDRemoteConfigReceiveResult)

It is triggered every time the SDK loads an A/B test configuration. If the remoteConfigWaiting has a default value (null), onReceived does not get called

onPrepareToChange()

It notifies the developer about coming changes in the A/B test configuration.

onChanged(result: DTDRemoteConfigChangeResult,

error: Error?)

It notifies the developer that the configuration has changed. Or about the reason why the configuration could not change.

Method
Description

-(void)onReceivedResult:

(enum DTDRemoteConfigReceiveResult)result

It is triggered every time the SDK loads an A/B test configuration. If the remoteConfigWaiting has a default value (null), onReceived does not get called

-(void)onPrepareToChange

It notifies the developer about coming changes in the A/B test configuration.

- (void)onChangedResult:

(enum DTDRemoteConfigChangeResult)result

error:(NSError *)error

It notifies the developer that the configuration has changed. Or about the reason why the configuration could not change.

Method
Description

onReceived(result: DTDRemoteConfigReceiveResult)

It is triggered every time the SDK loads an A/B test configuration. If the remoteConfigWaiting has a default value (null), onReceived does not get called

onPrepareToChange()

It notifies the developer about coming changes in the A/B test configuration.

onChanged(result: DTDRemoteConfigChangeResult, ex: Exception?)

It notifies the developer that the configuration has changed. Or about the reason why the configuration could not change.

Method
Description

onReceived(DTDRemoteConfigReceiveResult result)

It is triggered every time the SDK loads an A/B test configuration. If the remoteConfigWaiting has a default value (null), onReceived does not get called

onPrepareToChange()

It notifies the developer about coming changes in the A/B test configuration.

onChanged( DTDRemoteConfigChangeResult result, Exception ex)

It notifies the developer that the configuration has changed. Or about the reason why the configuration could not change.

IDTDRemoteConfigListener

Method
Description

void OnReceived(DTDRemoteConfigReceiveResult result);

It is triggered every time the SDK loads an A/B test configuration. If the remoteConfigWaiting has a default value (null), OnReceived does not get called

void OnPrepareToChange();

It notifies the developer about coming changes in the A/B test configuration.

void OnChanged(DTDRemoteConfigChangeResult result, string exceptionText = null);

It notifies the developer that the configuration has changed. Or about the reason why the configuration could not change.

IDTDRemoteConfigListener

Method
Description

OnReceived(DTDRemoteConfigReceiveResult result)

It is triggered every time the SDK loads an A/B test configuration. If the remoteConfigWaiting has a default value (null), OnReceived does not get called

OnPrepareToChange()

It notifies the developer about coming changes in the A/B test configuration.

OnChanged(DTDRemoteConfigChangeResult result, string error)

It notifies the developer that the configuration has changed. Or about the reason why the configuration could not change.

FDTDRemoteConfigReceiveResultDelegate

It is triggered every time the SDK loads an A/B test configuration. If the remoteConfigWaiting has a default value (null), OnReceived does not get called

DECLARE_DELEGATE_OneParam(FDTDRemoteConfigReceiveResultDelegate, EDTDRemoteConfigReceiveResult);

FDTDRemoteConfigPrepareToChangeDelegate

It notifies the developer about coming changes in the A/B test configuration.

DECLARE_DELEGATE(FDTDRemoteConfigPrepareToChangeDelegate);

FDTDRemoteConfigChangeResultDelegate

It notifies the developer that the configuration has changed. Or about the reason why the configuration could not change.

DECLARE_DELEGATE_TwoParams(FDTDRemoteConfigChangeResultDelegate, EDTDRemoteConfigChangeResult, const FString&);
Method
Description

onRemoteConfigReceive(result: GDDTDRemoteConfigReceiveResult.ReceiveResult):

It is triggered every time the SDK loads an A/B test configuration. If the remoteConfigWaiting has a default value (null), onReceived does not get called

onRemoteConfigPrepareToChange()

It notifies the developer about coming changes in the A/B test configuration.

onRemoteConfigChange(result: GDDTDRemoteConfigChangeResult.ChangeResult, error: String)

It notifies the developer that the configuration has changed. Or about the reason why the configuration could not change.

DTDRemoteConfigReceiveResult

It is triggered every time the SDK loads the configuration of A/B tests.

type
Description

DTDRemoteConfigReceiveResult.Success

It is triggered when the configuration of the A/B test is received.

DTDRemoteConfigReceiveResult.Failure

It is triggered if the SDK did not manage to get the A/B test configurations for the time period set in remoteConfigWaiting.

DTDRemoteConfigReceiveResult.Empty

It is triggered when the configuration of the A/B test is received, but the list of experiments is empty.

DTDRemoteConfigChangeResult

Notifies whether the configuration of the A/B test has been changed.

type
Description

DTDRemoteConfigReceiveResult.Success

Configuration is changed.

DTDRemoteConfigReceiveResult.Failure

Configuration change attempt failed.

Data options returned by the configChanged method signature

DTDRemoteConfigChangeResult
Exception message
Description

DTDRemoteConfigChangeResult.Success

null

When receiving an offer from the backend.

DTDRemoteConfigChangeResult.Success

null

When launching the SDK with a previously started test.

DTDRemoteConfigChangeResult.Success

null

When replacing the user with another user who previously started the test.

DTDRemoteConfigChangeResult.Failure

[A/B-Test Module] The Server refused to conduct the test.

If the server refused to provide a test available for participation.

DTDRemoteConfigChangeResult.Failure

[A/B-Test Module] Offer from devtodev not received within the allotted N seconds.

The backend offer is returned after a deadline e.g. due to a bad internet connection.

DTDRemoteConfigChangeResult.Failure

[A/B-Test Module] Offer from devtodev not received within the allotted N seconds.

The SDK was unable to receive an offer from the backend within N seconds e.g, duea bad internet connection or network problems.

DTDRemoteConfigChangeResult.Failure

[A/B-Test Module] In the process of receiving an offer from the server, the user was changed. Offer has been canceled.

When replacing the user with another user at the time of receiving an offer.

DTDRemoteConfigChangeResult.Failure

[A/B-Test Module] Offer refused, because application went into the background.

If a suitable test is found but the user made the app go into the background before the offer was received.

PreviousA/B testingNextWorking with A/B tests in the devtodev interface

Last updated 1 month ago

Was this helpful?

Blueprint
Blueprint
Blueprint
Blueprint
Blueprint
Blueprint
Blueprint