use service provider proto string impls #704
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This makes use of centralised from_str and to_string impls added to the proto lib here helium/proto#386 and removes the temp added local functions.
There is the option of updating mobile_config server to return the Service Provider enum value but I am not convinced that is a good approach as it enforces a specific enum to what could be argued is a generic API (key_to_rewardable_entity) which translates a given key to a rewardable entity. Baking in the assumption that a rewardable entity will always be a service provider enum would be a mistake.
The other option is to drop the generic API (naming & usage ) and make it specific to returning a service provider entity key. I ended up taking this approach but limited it to the mobile config client. The server still returns the entity key as defined in the DB ( ie a string ), the client API then attempts to convert that to the relevant enum before passing the enum value to the caller. This approach allows the client to have APIs which return either the enum value or the raw string. I could well be overthinking this