Assigned
Status Update
Comments
di...@google.com <di...@google.com> #2
Thank you for reporting this issue. We have been able to reproduce it internally and we will be working on a fix. We will update the issue with any related news.
di...@google.com <di...@google.com> #3
This is working as intended and is documented here:
https://developers.google.com/places/ios-sdk/place-details
"GMSPlaceFieldPhoneNumber, GMSPlaceFieldWebsite, GMSPlaceFieldOpeningHours, and GMSPlaceFieldAddressComponents are not supported for GMSPlaceLikelihoodList place objects."
We are working on adding it here to the list of unsupported fields:
https://developers.google.com/places/ios-sdk/client-migration#find-place-likelihoods
I will keep this issue open until we fix this documentation bug. Again thank you for flagging this.
I you are interested in having this feature that returns all address components, please explain your use case.
"GMSPlaceFieldPhoneNumber, GMSPlaceFieldWebsite, GMSPlaceFieldOpeningHours, and GMSPlaceFieldAddressComponents are not supported for GMSPlaceLikelihoodList place objects."
We are working on adding it here to the list of unsupported fields:
I will keep this issue open until we fix this documentation bug. Again thank you for flagging this.
I you are interested in having this feature that returns all address components, please explain your use case.
sc...@gmail.com <sc...@gmail.com> #4
This seems like a pretty standard use case from the previous iterations of this API. I need to pull the user's current location and get the address for display but often do not need to display the complete address. The user generally knows the city and state they are in so displaying a partial address allows for a much cleaner UI/UX. While it appears that I can achieve the same effect by making two API calls one to get the likelihood list and another to get the place details, that seems like a drain on user resources and could negatively affect performance, especially in rural and semi-rural markets where mobile data is often slow. Based on the fact that the deprecated version of the API returned all of the standard details for a place, this seems less like a feature add than a regression.
Description
When calling findPlaceLikelihoodsFromCurrentLocation with the GMSPlaceField.addressComponents field an error is returned - Error while parsing 'fields' parameter: Unsupported field name 'address_components'. AddressComponents is not listed as an unsupported field in the documentation.
What should happen instead?
- List addressComponents as an unsupported field mask for findPlaceLikelihoodsFromCurrentLocation or:
- Return the addressComponents on the place likelihood when requested.
Steps to reproduce the problem:
1. Create fields like - let fields: GMSPlaceField = GMSPlaceField(rawValue: UInt(GMSPlaceField.name.rawValue) |
UInt(GMSPlaceField.placeID.rawValue) | UInt(GMSPlaceField.addressComponents.rawValue))!
2. Call GMSPlacesClient.shared().findPlaceLikelihoodsFromCurrentLocation(withPlaceFields: fields, callback: callback)
3. Record error
Operating system version:
Google Maps SDK for iOS version:
Google Places API for iOS version:
Hardware model:
-------------------------------------------------------------------
[1] You can fork