Reduce boilerplate for subclasses

[d370urn3ur]

I work with Parse in both Android and iOS and I'm wondering if it would be possible to reduce all the boilerplate when subclassing a ParseObject, something similar to Gson serialization? iOS already does this, I just have to subclass PFObject and implement a subclassing protocol and all my defined properties are automagically populated, no need to write things like

public String getDisplayName() {
  return getString("displayName");
}
public void setDisplayName(String value) {
  put("displayName", value);
}

So that's basically 4 lines for each property and I wrote "displayName" 4 times. Plus by hand because I'm not even defining properties where I could take advantage of code generation. It seems insane, if I have a ParseObject with 20 properties I'm writing 80 lines of code that quadruplicates each property name. Thanks for considering it!

[grantland]

This sounds like it would be a great enhancement!

I'm not sure something like Gson serialization would work, since that requires creating an object with properties that the deserializer will set and ParseObject works with underlying server data with pending operations.

We don't have any current plans for this, but if you or anyone else has any ideas or solutions for this enhancement, we'd be glad to hear them.

[d370urn3ur]

If anyone is still interested in this I have created an annotation processor to generate ParseObject subclasses from schema objects. The project is here: https://github.com/d370urn3ur/AnnotatedParseObject

[addisonElliott]

I know this is an extremely old issue, but it caught my attention.

Although it would be nice to have an annotation that automatically generates getters/setters for you in an ParseObject subclass, I think this is unnecessary. For one, Android Studio provides a shortcut to create getters/setters for you. If you right-click the variable, go to Generate->Getter or Setter or Getter/Setter.

Then, you can create all of the getters/setters at once. If this is a lot of boilerplate code for you, then it is probably worthwhile to throw in a region so that this code can be collapsed.

My vote is to close this issue...

[natario1]

Me I would like this... It would be cool if we had something like

@ParseKey(String.class) static final String KEY_TITLE = "title";
@ParseKey(ParseGeoPoint.class) static final String KEY_POINT = "point";
@ParseKey(Author.class) static final String KEY_AUTHOR = "author";

in the object class. Though I admit I know nothing about annotation processors and I don't know if it's possible. I would leave this up-for-grabs...

[d370urn3ur]

@addisonElliott Yes you can generate the setters/getters but then you have to manually edit them all to conform to the ParseObject's expected behavior ( get_Type_("key") / put("key", value) ) which is my original complaint.

@natario1 If you look at my second comment I have already created a working annotator, but it is out of date and since my team has moved on from Parse I do not plan on maintaining it. Feel free to fork it and update it if you want.

[flovilmart]

@natario1 probably something to add to the std lib :)