Case Study: Using Google Places in ImmobilienScout24 iOS App

ImmobilienScout24 app is a real estate search app that allows the user to find a home based on their needs. One of the most frequently used parameter in our app is the location. Be it the location in which the user is searching for the houses or the addresses of the exposés themselves: geo location and addresses are widely used in our app.

Nestled in this app is also a feature that helps the user with relocation or moving from their old place to the new one. This feature allows the user to enter their current and new address and a few other relevant data, which is then sent to the backend for further processing. After that, the user gets offers from several relocation companies.

When we were thinking of redesign this flow, the idea was to implement the validation of the addresses on the client side. This was to reduce the burden on the server and to have more qualified leads to be sent. Being in the industry for a long time, our company has developed a strong location search backend. But that wasn’t helpful for us, since this database concentrates only on addresses/locations within the DACH region. The only viable option seemed to be Google Places API for our use case. This article aims to highlight our experience in implementing this.

Use case

The user enters a pin code for the selected country (can be Germany, Austria or Switzerland). This pin code needs to be validated against the country, and if it is valid, street name and house number are then entered in an autocomplete format. As a final step, the values of the street name, house number, pin code and the country are validated together.

Initial Effort

Our idea was to use the Places SDK for iOS, as the initial requirement was for address autocompletion. The SDK offers various services like details about current place, photos of a place, and of course, autocomplete. The advantage with the out-of-box implementation is the built-in UI that comes with it. This component takes care of all the requests and results, nothing is exposed for us to modify.

This is great for a direct implementation using the user’s current location, without any adjustments to the requests or the location itself. But it is a big disadvantage in our case. There cannot be any change in the design of this UI component, unless the implementation is in the form of a table data source.

Since we want to use the autocomplete for an address that is different than the user’s current location, the built-in UI provides us no control to restrict the results to a predefined locality or even a country. This leads to autocomplete results from all over the world; when the user is searching for something in Germany.

Even with the country specified in the request, a majority of the results are US based addresses. On top of this, the returned results have only five items. The chances of getting a valid result in Germany, with a few tries, are very slim. This would lead to the user typing out most of the address before a valid result is received in the response.

After several trials and errors, we settled on using Places API Web Services for our application. The location details can be modified on our side, to the granularity we wish to have. With the Place Autocomplete API, we can send the input address, control the parameters such as the country, a radius if needed, language, and type of result that can be expected. This worked out remarkably well for us.

Implementation

In our feature, the address validation is split into three parts:

• Pin code validation: Here, the pin code entered by the user is first validated against the country they have selected. The request is sent only after the user has entered the complete pin code.

https://maps.googleapis.com/maps/api/place/autocomplete/json?types=(regions)&components=country:de&key=<GoogleAPIKey>&language=en&input=10243

With this request, the type is specified as “regions” to receive results which contain a valid postal code. The results are then verified against the input pin code and country to retrieve a “Place ID” for the pin code. This id is then used to access the coordinate values of the pin code area which is used in the next step.

• Street name validation: This is an autocomplete feature where the user is shown a list of street names based on the pin code they entered in the previous step. The list is updated as and when the user types the street name.

https://maps.googleapis.com/maps/api/place/autocomplete/json?location=52.514744,13.4385605&types=address& components=country:de&key<GoogleAPIKey>& strictbounds&input=A&language=en&radius=5000

This request has more parameters than the previous one. Here, we add a radius of 5km and also send the coordinate values received in the previous step. This helps to filter out the values that are not in the mentioned pin code, thereby giving us more qualified results.

• Complete address validation: This final step is required to ensure that the pieces of addresses that were validated separately, are still valid when merged together.

https://maps.googleapis.com/maps/api/place/autocomplete/json?types=address&components=country:de&key=<GoogleAPIKey>&language=en&input=Andreasstra%C3%9Fe+10243

This request is more or less similar to the first one. The only difference is with the “type” parameter. Here we use “address” type since we already have the complete address.

Conclusion

Though the task seemed daunting in the beginning, we were able to find a suitable solution that works for us. It has a high rate of accuracy, though it is not a 100% accurate. Sometimes, the complete address validation step validates incorrect addresses correctly, resulting in ambiguous results. This is because the API considers the pin code value to be a part of the street name. This is not perfect, but chances of that happening are low.

In short, it was quite a learning experience to implement the Places API for our feature and make it work the way we want to.