Added getIdentityFlags method #51
Conversation
…ttings traits at the same time
Implemented getIdentity flags for getting flags by an identity and se…
| @@ -175,6 +175,12 @@ class Flagsmith constructor( | |||
| retrofit.getIdentityFlagsAndTraits(identity).enqueueWithResult(defaults = null, result = result) | |||
| .also { lastUsedIdentity = identity } | |||
|
|
|||
| fun getIdentityFlags(identity: String, traits: List<Trait>, result: (Result<ArrayList<Flag>>) -> Unit) { | |||
There was a problem hiding this comment.
I think better rename getIdentityFlags to setAndGetIdentityFlags
There was a problem hiding this comment.
For me, the function name getIdentityFlags is a bit confusing, because it doesn't match what this method does.
Get flags for an identity and set traits in the same call
Even in the code of this method, we can see the call ofpostTraits
An option that you propose in iOS PR (Add an optional traits argument to the existing getFeatureFlags method ) looks good to me. However, I think we don't need to raise an exception if the identity is null because there already is a condition if (identity != null), maybe we can use it and postTraits only if the identity is not null.
There was a problem hiding this comment.
However, I think we don't need to raise an exception if the identity is null because there already is a condition if (identity != null), maybe we can use it and postTraits only if the identity is not null.
In my opinion it makes sense to raise an exception here because it is an invalid set of arguments. I'm not sure what the benefit is of not raising an exception in this case? I think that, without raising the exception, we may end up with confusing behaviour (since the traits argument would be ignored in situations where the identity is not provided).
| if (traits != null) { | ||
| retrofit.postTraits(IdentityAndTraits(identity, traits)).enqueueWithResult(result = { | ||
| result(it.map { response -> response.flags }) | ||
| }).also { lastUsedIdentity = identity } | ||
| } else { | ||
| retrofit.getIdentityFlagsAndTraits(identity).enqueueWithResult { res -> | ||
| flagUpdateFlow.tryEmit(res.getOrNull()?.flags ?: emptyList()) | ||
| result(res.map { it.flags }) | ||
| } |
There was a problem hiding this comment.
Similar to my comment here, I think we can remove this conditional logic and always use the POST endpoint, but if it's non-trivial to achieve, we can ignore for the purpose of this PR.
No description provided.