Fixed
Status Update
No update yet.
Comments
yb...@google.com
we've considered this, just didn't have time to implement.
Btw, we cannot just use name() because it might be proguarded away. so we need to generate the code that matches enums to hardcoded string values.
If you are using name(), be careful about migrations since 2 different compilations might have different names for the enum values.
Btw, we cannot just use name() because it might be proguarded away. so we need to generate the code that matches enums to hardcoded string values.
If you are using name(), be careful about migrations since 2 different compilations might have different names for the enum values.
yb...@google.com
fl...@google.com
fl...@google.com
yb...@google.com
True. Even though this could be fixed by using proguard rules.
Would be great to see this in the future, it's really lots of code here ;)
Would be great to see this in the future, it's really lots of code here ;)
[Deleted User] <[Deleted User]>
What about the idea of using a more generic adapter which can handle all of the enums in your app? That way you could decide to persist them all with one "stone". You could choose to save them as strings, ordinals or even some other way of your choosing. But you would not have to add an adapter for every enum type in your app. You just have to add the one special enum adapter and Room would know how to use it for all enums.
ap...@google.com
This seems like a possible candidate for external contributions so moving it to the bug bounty hotlist.
We still need a proper design here hence not super straightforward.
Such design should ensure we are:
- safe for proguard (in case we go w/ name)
- have some logic for defaults (in case an enum is removed or renamed)
- possibly support ordinals (though that might be a case where we can require a type converter)
- possibly make it opt-in so that developer explicitly picks an option (e.g. some annotation on the enum to enable this)
Description
it is not intended for public use.