Allow Clients to Configure OkHttpClient for Improved Performance

[kamilReady]

Is your feature request related to a problem? Please describe.

The SDK doesn't allow clients to configure the OkHttpClient instance used for network operations. This creates a serious performance drawback since each app should maintain a single OkHttpClient instance to share thread pools and connection pools. Multiple instances lead to increased memory usage and reduced efficiency.

Describe the solution you'd like

Add a mechanism for clients to supply their own OkHttpClient instance during SDK initialization. This would enable:

• Sharing a single OkHttpClient across the entire application
• Reusing connection pools and thread pools

Describe alternatives you've considered

Exposing configuration options within the SDK would help but still results in multiple OkHttpClient instances if the client uses their own instance elsewhere, defeating the purpose of resource sharing.

Additional context

The OkHttp documentation recommends creating a single OkHttpClient instance and reusing it for all HTTP calls: "each client holds its own connection pool and thread pools. Reusing connections and threads reduces latency and saves memory."

This feature would align the SDK with best practices and allow developers to optimize their applications' network performance.

[mahmoud-elmorabea]

Hello,

Thanks for reaching out!

We currently don't support injecting custom OkHttpClient in our SDK however, our SDK tries to be non-invasive as possible by batching events together and sending them with a flushing policy of time or number of events, you can read about this here

You can also configure these numbers as you see fit using our SDK configuration:

val builder = CustomerIOConfigBuilder(applicationContext = context, "api-key")
    ...
    .flushAt(/* count */)
    .flushInterval( /* seconds */)
    .flushPolicies( /* policies */)

CustomerIO.initialize(builder.build())

Are you running into any performance issues or just trying to follow best practices outlined by OkHttp?

It might not be a bad idea to have 3rd party libraries have isolated clients. This keeps SDK traffic isolated for reliability and security (avoids app interceptors/retries/cookies changing behavior, preserves our TLS/pinning, and simplifies support/lifecycle). The extra client has negligible overhead since we do our best to be as non-invasive as possible and batch our requests.

[kamilReady]

Sharing OkHttpClient instances is standard practice for optimizing thread pool and connection pool usage. Without this, app startup performance suffers from resource fragmentation.

The SDK would remain fully isolated and you would still be able to configure the client properly via client.newBuilder() while allowing client customization. This is the standard approach - SDKs shouldn't force specific usage patterns that contradict tooling recommendations. The decision should remain with the client.

Examples like Glide and Coil demonstrate this pattern works well, allowing custom client configuration without compromising SDK functionality.

[Shahroz16]

Thanks @kamilReady for providing more context. We have pushed this for internal assessment and prioritization. Its not in our immediate plans, but we will update the ticket when there is a plan for this feature.