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 DTDRemoteConfigclass 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.
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:
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:
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:
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:
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:
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:
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 UDTDAnalyticsBPLibrary::InitializeWithAbTest initialization method.
If you used UDTDAnalyticsBPLibrary::Initialize previously, you need to replace it with UDTDAnalyticsBPLibrary::InitializeWithAbTest as the SDK initialization method.
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:
Example of SDK initialization that includes A/B testing:
importUIKitimportDTDAnalytics@mainclassAppDelegate: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)returntrue }// The method is called when the configuration has been receivedfunconReceived(result: DTDRemoteConfigReceiveResult) {print("Configuration received, result \(result)") }// Called when experiment is foundfunconPrepareToChange() {print("Experiment found") }// Called when SDK receives configfunconChanged(result: DTDRemoteConfigChangeResult, error: Error?) {print("DTDRemoteConfigChangeResult: \(result)")iflet error = error {print("DTDRemoteConfigError: \(error.localizedDescription)") } DTDRemoteConfig.applyConfig()// Use here or notify config listeners that actualConfig is readylet btnColorRemoteValue = DTDRemoteConfig.config["button_color"].stringValuelet btnSizeRemoteValue = DTDRemoteConfig.config["button_size"].stringValueprint("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:
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:
Example of SDK initialization that includes A/B testing:
classMainActivity : AppCompatActivity(), DTDRemoteConfigListener {overridefunonCreate(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 */overridefunonReceived(result: DTDRemoteConfigReceiveResult) { Log.d("D2D", "Configuration received") }/** * Called when experiment is found */overridefunonPrepareToChange() { Log.d("D2D", "Experiment found") }/** * called when SDK receives config */overridefunonChanged(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 readyval btnColorRemoteValue = DTDRemoteConfig.config["button_color"].stringValueval btnSizeRemoteValue = DTDRemoteConfig.config["button_size"].stringValue Log.d("D2D", "button color: $btnColorRemoteValue") Log.d("D2D", "button size: $btnSizeRemoteValue") }}
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:
Example of SDK initialization that includes A/B testing:
publicclassMainActivityJavaextendsAppCompatActivityimplementsDTDRemoteConfigListener { @OverrideprotectedvoidonCreate(@NullableBundle savedInstanceState) { super.onCreate(savedInstanceState);setContentView(R.layout.activity_main);// Config timeout, optionalDTDRemoteConfig.INSTANCE.setRemoteConfigWaiting(10.0);// Group timeout, optionalDTDRemoteConfig.INSTANCE.setGroupDefinitionWaiting(15.0);// Implementation defaults paramsHashMap<String,Object> map =newHashMap<>();map.put("button_color","green");map.put("button_size","8");// Initialize SDK with ab testDTDRemoteConfig.INSTANCE.setDefaults(map); } @OverridepublicvoidonReceived(@NonNullDTDRemoteConfigReceiveResult result) {Log.d("D2D","Configuration received"); } @OverridepublicvoidonPrepareToChange() {Log.d("D2D","Experiment found"); } @OverridepublicvoidonChanged(@NonNullDTDRemoteConfigChangeResult result, @NullableException 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 readyString 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); }}
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:
Example of SDK initialization that includes A/B testing:
usingSystem.Collections.Generic;usingDevToDev.Analytics;usingDevToDev.Analytics.ABTest;usingUnityEngine;namespaceAbTesting{publicclassExample:MonoBehaviour,IDTDRemoteConfigListener {privatevoidStart() {DontDestroyOnLoad(this); // Config timeout, optionalDTDRemoteConfig.RemoteConfigWaiting=10.0; // Group timeout, optionalDTDRemoteConfig.GroupDefinitionWaiting=15.0; // Implementation defaults paramsDTDRemoteConfig.Defaults=newDictionary<string,object> { {"button_color","green"}, {"button_size",8} }; // Initialize SDK with ab testDTDAnalytics.InitializeWithAbTests("app_key",this); } // The method is called when the configuration has been receivedpublicvoidOnReceived(DTDRemoteConfigReceiveResult result) {Debug.Log($"Configuration received, result {result}"); } // Called when experiment is foundpublicvoidOnPrepareToChange() {Debug.Log("Experiment found"); } // Called when SDK receives configpublicvoidOnChanged(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 readyDTDRemoteConfig.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}"); } }}
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:
Example of SDK initialization that includes A/B testing:
usingDevToDev.Analytics;usingSystem.Collections.Generic;usingSystem.Diagnostics;classMyRemoteConfigListener:IDTDRemoteConfigListener{ /** * The method is called when the configuration has been received */publicvoidOnReceived(DTDRemoteConfigReceiveResult result) {Debug.WriteLine("Configuration has been received!"); } /** * Called when experiment is found */publicvoidOnPrepareToChange() {Debug.WriteLine("Experiment was found!"); } /** * Called when SDK receives config */publicvoidOnChanged(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 }}publicstaticclassProgram{publicstaticvoidMain(string[] args) { // Config timeout, optionalDTDRemoteConfig.RemoteConfigWaiting=10; // Group timeout, optionalDTDRemoteConfig.GroupDefinitionWaiting=15; // Implementation defaults paramsDTDRemoteConfig.Defaults=newDictionary<string,object> { ["button_color"] ="green", ["button_size"] =8 }; // Create listenervar listener =newMyRemoteConfigListener(); // Initialize SDK with ab testDTDAnalytics.InitializeWithAbTest("appKey", listener); }}
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:
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, optionalUDTDRemoteConfigBPLibrary::SetRemoteConfigWaiting(10.0f);// Group timeout, optionalUDTDRemoteConfigBPLibrary::SetGroupDefinitionWaiting(15.0f);// Implementation defaults paramsFDTDRemoteConfigDefaults 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 receivedconstauto onConfigReceive =newFDTDRemoteConfigReceiveResultDelegate();onConfigReceive->BindLambda([=](EDTDRemoteConfigReceiveResult result){ UE_LOG(LogTemp, Warning,TEXT("Configuration received, result %s"),*UEnum::GetValueAsString(result));});// Called when experiment is foundconstauto onPrepareToChange =newFDTDRemoteConfigPrepareToChangeDelegate();onPrepareToChange->BindLambda([=](){UE_LOG(LogTemp, Warning,TEXT("Experiment found"));});// Called when SDK receives configconstauto onConfigChange =newFDTDRemoteConfigChangeResultDelegate();onConfigChange->BindLambda([=](EDTDRemoteConfigChangeResult result,constFString& 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 testUDTDAnalyticsBPLibrary::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:
Example of SDK initialization that includes A/B testing:
func_ready():# Config timeout, optionalDTDRemoteConfig.SetRemoteConfigWaiting(10)# Group timeout, optionalDTDRemoteConfig.SetGroupDefinitionWaiting(10)# Implementation defaults paramsvar defaults =GDDTDRemoteConfigDefaults.new() defaults.AddStringValue("button_color","green") defaults.AddIntegerValue("button_size",8)DTDRemoteConfig.SetDefaults(defaults)# Initialize SDK with ab testDTDAnalytics.SetLogLevel(GDDTDLogLevel.Debug)DTDAnalytics.InitializeWithConfigWithAbTest("appKey", onRemoteConfigChange, onRemoteConfigPrepareToChange, onRemoteConfigReceive)# The method is called when the configuration has been receivedfunconRemoteConfigReceive(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 funconRemoteConfigPrepareToChange():print("Experiment found")# Called when SDK receives configfunconRemoteConfigChange(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 readyvar 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.
DTDRemoteConfigCollection
Wrapper for remote parameters collection. Enables access to configuration values by using subscripting syntax.
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.
DTDRemoteConfigListener
It implements methods that report the status of A/B tests.
IDTDRemoteConfigListener
IDTDRemoteConfigListener
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