Allow custom data (or tag, or JSON) attached to symbols and other annotations

[zestyping]

In general, it's useful for clients of an API to be able to associate their own custom data with instances of object types owned by the API. In this case, it's useful for clients of the Mapbox SDK to be able to associate their own custom data with annotation objects.

For example, if each symbol corresponds to an object that has an ID in the client app, it could be useful to attach that ID to the symbol so the client app can find the object associated with a given symbol. Or, suppose each symbol identifies a point that has a latitude, longitude, and altitude; it could be useful to add a custom numeric field to the symbol for the altitude.

The Google Maps SDK supports this by letting you attach an arbitrary Java object to a Marker with the Object getTag() and setTag(Object) methods.

For the Mapbox SDK, I could imagine a couple of possible solutions:

1. Add Object getTag() and setTag(Object) methods to Annotation, just like Google Maps.

2. Add a JsonObject getData() method that returns a JSON container (initially empty). The caller can then freely manipulate the JSON container, reading and writing whatever fields it wants.

Solution 1 is more flexible and easy to use because you can attach anything.

Solution 2 seems like it might be closer to following the conventions of the Mapbox SDK, which seems to store everything internally as JSON. I don't really understand the reason for this convention, though; maybe it's for serialization? In that case, if the JSON data container is emitted as part of the Annotation's JSON, that would make it easier to serialize and restore the custom data fields along with the rest of the Annotation's fields.

Also, there's no reason why you couldn't support both.

[tobrun]

@zestyping attaching an arbitrary java object won't be possible as the annotation plugin is backed by a geojson source, the data stored should follow the geojson rfc and as already indicated we need to be able to serialize that data. That said, option 2 is a viable solution to your issue.

[zestyping]

Okay, option 2 totally works! What API call is the right way to do this?