Jackson Mixin style annotations about parceler HOT 12 CLOSED

It's nice to see a pure-Java configuration that is not based on Strings. That being said, this sort of configuration is brittle when refactoring as the compiler will not complain if the names of the properties change (although, we could make it complain I suppose).

Have you looked at the ParcelConverter option that allows you to define serialization manually? Will this not work for you?

from parceler.

Yes it is brittle and I have been bitten by that before for many times. But in some cases I would need to persist model objects that looked like this(from an external library that I can do nothing about):

    public static class Image {
        public enum Display {
            COVER, CONTAIN, START, END
        }
        public enum Type {
            BASE64, FILE, URL
        }
        public final Type type;
        public final Display display;
        public final int padding;
        public final String content;

        public Image(Type type, Display display, int padding, String content) {
            this.type = type;
            this.display = display;
            this.padding = padding;
            this.content = content;
        }
    }

If I could annotate this class directly, life would be too easy.
Now, I came up with:

1. Black magic
2. ParcelConverter as suggested
3. Wrapper class
4. Let parceler throw warning about final fields and ignore them

I'm haven't tested 1 and am not motivated to
2 is interesting
3 is what I'm currently using and I'm not very happy about it
I don't like 4 because a warning is a warning unless I can suppress it with an annotation

The mixin approach that I was suggesting would look something like this:

    @ParcelMixIn(Image.class)
    public abstract static class ImageMixIn {

        @ParcelConstructor
        public ImageMixIn(@ParcelParam("first")("type") Image.Type type,
                @ParcelParam("display") Display display, @ParcelParam("padding") int padding,
                @ParcelParam("content") String content) {
        }
    }

I'll experiment with ParcelConverter to see if it will suit my needs.

from parceler.

I don't advise this approach, but I was able to make your class work by extending it:

@Parcel
public class ParcelImage extends Image {
    @ParcelConstructor
    public ParcelImage(Type type, Display display, int padding, String content) {
        super(type, display, padding, content);
    }
}

Was this your approach with the Wrapper class?

Approach 1 you mention probably won't work, because the Parceler annotation need to exist at compile time.

So, the question is now: should we introduce a more-manual way of configuring Parceler's code generation? I see this fitting between the ParcelConverter option and the @Parcel/@ParcelClass options. The approach I would go with here is to introduce a set of annotations to model the classes serializable elements. These annotations would be fed directly into and mirror the ParcelableDescriptor class and related sub-elements. Keep in mind that Parceler walks up the class extension hierarchy and includes these elements in the generated Parcelable. In addition, Parceler pairs up input/output (write/read) pairs to ensure serialization and deserialization methods are mirrored. So, this approach would be pedantic, somewhat confusing (associating write/read pairs of different types) and, similar to the Jackson technique, brittle to changes.

As an example, this annotation approach would look like the following:

@ParcelConfiguration(
    type = Target.class
    constructorParams = {@ConstructorParam(type = Target2.class, on=Target.class, name="inputParam", field="outputField"),...}
    fieldParams = {@FieldParam(type = Target3.class, on=Target.class, name="someField", readMethod="getSomeField"),...}
    methodParams = {@MethodParam(type = Target4.class, on=TargetSuper.class, name="setTarget4", readMethod="getTarget4"),...}
)

I'm leaning towards leaving it as is with the ParcelConverter as the fall-back solution. I think this covers most, if not all, of the cases that wouldn't fit regular annotation processing analysis via @Parcel.

from parceler.

The wrapper class above is almost identical to mine. What I don't like is that I have to subclass a POJO, which can be problematic because the library can change the structure anytime and I would have to look out for that. This problem also affects the suggested mixin/@ParcelConfiguration approach too. I think the cleanest way of solving this would be something like:

@ParcelClass(class=Target.class, suppress=true)

And that would silence warnings about Target class only.

And anything that still doesn't work can use the ParcelConverter

from parceler.

I agree with your problems around the wrapper class. Personally, I'd rather use a ParcelConverter than the wrapper approach.

There was another request to suppress warnings (#45) but we did not move forward with it. You can suppress warnings by adding the -Xlint:-processing option. Keep in mind, the warnings are very helpful as they highlight that reflection is required, negating the benefits of using Parceler. When I see these warnings I know I've done something wrong.

from parceler.

I wonder if there is an approach that following configuration by exception instead of the mentioned verbose annotation approach.

Here's what I mean. We'll use your class as an example:

 public static class Image {
        public enum Display {
            COVER, CONTAIN, START, END
        }
        public enum Type {
            BASE64, FILE, URL
        }
        public final Type type;
        public final Display display;
        public final int padding;
        public final String content;
        public String extraContent;

        public Image(Type type, Display display, int padding, String content) {
            this.type = type;
            this.display = display;
            this.padding = padding;
            this.content = content;
        }
    }

Say you want the constructor to be used and the extraContent field to be ignored (@Transient). you could define it as follows:

@ParcelClass(value = Image.class,
    configuration = @ParcelConfiguration(
        constructor = @ConstructorConfiguration(Type.class, Display.class, int.class, String.class)
        transients = {@TransientConfiguration(type = Image.class, method = FIELD, name = "extraContent")}
));

These would effectively act as annotations directly on the fields/constructors/methods.
Thoughts?

from parceler.

This is even better than the MinIn approach! I think this solves not only the POJO problem but many other problems related to immutability as well. I think we can add this to the next snapshot and I'll give it a go.

from parceler.

is this change included in the 0.2.16-SNAPSHOT? can't wait to try it out :)

from parceler.

@tom91136, I haven't deployed it yet, but the beginnings of this is available on the referenced PR if you want to play with an early preview.

from parceler.

Sorry I was having exams in uni, I'm back now. I was testing out 0.2.16-SNAPSHOT and found that it's a bit different from the PR, is there an example on how I would use @Parcel annotation()?

from parceler.

@tom91136 This is definitely a WIP. You can find this progress under #62 if you want to play with it. I'd greatly appreciate your feedback.

from parceler.

I've been thinking about this feature for a couple months now, and I've come to the conclusion that it's largely unnecessary because of the existing ParcelConverter interface. The problem with adding a way of configuring a class externally is matching the read and write parameters between the constructor, factory method, fields and methods. This creates a huge mess and only duplicates what the ParcelConverter already does.

As always, I'm open to discussion, but I'm closing this issue and related PR for now.

from parceler.