Ignore static (and maybe final) variables about parceler HOT 19 CLOSED

Hmm, could you just make that @Transient? Finals should possibly error in field serialization during code generation. Or maybe finals are ignored and a warning is given.

from parceler.

Ah, just noticed @Transient, but static final vars should probably just be assumed transient no?

from parceler.

I'm thinking all finals should be ignored, not only static final.

from parceler.

probably for simplicity. Gson deserializes final fields through reflection, but I really don't think supporting that use case is necessary.

from parceler.

I guess we could serialize finals using reflection (we use reflection for private fields serialization). I wonder if this is necessary though, since we require a zero-arg constructor and finals need to be set in constructor blocks.

from parceler.

I would skip all finals for now and maybe add support in a later version if needed

from parceler.

Implemented the final fields set by reflection case (and a couple of other edge cases), let me know how it works for you @vinc3m1: 48fb1e1

from parceler.

I get these warnings during compilation, but i'm not seeing any crashes (yet).

warning: Parceler: Reflection is required to modify private fields, consider using non-private.
    public static final String STATUS_OFFLINE = "offline";

are static final fields actually ignored? or will parceler actually try to change them? More informative warning messages would be nice.

from parceler.

Parceler will try to read from and write to them. Reading from them isn't the issue, it's the writing that causes Parceler to require reflection. It seems like there are cases that writing finals doesn't work, even with reflection because of compiler inlining.

from parceler.

I think specifically static finals should always be ignored, they're usually compiled to constant values.

from parceler.

Im trying to think about this from a serialization perspective, much like Gson or regular Java serialization. In those cases I believe static finals are serialized, mainly because they could be reloaded by a separate VM. In Parceler's case, I don't believe Parcelables are serialized between Virtual Machines. Maybe this means all statics should be ignored.

Also, the transient keyword is respected in serialization cases, maybe we should support that as an analogous option to @Transient.

I believe regular finals should be serialized / deserialized properly, even if they do require reflection. This is inline with the serialization perspective.

Maybe I'm talking myself into this solution...

So here's my thoughts to go forward with:

• ignore all static fields because Parcelables are only serialized within the same VM (need to verify this)
• add transient keyword analogy to @Transient

from parceler.

I'm positive that Parcelables are mean't to be serialized within the same device, but not necessary the same process. I can't find the source but I remember a core android dev saying something along those lines. It was designed more for passing messages around and persisting state locally, not for long term storage like serializable or json. Thus why there isn't a serialVersionUID equivalent. And why Parcelables should never be saved to disk because implementation may change with dfiferent versions of Android.

It is however possible to pass Parcelables around between different apps via intents and bundles. I guess in that case, there is a possibility that you would want to marshall a constant, so maybe the @Transient annotation is sufficient

from parceler.

Right, good points. In that case maybe we shouldn't ignore statics, unless they are @Transient or transient of course. I'm going to set up a quick test app to verify, but I would imagine you are correct, that statics will not be identical between processes (or classloaders?).

I'm still interested in adding the transient keyword for completeness.. and possibly update the warning to cover final variables as well.

from parceler.

Ok, transients are now respected and I altered the warning to handle finals/privates accordingly f15512e. you could define your static final variable as follows:

public transient static final String STATUS_OFFLINE = "offline";

don't forget to run with ./gradlew build --refresh=dependencies

from parceler.

@vinc3m1 would love to release this afternoon, let me know if this works for you and I'll do it.

from parceler.

Yeah assuming this doesn't break anything. I think I'll stick to using @Transient so this doesn't affect me much.

from parceler.

Cool, sounds good. I'll release then.
On Feb 26, 2014 1:58 PM, "Vince Mi" [email protected] wrote:

Yeah assuming this doesn't break anything. I think I'll stick to using
@transient so this doesn't affect me much.

Reply to this email directly or view it on GitHubhttps://github.com//issues/21#issuecomment-36175635
.

from parceler.

Just released under 0.2.7.

from parceler.

👍

from parceler.