当Proximity Beacon API首次公布时，我想象的用例是创建一个系统，其中beacon 字段替换被简化，因为客户端检索的元数据（附件和键/值属性）与当前表示该数据的信标硬件（基本上是AdvertisedId）分开。
在我看来，附件和属性代表了信标的角色（Bus Stop X，Shop Front Door等），但硬件可以根据需要交换到该角色。这意味着如果信标死亡并且必须被替换，则可以轻松地使用API为同一角色注册/激活新的AdvertisedId，并停用/停用旧的（死的）信标硬件。
如果使用当前API实际可以使用此用例，我将无法解决问题。注册时无法为信标指定名称（它自动命名为其AdvertisedId的版本），并且在后续更新中忽略AdvertisedId（因此无法更改）。
我能说的最好，“在现场替换信标”的唯一方法是激活新信标并复制所有附件/属性/等。从旧的实例。我是否误解了API中关注点的分离？是创建信标角色以管理API之外的唯一方法吗？灯塔现场更换似乎是设计的核心租户。
答案 0 :(得分：1)
Proximity Beacon API没有创建可能包含一个或多个硬件设备的“角色”或“逻辑信标”的概念 - 期望开发人员等自己会这样做。
好消息是，这并不是那么困难 - 复制数据也非常简单。 API中的数据结构或信息位都不是非常复杂，因此复制它们只是部署应用程序中的一行或两行代码。
事实上，似乎信标注册数据的可能用例是如此多样化，并且许多API只是尽可能简单地保留所有这些用例。