1

当 Proximity Beacon API 首次发布时，我设想的用例是创建一个简化信标字段替换的系统，因为客户端检索的元数据（附件和键/值属性）与当前表示该数据的信标硬件是分开的（本质上是AdvertisedId）。

在我看来，附件和属性代表了信标的角色（巴士站 X、商店前门等），但可以根据需要将硬件换成该角色。这意味着如果信标死了并且必须更换，人们可以轻松地使用 APIAdvertisedId为相同的角色注册/激活新的，并停用/停用旧的（死）信标硬件。

我无法确定当前 API 是否真的可以使用此用例。注册时无法为信标指定名称（它会自动命名为其 AdvertisedId 的版本），并且AdvertisedId在后续更新中将被忽略（因此无法更改）。

我能说的最好的，“在现场替换信标”的唯一方法是激活一个新的信标并复制所有附件/属性/等。从旧实例。我是否误解了 API 中的关注点分离？是创建信标角色以在 API 之外进行管理的唯一方法吗？信标现场更换似乎是设计的核心租户。

4

1 回答 1

1

Proximity Beacon API 没有创建可能包含一个或多个硬件设备的“角色”或“逻辑信标”的概念——期望开发人员和类似的人自己做这件事。

好消息是这真的不是那么困难——复制数据也很简单。API 中的任何数据结构或信息位都不是非常复杂，因此在部署应用程序中复制它们只需一两行代码。

事实上，似乎信标注册数据的可能用例如此多样，而且很多，以至于 API 尽可能简单地允许所有这些用例。

于 2015-09-01T19:14:49.030 回答