Is it possible to have newly synced values for a flag only update once the app is initialized?

[silverAndroid]

Is your feature request related to a problem? Please describe.
I'm worried that if I guard some new business logic behind a flag, since a flag value can change at any moment, it might cause unforeseen (and potentially hard to recover from) bugs that might be hard to catch in a testing environment.

Describe the solution you'd like
An option in the configuration to specify that even though the SDK can continue polling for updates to flag values, it will still keep the flag value "stale" until the next time the app launches.

[tanderson-ld]

Hello and thank you for your feedback! We will discuss this feature request at our next technical discussion.

Could you provide more detail on how such flags are interacting with your program and/or each other? We can speculate, but having specific details will help us! Thanks.

[tanderson-ld]

We discussed this and will be putting something into our future feature backlog. Unfortunately, this doesn't mean we will definitely get to it because we always are prioritizing new work.

We also discussed ways you might be able to mitigate the risk. The best solution we came up with was to find cohesive groups of flags related to functionality and make helper functions that will request the flags in the cohesive group and hold the results in a container class. Then use that container class in the region of code it makes sense for. For example, if you have flags that affect the homescreen, create a HomeScreenFlagContainer class and a helper function like HomeScreenFlagContainer getHomeScreenFlags(). This function will call to the LDClient to get evaluations for the various flags that are used by the home screen. Then pass that container into the home screen related code.

Some gotchas to watch out for.

• LaunchDarkly analytics and experiments are driven by calling the SDK's evaluation methods. Not evaluating flags when your code needs a flag may lead to unexpected analytics and experiment behavior.
• Try to keep the size of these cohesive groups small and keep the scope of the group narrow. The whole idea behind feature flagging is to have reactive software that can be flexible!
• References to any flag container classes may be affected by lifecycle events.

[silverAndroid]

Sorry for the delay in my response, I completely missed the notifications.

Could you provide more detail on how such flags are interacting with your program and/or each other? We can speculate, but having specific details will help us! Thanks.

I'm coming from Firebase Remote Config and one of the loading strategies they suggested is essentially what (I hope) I conveyed above. Similarly, one of the loading anti-strategies is basically (if I understanding the docs correctly) what I'm worried may happen with the current real-time behaviour of LaunchDarkly.

[tanderson-ld]

We believe our previous recommendation addresses the anti-strategies you linked to. Could you provide a more concrete example of a flag update causing an issue in your specific app?

[Lexie2520]

details will help us! Thanks.

I'm coming from Firebase Remote Config and one of the loading strategies they suggested is essentially what (I hope) I conveyed above. Similarly, one of the loading anti-strategies is basically (if I understanding the docs correctly) what I'm worried may happen with the current real-time behaviour of LaunchDarkly.