The new LD Android SDK version preview in public

[audkar]

Is your feature request related to a problem? Please describe. We hear that new, reworked version of LD Android SDK is in progress for quite some time. It's a great opportunity to have solution that solves current pain-points. However it's really hard to do such upfront work without actually getting feedback from the users.

Describe the solution you'd like Open-sourcing and developing SDK in the public.

Additional context

While there is no exact ETA yet, we also have a new major version in the pipeline that will improve Android in general, we will reply on this either when we have new information or when the new version comes out.

@louis-launchdarkly

I am afraid that cycle until the new version of SDK will be suitable might be prolonged, since users will see it only in final stage which might not fully satisfy basic needs. That would lead to additional rework.

Not talking about published SNAPSHOT versions or anything. Just having source in a public would open possibility for comments from users.

From my perspective things I would like to see:

• Possibility to provide common ConnectionPool which is reused between application and SDKs. Or at least optimize SDK for opening less connections when a lot of Environments are used.
• Compatibility for reactive usage of feature toggles. We subscribe to changes of toggle (ldClient.registerFeatureFlagListener) in all cases. Coroutines API with Flow<...> would be useful, as that is official recommended way of building apps by Android team.
• Usage of androidx.startup SDK to automatically initialize LD SDK without blocking application.

[louis-launchdarkly]

Hello @audkar, thank you for the request and for listing out some of the features you would like to see in Android.

Let me answer this in two parts: While I can understand the concern and LaunchDarkly will release changes when the changes are ready, there are a lot of changes for this version and the corresponding backend so the time for an engineer to get this one in public is longer than typical.

For the three enhancement request, I have put those into the backlog. The team will look into those. Filed Internally as 178434.

[eli-darkly]

To expand a little on Louis's comment:

The primary purpose of the upcoming 4.0.0 release is to support new features that are going to be launched soon across the entire LaunchDarkly product.

Secondarily, we're also making internal improvements to clean up the implementation and address particular known issues; and we're changing the API of LDConfig to more closely resemble our server-side Java SDK and support some new features.

Practically speaking, there's no way we would have had time for any other new feature work in this release. But the other ideas you mentioned are all feature requests that would presumably be backward-compatible and opt-in— so there's no reason they would need to be done in a new major version release, anyway. If they're feasible, they would be done in a later 4.x release.

We do our best to add functionality incrementally. When we do a major version release, it's not with the intention of immediately implementing every desirable feature; a major version just means that there are potentially backward-incompatible changes, due to either a significant change in how the overall LaunchDarkly product works, or a need to drop compatibility with old platform versions.

[eli-darkly]

We still intend to do most of our development in a private repository prior to release, as we've always done. It's not really practical to have literally all of our interim work, in dozens of repositories, receive public commentary as we go along. But feature requests like the ones you've just made don't require access to the interim work anyway; you were able to make them perfectly well by filing an issue.