JSON API v2

[cmelchior]

Design and implement a more complete solution for our JSON API.
Current design doc is here:
https://github.com/cmelchior/realm-java/blob/29ab93bf7aeaa5cd048cbf468a228046496ecb13/json_api.md

Other features:
Strict mode: We should probably consider adding something like STRICT mode to our JSON parser which could throw an exception when encountering JSON properties it didn't recognise. At least for debugging it could save a lot of time.

Json export It should also be possible to convert any RealmObjects to JSON.

[Hazer]

How would the API handle this?

{
  "name": "Stuff",
  "badges" : ["fine", "green", "tasty"]
}

I can't change the Json input, so I was thinking that an Annotation-based Transformation, could play nice in this situation, there are plans on it?

[highwater]

@Hazer you mean like serialized name? It's in the proposed documentation above

Mapping between JSON names and Java names should just follow our default naming policy, unless overriden by a @SerializedName annotation.This allow for fine grained control of different naming schemes.
@SerializedName is also used by GSON.

I'm also waiting for this feature, is there any ETA, @cmelchior? Thanks.

[Hazer]

@highwater don't think so, I didn't made it clear.

I was thinking in that "badges" list, that would translate to List in Java. Realm can't save it. Serialized Name can help with it and I can't see ?

But in any case, I am waiting for SerializedName also.

[cmelchior]

@highwater Sorry no. Next on our list is being able to use custom constructors for RealmObjects which would make it possible to eg. use tools like GSON.

@Hazer Currently Realm doesn't support lists of primitive types. There is a an issue for it here: #575 . Once that is implemented it should be trivial to add JSON support for it.

[Hazer]

@cmelchior Thanks for pointing out issue #575 .

The JSON API Parser will be dropped in favor of the possibility of using external tools? Or its just higher priority to support external ones?

[cmelchior]

@Hazer
We still plan to provide native JSON support, but standalone objects are also a highly requested feature that also blocks our progress in other areas, so it has been given higher priority.

[erichkleung]

@cmelchior Do you have a timeline for the custom constructors for RealmObjects (to use GSON)? Thanks!

[cmelchior]

It is next on my list, right after we finish up merging outstanding PR's. So baring anything unexpected I will begin working on it today or tomorrow.

[TepesLucian]

Hi! Are you guys planning to add a createOrReplaceFromJson? Right now we get a lot of duplicate objects just with the createFromJson and the populate method in RealmObjects is package protected.

[cmelchior]

Yes, we definitely want to add that, but it require that we have primary keys working first #565, and they depend on standalone objects #728. Currently the plan is that the next release (0.77) will contain standalone objects, and I am pretty confident that we can have primary keys ready for 0.78.

[TepesLucian]

Awesome 👍

[hareshsandeep]

@cmelchior Is there any progress on storing dates with different formats in android? for instance, I am trying to store date format EEE, dd MMM yyyy hh:mm:ss Z and its crashing.

[bmunkholm]

@hareshsandeep Could we please ask you to create a new issue with more details so we can better help? Thanks!

[RustamG]

Is there any update on this? Is it hard to implement #1470 as one of the first steps?

[cmelchior]

Hi @RustamG
Sorry no, still update on this. For @SerializedName most of the existing JSON libraries can do this for you. However it is a feature we are looking into outside the contet of JSON as well, see e.g here: #451

[taltstidl]

Ok, I'd be willing to work on this, but wanted to first discuss naming and similiar design choices. The following is on my checklist:

• Improve import API with annotations
• Add export API

I'd also want to add similiar functionality to the realm-cocoa library, if you're open to that. My knowledge in Objective-C/Swift isn't as profound as in Java though, so I would probably need a few pointers here and there.

So, in short, here's what I would propose for the API (all up for discussion though):

• Add an annotation @SerializedName: the annotation would take the name of the attribute in its serialized representation, as well as an optional type (VALUE, LINK, or LINKLIST, defaults to VALUE). Here's an example model class using those annotations:

  public class Person extends RealmObject {
      @PrimaryKey @SerializedName("personID") long id;
      String name;
      @SerializedName("dogID", Type.LINK) Dog dog;
      @SerializedName("dogIDs", Type.LINKLIST) RealmList<Dog> dogs;
  }

  Which would properly import the following JSON:

  [
      {
          "personID": 1,
          "name": "Thomas",
          "dogID": 1,
          "dogIDs": [1, 2, 3]
      }
  ]

• Add export*ToJson methods: I'm still not sure whether it should be done more like the copyFromRealm methods (static methods inside Realm.java) or more like the delete methods (class methods of the respective RealmObject subclass). I could live with both and the decision is up to you, I guess:

  RealmResults<Person> persons = realm.where(Person.class).findAll();
  
  // Option 1: Realm methods
  JSONArray all = realm.exportAllToJson(persons);
  JSONObject single = realm.exportToJson(persons.get(0));
  
  // Option 2: RealmObject/Results methods
  JSONArray all = persons.exportAllToJson();
  JSONObject single = persons.get(0).exportToJson();

• Rename the create*FromJson methods to import*FromJson. This is to facilitate the export*ToJson methods created, and to allow more similiar APIs in realm-cocoa (e.g. realm.import(Person.self, fromJson: result)). The existing methods would be deprecated and routed through the new ones. If you guys disagree with this naming though or don't want to rename them, I understand and have no problem keeping them.

[Zhuinden]

Regarding @SerializedName: #3622

[cmelchior]

Hi @TR4Android Thank you very much for offering your help. We talked about this a bit internally and at his point in time we are not really comfortable going the route of export/import API's.

We can definitely see the point of them, but we really would like to avoid being a complete JSON library on top of being and database, especially since libraries like GSON, Moshi and Jackson already does a pretty good job.

So while we haven't agreed fully on the future yet, there is a fairly big chance we instead would want to autogenerate type adapters for the common GSON libraries and use an adapter approach like what is known from e.g. Retrofit. In that process our existing JSON API will most likely be fully deprecated.

@SerializedName is a bit of a special case since this also have implications outside JSON, e.g. if you want to sync objects across languages and want the ability to customize the name on each platform. So if you are still up for working on that we would very much appreciate your help.

I would however like to move that discussion to #1470 instead as that issue is more specific for this specific functionality. I will write up my thoughts on what is needed in #1470

[cmelchior]

Folding this into #3758