Configure parsing of collections

[cesar1000]

Twitter uses LoganSquare heavily to generate model objects from Json. In particular, we use type converters to avoid the need for copying lists when converting them to model objects. For example:

@JsonObject
public class JsonTweet extends ModelObjectProvider<Tweet> {
    // ...
}

@JsonObject
public class JsonTweetList extends ModelObjectProvider<TweetList> {
    @JsonField
    public List<Tweet> tweetList;

    @Override
    @NotNull
    public TweetList toModelObject() {
        return new TweetList(tweetList);
    }
}

This works as expected by declaring a type converter for Tweet that uses JsonTweet. The one thing we don't have control over is the creation of the list: I would like to be able to configure LoganSquare to use my own implementation of List; in particular, I would like to be able to guarantee that all parsed lists are immutable.

More in general, I would like to have the means to declare how to parse arbitrary collections, like SparseArray or map that don't use string keys. I think this would be a valuable addition to LoganSquare. Have you considered adding this feature? What are you ideas on how this would work?

[EricKuck]

This should be supported once work on generics is done, as you'll be able to treat Lists just like any other generic type. Cool to hear Twitter's using it!

[cesar1000]

Ah, that's great news! So, just to confirm, you're working on both the
support for generic Json objects and parsing of generic types? I'm looking
forward to checking that out! Also, I'll be happy to help test the new
release, since we're using LoganSquare extensively.

Thanks!
César
On Nov 1, 2015 6:24 PM, "Eric Kuck" [email protected] wrote:

This should be supported once work on generics is done, as you'll be able
to treat Lists just like any other generic type. Cool to hear Twitter's
using it!

—
Reply to this email directly or view it on GitHub
#97 (comment)
.

[EricKuck]

Sorry, I spoke too soon. I had forgotten that Lists were treated a "special" type that didn't worry about type converters in order to keep the generated code as fast as possible.

I'm trying to work through the best way to add support for this. It will be trivial to handle the case were the developer calls registerTypeConverter for all List types, but I'm not sure what to do in the case that they use to typeConverter annotation parameter. Since Lists were treated as special to start out, changing the way that parameters works would break existing code bases. So far the best I can think of is adding another parameter, collectionTypeConverter, but I really don't like that.

In the meantime, you should be able to use your custom List implementation with a TypeConverter by changing your declaration from

public List<Tweet> tweetList;

to

public CustomList<Tweet> tweetList;

I know it's not the cleanest, but it'll work if you need a quick and dirty workaround until an official solution is ready.

[cesar1000]

Ah, I was wondering about your plans for dealing with that. I thought about
moving list, set and map creation into a builder interface that can be
overriden - it does have a small performance impact though, so I'm not sure
whether that's acceptable. For the time being, I can try the alternative
that you propose.

César

On Mon, Nov 9, 2015 at 4:33 PM, Eric Kuck [email protected] wrote:

Sorry, I spoke too soon. I had forgotten that Lists were treated a
"special" type that didn't worry about type converters in order to keep the
generated code as fast as possible.

I'm trying to work through the best way to add support for this. It will
be trivial to handle the case were the developer calls
registerTypeConverter for all List types, but I'm not sure what to do in
the case that they use to typeConverter annotation parameter. Since Lists
were treated as special to start out, changing the way that parameters
works would break existing code bases. So far the best I can think of is
adding another parameter, collectionTypeConverter, but I really don't
like that.

In the meantime, you should be able to use your custom List
implementation with a TypeConverter by changing your declaration from

public List tweetList;

to

public CustomList tweetList;

I know it's not the cleanest, but it'll work if you need a quick and dirty
workaround until an official solution is ready.

—
Reply to this email directly or view it on GitHub
#97 (comment)
.