Fixed
Status Update
No update yet.
Comments
pe...@gmail.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.
gg...@google.com
gg...@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 ;)
al...@gmail.com
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.
gg...@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
Version used: 1.0.0-alpha01
Devices/Android versions reproduced on: Nexus 5X
How to reproduce:
Create and enqueue a data worker with a float or a double value:
Data.Builder builder = new Data.Builder();
builder.putFloat("test", 1.0f);
.... // create a request
WorkManager workManager = WorkManager.getInstance();
workManager.enqueue(request)
Read the value in the doWork() call:
public Worker.WorkerResult doWork()
{
this.getInputData().getFloat("test", 0f);
}
java.lang.IllegalArgumentException: Key intensity has invalid type class java.lang.Float
at androidx.work.Data$Builder.putAll(Data.java:632)
at androidx.work.OverwritingInputMerger.merge(OverwritingInputMerger.java:43)
at androidx.work.impl.WorkerWrapper.run(WorkerWrapper.java:120)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1133)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:607)
at java.lang.Thread.run(Thread.java:761)
The problem seems to be that the androidx.work.Data$Builder.putAll method though is handling all data types including float/double arrays, is actually missing float and double primitive types.