support for multiple languages in geocoding model objects

[osana]

This PR will resolve #446

There were two parts to this PR:

• Geocoding module will not depend on AutoValue. This makes it easier to do json parsing customization.
• Add custom parsing of fileds like:
  text_{language} fields into a Map (lang -> text string in that language)

Added tests.

[LukasPaczos]

Looks like the adapter always uses String.class, does it have to be lazily initialized in each method instead once in the class field?

[osana]

This is the part that I was not sure about.
The code is extracted from generated AutoValue.
There is an instance variable: stringAdapter which will be Lazily initialized.
I am not sure why there is a need to keep a local copy of this. stringAdapter

Decided to keep it as is. I think I should address that part separately.

[LukasPaczos]

The passed collections references seem to always be nulls and are initialized only here, do we need to pass them in the first place then?

[osana]

I believe readLanguages will be called multiple times. In case of CarmenContext json could look like:

"context": [
{
"id": "country.9053006287256050",
"short_code": "us",
"wikidata": "Q30",
"text_ru": "Соединённые Штаты Америки",
"language_ru": "ru",
"text": "Соединённые Штаты Америки",
"language": "ru",
"text_fr": "États-Unis",
"language_fr": "fr"
}
]
}

so it will be called to read:
"language_ru": "ru",
then to read:
"language_fr": "fr"

[LukasPaczos]

Will it be called multiple times with the same list as an argument?

[osana]

Yes. JsonReader is parsing each key/value as they come in. We cannot get all the language_* pairs (and similarly for other pairs and JsonWriter). I believe TypeAdapters are more efficient then JsonSerializer/Deserializer as do not have an intermediate parsed state. Because of that though it is a bit more restrictive.

[LukasPaczos]

What's the advantage of making Feature/FeatureCollection serializable now? If we'd like to make them serializable in general, why not make GeoJson implement Serializable?

[osana]

I noticed inconsistency that felt odd, so decided to add it there. I think you are right: we can just add Serializable to GeoJson. Will experiment

[osana]

I decide to remove these changes from this PR.
I think your suggestion is a valid one and should be addressed in a separate PR.

[LukasPaczos]

Whoops, didn't mean to approve, only comment.

[langsmith]

cc @kbauhaus as fyi that this is moving

[LukasPaczos]

I think this PR is functionally fine, but the style is off because it comes from generated code. We're going to need to maintain it manually now, so it should be cleaned up before it's merged to master in my opinion.

[osana]

Thank you for 👀 @LukasPaczos
Would love to hear your suggestions.

[LukasPaczos]

I'm thinking about the left comments like unnecessary local object copies, lazy inits, or null checks.

[osana]

Lazy init for TypeAdapter does not make sense - agree with you.
I do not understand why the generated code had a double assignment.
I can get rid of those and then see what happens.

I do think that some TypeAdapters should be lazily initialized as those fields are rarely used like foBoundingBox, etc.

[stale]

This pull request has been automatically detected as stale because it has not had recent activity and will be archived. Thank you for your contributions.

[stale]

This pull request has been automatically detected as stale because it has not had recent activity and will be archived. Thank you for your contributions.

[stale]

This pull request has been automatically detected as stale because it has not had recent activity and will be archived. Thank you for your contributions.

[stale]

This pull request has been automatically detected as stale because it has not had recent activity and will be archived. Thank you for your contributions.