案例研究：在ImmobilienScout24 iOS App中使用Google Places

ImmobilienScout24应用程序是一款房地产搜索应用程序，可让用户根据自己的需求找到房屋。 我们的应用程序中最常用的参数之一是位置。 无论是用户搜索房屋的位置还是博览会本身的地址：地理位置和地址在我们的应用程序中得到了广泛使用。

该应用程序中还包含一项功能，可帮助用户重新定位或从他们的旧位置移到新位置。 此功能允许用户输入其当前和新地址以及一些其他相关数据，然后将其发送到后端进行进一步处理。 此后，用户从多家搬迁公司获得报价。

当我们考虑重新设计该流程时，其想法是在客户端实施地址验证。 这是为了减轻服务器的负担，并发送更多合格的潜在客户。 长期从事该行业，我们公司开发了强大的位置搜索后端。 但这对我们没有帮助，因为此数据库仅集中在DACH区域内的地址/位置。 对于我们的用例，唯一可行的选择似乎是Google Places API。 本文旨在强调我们在实施此方面的经验。

用例

用户输入所选国家/地区的个人识别码（可以是德国，奥地利或瑞士）。 该PIN码需要针对国家/地区进行验证，如果有效，则以自动完成格式输入街道名称和门牌号码。 最后，街道名称，门牌号码，密码和国家/地区的值将一起验证。

最初的努力

我们的想法是使用iOS版Places SDK，因为最初的要求是地址自动填充。 SDK提供了各种服务，例如有关当前地点的详细信息，地点的照片，以及自动完成功能。 开箱即用的实现的优点是它附带的内置UI。 该组件负责所有请求和结果，没有任何内容可供我们修改。

这对于使用用户当前位置的直接实现非常有用，而无需对请求或位置本身进行任何调整。 但这对我们来说是一个很大的缺点。 除非实现采用表数据源的形式，否则此UI组件的设计不能进行任何更改。

由于我们要对与用户当前位置不同的地址使用自动完成功能，因此内置的UI无法控制将结果限制在预定义的地区或国家/地区。 这导致来自世界各地的自动完成结果； 当用户在德国搜索商品时。

即使在请求中指定了国家/地区，大多数结果还是位于美国的地址。 最重要的是，返回的结果只有五个项目。 尝试几次在德国获得有效结果的机会非常渺茫。 这将导致用户在响应中收到有效结果之前先键入大部分地址。

经过几次试验和错误，我们决定为我们的应用程序使用Places API Web服务。 可以在我们这边修改位置详细信息，以达到我们希望的粒度。 使用Place Autocomplete API，我们可以发送输入地址，控制参数，例如国家/地区，所需的半径，语言以及可以预期的结果类型。 这对我们非常有效。

实作

在我们的功能中，地址验证分为三个部分：

• 验证码：此处，首先根据用户选择的国家/地区验证用户输入的验证码。 仅在用户输入完整的个人识别码后才发送请求。

https://maps.googleapis.com/maps/api/place/autocomplete/json?types=(regions)&components=country:de&key=&language=zh-CN&input=10243

通过此请求，将类型指定为“区域”以接收包含有效邮政编码的结果。 然后根据输入的密码和国家/地区验证结果，以获取该密码的“地点ID”。 然后，此id用于访问在下一步中使用的pin码区域的坐标值。

• 街道名称验证：这是一项自动完成功能，其中根据用户在上一步中输入的密码，向用户显示街道名称列表。 当用户键入街道名称时，该列表将更新。

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

此请求具有比上一个更多的参数。 在这里，我们添加了5km的半径，并且还发送了上一步中收到的坐标值。 这有助于过滤掉未提及的个人识别码中的值，从而为我们提供更多合格的结果。

• 完整的地址验证：这是最后一步，需要确保分别验证的地址片段在合并在一起时仍然有效。

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

该请求或多或少与第一个请求相似。 唯一的区别是使用“ type”参数。 这里我们使用“地址”类型，因为我们已经有了完整的地址。

结论

尽管一开始任务艰巨，但我们仍然能够找到适合我们的解决方案。 尽管不是100％的准确度，但它具有很高的准确率。 有时， 完整的地址验证步骤会正确验证不正确的地址，从而导致结果不明确。 这是因为API认为个人识别码值是街道名称的一部分。 这不是完美的，但是发生这种情况的可能性很小。

简而言之，为我们的功能实现Places API并使它以我们想要的方式工作是一种很好的学习经验。