The availability of features may depend on your plan type. Contact your Customer Success Manager if you have any questions.

Dev guideRecipesAPI Reference
Dev guideAPI ReferenceUser GuideLegal TermsGitHubDev CommunityOptimizely AcademySubmit a ticketLog In
Dev guide

Configure event dispatcher for the Android SDK

How to configure the event dispatcher for HTTP requests made from every impression or conversion in the Optimizely Feature Experimentation Android SDK.

The Optimizely Feature Experimentation SDKs make HTTP requests for every decision event or conversion event that gets triggered. Each SDK has a built-in event dispatcher for handling these events, but we recommend overriding it based on the specifics of your environment.

The Android SDK has an out-of-the-box asynchronous dispatcher. We recommend customizing the event dispatcher you use in production to ensure that you queue and send events in a manner that scales to the volumes handled by your application. Customizing the event dispatcher allows you to take advantage of features like batching, which makes it easier to handle large event volumes efficiently or to implement retry logic when a request fails. You can build your dispatcher from scratch or start with the provided dispatcher.

The examples show that to customize the event dispatcher, initialize the Optimizely client (or manager) with an event dispatcher instance.

// Using an anonymous class here to implement the EventHandler interface.
// Feel free to create an explicit class that implements the interface instead.
val eventHandler = object : EventHandler {
   override fun dispatchEvent(logEvent: LogEvent) {
      // Send event to our log endpoint as documented in
      // https://developers.optimizely.com/x/events/api/index.html
   }
}

// Build a manager
val optimizelyManager = OptimizelyManager.builder()
          .withSDKKey("SDK_KEY_HERE")
          .withEventDispatchInterval(60, TimeUnit.SECONDS)
          .withEventHandler(eventHandler)
          .build(context)

// With the new Android O differences, you need to register the
// service for the intent filter you desire in code instead of in the manifest.
val eventRescheduler = EventRescheduler()
context.registerReceiver(eventRescheduler,
           IntentFilter(WifiManager.SUPPLICANT_CONNECTION_CHANGE_ACTION))
// Using an anonymous class here to implement the EventHandler interface.
// Feel free to create an explicit class that implements the interface instead.
EventHandler eventHandler = new EventHandler() {
   @Override
   public void dispatchEvent(LogEvent logEvent) throws Exception {
      // Send event to our log endpoint as documented in 
      // https://developers.optimizely.com/x/events/api/index.html
   }
};

// Build a manager
OptimizelyManager optimizelyManager = OptimizelyManager.builder()
       .withSDKKey("SDK_KEY_HERE")
       .withEventDispatchInterval(60, TimeUnit.SECONDS)
       .withEventHandler(eventHandler)
       .build(context);


// With the new Android O differences, you need to register the
// service for the intent filter you desire in code instead of in the manifest.
EventRescheduler eventRescheduler = new EventRescheduler();

context.registerReceiver(eventRescheduler,
           new IntentFilter(WifiManager.SUPPLICANT_CONNECTION_CHANGE_ACTION));

The event dispatcher should implement a dispatchEvent function, which takes in three arguments: httpVerb, url, and params, all of which are created by the internal EventBuilder class. In this function, you should send a POST request to the given url using the params as the body of the request (be sure to stringify it to JSON) and {content-type: 'application/json'} in the headers.

🚧

Important

If you are using a custom event dispatcher, do not modify the event payload returned from Optimizely Feature Experimentation. Modifying this payload will alter your results.

The included event handler implementation includes queueing and flushing, so it will work even if an app is offline. The event handler uses an IntentService to queue up events to dispatch. If they fail to send, they are stored in a sqlite database and scheduled to be dispatched later. If you want to have events flushed when Wi-Fi is available or after reboot or reinstall using the default event handler, you need to augment your AndroidManifest.xml to include the intent filter declarations.

//  Add these lines to your manifest if you want the event handler background services to schedule themselves again after a boot or package replace.
<receiver
    android:name="com.optimizely.ab.android.event_handler.EventRescheduler"
    android:enabled="true"
    android:exported="false">
    <intent-filter>
        <action android:name="android.intent.action.MY_PACKAGE_REPLACED" />
        <action android:name="android.intent.action.BOOT_COMPLETED" />
        <action android:name="android.net.wifi.supplicant.CONNECTION_CHANGE" />
    </intent-filter>
</receiver>

You will need to implement EventHandler to use your own event handler.

📘

Note

To handle backgrounding in Android O and later, you also need to register your event handler rescheduler in code. See the code sample above.