@SerializedName annotation for defining Class/Field names

We need something similar to GSON’s SerializedName annotation which can map a different name field from JSON string to RealmObject’s property.

eg:

{ "dog_name": "abc"}

class Dog {
    @SerializedName("dog_name")
    private String name;
}

[cmelchior]

I have the same feeling, but it gets a bit tricky, because cross-platform schemas are a big topic for us right now 😄

public class Foo extends RealmObject {

  // This is definitely eecky
  @SerializedName("my_stupid_json_name")
  @FieldName("internal_name")
  private String name;
} 

Thinking about this. Maybe this is actually the best time to actually split our JSON API away from Realm, because a @SerializedName for JSON would only make sense if you used our JSON API, if you use e.g GSON it would just be confusing that Realm also had a similar annotation.

Instead we should create adapters for the various JSON imports:

- `io.realm:android-json-adapter:1.0.0` : Basically our existing API just moved to a seperate dependency. This library could then include specialized annotations like `@SerializedName`

- `io.realm:gson-adapter:1.0.0` : GSON type adapters

- `io.realm:android-streaming-json-adapter:1.0.0` : Our API 11 streaming adapters

Alternatively they get configured through the new realm closure block introduced in 2.0

It would have the following implications:

• All createFromJson* and createOrUpdateFromJson* methods would be removed from our current public API.
• JSON Support is entirely opt-in. Right now they are a massive chunck of our proxy classes, we could strip a lot of code.
• We will have to find another way of calling JSON methods. GSON/Moshi/Jackson can continue to use our copyToRealm, but we need somewhere to hook “standard” JSON output in. Where isn’t clear to me.

[beeender]

Split the json to another project would be great, especially we will have a chance to switch to javapoet from there. But the new project probably needs to be more generic to support other data converters than JSON, eg. flatbuffer.