chore: Refactor FlagsProvider and FlagsClient into one#2899
Conversation
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## feature/feature-flagging #2899 +/- ##
============================================================
- Coverage 70.75% 70.59% -0.16%
============================================================
Files 826 826
Lines 30078 30087 +9
Branches 5009 5124 +115
============================================================
- Hits 21279 21238 -41
- Misses 7408 7410 +2
- Partials 1391 1439 +48
🚀 New features to boost your workflow:
|
| * in production code. It delegates to [clear] to remove all client registrations. | ||
| */ | ||
| @Suppress("unused") | ||
| private fun reset() { |
There was a problem hiding this comment.
is it used anywhere? seems like redundant method if it delegates to another one anyway.
There was a problem hiding this comment.
good catch; no longer needed
Co-authored-by: Nikita Ogorodnikov <[email protected]>
typotter
left a comment
There was a problem hiding this comment.
thanks for the review. PTAL
| * in production code. It delegates to [clear] to remove all client registrations. | ||
| */ | ||
| @Suppress("unused") | ||
| private fun reset() { |
There was a problem hiding this comment.
good catch; no longer needed
…client-client-client-manager-or-eliminate
|
/merge |
|
View all feedbacks in Devflow UI.
The expected merge time in
[email protected] cancelled this merge request build |
|
View all feedbacks in Devflow UI.
This merge request is not mergeable yet, because of pending checks/missing approvals. It will be added to the queue as soon as checks pass and/or get approvals.
[email protected] unqueued this merge request |
…name-provider-client-client-client-manager-or-eliminate
|
/remove |
|
View all feedbacks in Devflow UI.
|
jonathanmos
left a comment
There was a problem hiding this comment.
LGTM on the whole - I left some minor comments
| { "Missing required configuration parameters: $missingParams" } | ||
| ) | ||
|
|
||
| return null |
There was a problem hiding this comment.
Do we prefer null here or a NoOpFlagsClient? Also, after this we could probably remove the TODO on line 82
There was a problem hiding this comment.
null here is fine; we are dropping this create-on-enable routine anyway and will guarantee a non-null Client from the create/get methods
| * Must contain a valid targeting key; invalid contexts are logged and ignored. | ||
| */ | ||
| override fun setContext(context: EvaluationContext) { | ||
| // Validate targeting key is not blank |
| * in production code. It delegates to [clear] to remove all client registrations. | ||
| */ | ||
| @Suppress("unused") | ||
| private fun reset() { |
| */ | ||
| override fun resolveBooleanValue(flagKey: String, defaultValue: Boolean): Boolean { | ||
| val precomputedFlag = flagsRepository.getPrecomputedFlag(flagKey) | ||
| return precomputedFlag?.variationValue?.toBooleanStrictOrNull() ?: defaultValue |
There was a problem hiding this comment.
do we want to use toBooleanStrictOrNull here or just toBooleanOrNull. The doc for the former is here https://kotlinlang.org/api/core/kotlin-stdlib/kotlin.text/to-boolean-strict-or-null.html.
There was a problem hiding this comment.
hm. I think toBooleanOrNull makes more sense here, thanks.
Jonathan makes this change in #2895
Co-authored-by: Nikita Ogorodnikov <[email protected]> Co-authored-by: Jonathan Moskovich <[email protected]>
|
/merge |
|
View all feedbacks in Devflow UI.
The expected merge time in
|
Flags Feature - FlagsClient
Feature Flagging mobile SDK spike
stacked on #2896
FFL-1116
What does this PR do?
Refactors the WIP
dd-sdk-android-flagspackage to consolidateFlagsProviderfunctionality intoFlagsClientusing an interface + companion object pattern. This provides cleaner static access (FlagsClient.instance()) while maintaining instance-based flag operations, aligning with mobile-api-spec.md requirements.Motivation
The existing dual-class pattern (
FlagsClientobject +FlagsProviderinterface) was confusing and didn't align with mobile-api-spec.md. The spec requires static access for client instances but instance methods for flag operations. This refactoring simplifies the API to a singleFlagsClientclass that provides both patterns cleanly and adheres to the agreed upon spec for mobile flags SDKsAdditional Notes
Out of scope
API Target
Key Changes Made
FlagsProviderseparate classFlagsClientFlagsClient.instance()entry pointReview checklist (to be filled by reviewers)