Routable points support for services-geocoding

[DzmitryFomchyn]

Add routable points support for services-geocoding

[codecov]

Codecov Report

Merging #1522 (1ae380d) into main (d112384) will increase coverage by 0.01%.
The diff coverage is 83.33%.

❗ Current head 1ae380d differs from pull request most recent head a9cdf39. Consider uploading reports for the commit a9cdf39 to get more accurate results

@@             Coverage Diff              @@
##               main    #1522      +/-   ##
============================================
+ Coverage     77.25%   77.26%   +0.01%     
- Complexity      952      957       +5     
============================================
  Files           130      132       +2     
  Lines          4080     4091      +11     
  Branches        587      588       +1     
============================================
+ Hits           3152     3161       +9     
- Misses          678      679       +1     
- Partials        250      251       +1     

Impacted Files	Coverage Δ
.../mapbox/api/geocoding/v5/models/CarmenContext.java	33.33% <ø> (ø)
.../mapbox/api/geocoding/v5/models/CarmenFeature.java	82.14% <ø> (ø)
.../mapbox/api/geocoding/v5/models/RoutablePoint.java	71.42% <71.42%> (ø)
...a/com/mapbox/api/geocoding/v5/MapboxGeocoding.java	85.84% <100.00%> (+0.12%)	⬆️
...mapbox/api/geocoding/v5/models/RoutablePoints.java	100.00% <100.00%> (ø)

[Guardiola31337]

Left some comments.

[Guardiola31337]

Is this really nullable? I mean, what I'd expect is RoutablePoints to be nullable but If they're not, any RoutablePoint from the list to have valid values. Does that make sense?

[kalbaxa]

@Guardiola31337 Do you mean by duplicating e.g. the rooftop location in RoutablePoints? If yes, I disagree.

I assume the correct distinction would be to leave RoutablePoints null if there are none and let the app logic decide how to behave in that case (e.g. fallback to original location). Otherwise it's becoming ambiguous whether the data is actually available for the specific search result.

[DzmitryFomchyn]

@Guardiola31337 in addition to what @kalbaxa said, I think it's better to leave it as nullable because all the service-geocoder relies on AutoValue/GSON serialisation/deserialisation. If we declare any field as non-nullable and for some reason backend don't send the value, the SDK will crash. I don't want this. I think it's better to check for null on customer's side and use alternative fallback. Also, nullable fields are consistent with the current approach.

[Guardiola31337]

@kalbaxa What I meant was that routable points could be null (that's totally fine) but if the server emits a routable point, I would expect not to be null (having null fields), that's the contract I'd expect from the backend.

[Guardiola31337]

@DzmitryFomchyn IMO errors in the backend should fail-fast, this approach would hide this type of issues as they'd go unnoticed.

[DzmitryFomchyn]

A can agree with that, but we should also be consistent here. All the current code relies on nullability, it won't make any better if we make one field as non-null while everything else remain nullable. Given everything that's written above, I think we should leave as is now and discuss another approach in case of SDK refactoring, if it happen. More likely, service-geocoder will be deprecated soon.

[dzinad]

If we declare any field as non-nullable and for some reason backend don't send the value, the SDK will crash. I don't want this.

+++

Event if it's not an error on the backend side, it can be a logic change. For example, we accidentally made waypoints nullable but that played well because after some time they did become nullable because a case was introduced that they can be returned in a different response level.

[LukasPaczos]

it can be a logic change

A logic change like this should mean a major version upgrade of an endpoint. All customers (not only Nav SDK) would be impacted by such an intentional change.

[dzinad]

Not necessarily. With waypoints they wouldn't (and weren't). Because it depends on a new request parameter which falls back to old behaviour.

[LukasPaczos]

We would have to provide backwards compatibility if that wasn't the case (either on backend or mapbox-java level). We were lucky and needed less work for that specific situation but that shouldn't be the reason to make contracts less strict going forward.

[kalbaxa]

When we align with @DzmitryFomchyn and @Guardiola31337 on the routable points approach, I'm good with the merge.

[Guardiola31337]

Discussed internally, let's ship as is as services-geocoding is going to be deprecated soon.

cc @DzmitryFomchyn @kalbaxa